חיפוש וקטורי ב-Laravel תומך כעת ב-MariaDB

Laravel 13 מאפשרת למפתחים להריץ שאילתות חיפוש וקטורי טבעיות מול MariaDB, מה שמוסיף יכולות חיפוש סמנטי לאקוסיסטם של Laravel מבלי לכפות מעבר ל-PostgreSQL.

התמיכה החדשה מחליפה את המימוש הקודם של המסגרת (framework) שתמך ב-PostgreSQL בלבד, כך שהמתודה המוכרת whereVectorSimilarTo עובדת כעת ישירות עם חיבור MariaDB. אם אתם בונים מנועי המלצות, כלי דמיון מסמכים, או כל תכונה המסתמכת על לוגיקת "שכן קרוב" (nearest-neighbor), השינוי הזה מסיר נקודת חיכוך משמעותית.

למה השינוי הזה חשוב

בונה השאילתות (query builder) של Laravel זיהה בעבר צרכי חיפוש וקטורי באמצעות בדיקת instanceof שזיהתה רק חיבורי PostgreSQL. גישה זו קשרה את התכונה לדרייבר (driver) יחיד ופיזרה את בסיס הקוד בתנאים (conditionals) ספציפיים למסדי נתונים.

גרסה 13 מעבירה את הלוגיקה לשכבת הדקדוק (grammar layer) ומוסיפה שתי מתודות ספציפיות לדרייבר:

  • supportsVectorDistance() – מודיעה ל-Laravel האם החיבור הנוכחי יכול לחשב מרחקים וקטוריים.
  • compileVectorDistanceExpression() – בונה את קטע ה-SQL שמבצע את החישוב.

על ידי הקצאת האחריות הזו לכל דרייבר, המסגרת נוטשת את ה"טריק" של בדיקת סוג (type-checking) ומפנה את הדרך להרחבות עתידיות. הוספת תמיכה במסד נתונים אחר פירושה כעת מימוש של מספר מתודות בדרייבר, במקום פיזור של בלוקים מותנים.

MariaDB מקבלת את הפונקציות הטבעיות, MySQL לא

MariaDB מגיעה עם פונקציות וקטוריות טבעיות. ב-MySQL סטנדרטי הן חסרות, אלא אם כן משתמשים בשירות ענן ייעודי שמוסיף הרחבות AI.

Laravel נמנעת בכוונה מחישוב דמיון בצד ה-PHP. חישוב וקטורים ב-PHP ישבור את הפגנציה (pagination) ויאט את האפליקציה ללא אזהרה. השלכת שגיאה (throwing an error) כאשר הדרייבר אינו יכול לטפל בפעולה מספקת מצב כשל בטוח יותר.

מה משתמשי MySQL יכולים לעשות עכשיו

אם ה-stack שלכם מריץ MySQL רגיל, יש לכם שלוש דרכים ריאליות:

  1. להגרל ל-MariaDB – תחליף ישיר (drop-in replacement) עבור רוב עומסי העבודה של MySQL, המעניק תמיכה וקטורית טבעית תוך שמירה על אותו אקוסיסטם.
  2. להוסיף שירות חיפוש ייעודי – להריץ מופע (instance) קל משקל של PostgreSQL לצד MySQL אך ורק עבור שאילתות דמיון.
  3. לחיות בלעדיו – חיפוש סמנטי הוא אופציונלי עבור אפליקציות רבות; אם התועלת אינה עולה על העלות התפעולית, להישאר ב-MySQL עשוי להיות הבחירה הפרגמטית.

לכל אפשרות יש פשרות (trade-offs) מבחינת מורכבות תפעולית, שיהוי (latency) ועלויות תחזוקה. ההחלטה תלויה במידת המרכזיות של החיפוש הוקטורי בהצעת הערך של המוצר שלכם.

לקחים לעיצוב API

השינוי ב-Laravel ממחיש עיקרון עיצוב רחב יותר: הימנעו מפיזור בדיקות ספציפיות למסד נתונים לאורך הלוגיקה המרכזית. כאשר תכונה מסוימת תלויה ביכולות של מנוע ספציפי, כדלו (encapsulate) את התלות הזו מאחורי ממשק דרייבר (driver interface). הגישה החדשה מבוססת הדקדוק עושה בדיוק את זה, ומכינה את המסגרת להרחבות עתידיות מבלי לחזור על בונה השאילתות המרכזי.

מפתחים שבונים חבילות (packages) משלהם צריכים לשים לב לכך. אם אתם מוצאים בדיקות instanceof לסוג מסד נתונים בתוך שכבת השירות (service layer) שלכם, העבירו את האחריות הזו לדרייבר או לאדפטר (adapter) ייעודי. זה שומר על ה-API הציבורי נקי ומבטיח שהקוד שלכם יהיה עמיד לעתיד (future-proof).