ഒരു വീഡിയോ-ഹോസ്റ്റിംഗ് സർവീസിന്റെ എഞ്ചിനീയറിംഗ് ടീം അവരുടെ SQLite FTS5 ഇൻഡക്സിന് പകരം ഒരു OpenSearch ക്ലസ്റ്റർ ഉപയോഗിക്കാൻ തീരുമാനിച്ചു. ഇത് സെർച്ച് റിസൾട്ടുകൾ ലഭിക്കാത്ത ക്വറികൾ (zero-result queries) 12%-ൽ നിന്ന് 1.4%-ലേക്ക് കുറയ്ക്കാനും, ലേറ്റൻസി (latency) 28 ms-ൽ താഴെ നിലനിർത്തിക്കൊണ്ടുതന്നെ സെർച്ച്-ടു-ക്ലിക്ക് നിരക്ക് 9% വർദ്ധിപ്പിക്കാനും സഹായിച്ചു.
എന്തുകൊണ്ടാണ് ഈ മാറ്റം അനിവാര്യമായത്
SQLite-ന്റെ ഫുൾ-ടെക്സ്റ്റ് സെർച്ച് എക്സ്റ്റൻഷൻ (FTS5) ആകർഷകമാണ്: ഇത് ഡാറ്റയുടെ ബാക്കി ഭാഗങ്ങൾ ഇരിക്കുന്ന അതേ ഫയലിൽ തന്നെ നിലനിൽക്കുന്നു, ലൈസൻസിംഗ് ചിലവുകൾ ഇല്ല, കൂടാതെ കൃത്യമായ ടോക്കൺ മാച്ചുകൾക്കായി (exact token matches) ഉടനടി ഫലങ്ങൾ നൽകുന്നു. എന്നിരുന്നാലും, പ്ലാറ്റ്ഫോമിലെ ലോഗുകൾ പരിശോധിച്ചപ്പോൾ പത്ത് ശതമാനത്തിലധികം ഉപയോക്താക്കളുടെ സെർച്ചുകൾക്കൊന്നും ഫലങ്ങൾ ലഭിക്കുന്നില്ലെന്ന് കണ്ടെത്തി. മൊബൈൽ കീബോർഡുകളിൽ ആളുകൾ വരുത്തുന്ന "intersteller" അല്ലെങ്കിൽ "avengrs endgame" പോലുള്ള അക്ഷരത്തെറ്റുകളാണ് (typos) ഇതിന് പ്രധാന കാരണം.
ട്രിഗ്രാമുകൾ (trigrams - മൂന്ന് അക്ഷരങ്ങളുള്ള ഭാഗങ്ങൾ) ഉപയോഗിച്ചുള്ള ഒരു ചെറിയ പരിഹാരം വഴി റിസൾട്ടുകൾ ലഭിക്കാത്ത നിരക്ക് 7%-ലേക്ക് കുറച്ചെങ്കിലും അത് രണ്ട് പ്രശ്നങ്ങൾക്ക് കാരണമായി. ഒന്നാമതായി, ഇൻഡക്സിന്റെ വലിപ്പം അതിന്റെ യഥാർത്ഥ വലുപ്പത്തിന്റെ മൂന്നിരട്ടിയിലധികമായി വർദ്ധിച്ചു, ഇത് സ്റ്റോറേജ് ചിലവ് കൂട്ടുകയും അപ്ഡേറ്റുകൾ സാവധാനത്തിലാക്കുകയും ചെയ്തു. രണ്ടാമതായി, സെർച്ച് റിസൾട്ടുകളുടെ കൃത്യത (relevance) കുറഞ്ഞു; ഫസി മാച്ചിംഗ് (fuzzy matching) വഴി ബന്ധമില്ലാത്ത വീഡിയോകളുടെ ഒരു കൂട്ടം ലഭിച്ചതിനാൽ ഉപയോക്താക്കൾക്ക് ശരിയായ വീഡിയോ കണ്ടെത്താൻ ബുദ്ധിമുട്ടായി.
അക്ഷരത്തെറ്റുകൾ തിരിച്ചറിയാനും (typo-tolerance) മികച്ച രീതിയിൽ റിസൾട്ടുകൾ ക്രമീകരിക്കാനും (relevance scoring) ശേഷിയുള്ള, പ്രത്യേകമായി നിർമ്മിച്ച ഒരു സെർച്ച് എഞ്ചിൻ ആവശ്യമാണെന്ന് ടീം തീരുമാനിച്ചു.
OpenSearch പൈപ്പ്ലൈൻ നിർമ്മിക്കുന്നു
SQLite-നെ പ്രധാന ഡാറ്റാ സ്രോതസ്സായി (source of truth) നിലനിർത്തുക
OpenSearch ഒരു റീഡ്-ഒൺലി റെപ്ലിക്കയായി (read-only replica) പ്രവർത്തിച്ചു. എല്ലാ വീഡിയോ മെറ്റാഡേറ്റയും SQLite-ൽ തന്നെ നിലനിർത്തി; അതിനാൽ ഡാറ്റ നഷ്ടപ്പെടാതിരിക്കാൻ സെർച്ച് ഇൻഡക്സ് വീണ്ടും നിർമ്മിക്കാൻ സാധിക്കും. OpenSearch ക്ലസ്റ്റർ പ്രവർത്തനരഹിതമായാൽ, ആപ്ലിക്കേഷൻ തനിയെ പഴയ FTS5 എഞ്ചിനിലേക്ക് മാറുന്ന രീതിയിലാണ് ക്രമീകരിച്ചിരുന്നത്.
“should” ക്വറി ഉപയോഗിച്ച് റിസൾട്ടുകളുടെ കൃത്യത വർദ്ധിപ്പിക്കുന്നു
ഫസി മാച്ചിംഗിനെ മാത്രം ആശ്രയിക്കുന്നതിന് പകരം, ക്വറി മൂന്ന് ഘടകങ്ങൾ സംയോജിപ്പിച്ചു:
- Exact phrase match – ഏറ്റവും ഉയർന്ന മുൻഗണന, ശരിയായ ടൈറ്റിൽ ടൈപ്പ് ചെയ്യുന്ന ഉപയോക്താക്കൾക്ക് ഇത് മികച്ച ഫലങ്ങൾ നൽകുന്നു.
- All terms present – ഇടത്തരം മുൻഗണന, വാക്കുകൾ കൃത്യമായ ക്രമത്തിലല്ലെങ്കിലും എല്ലാ വാക്കുകളും അടങ്ങിയ ക്വറികൾ കണ്ടെത്തുന്നു.
- Fuzzy match – കുറഞ്ഞ മുൻഗണന, അക്ഷരത്തെറ്റുകൾ വരുത്തിയ വാക്കുകൾക്കായി ഒരു സുരക്ഷാ കവചമായി പ്രവർത്തിക്കുന്നു.
ഈ ക്രമം കൃത്യമായ ക്വറികൾക്ക് മികച്ച ഫലങ്ങൾ നൽകുന്നതോടൊപ്പം തന്നെ അക്ഷരത്തെറ്റുകൾ വരുത്തുന്നവർക്കും സഹായകരമായി മാറി.
ഫസി സെറ്റിംഗുകൾ ക്രമീകരിക്കൽ (Tuning fuzzy settings)
പ്രിഫിക്സ് ലെങ്ത് (prefix length) 1 ആയി നിശ്ചയിച്ചതിലൂടെ, ഫസി ലോജിക് പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ഓരോ വാക്കിന്റെയും ആദ്യ അക്ഷരം കൃത്യമായിരിക്കണം എന്ന് നിർബന്ധമാക്കി. ഇത് സെർച്ച് വേഗത നിലനിർത്താനും മെമ്മറിയിൽ അമിതഭാരം ഉണ്ടാക്കാതിരിക്കാനും സഹായിച്ചു. കൂടാതെ, റിസോഴ്സുകൾ അമിതമായി ഉപയോഗിക്കുന്നത് തടയാൻ ടേം എക്സ്പാൻഷനുകളുടെ (term expansions) പരമാവധി പരിധിയും നിശ്ചയിച്ചു.
സിൻക്രൊണൈസേഷൻ സ്ട്രാറ്റജി (Synchronisation strategy)
OpenSearch ഇൻഡക്സിനെ SQLite-മായി ഒരേപോലെ നിലനിർത്താൻ മൂന്ന് പ്രക്രിയകൾ ഉപയോഗിച്ചു:
- പുതിയ ഡാറ്റ സിങ്ക് ചെയ്യാൻ ഒരു cron job.
- Nightly diff pass – ഇൻക്രിമെന്റൽ അപ്ഡേറ്റുകളിൽ വിട്ടുപോയ മാറ്റങ്ങൾ കണ്ടെത്തുന്നു.
- Weekly full rebuild – ഒരു ഇൻഡക്സ് ഏലിയാസിന് (index alias) പിന്നിൽ പ്രവർത്തിക്കുന്നു, തുടർന്ന് ഒറ്റ ഓപ്പറേഷനിലൂടെ ഏലിയസ് മാറ്റുന്നു, ഇത് ഡൗൺടൈം ഇല്ലാതിരിക്കുമെന്ന് ഉറപ്പാക്കുന്നു.
രണ്ടാഴ്ചയ്ക്ക് ശേഷമുള്ള ഫലങ്ങൾ
- റിസൾട്ടുകൾ ലഭിക്കാത്ത ക്വറികൾ 12%-ൽ നിന്ന് 1.4%-ലേക്ക് കുറഞ്ഞു.
- സെർച്ച്-ടു-ക്ലിക്ക് കൺവേർഷൻ 9% വർദ്ധിച്ചു.
- മീഡിയൻ ലേറ്റൻസി 28 ms-ൽ താഴെയായി നിലനിർത്തി, ഇത് പ്ലാറ്റ്ഫോമിന്റെ യൂസർ എക്സ്പീരിയൻസ് ലക്ഷ്യത്തിന് അനുസൃതമാണ്.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
ഈ മൈഗ്രേഷൻ എന്നത് വെറുതെ ഇൻസ്റ്റാൾ ചെയ്താൽ മാത്രം മതിയാകുന്ന ഒന്നല്ല. പ്രൈമറി ഡാറ്റാബേസിന് പകരം ഒരു സെർച്ച് എഞ്ചിൻ ഒരിക്കലും ഉപയോഗിക്കരുത് എന്ന് ടീം ഓർമ്മിപ്പിക്കുന്നു; എല്ലാ വീഡിയോ മെറ്റാഡേറ്റുകളുടെയും പ്രധാന സ്രോതസ്സ് ഇപ്പോഴും SQLite തന്നെയാണ്.
ചുരുക്കത്തിൽ
ഒരു പ്രത്യേക സെർച്ച് എഞ്ചിൻ ഉപയോഗിച്ച് അക്ഷരത്തെറ്റുകൾ പരിഹരിക്കാൻ സാധിച്ചത് ഉപയോക്താക്കളുടെ സെർച്ച് അനുഭവം കൂടുതൽ സുഗമവും വേഗതയുള്ളതുമാക്കി മാറ്റി. റിലേഷണൽ സ്റ്റോറിനെ പ്രധാന സ്രോതസ്സായി നിലനിർത്തുന്നതും, റിസൾട്ടുകളുടെ കൃത്യത വർദ്ധിപ്പിക്കുന്നതും, ഫസി ലോജിക് സുരക്ഷിതമാക്കുന്നതുമായ ഒരു കൃത്യമായ ആർക്കിടെക്ചർ വഴി, സ്ഥിരത നഷ്ടപ്പെടുത്താതെ തന്നെ മികച്ച ഫലങ്ങൾ നേടാൻ കഴിയുമെന്ന് ഈ പഠനം തെളിയിക്കുന്നു.