ایک ویڈیو ہوسٹنگ سروس کی انجینئرنگ ٹیم نے اپنے SQLite FTS5 انڈیکس کو OpenSearch کلسٹر سے تبدیل کر دیا، جس سے بغیر نتیجے والی (zero-result) کوئریز 12% سے کم ہو کر 1.4% رہ گئیں اور لیٹنسی (latency) کو 28 ms سے کم رکھتے ہوئے سرچ-ٹو-کلک ریٹ میں 9% اضافہ ہوا۔
یہ تبدیلی کیوں ضروری ہو گئی
SQLite کا فل ٹیکسٹ سرچ ایکسٹینشن (FTS5) پرکشش ہے: یہ باقی ڈیٹا کے ساتھ ایک ہی فائل میں رہتا ہے، اس کی کوئی لائسنسنگ لاگت نہیں ہے، اور یہ درست ٹوکن میچز کے لیے فوری طور پر نتائج فراہم کرتا ہے۔ تاہم، پلیٹ فارم کے لاگز سے پتہ چلا کہ صارفین کی بارہ فیصد تلاشوں کے کوئی نتائج نہیں مل رہے تھے۔ "intersteller" یا "avengrs endgame" جیسی غلط ہجے (misspellings) — وہ غلطیاں جو لوگ موبائل کی بورڈ پر کرتے ہیں — اس کی بنیادی وجہ تھیں۔
ٹرائگرامز (تین حروف کے ٹکڑے) کا استعمال کرتے ہوئے ایک فوری حل (hack) نے خالی سرچ کی شرح کو 7% تک کم کر دیا لیکن دو مسائل پیدا کر دیے۔ پہلا یہ کہ انڈیکس اپنے اصل سائز سے تین گنا زیادہ بڑھ گیا، جس سے اسٹوریج کے اخراجات بڑھ گئے اور اپ ڈیٹس سست ہو گئیں۔ دوسرا یہ کہ متعلقہ نتائج (relevance) متاثر ہوئے؛ فزی میچنگ (fuzzy matching) نے غیر متعلقہ ویڈیوز کا ایک الجھا ہوا مجموعہ پیش کیا، جس سے صارفین کی رہنمائی کرنے کے بجائے وہ الجھ گئے۔
ٹیم نے یہ نتیجہ اخذ کیا کہ ایک خاص مقصد کے لیے بنایا گیا سرچ انجن درکار ہے، جس میں قدرتی طور پر ٹائپو ٹالرنس (typo-tolerance) اور جدید ریلیوینس اسکورنگ موجود ہو۔
OpenSearch پائپ لائن کی تعمیر
SQLite کو اصل ذریعہ (source of truth) کے طور پر برقرار رکھیں
OpenSearch ایک عارضی، صرف پڑھنے کے قابل (read-only) ریپلیکا کے طور پر کام کرتا تھا۔ تمام ویڈیو میٹا ڈیٹا SQLite میں ہی رہا؛ سرچ انڈیکس کو ڈیٹا کے نقصان کے خطرے کے بغیر دوبارہ بنایا جا سکتا تھا۔ جب OpenSearch کلسٹر ڈاؤن ہوتا، تو ایپلی کیشن خود بخود اصل FTS5 انجن پر واپس آ جاتی۔
"should" کوئری کے ساتھ تہوں میں تقسیم شدہ ریلیوینس
صرف فزی میچنگ پر انحصار کرنے کے بجائے، کوئری میں تین شقیں (clauses) شامل کی گئیں:
- Exact phrase match – سب سے زیادہ بوسٹ (boost)، ان صارفین کے لیے جو عنوان بالکل درست ٹائپ کرتے ہیں۔
- All terms present – درمیانہ بوسٹ، ایسی کوئریز کو پکڑنے کے لیے جہاں ہر لفظ موجود ہو لیکن ضروری نہیں کہ وہ ترتیب میں ہوں۔
- Fuzzy match – کم بوسٹ، غلط ہجے والے ٹوکنز کے لیے ایک حفاظتی جال (safety net) کے طور پر کام کرتا ہے۔
اس درجہ بندی نے درست کوئریز کے لیے درستگی (precision) کو برقرار رکھا جبکہ ٹائپو کے لیے ایک آسان متبادل بھی فراہم کیا۔
فزی سیٹنگز کی ٹیوننگ
پری فکس لینتھ (prefix length) کو 1 رکھنے سے یہ لازمی ہو گیا کہ فزی لاجک کے کام کرنے سے پہلے ہر لفظ کا پہلا حرف میچ ہو۔ اس اصول نے سرچ کو تیز رکھا اور ممکنہ الفاظ کے اس پھیلاؤ کو روکا جو میموری پر بوجھ ڈال سکتا ہے۔ ٹیم نے ٹرمز کی توسیع (term expansions) کی زیادہ سے زیادہ تعداد کو بھی محدود کر دیا، جو وسائل کے بے جا استعمال کے خلاف ایک اور حفاظتی تدبیر تھی۔
سنکرونائزیشن کی حکمت عملی
تین تکمیلی عمل OpenSearch انڈیکس کو SQLite کے ساتھ ہم آہنگ رکھتے ہیں:
- نیا ڈیٹا سنک کرنے کے لیے ایک کرون جاب (cron job)۔
- نائٹلی ڈف پاس (Nightly diff pass) – ان غلطیوں کی جانچ کرتا ہے جو بتدریج اپ ڈیٹس کے دوران رہ گئی ہوں۔
- ہفتہ وار مکمل ری بلڈ (Weekly full rebuild) – ایک انڈیکس ایلیئس (index alias) کے پیچھے چلتا ہے، اور پھر ایک ہی آپریشن میں ایلیئس کو تبدیل کر دیتا ہے، جس سے ڈاؤن ٹائم (downtime) صفر رہتا ہے۔
دو ہفتوں کے بعد قابل پیمائش اثرات
- بغیر نتیجے والی کوئریز 12% سے کم ہو کر 1.4% رہ گئیں۔
- سرچ-ٹو-کلک کنورژن میں 9% اضافہ ہوا۔
- میڈین لیٹنسی (Median latency) 28 ms سے کم رہی، جو پلیٹ فارم کے یوزر ایکسپیرینس کے ہدف کے عین مطابق ہے۔
احتیاطی تدابیر اور مضادات
یہ مائیگریشن کوئی "پلاگ اینڈ پلے" اپ گریڈ نہیں ہے۔ ٹیم اس بات پر زور دیتی ہے کہ بنیادی ڈیٹا بیس کو کبھی بھی سرچ انجن سے تبدیل نہیں کیا جانا چاہیے؛ تمام ویڈیو میٹا ڈیٹا کے لیے SQLite ہی مستند اسٹور رہتا ہے۔
خلاصہ
ایک خاص مقصد کے لیے بنائے گئے سرچ انجن کے ذریعے ٹائپو ٹالرنس شامل کرنے سے صارف کے سفر میں آنے والی ایک واضح رکاوٹ ایک ہموار اور تیز تجربے میں بدل گئی۔ یہ کیس اسٹڈی دکھاتی ہے کہ ایک منظم آرکیٹیکچر — جس میں ریلیشنل اسٹور کو اصل ذریعہ (source of truth) کے طور پر رکھا جائے، ریلیوینس کی تہیں بنائی جائیں، اور فزی لاجک کا تحفظ کیا جائے — استحکام کو قربان کیے بغیر قابل پیمائش فوائد فراہم کر سکتا ہے۔