دیتابیس PostgreSQL قابلیت Full-Text search داره که خیلی وقت ها میتونه نیازمندی هارو پوشش بده و لازم نباشه سرویسی مثل elasticsearch رو بصورت مجزا استفاده کرد. چون نگهداری و مدیریت هر سرویس جدید هم هزینه نیروی انسانی داره و هم هزینه زمانی و انتقال دانش و کسب تجربه و غیره.
این مقاله قابلیت های دیتابیس PostgreSQL برای Full-Text search رو بیان میکنه
Create an advanced search engine with PostgreSQL
https://xata.io/blog/postgres-full-text-search-engine
#gocasts
#database #postgres
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
این مقاله قابلیت های دیتابیس PostgreSQL برای Full-Text search رو بیان میکنه
Create an advanced search engine with PostgreSQL
https://xata.io/blog/postgres-full-text-search-engine
#gocasts
#database #postgres
➖➖➖➖➖➖➖➖
🕊 @gopher_academy
👍4❤2🕊2🔥1🍾1
🔵 عنوان مقاله
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد چگونه با الگوی Outbox در کنار Go و Postgres، مشکل دو‌نوشتن را حل کنیم و ارسال رویدادها را قابل‌اعتماد کنیم. ایده اصلی این است که در یک تراکنش واحد، هم تغییرات دامنه و هم رکورد مربوط به رویداد در جدول outbox ذخیره شود تا یا هر دو باهم انجام شوند یا هیچ‌کدام. سپس یک پردازشگر پس‌زمینه رکوردهای معوق را با SELECT … FOR UPDATE SKIP LOCKED برداشته، آن‌ها را به سامانه‌ای مثل Kafka یا RabbitMQ یا یک وب‌هوک ارسال می‌کند و وضعیت‌شان را به processed تغییر می‌دهد.
نکات کلیدی پیاده‌سازی شامل: طراحی جدول outbox با فیلدهایی مانند type، payload (معمولاً JSON)، status، retry_count و زمان‌ها؛ پوشش هر دو عملیات (نوشتن دامنه و درج outbox) در یک تراکنش؛ پیاده‌سازی worker در Go برای برداشت دسته‌ای، ارسال، ثبت موفقیت/خطا و بازآزمایی با backoff؛ تکیه بر تحویل حداقل-یک‌بار همراه با مصرف‌کننده‌های idempotent برای مدیریت تکرار؛ و پایش شاخص‌هایی مثل تأخیر برداشت و نرخ شکست. برای بهینگی عملیاتی، پاکسازی دوره‌ای رکوردهای پردازش‌شده، ایندکس‌گذاری مناسب، رسیدگی به پیام‌های مشکل‌دار (dead-letter) و حفظ ترتیب رویدادها در سطح aggregate ضروری است. ترکیب polling با LISTEN/NOTIFY در Postgres می‌تواند زمان واکنش را بهتر کند. نتیجه، راهکاری ساده و مقیاس‌پذیر است که بدون تراکنش‌های توزیع‌شده، قابلیت اتکا را در معماری رویدادمحور فراهم می‌کند.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Messaging #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/174422/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** این مقاله توضیح می‌دهد چگونه با الگوی Outbox در کنار Go و Postgres، مشکل دو‌نوشتن را حل کنیم و ارسال رویدادها را قابل‌اعتماد کنیم. ایده اصلی این است که در یک تراکنش واحد، هم تغییرات دامنه و هم رکورد مربوط به رویداد در جدول outbox ذخیره شود تا یا هر دو باهم انجام شوند یا هیچ‌کدام. سپس یک پردازشگر پس‌زمینه رکوردهای معوق را با SELECT … FOR UPDATE SKIP LOCKED برداشته، آن‌ها را به سامانه‌ای مثل Kafka یا RabbitMQ یا یک وب‌هوک ارسال می‌کند و وضعیت‌شان را به processed تغییر می‌دهد.
نکات کلیدی پیاده‌سازی شامل: طراحی جدول outbox با فیلدهایی مانند type، payload (معمولاً JSON)، status، retry_count و زمان‌ها؛ پوشش هر دو عملیات (نوشتن دامنه و درج outbox) در یک تراکنش؛ پیاده‌سازی worker در Go برای برداشت دسته‌ای، ارسال، ثبت موفقیت/خطا و بازآزمایی با backoff؛ تکیه بر تحویل حداقل-یک‌بار همراه با مصرف‌کننده‌های idempotent برای مدیریت تکرار؛ و پایش شاخص‌هایی مثل تأخیر برداشت و نرخ شکست. برای بهینگی عملیاتی، پاکسازی دوره‌ای رکوردهای پردازش‌شده، ایندکس‌گذاری مناسب، رسیدگی به پیام‌های مشکل‌دار (dead-letter) و حفظ ترتیب رویدادها در سطح aggregate ضروری است. ترکیب polling با LISTEN/NOTIFY در Postgres می‌تواند زمان واکنش را بهتر کند. نتیجه، راهکاری ساده و مقیاس‌پذیر است که بدون تراکنش‌های توزیع‌شده، قابلیت اتکا را در معماری رویدادمحور فراهم می‌کند.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Messaging #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/174422/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Medium
How to implement the Outbox pattern in Go and Postgres
I was at a ContainerDays conference recently and attended a great talk from Nikolay Kuznetsov about the Outbox pattern and resilient system…
❤2
🔵 عنوان مقاله
PG Back Web 0.5: A Postgres Backup System with Web Interface
🟢 خلاصه مقاله:
** PG Back Web 0.5 یک ابزار مبتنی بر Go برای مدیریت پشتیبان‌گیری‌های Postgres از طریق یک رابط وب ساده و کاربرپسند است. این برنامه امکان زمان‌بندی پشتیبان‌ها، پایش وضعیت و مشاهده تاریخچه را فراهم می‌کند و با webhooks می‌تواند اعلان‌ها را به سامانه‌های بیرونی ارسال کند. استقرار آن به‌صورت Docker image بسیار ساده است و در نسخه 0.5 پشتیبانی از Postgres 18 نیز اضافه شده تا با آخرین نسخه Postgres سازگار باشد.
#Postgres #Backup #Go #Docker #Database #DevOps #Webhooks #Monitoring
🟣لینک مقاله:
https://golangweekly.com/link/175372/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
PG Back Web 0.5: A Postgres Backup System with Web Interface
🟢 خلاصه مقاله:
** PG Back Web 0.5 یک ابزار مبتنی بر Go برای مدیریت پشتیبان‌گیری‌های Postgres از طریق یک رابط وب ساده و کاربرپسند است. این برنامه امکان زمان‌بندی پشتیبان‌ها، پایش وضعیت و مشاهده تاریخچه را فراهم می‌کند و با webhooks می‌تواند اعلان‌ها را به سامانه‌های بیرونی ارسال کند. استقرار آن به‌صورت Docker image بسیار ساده است و در نسخه 0.5 پشتیبانی از Postgres 18 نیز اضافه شده تا با آخرین نسخه Postgres سازگار باشد.
#Postgres #Backup #Go #Docker #Database #DevOps #Webhooks #Monitoring
🟣لینک مقاله:
https://golangweekly.com/link/175372/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - eduardolat/pgbackweb: 🐘 Effortless PostgreSQL backups with a user-friendly web interface! 🌐💾
🐘 Effortless PostgreSQL backups with a user-friendly web interface! 🌐💾 - eduardolat/pgbackweb
❤1
Forwarded from Database Labdon
🔵 عنوان مقاله
Did You Know Postgres Tables are Limited to 1,600 Columns?
🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.
#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176989/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Did You Know Postgres Tables are Limited to 1,600 Columns?
🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.
#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/176989/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Data Bene
Did you know? Tables in PostgreSQL are limited to 1,600 columns
It's a hard-coded limit in Postgres for tables to not exceed 1,600 columns. Let's test all the ways you can reach that limit, and explore how to address the situation when you reach this limit unexpectedly.