pg_durable: اجرای پایدار کارها داخل خود PostgreSQL
خلاصهٔ کاملتر
تو این صفحه، مایکروسافت افزونهٔ pg_durable رو معرفی میکنه که هدفش اینه الگوی «اجرای پایدار» (durable execution) رو بیاره داخل خود PostgreSQL. ایدهٔ اصلی اینه: کارهای پسزمینهٔ طولانی و خطاپذیر رو، که معمولاً با چسبوندن کرونجاب و وُرکر و صف و جدول وضعیت به هم قابلاعتماد میکردی، حالا مستقیم با SQL داخل دیتابیس تعریف میکنی و خود Postgres هر قدم رو چکپوینت میکنه.
به گفتهٔ مایکروسافت، یه تابع pg_durable در واقع یه گراف از قدمهای SQL هست که Postgres اجراشون میکنه و بینشون چکپوینت میذاره. اگه دیتابیس کرش کنه، ریاستارت بشه یا یه قدم خطا بده، اجرا از آخرین چکپوینت پایدار ادامه پیدا میکنه؛ یعنی مجبور نیستی کاری که قبلاً موفق انجام شده رو دوباره از اول بزنی یا حالت رو دستی بازسازی کنی.
نحوهٔ کارش اینه که ورکفلو رو با عملگرهای ترکیبپذیری مثل ~> و |=> میسازی، با df.start() شروعش میکنی و یه instance ID میگیری، بعد رانتایم هر قدم رو پایدار اجرا میکنه و در همین حین میتونی وضعیت و نتیجه رو از خود جدولهای Postgres مثل df.instances کوئری بگیری. یه نمونهٔ ساده از همین DSL تو صفحه اومده:
SELECT df.start(
'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
~> 'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);این افزونه چندتا کاربرد مشخص رو هدف گرفته: پایپلاینهای embedding برداری (chunk کردن، صدا زدن API و درج تو pgvector)، پایپلاینهای ingest، نگهداری زمانبندیشده با مرحلهٔ تأیید، و فناوت موازی که چند کوئری مستقل رو همزمان اجرا میکنه و بعد نتایج رو join میکنه. به جاش، برای کاری که فقط یه INSERT ... SELECT سادهست یا نیاز به پاسخ همزمان زیرمیلیثانیه داره، میگن مناسب نیست.
از نظر زیرساخت، pg_durable به صورت یه افزونهٔ معمولی Postgres نصب میشه (با CREATE EXTENSION pg_durable)، یه background worker ثبت میکنه و هیچ سرویس بیرونی مثل Redis یا Temporal لازم نداره. زیر کاپوتش روی دو کتابخونهٔ Rust به اسم duroxide (رانتایم ارکستریشن با replay و چکپوینت) و duroxide-pg (نگهداری حالت تو خود Postgres) سواره. نکتهٔ امنیتیش هم اینه که نصب افزونه بهطور پیشفرض هیچ دسترسیای به PUBLIC نمیده و با Row-Level Security هر کاربر فقط instanceهای خودشو میبینه؛ فقط رول background worker باید superuser باشه چون برای مدیریت کار همه، RLS رو دور میزنه.
نویسنده تأکید میکنه که این مدل عمداً «SQL-شکل» هست؛ یعنی اگه یه قدم به کد دلخواه یا کنترلفلوی پیچیدهٔ in-memory نیاز داشته باشه، یا باید تو یه تابع SQL بپیچیش یا پشت یه endpoint از نوع HTTP بذاریش. این پروژه فعلاً تو فاز Preview هست و تو سرویس ابری جدید مایکروسافت یعنی Azure HorizonDB هم با همین افزونه داخلش ارائه میشه.
نکات کلیدی:
- ورکفلوهای پایدار و خطاپذیر رو مستقیم با SQL داخل Postgres تعریف میکنی، بدون سرویس جانبی.
- بعد از کرش یا ریاستارت، اجرا از آخرین چکپوینت ادامه پیدا میکنه نه از اول.
- جای کرونجاب و وُرکر و صف و جدول وضعیت رو میگیره؛ وضعیت کار از جدولهایی مثل df.instances قابلمشاهدهست.
- روی دو کتابخونهٔ Rust به اسم duroxide و duroxide-pg ساخته شده و فعلاً تو فاز Preview هست.




