એક વીડિયો-હોસ્ટિંગ સર્વિસની એન્જિનિયરિંગ ટીમે તેના SQLite FTS5 ઇન્ડેક્સને OpenSearch ક્લસ્ટર સાથે બદલી નાખ્યું, જેનાથી શૂન્ય-પરિણામ ધરાવતી ક્વેરીઝ (zero-result queries) 12% થી ઘટાડીને 1.4% કરી દીધી અને લેટન્સી (latency) ને 28 ms થી નીચે રાખીને સર્ચ-ટુ-ક્લિક રેટમાં 9% નો વધારો કર્યો.
આ બદલાવ શા માટે તાકીદનો બન્યો
SQLiteનું ફૂલ-ટેક્સ્ટ સર્ચ એક્સટેન્શન (FTS5) આકર્ષક છે: તે બાકીના ડેટાની જેમ જ એક જ ફાઇલમાં રહે છે, તેની કોઈ લાયસન્સિંગ કિંમત નથી, અને ચોક્કસ ટોકન મેચ માટે તરત જ પરિણામો આપે છે. જોકે, પ્લેટફોર્મના લોગ્સ દર્શાવે છે કે વપરાશકર્તાઓની બાર ટકા સર્ચમાં કંઈ જ પરિણામ મળતું નહોતું. "intersteller" અથવા "avengrs endgame" જેવી જોડણીની ભૂલો (misspellings) – જે પ્રકારની ટાઇપો મોબાઈલ કીબોર્ડ પર લોકો કરતા હોય છે – તે આનું મુખ્ય કારણ હતી.
ટ્રિગ્રામ્સ (ત્રણ-અક્ષરના ટુકડાઓ) નો ઉપયોગ કરીને કરવામાં આવેલા એક ઝડપી હૅકથી ખાલી-સર્ચ રેટ 7% સુધી ઘટ્યો, પરંતુ તેનાથી બે સમસ્યાઓ ઊભી થઈ. પ્રથમ, ઇન્ડેક્સ તેના મૂળ કદ કરતાં ત્રણ ગણાથી વધુ મોટો થઈ ગયો, જેનાથી સ્ટોરેજ ખર્ચ વધ્યો અને અપડેટ્સ ધીમા પડ્યા. બીજું, રિલેવન્સ (સંબંધિતતા) ઘટી ગઈ; ફઝી મેચિંગ (fuzzy matching) દ્વારા અસંબંધિત વીડિયોનું મિશ્રણ મળતું હતું, જે વપરાશકર્તાઓને માર્ગદર્શન આપવાને બદલે મૂંઝવણમાં મૂકતું હતું.
ટીમે એ તારણ કાઢ્યું કે નેટિવ ટાઇપો-ટોલરન્સ (typo-tolerance) અને અત્યાધુનિક રિલેવન્સ સ્કોરિંગ ધરાવતા, ખાસ કરીને સર્ચ માટે બનાવેલા સર્ચ એન્જિનની જરૂર હતી.
OpenSearch પાઇપલાઇન બનાવવી
SQLite ને 'સોર્સ ઓફ ટ્રુથ' તરીકે રાખો
OpenSearch એક ડિસ્પોઝેબલ, રીડ-ઓન્લી રેપ્લિકા તરીકે કામ કરતું હતું. તમામ વીડિયો મેટાડેટા SQLite માં જ રહ્યો; ડેટા ગુમાવવાનું જોખમ લીધા વિના સર્ચ ઇન્ડેક્સ ફરીથી બનાવી શકાય તેમ હતો. જ્યારે OpenSearch ક્લસ્ટર બંધ થઈ જાય, ત્યારે એપ્લિકેશન આપમેળે મૂળ FTS5 એન્જિન પર પાછી આવી જતી હતી.
“should” ક્વેરી સાથે લેયર્ડ રિલેવન્સ
માત્ર ફઝી મેચિંગ પર આધાર રાખવાને બદલે, ક્વેરીમાં ત્રણ ક્લોઝ (clauses) ને જોડવામાં આવ્યા હતા:
- Exact phrase match – સૌથી વધુ બૂસ્ટ, જે વપરાશકર્તાઓને પ્રોત્સાહિત કરે છે જેમણે શીર્ષક સાચું ટાઇપ કર્યું હોય.
- All terms present – મધ્યમ બૂસ્ટ, જે એવી ક્વેરીઓને પકડે છે જ્યાં દરેક શબ્દ દેખાય છે પરંતુ તે અનિવાર્યપણે ક્રમમાં હોતા નથી.
- Fuzzy match – ઓછું બૂસ્ટ, જે ખોટી જોડણી ધરાવતા ટોકન્સ માટે સેફ્ટી નેટ તરીકે કામ કરે છે.
આ પદાનુક્રમ (hierarchy) ચોક્કસ ક્વેરી માટે સચોટતા જાળવી રાખે છે અને સાથે જ ટાઇપો માટે સુગમ વિકલ્પ (fallback) પણ આપે છે.
ફઝી સેટિંગ્સનું ટ્યુનિંગ
પ્રીફિક્સ લંબાઈ (prefix length) 1 રાખવાથી ફઝી લોજિક લાગુ થાય તે પહેલાં દરેક શબ્દના પ્રથમ અક્ષરનું મેચ થવું ફરજિયાત બન્યું. આ નિયમે સર્ચને ઝડપી રાખ્યું અને મેમરી પર ભાર વધારી શકે તેવા ઉમેદવાર શબ્દોના (candidate terms) અતિશય વધારાને અટકાવ્યો. ટીમે ટર્મ એક્સપાન્શનની મહત્તમ સંખ્યા પર પણ મર્યાદા નક્કી કરી, જે સંસાધનોના અતિશય વપરાશ સામે બીજો એક રક્ષણાત્મક ઉપાય હતો.
સિંક્રનાઇઝેશન વ્યૂહરચના
ત્રણ પૂરક પ્રક્રિયાઓ OpenSearch ઇન્ડેક્સને SQLite સાથે સુસંગત રાખે છે:
- નવો ડેટા સિંક કરવા માટે ક્રૉન જોબ (cron job).
- નાઈટલી ડિફ પાસ (Nightly diff pass) – ઇન્ક્રીમેન્ટલ અપડેટ્સમાંથી રહી ગયેલા તફાવતો માટે સ્કેન કરે છે.
- સાપ્તાહિક ફૂલ રીબિલ્ડ (Weekly full rebuild) – ઇન્ડેક્સ એલિયાસ (index alias) પાછળ ચાલે છે, અને પછી સિંગલ ઓપરેશનમાં એલિયાસ બદલી નાખે છે, જે ઝીરો ડાઉનટાઇમની ખાતરી આપે છે.
બે અઠવાડિયા પછી માપી શકાય તેવો પ્રભાવ
- શૂન્ય-પરિણામ ધરાવતી ક્વેરીઝ 12% થી ઘટીને 1.4% થઈ ગઈ.
- સર્ચ-ટુ-ક્લિક કન્વર્ઝનમાં 9% નો વધારો થયો.
- મીડિયન લેટન્સી (Median latency) 28 ms થી નીચે રહી, જે પ્લેટફોર્મના યુઝર-એક્સપિરિયન્સ લક્ષ્યાંક મુજબ જ છે.
સાવચેતીઓ અને વિરોધાભાસી મુદ્દાઓ
આ માઈગ્રેશન કોઈ 'પ્લગ-એન્ડ-પ્લે' અપગ્રેડ નથી. ટીમ ભાર મૂકે છે કે પ્રાઇમરી ડેટાબેઝને ક્યારેય સર્ચ એન્જિન દ્વારા બદલવો જોઈએ નહીં; તમામ વીડિયો મેટાડેટા માટે SQLite એ અધિકૃત સ્ટોર (authoritative store) તરીકે રહે છે.
નિષ્કર્ષ
ખાસ કરીને બનાવેલા સર્ચ એન્જિન દ્વારા ટાઇપો-ટોલરન્સ ઉમેરવાથી યુઝર જર્નીમાં આવતો અવરોધ એક સરળ અને ઝડપી અનુભવમાં બદલાઈ ગયો. આ કેસ સ્ટડી દર્શાવે છે કે એક શિસ્તબદ્ધ આર્કિટેક્ચર – રિલેશનલ સ્ટોરને 'સોર્સ ઓફ ટ્રુથ' તરીકે રાખવું, રિલેવન્સના સ્તરો બનાવવા અને ફઝી લોજિકનું રક્ષણ કરવું – સ્થિરતા સાથે બાંધછોડ કર્યા વિના માપી શકાય તેવા ફાયદા આપી શકે છે.