Laravel Vector Search இப்போது MariaDB-ஐ ஆதரிக்கிறது

Laravel 13, டெவலப்பர்கள் MariaDB-இல் நேரடி (native) vector-search வினவல்களை (queries) இயக்க அனுமதிக்கிறது. இது PostgreSQL-க்கு மாற வேண்டிய கட்டாயம் இல்லாமலேயே, Laravel ecosystem-இல் semantic-search வசதிகளைச் சேர்க்கிறது.

இந்த புதிய ஆதரவு, கட்டமைப்பின் (framework) முந்தைய PostgreSQL-மட்டும் சார்ந்திருந்த செயல்பாட்டை மாற்றுகிறது. எனவே, நன்கு தெரிந்த whereVectorSimilarTo முறை (method) இப்போது MariaDB இணைப்போடு நேரடியாகச் செயல்படும். நீங்கள் recommendation engines, document-similarity கருவிகள் அல்லது "nearest-neighbor" தர்க்கத்தைப் (logic) பயன்படுத்தும் எந்தவொரு அம்சத்தையும் உருவாக்குகிறீர்கள் என்றால், இந்த மாற்றம் ஒரு முக்கியத் தடையை நீக்குகிறது.

இந்த மாற்றம் ஏன் முக்கியமானது

Laravel-இன் query builder முன்னதாக, PostgreSQL இணைப்புகளை மட்டுமே அடையாளம் காணும் instanceof சோதனை மூலம் vector-search தேவைகளைக் கண்டறிந்தது. அந்த அணுகுமுறை, இந்த வசதியை ஒரு குறிப்பிட்ட driver-உடன் மட்டுமே இணைத்ததுடன், codebase முழுவதும் database-குறிப்பிட்ட நிபந்தனைகளை (conditionals) நிறைத்தது.

13-வது வெளியீடு இந்த தர்க்கத்தை (logic) grammar layer-க்குள் நகர்த்துகிறது மற்றும் இரண்டு driver-குறிப்பிட்ட முறைகளைச் சேர்க்கிறது:

  • supportsVectorDistance() – தற்போதைய இணைப்பு vector distances-ஐ கணக்கிட முடியுமா என்பதை Laravel-இடம் தெரிவிக்கிறது.
  • compileVectorDistanceExpression() – கணக்கீட்டைச் செய்யும் SQL fragment-ஐ உருவாக்குகிறது.

இந்த பொறுப்புகளை ஒவ்வொரு driver-க்கும் ஒதுக்குவதன் மூலம், framework அந்த "type-checking" முறையைத் தவிர்த்துவிட்டு, எதிர்கால விரிவாக்கங்களுக்கான (extensions) வழியைத் தெளிவுபடுத்துகிறது. இப்போது மற்றொரு database-க்கான ஆதரவைச் சேர்ப்பது என்பது, நிபந்தனைத் தொகுதிகளை (conditional blocks) சிதறவிடுவதைத் தவிர்த்து, சில driver முறைகளைச் செயல்படுத்துவதாகும்.

MariaDB-இல் native functions உள்ளன, ஆனால் MySQL-இல் இல்லை

MariaDB-இல் native vector functions உள்ளன. AI extensions-களைச் சேர்க்கும் ஒரு சிறப்பு cloud சேவையைப் பயன்படுத்தாவிட்டால், சாதாரண MySQL-இல் இவை இருக்காது.

Laravel வேண்டுமென்றே PHP பக்கத்தில் similarity கணக்கீடுகளைத் தவிர்க்கிறது. PHP-இல் vectors-ஐக் கணக்கிடுவது pagination-ஐப் பாதிக்கும் மற்றும் எச்சரிக்கையின்றி செயலியை (app) மெதுவாக்கும். ஒரு driver அந்தச் செயல்பாட்டைச் செய்ய முடியாமல் போகும்போது பிழையை (error) வெளியிடுவது, பாதுகாப்பான ஒரு தோல்வி முறையை (failure mode) வழங்குகிறது.

MySQL பயனர்கள் இப்போது என்ன செய்யலாம்

உங்கள் stack சாதாரண MySQL-இல் இயங்கினால், உங்களிடம் மூன்று நடைமுறை வழிகள் உள்ளன:

  1. MariaDB-க்கு மாறவும் – இது பெரும்பாலான MySQL workloads-களுக்கு ஒரு நேரடி மாற்றாகும் (drop-in replacement). இது அதே ecosystem-ஐத் தக்கவைத்துக் கொள்ளும் அதே வேளையில், உங்களுக்கு native vector ஆதரவையும் வழங்குகிறது.
  2. ஒரு பிரத்யேக search service-ஐச் சேர்க்கவும் – similarity queries-களுக்காக மட்டும் MySQL உடன் இணைந்து ஒரு இலகுவான (lightweight) PostgreSQL instance-ஐ இயக்கலாம்.
  3. இது இல்லாமல் இயங்கவும் – பல பயன்பாடுகளுக்கு semantic search என்பது விருப்பத்தேர்வுதான்; அதன் பயன் செயல்பாட்டுச் செலவை (operational cost) விட அதிகமாக இல்லையென்றால், MySQL-லேயே தொடர்வது ஒரு நடைமுறைச் சாத்தியமான தேர்வாக இருக்கலாம்.

ஒவ்வொரு விருப்பமும் செயல்பாட்டு சிக்கல் (operational complexity), தாமதம் (latency) மற்றும் பராமரிப்புச் சுமை (maintenance overhead) ஆகியவற்றில் சமரசங்களை (trade-offs) உள்ளடக்கியது. உங்கள் தயாரிப்பின் மதிப்பு முன்மொழிவில் (value proposition) vector search எவ்வளவு முக்கியமானது என்பதைப் பொறுத்தே இந்த முடிவு அமையும்.

API வடிவமைப்பிற்கான பாடங்கள்

Laravel-இன் இந்த மாற்றம் ஒரு பரந்த வடிவமைப்புத் தத்துவத்தை விளக்குகிறது: core logic முழுவதும் database-குறிப்பிட்ட சோதனைகளைச் சிதறவிடுவதைத் தவிர்க்கவும். ஒரு அம்சம் ஒரு குறிப்பிட்ட engine-இன் திறன்களைச் சார்ந்து இருக்கும்போது, அந்தச் சார்பை (dependency) ஒரு driver interface-இன் பின்னால் மறைத்து வைக்கவும் (encapsulate). புதிய grammar-அடிப்படையிலான அணுகுமுறை சரியாக அதைச் செய்கிறது, core query builder-ஐ மீண்டும் அணுகாமலேயே எதிர்கால விரிவாக்கங்களுக்காக framework-ஐத் தயார்படுத்துகிறது.

சொந்தமாக packages உருவாக்கும் டெவலப்பர்கள் இதைக் கவனத்தில் கொள்ள வேண்டும். உங்கள் service layer-க்குள் ஒரு database வகையைச் சரிபார்க்க instanceof சோதனைகளைக் கண்டால், அந்தப் பொறுப்பை driver அல்லது ஒரு பிரத்யேக adapter-க்கு மாற்றவும். இது public API-ஐத் தூய்மையாக வைத்திருப்பதோடு, உங்கள் குறியீட்டையும் (code) எதிர்காலத்திற்குத் தயார்படுத்தும் (future-proofs).