MariaDB در برابر PostgreSQL در زیرساخت‌های جست‌وجوی برداری لاراول

اگر امروز برای پیاده‌سازی جست‌وجوی معنایی مجبور به استفاده از PostgreSQL هستید، حالا می‌توانید بدون تغییر زیرساخت، از MariaDB استفاده کنید. این قابلیت که در ۲۰ اوت ۲۰۲۶ به شاخه Laravel 13.x اضافه شد، اجازه می‌دهد عملیات پیچیده برداری را مستقیماً با متدهایی مثل whereVectorSimilarTo و orderByVectorDistance مدیریت کنید. این به‌روزرسانی که از طریق PR #61250 معرفی شد، رسماً پشتیبانی بومی از جست‌وجوی برداری را به MariaDB می‌آورد.

به نقل از مستندات PR #61250، این به‌روزرسانی گرهی از مشکلات میلیون‌ها توسعه‌دهنده‌ای باز می‌کند که خانواده MySQL را برای نرم‌افزارهای تجاری ترجیح می‌دهند. تا پیش از این، اکوسیستم PHP برای مدیریت بردار معنایی (Embedding) — که مثل یک کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — یا به پایگاه‌داده‌های برداری خارجی وابسته بود یا تنها از افزونه pgvector در PostgreSQL استفاده می‌کرد. در واقع، پیاده‌سازی برداری در لاراول به‌صورت سخت‌افزاری (Hard-coded) برای PostgreSQL طراحی شده بود و این موضوع یک گلوگاه فنی برای کسانی ایجاد می‌کرد که نمی‌خواستند از محیط Postgres استفاده کنند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی لایه‌های داده اشاره کردیم، وابستگی شدید به یک موتور خاص، مقیاس‌پذیری را سخت می‌کند. طبق گزارش وب‌سایت dev.to، لاراول پیش از این یک «بدهی فنی» (Technical Debt) بحرانی داشت؛ منطق محاسبه فاصله برداری به‌جای اینکه در درایور پایگاه‌داده باشد، به‌صورت سخت‌افزاری در Query Builder برای Postgres تعریف شده بود. به طور مشخص، بررسی instanceof PostgresConnection در داخل Query Builder وجود داشت و منطق محاسبه فواصل — به‌ویژه عملگر <=> در pgvector — در خودِ Builder زندگی می‌کرد، نه در گرامرِ درایور دیتابیس.

بازنگری در طراحی درایورها

این تغییر ساختاری، درسی در طراحی API است. مشکل اصلی این بود که Query Builder پیش‌فرض‌هایی درباره نوع اتصال (Connection) داشت. با انتقال این منطق، لاراول از پرداخت «صورت‌حساب» سنگینی که هنگام افزودن دومین پایگاه‌داده به یک ویژگی تک-دیتابیسی رخ می‌دهد، جلوگیری کرد.

لاراول حالا به‌جای حدس زدن نوع اتصال، از درایور می‌پرسد که آیا قابلیت محاسبه فاصله برداری را دارد یا خیر. این کار از طریق دو متد جدید در سطح گرامر انجام می‌شود:

• supportsVectorDistance(): بررسی می‌کند که آیا پایگاه‌داده فعلی توانایی مدیریت این عملیات را دارد یا خیر.
• compileVectorDistanceExpression($column): پرس‌وجوی PHP را به نحو SQL خاصی که توسط آن پایگاه‌داده مورد نیاز است، تبدیل (Compile) می‌کند.

این رویکرد دقیقاً همان الگویی است که لاراول سال‌ها برای قابلیت‌هایی مثل compileRandom() یا پشتیبانی از Savepoint استفاده کرده است: یک پیاده‌سازی پایه در گرامر و بازنویسی‌های (Overrides) مجزا برای هر درایور.

