اگر دیتابیس شما در مواجهه با پرسوجوهای پیچیده کند میشود، شاید راهکار نه در تغییر سختافزار، بلکه در جایگزینی مغز متفکرِ برنامهریز باشد. یک مدل زبانی کوچک با ۴ میلیارد پارامتر توانست تأخیر اجرای دستورات در یکی از محبوبترین دیتابیسهای جهان را نزدیک به ۴۵٪ کاهش دهد.
به نقل از گزارش فنی روهان بانسال (Rohan Bansal)، مدل Qwen 4B توانست در مقایسه با برنامههای پیشفرض Postgres، تأخیر را ۴۴.۷٪ کم کند. این نتیجه ثابت میکند که حتی مدلهای کوچک، اگر سیگنال پاداش دقیقی دریافت کنند، میتوانند از دههها تجربه مهندسی در الگوریتمهای سختافزاری پیشی بگیرند.
بهینهسازهای دیتابیس سالهاست که با مسئله «ترتیب اتصال» (Join Ordering) دستوپنجه نرم میکنند. در مطالعهای که در سال ۲۰۱۵ توسط ویکتور لیس (Viktor Leis) و همکارانش انجام شد — و بانسال یک دهه بعد آن را بازتولید کرد — محققان دریافتند که بهینهسازهای تجاری و متنباز بهطور مداوم در پرسوجوهای پیچیده، تصمیمات غیربهینهای میگیرند. دلیل این شکست فنی این است که یافتن ترتیب ایدهآل برای اتصال ۱۰ جدول، یک مسئله NP-hard است؛ یعنی تعداد احتمالات بهقدری زیاد است که بهصورت ترکیبی رشد میکند و موتور دیتابیس مجبور میشود به تخمینهای آماری تکیه کند که اغلب خطا میکنند.
زمینه: شکست بهینهسازهای سنتی
وقتی Postgres یک پرسوجو با چندین JOIN دریافت میکند، باید تصمیم بگیرد جداول را با چه ترتیبی ترکیب کند و از کدام الگوریتم استفاده کند: Hash Join، Nested Loop یا Merge Join. این تصمیم که توسط برنامهریز پرسوجو (Query Planner) گرفته میشود، حیاتی است. این تصمیم میتواند تفاوت بین یک پاسخ ۷۰ میلیثانیهای یا ۷۰۰ میلیثانیهای باشد.
برنامهریز هزینهها را بر اساس آمارهای داخلی تخمین میزند. اما این تخمینها وقتی همبستگی بین ستونها وجود داشته باشد یا توزیع دادهها غیریکنواخت باشد، بهسرعت دقت خود را از دست میدهند. از آنجا که فضای جستوجو برای ترتیب اتصال بسیار گسترده است، موتور دیتابیس از قواعد ثابت (Heuristics) استفاده میکند تا زمانی که صرف برنامهریزی پرسوجو، بیشتر از زمان اجرای خود آن نباشد.
چالش NP-Hard
ترتیب اتصال اساساً یک مسئله انفجار ترکیبی است. تنها با ۱۰ جدول در یک پرسوجوی واحد، تعداد درختهای اتصال احتمالی بهقدری زیاد است که هیچ بهینهسازی نمیتواند همه آنها را در زمانی که کاربر حاضر است منتظر یک برنامه بماند، بررسی کند. به همین دلیل است که موتورهایی مانند Postgres به Heuristics تکیه میکنند.
فرصتی برای یادگیری تقویتی
فرضیه اصلی بانسال ساده بود: در حالی که تولید یک برنامه بهینه دشوار است، اما تأیید اینکه آیا یک برنامه سریع است یا خیر، بسیار ساده است. شما بهسادگی پرسوجو را اجرا میکنید و زمان را اندازه میگیرید. این وضعیت، محیطی ایدهآل برای یادگیری تقویتی (Reinforcement Learning) ایجاد میکند، جایی که مدل میتواند از طریق آزمون و خطا و با استفاده از یک تابع پاداش شفاف یاد بگیرد. وقتی تنها یک محور برای بهینهسازی وجود داشته باشد — یعنی زمان اجرا — مسئله به تقویت رفتارهایی تبدیل میشود که برنامههای سریعتری تولید میکنند، بدون اینکه نیازی به برنامههای «درست» برچسبگذاری شده توسط انسان باشد.
مکانیزم آموزش مدل
بانسال بهینهسازی پرسوجو را مانند یک بازی با امتیاز قابل اندازهگیری دید. این فرآیند از طریق «رولاوتها» (Rollouts) پیش رفت که در آن مدل کاندیداهای مختلف را پیشنهاد میداد و سیستم نتیجه واقعی را میسنجید:
- تنظیم نظارتشده (SFT): مدل ابتدا تحت فرآیند distillation off-policy قرار گرفت. این مرحله شامل تقریباً ۵۰۰ مسیر (trajectory) تولید شده توسط یک عامل GPT-6 Astra بود که نمونههای اولیه رفتار را پیش از شروع RL در اختیار مدل قرار داد.
- یادگیری تقویتی (RL): مدل از نسخهای سفارشی از GRPO (بهینهسازی سیاست نسبی گروهی) استفاده کرد. این تکنیک بهجای مقایسه خروجیها با یک مدل ارزش (Value Model) جداگانه، چندین رولاوت برای یک ورودی یکسان را با یکدیگر مقایسه میکند.
- فرآیند ارزیابی: برای هر پرسوجوی SQL، مدل چهار برنامه کاندید متمایز در قالب «راهنما» (Hint) تولید کرد. هر کاندید به یک نمونه واقعی Postgres ارسال، اجرا و در برابر برنامه پیشفرض موتور سنجیده شد. تفاوت در تأخیر (Latency)، به عنوان یک پاداش اسکالر برای تنظیم وزنهای مدل استفاده شد.
زیرساخت و پیادهسازی فنی
از آنجا که Postgres برخلاف Oracle یا SQL Server، بهصورت پیشفرض از راهنماهای بومی در SQL استاندارد پشتیبانی نمیکند، سیستم به افزونه pg_hint_plan متکی است. این ابزار به مدل اجازه میدهد دستورات خاصی را در کامنتها تزریق کند — مانند /*+ HashJoin(a b) */ — که افزونه آنها را پیش از ساخت برنامه نهایی توسط برنامهریز تفسیر میکند.
برای جلوگیری از نویز سیستمعامل که میتوانست سیگنال پاداش را مخدوش کند، بانسال مجبور شد یک مشکل زیرساختی خاص را حل کند: تداخل حافظه کش صفحه (Page Cache) لینوکس بین کانتینرهای همزمان. اگر کانتینرها حافظه کش را بهطور نابرابر به اشتراک بگذارند، یک برنامه یکسان میتواند زمانهای اجرای متفاوتی تولید کند و الگوریتم RL را گیج کند.
ساختار سختافزاری آزمایش به شرح زیر بود:
- گره آموزش: یک نود اجارهای با ۲ عدد GPU H100 که vLLM و فرآیند آموزش را اجرا میکرد.
- گره اندازهگیری: چهار کانتینر Postgres روی یک دسکتاپ محلی برای جداسازی کامل محیط اجرا.
- GRPO سفارشی: نسخهای اصلاحشده از الگوریتم که بهطور خاص برای نرمالسازی پاداشها در این محیط اندازهگیری نویزی طراحی شده بود.
بنچمارکهای عملکردی
در این آزمایش از زیرمجموعهای از دادههای IMDb استفاده شد. این یک طرح (Schema) کلاسیک برای بنچمارک اتصال است زیرا جداول بزرگ، جداول رابط (Junction Tables) و جداول کوچک کاتالوگ را با هم ترکیب میکند و بهینهساز را مجبور میکند بین استراتژیهای متنوع انتخاب کند.
این طرح شامل موارد زیر بود:
title: تقریباً ۱ میلیون ردیف.movie_companies: تقریباً ۲ میلیون ردیف (جدول رابط بین فیلمها و شرکتها).company_name: تقریباً ۱۰۰,۰۰۰ ردیف.
مثال ساده شده از طرح:
CREATE TABLE title ( id integer PRIMARY KEY, title text, production_year integer, kind_id integer );
CREATE TABLE movie_companies ( id integer PRIMARY KEY, movie_id integer, company_id integer, company_type_id integer, note text );
CREATE TABLE company_name ( id integer PRIMARY KEY, name text, country_code text );
در ۱۱۳ پرسوجو شامل چندین اتصال، مدل به کاهش ۴۴.۷٪ در تأخیر دست یافت. نقطه شروع تکاندهنده بود: پیش از آموزش، مدل Qwen 4B در ۹۹ مورد از ۱۱۳ پرسوجو حتی نتوانست یک برنامه از نظر سینتکسی معتبر تولید کند. این یعنی پیشرفت حاصل از آموزش ساختار یک دامنه تخصصی از صفر بود، نه صرفاً اصلاح دانش موجود.
مثال عملی از راهنمایی مدل
یک پرسوجو را در نظر بگیرید که تعداد فیلمهای یک شرکت خاص را میشمارد: SELECT count(*) FROM title t JOIN movie_companies mc ON mc.movie_id = t.id JOIN company_name cn ON cn.id = mc.company_id WHERE cn.name = 'Toho'.
- برنامه پیشفرض Postgres: ۱۱۸ میلیثانیه.
- راهنمای مدل
/*+ Leading((cn mc) t) */: ۷۴ میلیثانیه (موفق). - راهنمای مدل
/*+ NestLoop(t mc) */: ۱۶۳ میلیثانیه (شکست).
این تفاوت بین رولاوتها، دقیقاً همان سیگنالی بود که الگوریتم GRPO برای یادگیری اینکه کدام ساختارهای اتصال در زمینههای خاص بهتر عمل میکنند، به آن نیاز داشت.
راهنمای تفصیلی راهنماها (pg_hint_plan)
مدل بسته به توزیع دادهها، راهنماهای مختلفی را برای بازنویسی تصمیمات برنامهریز انتخاب میکند:
- HashJoin(a b)
- زمان استفاده: جداول بزرگ بدون ایندکسهای مفید روی شرط اتصال.
- مزیت: عملکرد بالا در صورتی که هش در حافظه جای بگیرد.
- محدودیت: مصرف زیاد
work_mem؛ در صورت بزرگ بودن هش ممکن است دادهها به دیسک منتقل شوند.
- NestLoop(a b)
- زمان استفاده: وقتی یکی از جداول بسیار کوچک است یا قبلاً بهشدت فیلتر شده است.
- مزیت: سربار بسیار کم برای تعداد ردیفهای اندک.
- محدودیت: اگر تخمین ردیفها نادرست باشد، عملکرد بهشدت افت میکند.
- IndexScan(a)
- زمان استفاده: وجود یک ایندکس گزینشی (Selective) روی ستون فیلتر شده.
- مزیت: جلوگیری از خواندن کل جدول.
- محدودیت: اگر گزینشپذیری پایین باشد (ردیفهای زیادی بازگردانده شوند)، نتیجه معکوس میدهد.
- Leading((a b) c)
- زمان استفاده: وقتی ترتیب بهینه بین سه یا چند جدول مشخص است.
- مزیت: حذف فرآیند جستوجوی ترکیبی بهینهساز.
- محدودیت: در صورت تغییر طرح یا توزیع دادهها، نیاز به بررسی دستی دارد.
تحلیل برای مهندسان
این آزمایش این فرض را تغییر میدهد که بهینهسازی دیتابیس لزوماً نیازمند تغییرات عمیق در هسته موتور است. ثابت شد که یک مدل کوچک و ارزان میتواند بهعنوان یک «مشاور» خارجی برای یک سیستم بالغ عمل کند. با این حال، این یک جایگزین مستقیم برای بارهای کاری OLTP نیست. سربار یک فراخوانی استنتاج LLM احتمالاً بیشتر از صرفهجویی حاصل برای تراکنشهای در سطح میلیثانیه خواهد بود.
برای پرسوجوهای تحلیلی سنگین، توازن متفاوت است. ارزش واقعی در اینجا الگو است: استفاده از RL با یک پاداش قابل تأیید (زمان اجرا) برای حل مسائل NP-hard. این رویکرد مشابه روند فعلی در مدلهای استدلال ریاضی است که همان منطق را در مهندسی سیستمها به کار میگیرند.
اگر میخواهید این مورد را بهصورت دستی تست کنید، میتوانید pg_hint_plan را روی Debian، Ubuntu یا macOS نصب کنید. از EXPLAIN (ANALYZE, BUFFERS) برای مقایسه برنامههای پیشفرض با راهنماهای دستی استفاده کنید. نکته کلیدی، تأیید خط لاگ pg_hint_plan: hint syntax OK است تا مطمئن شوید موتور به دلیل خطای سینتکسی، دستورات شما را نادیده نمیگیرد.
مسیرهای آینده
بانسال این پروژه را به عنوان یک اثبات مفهوم (PoC) ارائه میدهد. گامهای آینده شامل گسترش بنچمارک فراتر از ۱۱۳ پرسوجوی IMDb و اندازهگیری دقیق هزینه استنتاج در برابر زمان ذخیره شده برای یافتن «نقطه سربه سر» (Break-even point) است. همچنین پتانسیل این وجود دارد که بررسی شود آیا این رویکرد RL میتواند تصمیمات دیگر دیتابیس، مانند انتخاب ایندکس یا پیکربندی work_mem برای هر پرسوجو را بهینه کند یا خیر.
در نهایت، این آزمایش نشان میدهد که وقتی یک وظیفه دارای تابع پاداش قابل تأیید و ارزان باشد، یک مدل ۴ میلیارد پارامتری میتواند از یک سیستم Heuristic با دههها تجربه مهندسی پیشی بگیرد.
گفتگو