ஒரு வீடியோ-ஹோஸ்டிங் சேவையின் பொறியியல் குழு, அதன் SQLite FTS5 குறியீட்டை (index) ஒரு OpenSearch கிளஸ்டராக மாற்றியது. இதன் மூலம், முடிவுகள் ஏதுமில்லாத தேடல்கள் (zero-result queries) 12%-லிருந்து 1.4%-ஆகக் குறைந்து, தேடல்-லிருந்து-கிளிக் விகிதம் (search-to-click rate) 9% அதிகரித்தது; அதே நேரத்தில் தாமத நேரம் (latency) 28 ms-க்கும் குறைவாகவே இருந்தது.
இந்த மாற்றம் ஏன் அவசியமானது
SQLite-ன் முழு-உரை தேடல் விரிவாக்கம் (FTS5) மிகவும் வசதியானது: இது மற்ற தரவுகளுடன் ஒரே கோப்பிலேயே இருக்கும், உரிமக் கட்டணம் (licensing cost) ஏதுமில்லை, மேலும் துல்லியமான சொற்களுக்கு உடனடியாகப் பொருத்தமான முடிவுகளைத் தரும். இருப்பினும், தளத்தின் பதிவுகள் (logs), பயனர்களின் தேடல்களில் ஒரு டஜன் சதவீதம் எவ்வித முடிவையும் காட்டவில்லை என்பதைக் காட்டின. மொபைல் விசைப்பலகைகளில் மக்கள் செய்யும் “intersteller” அல்லது “avengrs endgame” போன்ற எழுத்துப் பிழைகளே (typos) இதற்கு முக்கியக் காரணமாக இருந்தன.
Trigrams (மூன்று எழுத்துத் துண்டுகள்) முறையைப் பயன்படுத்திச் செய்யப்பட்ட ஒரு விரைவான முயற்சி, முடிவுகள் இல்லாத தேடல் விகிதத்தை 7%-ஆகக் குறைத்தது, ஆனால் இரண்டு சிக்கல்களை உருவாக்கியது. முதலாவதாக, குறியீட்டின் அளவு (index size) அதன் அசல் அளவை விட மூன்று மடங்குக்கும் அதிகமாக அதிகரித்தது, இது சேமிப்புச் செலவை அதிகரித்தது மற்றும் புதுப்பிப்புகளை (updates) மெதுவாக்கியது. இரண்டாவதாக, பொருத்தத் தன்மை (relevance) பாதிக்கப்பட்டது; 'fuzzy matching' முறை தொடர்பில்லாத வீடியோக்களின் கலவையைத் தந்து, பயனர்களை வழிநடத்துவதற்குப் பதிலாகக் குழப்பமடையச் செய்தது.
இயல்பாகவே எழுத்துப் பிழைகளைத் தாங்கும் திறன் (typo-tolerance) மற்றும் மேம்பட்ட பொருத்தத் தன்மை மதிப்பீடு (relevance scoring) கொண்ட, ஒரு பிரத்யேகத் தேடுபொறியை (search engine) உருவாக்க வேண்டும் என்று குழு முடிவு செய்தது.
OpenSearch குழாயை (pipeline) உருவாக்குதல்
SQLite-ஐ உண்மையான ஆதாரமாக (source of truth) வைத்திருத்தல்
OpenSearch ஒரு தற்காலிக, வாசிப்பு-மட்டும் (read-only) நகலாகச் செயல்பட்டது. அனைத்து வீடியோ மெட்டாடேட்டாக்களும் (metadata) SQLite-லேயே இருந்தன; தரவு இழப்பு ஏற்படும் அபாயம் இன்றி தேடல் குறியீட்டை மீண்டும் உருவாக்க முடிந்தது. OpenSearch கிளஸ்டர் செயலிழந்தால், பயன்பாடு தானாகவே அசல் FTS5 இயந்திரத்திற்கு மாறிவிடும்.
"should" வினவல் மூலம் அடுக்குமுறைப் பொருத்தத் தன்மை (Layered relevance)
வெறும் fuzzy matching முறையை மட்டும் நம்பியிருக்காமல், வினவல் மூன்று பகுதிகளைக் கொண்டிருந்தது:
- Exact phrase match – மிக உயர்ந்த முன்னுரிமை (highest boost), தலைப்பைச் சரியாகத் தட்டச்சு செய்யும் பயனர்களுக்குப் பயன் தரும்.
- All terms present – நடுத்தர முன்னுரிமை (medium boost), அனைத்துச் சொற்களும் இருக்கும் ஆனால் வரிசையில் இருக்க வேண்டிய அவசியமில்லை என்ற தேடல்களைக் கண்டறியும்.
- Fuzzy match – குறைந்த முன்னுரிமை (low boost), எழுத்துப் பிழைகள் உள்ள சொற்களுக்கு ஒரு பாதுகாப்பு வலையாகச் செயல்படும்.
இந்த வரிசைமுறை, தெளிவான தேடல்களுக்குத் துல்லியத்தைப் பாதுகாப்பதோடு, எழுத்துப் பிழைகளுக்கும் ஒரு நெகிழ்வான தீர்வை வழங்கியது.
Fuzzy அமைப்புகளைச் சரிசெய்தல் (Tuning)
Prefix length-ஐ 1 ஆக வைப்பதன் மூலம், fuzzy logic செயல்படுவதற்கு முன் ஒவ்வொரு சொல்லின் முதல் எழுத்தும் பொருந்த வேண்டும் என்பது கட்டாயமாக்கப்பட்டது. இந்த விதி தேடலை வேகமாகவும், நினைவகத்தை (memory) அதிகப்படியாகப் பயன்படுத்தக்கூடிய தேடல் சொற்களின் பெருக்கத்தைத் தடுத்தும் வைத்திருந்தது. மேலும், சொற்களின் விரிவாக்கத்தின் (term expansions) அதிகபட்ச எண்ணிக்கையையும் குழு கட்டுப்படுத்தியது, இது வளங்கள் (resources) வீணாவதைத் தடுக்கும் மற்றொரு பாதுகாப்பு நடவடிக்கையாகும்.
ஒத்திசைவு உத்தி (Synchronisation strategy)
மூன்று நிரப்புச் செயல்பாடுகள் OpenSearch குறியீட்டை SQLite உடன் ஒத்திசைவாக வைத்திருக்கின்றன:
- புதிய தரவை ஒத்திசைக்க ஒரு cron job.
- இரவுநேர வேறுபாட்டு ஆய்வு (Nightly diff pass) – படிப்படியான புதுப்பிப்புகளில் (incremental updates) விடுபட்ட முரண்பாடுகளைக் கண்டறியும்.
- வாராந்திர முழுமையான மறுஉருவாக்கம் (Weekly full rebuild) – ஒரு index alias மூலம் இயங்கும், பின்னர் ஒரே செயல்பாட்டில் அந்த alias-ஐ மாற்றும், இதன் மூலம் தடையற்ற சேவையை (zero downtime) உறுதி செய்கிறது.
இரண்டு வாரங்களுக்குப் பிறகு அளவிடக்கூடிய தாக்கம்
- முடிவுகள் இல்லாத தேடல்கள் 12%-லிருந்து 1.4%-ஆகக் குறைந்தன.
- தேடல்-லிருந்து-கிளிக் மாற்றம் (Search-to-click conversion) 9% அதிகரித்தது.
- இடைநிலைத் தாமதம் (Median latency) 28 ms-க்கும் குறைவாகவே இருந்தது, இது தளத்தின் பயனர் அனுபவ இலக்கிற்குள் இருந்தது.
எச்சரிக்கைகள் மற்றும் மாற்றுக்கருத்துகள்
இந்த இடமாற்றம் (migration) என்பது எளிதாகச் செய்து முடிக்கக்கூடிய (plug-and-play) மேம்படுத்தல் அல்ல. முதன்மைத் தரவுத்தளத்தை (primary database) ஒரு தேடுபொறியால் ஒருபோதும் மாற்றக்கூடாது என்று குழு வலியுறுத்துகிறது; அனைத்து வீடியோ மெட்டாடேட்டாக்களுக்கும் SQLite-தான் அதிகாரப்பூர்வமான சேமிப்பகமாகத் தொடர்கிறது.
சுருக்கம்
ஒரு பிரத்யேகத் தேடுபொறி மூலம் எழுத்துப் பிழைகளைத் தாங்கும் திறனைச் சேர்த்தது, பயனர் பயணத்தில் ஒரு முட்டுக்கட்டையாக இருந்த சிக்கலை ஒரு மென்மையான, வேகமான அனுபவமாக மாற்றியது. ஒரு ஒழுங்குபடுத்தப்பட்ட கட்டமைப்பு – அதாவது உறவுநிலைச் சேமிப்பகத்தை (relational store) உண்மையான ஆதாரமாக வைத்திருப்பது, அடுக்குமுறைப் பொருத்தத் தன்மையைப் பயன்படுத்துவது மற்றும் fuzzy logic-ஐப் பாதுகாப்பது – நிலைத்தன்மையைப் பாதிக்காமல் அளவிடக்கூடிய முன்னேற்றங்களைத் தரும் என்பதை இந்த ஆய்வு காட்டுகிறது.