در MariaDB، این دستورات به تابع vec_distance_cosine() تبدیل می‌شوند. این قابلیت در نسخه‌های ۱۱.۷ Community و ۱۱.۴.۵-۳ Enterprise که هر دو دارای نوع ستون بومی VECTOR هستند، در دسترس است. لازم به ذکر است که بخش مربوط به Schema — شامل typeVector() و ایندکس‌های برداری — از طریق یک PR قدیمی‌تر اضافه شده بود و تنها بخش پرس‌وجو (Query) بود که جای خالی‌اش حس می‌شد. همچنین، پنج روز پس از ادغام اولیه، به‌روزرسانی دوم (PR #61337) منتشر شد که یک اصلاحیه SQL ارائه داد و قابلیت AsVector را به Eloquent اضافه کرد تا تبدیل داده‌های برداری در مدل‌ها برای توسعه‌دهندگان ساده‌تر شود.

شکاف موجود در MySQL

با وجود این پیشرفت، MySQL استاندارد همچنان پشتیبانی نمی‌شود. اگر سعی کنید از متدهای برداری مثل whereVectorSimilarTo() روی یک اتصال معمولی MySQL استفاده کنید، همچنان با خطای RuntimeException مواجه می‌شوید. در واقع، PR مذکور تنها پیام خطا را به‌روزرسانی کرد تا به پشتیبانی از MariaDB اشاره کند.

این محدودیت مربوط به خودِ پایگاه‌داده است، نه فریم‌ورک لاراول. توابع بومی فاصله برداری مانند DISTANCE() و VECTOR_DISTANCE() تنها در MySQL HeatWave (در زیرساخت ابری اوراکل - OCI) یا MySQL AI وجود دارند. از آنجایی که این توابع در نسخه‌های استاندارد Community یا Enterprise موجود نیستند، هیچ SQL-ی وجود ندارد که لاراول بتواند آن را کامپایل کند.

نکته بسیار مهم این است که تیم توسعه در این PR صراحتاً از پیاده‌سازی یک جایگزین (Fallback) در سمت PHP — که ردیف‌ها را واکشی کرده و شباهت را در حافظه محاسبه کند — خودداری کرد. چنین اقدامی می‌توانست فاجعه‌بار باشد، زیرا معنای متدهای limit() و صفحه‌بندی (Pagination) را به‌طور مخفیانه تغییر می‌داد و قرارداد عملکردی (Performance Contract) پرس‌وجو را بدون هشدار به کاربر می‌شکست.

تحلیل تحریریه

این حرکت نشان می‌دهد که قابلیت‌های هوش مصنوعی دیگر به‌عنوان افزونه‌های خاص دیده نمی‌شوند، بلکه در حال تبدیل شدن به ویژگی‌های استاندارد پایگاه‌داده هستند. با انتقال منطق به سطح Grammar، لاراول راه را برای افزودن درایورهای آینده یا معیارهای فاصله دیگر (مانند فاصله اقلیدسی - Euclidean distance) بدون نیاز به «جراحی قلب باز» در هسته Query Builder باز کرد. حتی در حال حاضر پیشنهادی وجود دارد تا معیار فاصله به‌جای فرض پیش‌فرض، قابل پیکربندی باشد.

برای یک توسعه‌دهنده، MariaDB اکنون مقرون‌به‌صرفه‌ترین مسیر برای دسترسی به بردارها در اکوسیستم MySQL است و نیاز به نگهداری یک نمونه Postgres جداگانه را از بین می‌برد و پیچیدگی زیرساخت را کاهش می‌دهد. اما این موضوع شکافی را آشکار می‌کند: در حالی که MariaDB و PostgreSQL به سمت استانداردهای باز برداری می‌روند، کاربران MySQL استاندارد برای دسترسی به این ویژگی‌های AI به محیط‌های ابری اختصاصی رانده می‌شوند.

باید به یاد داشت که ایندکس‌های برداری سمت سرور نمی‌توانند داده‌های رمزنگاری‌شده در سمت کلاینت را پردازش کنند. اگر اپلیکیشن شما از رمزنگاری پاکتی (Envelope Encryption) برای یادداشت‌های حساس استفاده می‌کند — جایی که سرور پاکت‌هایی را ذخیره می‌کند که قادر به باز کردن آن‌ها نیست — آن فیلدها برای قابلیت‌های جست‌وجوی معنایی دیتابیس نامرئی خواهند بود. شما نمی‌توانید متنی را که نمی‌توانید بخوانید، به بردار تبدیل کنید.

برای پیاده‌سازی جست‌وجوی معنایی در امروز — برای مثال، تطبیق عبارت «درمان وز» زمانی که کاربر «موی پف‌کرده» را تایپ می‌کند — کاربران MySQL سه گزینه اصلی دارند:

۱. مهاجرت به MariaDB: ارزان‌ترین راه برای دستیابی به بردار بومی، به شرطی که مهاجرت یک فرآیند ساده باشد و نه یک عملیات قهرمانانه و دشوار.
۲. استفاده از Sidecar Postgres: استقرار یک نمونه کوچک Postgres با pgvector در کنار MySQL اصلی که از طریق رویدادهای اپلیکیشن (Application Events) همگام‌سازی شود.
۳. صبر کردن: جست‌وجوی معنایی در برنامه‌های تجاری اغلب یک قابلیت «خوب است اگر باشد» (Nice-to-have) است و هزینه زیرساخت اشتباه ممکن است سال‌ها پرداخت شود.

گام بعدی شما

• اگر از MySQL استفاده می‌کنید و به جست‌وجوی معنایی نیاز دارید، مهاجرت به MariaDB ۱۱.۷ را بررسی کنید.
• برای پروژه‌هایی که تغییر دیتابیس در آن‌ها ممکن نیست، از الگوی Sidecar Postgres استفاده کنید.
• در صورت استفاده از رمزنگاری داده‌ها، استراتژی‌های رمزنگاری قابل جست‌وجو (Searchable Encryption) را مطالعه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.