جستجوی برداری Laravel اکنون از MariaDB پشتیبانی می‌کند
Laravel 13 به توسعه‌دهندگان اجازه می‌دهد پرس‌وجوهای جستجوی برداری بومی (native) را روی MariaDB اجرا کنند و بدون اجبار به تغییر از PostgreSQL، قابلیت‌های جستجوی معنایی (semantic-search) را به اکوسیستم Laravel اضافه کند.
این پشتیبانی جدید جایگزین پیاده‌سازی قبلی فریم‌ورک است که فقط از PostgreSQL پشتیبانی می‌کرد؛ بنابراین متد آشنای whereVectorSimilarTo اکنون مستقیماً با اتصال MariaDB کار می‌کند. اگر در حال ساخت موتورهای پیشنهاددهنده، ابزارهای شباهت اسناد یا هر ویژگی دیگری هستید که بر منطق «نزدیک‌ترین همسایه» (nearest-neighbor) تکیه دارد، این تغییر یک مانع بزرگ را از میان برمی‌دارد.
چرا این تغییر اهمیت دارد
کوئری‌ساز (query builder) لاراول پیش از این، نیاز به جستجوی برداری را با یک تست instanceof تشخیص می‌داد که فقط اتصالات PostgreSQL را شناسایی می‌کرد. آن رویکرد، این قابلیت را به یک درایور واحد محدود می‌کرد و کد را با شرط‌های (conditionals) مربوط به پایگاه داده‌های خاص پر می‌کرد.
نسخه ۱۳ این منطق را به لایه دستور زبان (grammar layer) منتقل کرده و دو متد مخصوص درایور اضافه می‌کند:
supportsVectorDistance()– به Laravel می‌گوید که آیا اتصال فعلی می‌تواند فواصل برداری را محاسبه کند یا خیر.compileVectorDistanceExpression()– قطعه کد SQL را که محاسبات را انجام می‌دهد، می‌سازد.
با واگذاری این مسئولیت‌ها به هر درایور، فریم‌ورک از ترفند «بررسی نوع» (type-checking) دست می‌کشد و راه را برای توسعه‌های آتی هموار می‌کند. اکنون اضافه کردن پشتیبانی از یک پایگاه داده دیگر، به معنای پیاده‌سازی چند متد در درایور است، به جای اینکه بلوک‌های شرطی را در همه جا پراکنده کنید.
MariaDB توابع بومی را دریافت می‌کند، اما MySQL خیر
MariaDB همراه با توابع برداری بومی عرضه می‌شود. MySQL استاندارد فاقد این توابع است، مگر اینکه از یک سرویس ابری تخصصی استفاده کنید که افزونه‌های هوش مصنوعی (AI extensions) را اضافه می‌کند.
Laravel عمداً از محاسبه شباهت در سمت PHP خودداری می‌کند. محاسبه بردارها در PHP باعث از کار افتادن صفحه‌بندی (pagination) و کند شدن برنامه بدون هیچ هشداری می‌شود. پرتاب کردن خطا (throwing an error) زمانی که درایور نمی‌تواند عملیات را انجام دهد، حالت شکست (failure mode) ایمن‌تری را فراهم می‌کند.
کاربران MySQL اکنون چه کاری می‌توانند انجام دهند
اگر پشته تکنولوژی (stack) شما از MySQL معمولی استفاده می‌کند، سه مسیر واقع‌بینانه پیش رو دارید:
- مهاجرت به MariaDB – جایگزینی مستقیم برای اکثر بارهای کاری MySQL که ضمن حفظ همان اکوسیستم، پشتیبانی بومی از بردار را به شما می‌دهد.
- افزودن یک سرویس جستجوی اختصاصی – اجرای یک نمونه سبک از PostgreSQL در کنار MySQL صرفاً برای پرس‌وجوهای شباهت.
- زندگی بدون آن – جستجوی معنایی برای بسیاری از اپلیکیشن‌ها اختیاری است؛ اگر مزیت آن از هزینه عملیاتی بیشتر نیست، ماندن روی MySQL ممکن است انتخابی عمل‌گرایانه باشد.
هر گزینه دارای سبک و سنگینی (trade-offs) در پیچیدگی عملیاتی، تأخیر (latency) و هزینه‌های نگهداری است. تصمیم‌گیری به این بستگی دارد که جستجوی برداری چقدر در ارزش پیشنهادی (value proposition) محصول شما نقش محوری دارد.
درس‌هایی برای طراحی API
تغییر لاراول یک اصل طراحی گسترده‌تر را نشان می‌دهد: از پراکندن بررسی‌های مربوط به پایگاه داده‌های خاص در سراسر منطق اصلی خودداری کنید. وقتی یک ویژگی به قابلیت‌های یک موتور خاص وابسته است، آن وابستگی را پشت یک رابط درایور (driver interface) کپسوله‌سازی کنید. رویکرد جدید مبتنی بر دستور زبان (grammar-based) دقیقاً همین کار را انجام می‌دهد و فریم‌ورک را بدون نیاز به بازنگری در کوئری‌ساز اصلی، برای توسعه‌های آینده آماده می‌کند.
توسعه‌دهندگانی که پکیج‌های خود را می‌سازند باید توجه کنند. اگر در لایه سرویس خود با بررسی‌های instanceof برای نوع پایگاه داده مواجه شدید، آن مسئولیت را به درایور یا یک آداپتور اختصاصی منتقل کنید. این کار باعث می‌شود API عمومی تمیز باقی بماند و کد شما در برابر تغییرات آینده مقاوم (future-proof) باشد.