تیم مهندسی پشت یک سرویس میزبانی ویدیو، ایندکس SQLite FTS5 خود را با یک کلاستر OpenSearch جایگزین کرد که باعث کاهش پرسوجوهای بدون نتیجه از ۱۲٪ به ۱.۴٪ و افزایش نرخ کلیک بر روی نتایج جستجو به میزان ۹٪ شد، در حالی که تأخیر (latency) را زیر ۲۸ میلیثانیه نگه داشت.
چرا این تغییر ضروری شد
افزونه جستجوی متن کامل SQLite (FTS5) جذاب است: این افزونه در همان فایلی قرار دارد که بقیه دادهها هستند، هزینه لایسنس ندارد و برای تطبیقهای دقیق (exact token matches) بلافاصله نتایج را برمیگرداند. با این حال، لاگهای پلتفرم نشان داد که دوازده درصد از جستجوهای کاربران هیچ نتیجهای نداشت. غلطهای املایی مانند "intersteller" یا "avengrs endgame" – همان نوع غلطهایی که مردم در کیبوردهای موبایل مرتکب میشوند – مقصر اصلی بودند.
یک راهکار موقت (hack) با استفاده از trigrams (قطعات سه کاراکتری) نرخ جستجوهای خالی را به ۷٪ کاهش داد، اما دو مشکل ایجاد کرد. اول اینکه حجم ایندکس به بیش از سه برابر اندازه اصلی خود رسید که باعث افزایش هزینههای ذخیرهسازی و کند شدن بهروزرسانیها شد. دوم اینکه میزان مرتبط بودن نتایج (relevance) آسیب دید؛ تطبیق فازی (fuzzy matching) ترکیبی پر از نویز از ویدیوهای بیربط را برمیگرداند که به جای راهنمایی کاربران، آنها را گیج میکرد.
تیم به این نتیجه رسید که به یک موتور جستجوی اختصاصی، با قابلیت تحمل خطای املایی (typo-tolerance) بومی و امتیازدهی پیشرفته به مرتبط بودن نتایج، نیاز دارد.
ساخت خط لوله (pipeline) OpenSearch
حفظ SQLite به عنوان منبع اصلی حقیقت (source of truth)
OpenSearch به عنوان یک کپی (replica) خواندنی و موقتی عمل میکرد. تمام متادیتای ویدیوها در SQLite باقی ماند؛ بنابراین ایندکس جستجو را میتوانست بدون خطر از دست رفتن دادهها بازسازی کرد. زمانی که کلاستر OpenSearch از دسترس خارج میشد، اپلیکیشن به طور خودکار به موتور اصلی FTS5 بازمیگشت.
لایهبندی مرتبط بودن نتایج با یک پرسوجوی "should"
به جای تکیه صرف بر تطبیق فازی (fuzzy matching)، پرسوجو از ترکیب سه بند (clause) تشکیل شد:
- تطبیق عبارت دقیق (Exact phrase match) – بیشترین امتیاز (boost)، برای پاداش دادن به کاربرانی که عنوان را درست تایپ کردهاند.
- حضور تمام کلمات (All terms present) – امتیاز متوسط، برای شناسایی پرسوجوهایی که در آنها هر کلمه ظاهر شده اما لزوماً به ترتیب نیستند.
- تطبیق فازی (Fuzzy match) – امتیاز کم، به عنوان یک شبکه ایمنی برای توکنهای دارای غلط املایی.
این سلسلهمراتب، دقت را برای پرسوجوهای صحیح حفظ کرد و در عین حال یک جایگزین منعطف برای غلطهای املایی ارائه داد.
تنظیم تنظیمات فازی (fuzzy settings)
تعیین طول پیشوند (prefix length) برابر با ۱، باعث میشد که اولین کاراکتر هر عبارت قبل از فعال شدن منطق فازی، حتماً مطابقت داشته باشد. این قانون باعث سریع ماندن جستجو شد و از انفجار کلمات کاندید که میتواند حافظه را پر کند، جلوگیری کرد. تیم همچنین حداکثر تعداد گسترش عبارات (term expansions) را محدود کرد که راهکار دیگری برای جلوگیری از مصرف بیرویه منابع بود.
استراتژی همگامسازی
سه فرآیند مکمل، ایندکس OpenSearch را با SQLite همسو نگه میدارند:
- یک cron job برای همگامسازی دادههای جدید.
- بررسی تفاوتهای شبانه (Nightly diff pass) – جستجو برای یافتن ناهماهنگیهایی که از بهروزرسانیهای افزایشی عبور کردهاند.
- بازسازی کامل هفتگی – در پسزمینه یک نام مستعار ایندکس (index alias) اجرا میشود و سپس نام مستعار را در یک عملیات واحد جایگزین میکند که تضمینکننده عدم توقف سرویس (zero downtime) است.
تأثیر قابل اندازهگیری پس از دو هفته
- پرسوجوهای بدون نتیجه از ۱۲٪ به ۱.۴٪ کاهش یافت.
- نرخ تبدیل جستجو به کلیک ۹٪ افزایش یافت.
- میانه تأخیر (median latency) زیر ۲۸ میلیثانیه باقی ماند که کاملاً در محدوده هدف تجربه کاربری پلتفرم بود.
ملاحظات و نکات متقابل
این مهاجرت یک ارتقای ساده و آماده (plug-and-play) نیست. تیم تأکید میکند که پایگاه داده اصلی هرگز نباید با یک موتور جستجو جایگزین شود؛ SQLite همچنان منبع معتبر برای تمام متادیتای ویدیو باقی میماند.
خلاصه کلام
افزودن قابلیت تحمل خطای املایی از طریق یک موتور جستجوی اختصاصی، یک بنبست محسوس در مسیر کاربر را به تجربهای روان و سریع تبدیل کرد. این مطالعه موردی نشان میدهد که یک معماری منضبط – حفظ ذخیرهساز رابطهای به عنوان منبع اصلی حقیقت، لایهبندی مرتبط بودن نتایج و محافظت از منطق فازی – میتواند بدون قربانی کردن پایداری، دستاوردهای قابل اندازهگیری ارائه دهد.