بحث المتجهات في Laravel يدعم الآن MariaDB

يتيح Laravel 13 للمطورين تشغيل استعلامات البحث عن المتجهات (vector-search) الأصلية مقابل MariaDB، مما يضيف قدرات البحث الدلالي (semantic-search) إلى منظومة Laravel دون إجبارهم على الانتقال إلى PostgreSQL.

يحل هذا الدعم الجديد محل التنفيذ السابق الذي كان مقتصرًا على PostgreSQL فقط، لذا فإن طريقة whereVectorSimilarTo المألوفة تعمل الآن مباشرة مع اتصال MariaDB. إذا كنت تقوم ببناء محركات توصية، أو أدوات تشابه المستندات، أو أي ميزة تعتمد على منطق "الجار الأقرب" (nearest-neighbor)، فإن هذا التغيير يزيل عقبة رئيسية.

لماذا يهم هذا التحول

كان مُنشئ الاستعلامات (query builder) في Laravel يكتشف احتياجات البحث عن المتجهات سابقًا عبر اختبار instanceof الذي كان يتعرف فقط على اتصالات PostgreSQL. هذا النهج ربط الميزة بمشغل (driver) واحد وملأ قاعدة الكود بشروط خاصة بقواعد بيانات معينة.

ينقل الإصدار 13 المنطق إلى طبقة القواعد (grammar layer) ويضيف طريقتين خاصتين بالمشغل:

  • supportsVectorDistance() – يخبر Laravel ما إذا كان الاتصال الحالي يمكنه حساب مسافات المتجهات.
  • compileVectorDistanceExpression() – يبني جزء SQL الذي يقوم بالحساب.

من خلال إسناد هذه المسؤوليات إلى كل مشغل، يتخلص الإطار من حيلة "التحقق من النوع" (type-checking) ويمهد الطريق للتوسعات المستقبلية. إن إضافة الدعم لقاعدة بيانات أخرى تعني الآن تنفيذ طريقتين للمشغل بدلاً من تشتيت كتل الشروط البرمجية.

MariaDB تحصل على الوظائف الأصلية، بينما لا يحصل MySQL عليها

تأتي MariaDB مزودة بوظائف متجهات أصلية. بينما يفتقر MySQL القياسي إليها ما لم تستخدم عرضًا سحابيًا متخصصًا يضيف ملحقات الذكاء الاصطناعي.

يتجنب Laravel عمدًا إجراء حسابات التشابه في جانب PHP. فالحسابات الخاصة بالمتجهات في PHP قد تؤدي إلى كسر الترقيم (pagination) وإبطاء التطبيق دون سابق إنذار. لذا، فإن إطلاق خطأ عندما لا يستطيع المشغل التعامل مع العملية يوفر وضع فشل أكثر أمانًا.

ما يمكن لمستخدمي MySQL فعله الآن

إذا كانت بنيتك التقنية تعتمد على MySQL العادي، فلديك ثلاثة مسارات واقعية:

  1. الانتقال إلى MariaDB – بديل مباشر لمعظم أعباء عمل MySQL، مما يمنحك دعمًا أصليًا للمتجهات مع الحفاظ على نفس المنظومة.
  2. إضافة خدمة بحث مخصصة – تشغيل نسخة PostgreSQL خفيفة بجانب MySQL مخصصة فقط لاستعلامات التشابه.
  3. الاستمرار بدونها – البحث الدلالي اختياري للعديد من التطبيقات؛ فإذا كانت الفائدة لا تفوق التكلفة التشغيلية، فقد يكون البقاء على MySQL هو الخيار العملي.

يحمل كل خيار مقايضات من حيث التعقيد التشغيلي، وزمن الاستجابة (latency)، وأعباء الصيانة. ويعتمد القرار على مدى مركزية البحث عن المتجهات في القيمة المقترحة لمنتجك.

دروس في تصميم API

يوضح تغيير Laravel مبدأ تصميمًا أوسع: تجنب نثر التحققات الخاصة بقواعد البيانات في جميع أنحاء المنطق الأساسي. عندما تعتمد ميزة ما على قدرات محرك معين، قم بتغليف هذا الاعتماد خلف واجهة مشغل (driver interface). وهذا هو بالضبط ما يفعله النهج الجديد القائم على القواعد (grammar-based)، مما يهيئ الإطار للتوسعات المستقبلية دون الحاجة إلى إعادة زيارة مُنشئ الاستعلامات الأساسي.

يجب على المطورين الذين يبنون حزمهم الخاصة الانتباه لذلك. إذا وجدت تحققات instanceof لنوع قاعدة بيانات داخل طبقة الخدمة (service layer) الخاصة بك، فانقل تلك المسؤولية إلى المشغل أو إلى محول (adapter) مخصص. فهذا يحافظ على نظافة واجهة برمجة التطبيقات العامة ويجعل كودك جاهزًا للمستقبل.