LISTEN/NOTIFY پستگرس هم مقیاس‌پذیره
خلاصهٔ کامل‌تر
این مقاله از تیم DBOS به یه ادعای معروف جواب می‌ده که می‌گفت LISTEN/NOTIFY پستگرس مقیاس‌پذیر نیست. نویسنده می‌گه این ادعا کاملاً غلط نیست: NOTIFY رفتار غیرشهودی و مستندنشده‌ای داره، ولی «رفتار غیرشهودی» با «مقیاس‌ناپذیر» فرق داره. هدفشون اینه که با همین ابزار، استریم‌های کم‌تأخیر و بادوام رو روی پستگرس بسازن.
طراحی پایه ساده‌ست: یه جدول streams که هر تکه از استریم (مثلاً یه توکنِ جواب LLM) یه ردیف جدیده. سخت‌ترش خوندنه، چون نمی‌دونی تکهٔ بعدی کِی می‌رسه. سرکشیِ مداوم (polling) خوب جواب نمی‌ده؛ فاصلهٔ زیاد تأخیر رو بالا می‌بره و فاصلهٔ کم دیتابیس رو خفه می‌کنه. راه بهتر LISTEN/NOTIFY ئه که خواننده‌ها منتظر می‌مونن و به‌محض رسیدن دادهٔ جدید بیدار می‌شن.
ولی پیاده‌سازی اولیه‌شون که با یه trigger روی هر نوشتن NOTIFY می‌فرستاد، بیشتر از ۲٫۹ هزار نوشتن در ثانیه بالا نمی‌رفت، اونم بدون اینکه CPU یا دیسک پستگرس پر شه. به گفتهٔ نویسنده، علتش یه قفل انحصاری سراسریه که پستگرس موقع commit هر تراکنشِ دارای NOTIFY می‌گیره. این قفل لازمه چون پستگرس تضمین می‌کنه اعلان‌ها به ترتیب commit فرستاده می‌شن، پس commitها رو سریالی می‌کنه و اجازه نمی‌ده group commit کار کنه.
کلید حل مسئله اینه که تو استریم‌ها، خودِ اعلان منبع حقیقت نیست؛ فقط به خواننده تلنگر می‌زنه که بره جدول رو چک کنه. پس لازم نیست اعلان‌ها کاملاً مرتب یا بادوام باشن. تیم DBOS اعلان‌ها رو تو حافظه بافر می‌کنه و دوره‌ای تو یه تراکنش دسته‌ای فلاش می‌کنه، جوری که قفل سراسری فقط موقع فلاش گرفته شه نه برای تک‌تک نوشتن‌ها. برای اینکه کرش‌کردنِ پروسه باعث گم‌شدن اعلان نشه، خواننده‌ها هرازگاهی دیتابیس رو هم به‌عنوان fallback چک می‌کنن.
نتیجه چشمگیر بوده: تا ۶۰ هزار نوشتن در ثانیه (۲۰ برابر قبل) با تأخیر ۱۵ تا ۱۰۰ میلی‌ثانیه. این بار برخلاف قبل، CPU پستگرس کامل مصرف میشه، یعنی دیتابیس واقعاً اشباع شده نه اینکه پشت قفل گیر کرده باشه. نویسنده اشاره می‌کنه یه patch پستگرس (برای نسخهٔ ۱۹) هم هست، ولی اون این گلوگاه رو حل نمی‌کنه و فقط حالت خاصِ چند کاناله رو بهینه می‌کنه.
نکات کلیدی:
- بدنامیِ مقیاس‌ناپذیری LISTEN/NOTIFY از یه قفل انحصاری سراسری موقع commit میاد
- این قفل ترتیب اعلان‌ها رو تضمین می‌کنه ولی commitها رو سریالی و group commit رو بی‌اثر می‌کنه
- چون اعلان فقط تلنگره و منبع حقیقت نیست، میشه بافر و دسته‌ای فلاشش کرد
- خواننده‌ها برای جبران اعلان‌های گم‌شده، دیتابیس رو دوره‌ای هم چک می‌کنن
- نتیجه: ۶۰ هزار نوشتن در ثانیه با تأخیر چند ده میلی‌ثانیه‌ای روی یه سرور
