الگوی Outbox و داستان یک راهکار هوشمندانه در پستگرس
https://dev.to/msdousti/postgresql-outbox-pattern-revamped-part-1-3lai/
🎯 الگوی Outbox چیست؟
در یک فروشگاه آنلاین، ثبت سفارش باید چند کار را انجام دهد:
✅ذخیره در پایگاه داده
✅ارسال ایمیل تأیید
✅به‌روزرسانی موجودی
✅اطلاع به واحد ارسال
این اکشن‌ها به بروکرهایی مثل Kafka ارسال می‌شوند تا هر واحد کار خود را انجام دهد.
❓ اگر ارسال پیام به بروکر با خطا مواجه شود؟
Outbox وارد می‌شود! سفارش در پایگاه داده ذخیره شده و یک پیام در جدول Outbox ثبت می‌شود. یک سرویس جداگانه پیام‌ها را خوانده و به بروکر می‌فرستد. در صورت خطا، پیام در جدول باقی می‌ماند تا دوباره برای پردازش ارسال شود اما ...
🔍 چالش: حجم بالای داده‌ها
با افزایش پیام‌ها در Outbox:
⚠️کوئری‌های خواندن پیام‌های منتشرنشده کند می‌شوند.
⚠️ایندکس‌ها به دلیل آپدیت‌های مکرر غیربهینه می‌شوند.
⚠️مصرف منابع سیستم افزایش می‌یابد.
💡 راه‌حل: پارتیشن‌بندی هوشمند
صادق دوستی پیشنهاد می‌کند جدول Outbox را به دو پارتیشن تقسیم کنیم:
outbox_unpublished: پیام‌های منتشرنشده (published_at IS NULL)
outbox_published: پیام‌های منتشرشده (published_at NOT NULL)
با این کار، پیام‌های جدید به outbox_unpublished می‌روند و پس از انتشار، به‌صورت خودکار به outbox_published منتقل می‌شوند. بنابراین کوئری‌ها فقط روی پارتیشن سبک‌تر اجرا می‌شوند.
🎉 مزایا:
✅سرعت بالا: کوئری‌ها روی پارتیشن کوچک‌تر اجرا می‌شوند.
✅مدیریت آسان: حذف پیام‌های قدیمی با TRUNCATE سریع است.
✅بهینه‌سازی منابع: ایندکس‌ها کوچک و کارآمد می‌مانند.
🏁 جمع‌بندی
الگوی Outbox برای هماهنگی سیستم‌های توزیع‌شده عالی است، اما پیاده‌سازی نادرست آن مشکل‌ساز می‌شود. پارتیشن‌بندی هوشمند صادق دوستی این الگو را بهینه‌تر و سریع‌تر می‌کند.
🔗 برای جزئیات بیشتر، حتا مقاله صادق در Dev.to را بخوانید!
#outbox #postgres #performance #database #dataengineering
#مهندسی_داده
اخیراً مقاله‌ای از صادق دوستی در Dev.to خواندم که نشان داد با تجربه و تسلط، می‌توان برای چالش‌های بزرگ، راه‌حل‌هایی هوشمندانه و ساده پیدا کرد. یعنی در دنیای فنی، گاهی غرق پیچیدگی‌ها می‌شویم و راه‌حل‌های ساده اما عمیق را نادیده می‌گیریم. این پست ادای دینی است به صادق عزیز Sadeq Dousti و مقالات ارزشمندش، و مروری بر مشکل پیاده‌سازی الگوی Outbox با PostgreSQL در حجم بالای داده و راه‌حلی خلاقانه برای آن.
https://dev.to/msdousti/postgresql-outbox-pattern-revamped-part-1-3lai/
🎯 الگوی Outbox چیست؟
در یک فروشگاه آنلاین، ثبت سفارش باید چند کار را انجام دهد:
✅ذخیره در پایگاه داده
✅ارسال ایمیل تأیید
✅به‌روزرسانی موجودی
✅اطلاع به واحد ارسال
این اکشن‌ها به بروکرهایی مثل Kafka ارسال می‌شوند تا هر واحد کار خود را انجام دهد.
❓ اگر ارسال پیام به بروکر با خطا مواجه شود؟
Outbox وارد می‌شود! سفارش در پایگاه داده ذخیره شده و یک پیام در جدول Outbox ثبت می‌شود. یک سرویس جداگانه پیام‌ها را خوانده و به بروکر می‌فرستد. در صورت خطا، پیام در جدول باقی می‌ماند تا دوباره برای پردازش ارسال شود اما ...
🔍 چالش: حجم بالای داده‌ها
با افزایش پیام‌ها در Outbox:
⚠️کوئری‌های خواندن پیام‌های منتشرنشده کند می‌شوند.
⚠️ایندکس‌ها به دلیل آپدیت‌های مکرر غیربهینه می‌شوند.
⚠️مصرف منابع سیستم افزایش می‌یابد.
💡 راه‌حل: پارتیشن‌بندی هوشمند
صادق دوستی پیشنهاد می‌کند جدول Outbox را به دو پارتیشن تقسیم کنیم:
outbox_unpublished: پیام‌های منتشرنشده (published_at IS NULL)
outbox_published: پیام‌های منتشرشده (published_at NOT NULL)
با این کار، پیام‌های جدید به outbox_unpublished می‌روند و پس از انتشار، به‌صورت خودکار به outbox_published منتقل می‌شوند. بنابراین کوئری‌ها فقط روی پارتیشن سبک‌تر اجرا می‌شوند.
🎉 مزایا:
✅سرعت بالا: کوئری‌ها روی پارتیشن کوچک‌تر اجرا می‌شوند.
✅مدیریت آسان: حذف پیام‌های قدیمی با TRUNCATE سریع است.
✅بهینه‌سازی منابع: ایندکس‌ها کوچک و کارآمد می‌مانند.
🏁 جمع‌بندی
الگوی Outbox برای هماهنگی سیستم‌های توزیع‌شده عالی است، اما پیاده‌سازی نادرست آن مشکل‌ساز می‌شود. پارتیشن‌بندی هوشمند صادق دوستی این الگو را بهینه‌تر و سریع‌تر می‌کند.
🔗 برای جزئیات بیشتر، حتا مقاله صادق در Dev.to را بخوانید!
#outbox #postgres #performance #database #dataengineering
#مهندسی_داده
👍1