Laravel Vector Search ഇപ്പോൾ MariaDB പിന്തുണയ്ക്കുന്നു
PostgreSQL-ലേക്ക് മാറാൻ നിർബന്ധിക്കാതെ തന്നെ, Laravel ഇക്കോസിസ്റ്റത്തിൽ സെമാന്റിക് സെർച്ച് (semantic-search) ശേഷികൾ ചേർത്ത് MariaDB-യിൽ നേറ്റീവ് വെക്റ്റർ സെർച്ച് ക്വറികൾ പ്രവർത്തിപ്പിക്കാൻ Laravel 13 ഡെവലപ്പർമാരെ അനുവദിക്കുന്നു.
ഫ്രെയിംവർക്കിന്റെ മുൻപത്തെ PostgreSQL-മാത്രമുള്ള സംവിധാനത്തിന് പകരം ഈ പുതിയ പിന്തുണ വന്നിരിക്കുന്നു, അതിനാൽ പരിചിതമായ whereVectorSimilarTo മെത്തേഡ് ഇപ്പോൾ MariaDB കണക്ഷനുമായി നേരിട്ട് പ്രവർത്തിക്കും. നിങ്ങൾ റെക്കമെൻഡേഷൻ എഞ്ചിനുകൾ, ഡോക്യുമെന്റ് സിമിലാരിറ്റി ടൂളുകൾ, അല്ലെങ്കിൽ "nearest-neighbor" ലോജിക്കിനെ ആശ്രയിക്കുന്ന മറ്റേതെങ്കിലും ഫീച്ചറുകൾ എന്നിവ നിർമ്മിക്കുകയാണെങ്കിൽ, ഈ മാറ്റം വലിയൊരു തടസ്സം ഒഴിവാക്കുന്നു.
ഈ മാറ്റം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
Laravel-ന്റെ ക്വറി ബിൽഡർ മുമ്പ് വെക്റ്റർ സെർച്ച് ആവശ്യങ്ങൾ തിരിച്ചറിയുന്നത് PostgreSQL കണക്ഷനുകൾ മാത്രം തിരിച്ചറിയുന്ന ഒരു instanceof ടെസ്റ്റ് വഴിയായിരുന്നു. ആ രീതി ഈ ഫീച്ചറിനെ ഒരു ഡ്രൈവറുമായി മാത്രം ബന്ധിപ്പിക്കുകയും കോഡ്ബേസിൽ ഡാറ്റാബേസ് പ്രത്യേക കണ്ടീഷനുകൾ (conditionals) നിറയ്ക്കുകയും ചെയ്തിരുന്നു.
13-ാം പതിപ്പ് ഈ ലോജിക്കിനെ ഗ്രാമർ ലെയറിലേക്ക് (grammar layer) മാറ്റുകയും രണ്ട് ഡ്രൈവർ-സ്പെസിഫിക് മെത്തേഡുകൾ ചേർക്കുകയും ചെയ്യുന്നു:
supportsVectorDistance()– നിലവിലെ കണക്ഷന് വെക്റ്റർ ദൂരങ്ങൾ (vector distances) കണക്കാക്കാൻ കഴിയുമോ എന്ന് Laravel-നെ അറിയിക്കുന്നു.compileVectorDistanceExpression()– കണക്കുകൂട്ടലുകൾ നടത്തുന്നതിനുള്ള SQL ഫ്രാഗ്മെന്റ് നിർമ്മിക്കുന്നു.
ഈ ഉത്തരവാദിത്തങ്ങൾ ഓരോ ഡ്രൈവറിനും നൽകുന്നതിലൂടെ, ഫ്രെയിംവർക്ക് "type-checking" ഹാക്ക് ഒഴിവാക്കുകയും ഭാവിയിലെ വിപുലീകരണങ്ങൾക്കായി വഴിതുറക്കുകയും ചെയ്യുന്നു. മറ്റൊരു ഡാറ്റാബേസിന് പിന്തുണ നൽകുക എന്നതിനർത്ഥം കണ്ടീഷനൽ ബ്ലോക്കുകൾ ചിതറിച്ചു വിതറുന്നതിന് പകരം കുറച്ച് ഡ്രൈവർ മെത്തേഡുകൾ നടപ്പിലാക്കുക എന്നതാണ്.
MariaDB-ക്ക് നേറ്റീവ് ഫംഗ്ഷനുകൾ ലഭിക്കുന്നു, എന്നാൽ MySQL-ന് ലഭിക്കുന്നില്ല
MariaDB-യിൽ നേറ്റീവ് വെക്റ്റർ ഫംഗ്ഷനുകൾ ലഭ്യമാണ്. AI എക്സ്റ്റൻഷനുകൾ ചേർക്കുന്ന പ്രത്യേക ക്ലൗഡ് സേവനങ്ങൾ ഉപയോഗിക്കുന്നില്ലെങ്കിൽ സാധാരണ MySQL-ൽ ഇവ ലഭ്യമല്ല.
PHP വശത്ത് വെച്ച് സിമിലാരിറ്റി കണക്കുകൂട്ടുന്നത് Laravel ബോധപൂർവ്വം ഒഴിവാക്കുന്നു. PHP-യിൽ വെക്റ്ററുകൾ കണക്കാക്കുന്നത് പേജിനേഷൻ (pagination) തകരാറിലാക്കാനും ആപ്പിന്റെ വേഗത കുറയ്ക്കാനും കാരണമാകും. ഡ്രൈവർക്ക് ഈ ഓപ്പറേഷൻ കൈകാര്യം ചെയ്യാൻ കഴിയില്ലെങ്കിൽ ഒരു എറർ (error) കാണിക്കുന്നത് കൂടുതൽ സുരക്ഷിതമായ ഒരു രീതിയാണ്.
MySQL ഉപയോക്താക്കൾക്ക് ഇപ്പോൾ എന്തുചെയ്യാൻ കഴിയും
നിങ്ങളുടെ സ്റ്റാക്കിൽ സാധാരണ MySQL ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, നിങ്ങൾക്ക് മൂന്ന് പ്രായോഗിക വഴികളുണ്ട്:
- MariaDB-ലേക്ക് മാറുക – ഒരേ ഇക്കോസിസ്റ്റം നിലനിർത്തിക്കൊണ്ടുതന്നെ നേറ്റീവ് വെക്റ്റർ പിന്തുണ നൽകുന്ന, മിക്ക MySQL വർക്ക്ലോഡുകൾക്കും പകരമായി ഉപയോഗിക്കാവുന്ന ഒരു മാർഗ്ഗമാണിത്.
- ഒരു ഡെഡിക്കേറ്റഡ് സെർച്ച് സർവീസ് ചേർക്കുക – സിമിലാരിറ്റി ക്വറികൾക്കായി മാത്രം MySQL-നോടൊപ്പം ഒരു ലഘുവായ PostgreSQL ഇൻസ്റ്റൻസ് പ്രവർത്തിപ്പിക്കുക.
- ഇതില്ലാതെ മുന്നോട്ട് പോകുക – പല ആപ്ലിക്കേഷനുകൾക്കും സെമാന്റിക് സെർച്ച് നിർബന്ധമല്ല; ഇതിന്റെ ഗുണം പ്രവർത്തന ചെലവിനേക്കാൾ (operational cost) കൂടുതലല്ലെങ്കിൽ, MySQL-ൽ തന്നെ തുടരുന്നതാകാം പ്രായോഗികമായ തീരുമാനം.
ഓരോ ഓപ്ഷനും പ്രവർത്തന സങ്കീർണ്ണത (operational complexity), ലേറ്റൻസി (latency), മെയിന്റനൻസ് എന്നിവയിൽ വിട്ടുവീഴ്ചകൾ ആവശ്യപ്പെടുന്നു. നിങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ മൂല്യത്തിന് (value proposition) വെക്റ്റർ സെർച്ച് എത്രത്തോളം പ്രധാനമാണ് എന്നതിനെ ആശ്രയിച്ചിരിക്കും നിങ്ങളുടെ തീരുമാനം.
API ഡിസൈനിനുള്ള പാഠങ്ങൾ
Laravel വരുത്തിയ ഈ മാറ്റം ഒരു വലിയ ഡിസൈൻ തത്വം വ്യക്തമാക്കുന്നു: കോർ ലോജിക്കിനുള്ളിലുടനീളം ഡാറ്റാബേസ് പ്രത്യേക പരിശോധനകൾ (database-specific checks) ഒഴിവാക്കുക. ഒരു ഫീച്ചർ ഒരു പ്രത്യേക എഞ്ചിന്റെ കപ്പാസിറ്റിയെ ആശ്രയിച്ചാണെങ്കിൽ, ആ ഡിപെൻഡൻസിയെ ഒരു ഡ്രൈവർ ഇന്റർഫേസിന് പിന്നിൽ ഉൾക്കൊള്ളിക്കുക (encapsulate). പുതിയ ഗ്രാമർ അധിഷ്ഠിത സമീപനം കൃത്യമായി ഇത് ചെയ്യുന്നു, കോർ ക്വറി ബിൽഡർ വീണ്ടും മാറ്റം വരുത്താതെ തന്നെ ഭാവിയിലെ വിപുലീകരണങ്ങൾക്കായി ഫ്രെയിംവർക്കിനെ ഇത് സജ്ജമാക്കുന്നു.
സ്വന്തമായി പാക്കേജുകൾ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാർ ഇത് ശ്രദ്ധിക്കണം. നിങ്ങളുടെ സർവീസ് ലെയറിനുള്ളിൽ ഡാറ്റാബേസ് ടൈപ്പിനായുള്ള instanceof പരിശോധനകൾ കണ്ടാൽ, ആ ഉത്തരവാദിത്തം ഒരു ഡ്രൈവറിലേക്കോ അല്ലെങ്കിൽ ഒരു ഡെഡിക്കേറ്റഡ് അഡാപ്റ്ററിലേക്കോ മാറ്റുക. ഇത് പബ്ലിക് API വൃത്തിയായി സൂക്ഷിക്കാനും നിങ്ങളുടെ കോഡ് ഭാവിയിലേക്കും അനുയോജ്യമാക്കാനും സഹായിക്കും.