قام الفريق الهندسي المسؤول عن خدمة استضافة فيديوهات باستبدال فهرس SQLite FTS5 بمجموعة OpenSearch، مما أدى إلى خفض الاستعلامات التي لا تعيد نتائج من 12% إلى 1.4%، ورفع معدل التحويل من البحث إلى النقر بنسبة 9%، مع الحفاظ على زمن الاستجابة (latency) أقل من 28 مللي ثانية.
لماذا أصبح التبديل أمراً ملحاً
تعتبر إضافة البحث عن النص الكامل (FTS5) في SQLite جذابة: فهي توجد في نفس الملف الذي يحتوي على بقية البيانات، ولا تترتب عليها تكاليف ترخيص، وتعيد النتائج فوراً عند مطابقة الرموز (tokens) بدقة. ومع ذلك، أظهرت سجلات المنصة أن نسبة 12% من عمليات بحث المستخدمين لم تعيد أي نتائج على الإطلاق. كانت الأخطاء الإملائية مثل "intersteller" أو "avengrs endgame" –وهي نوع الأخطاء التي يرتكبها الأشخاص عند استخدام لوحات مفاتيح الهواتف المحمولة– هي المسبب الرئيسي.
أدت محاولة سريعة باستخدام الـ trigrams (أجزاء مكونة من ثلاثة أحرف) إلى خفض معدل البحث الفارغ إلى 7%، لكنها تسببت في مشكلتين. أولاً، تضخم الفهرس ليصبح أكثر من ثلاثة أضعاف حجمه الأصلي، مما أدى إلى زيادة تكاليف التخزين وإبطاء عمليات التحديث. ثانياً، تضررت دقة النتائج (relevance)؛ حيث أعطت المطابقة التقريبية (fuzzy matching) مزيجاً مشوشاً من الفيديوهات غير ذات الصلة، مما أدى إلى إرباك المستخدمين بدلاً من توجيههم.
خلص الفريق إلى الحاجة إلى محرك بحث مخصص، يتميز بقدرة أصلية على تحمل الأخطاء الإملائية (typo-tolerance) ونظام متطور لتقييم صلة النتائج (relevance scoring).
بناء مسار OpenSearch
الإبقاء على SQLite كمصدر أساسي للحقيقة (source of truth)
عمل OpenSearch كنسخة احتياطية للقراءة فقط وقابلة للاستبدال. ظلت جميع بيانات الفيديو الوصفية (metadata) في SQLite؛ حيث يمكن إعادة بناء فهرس البحث دون المخاطرة بفقدان البيانات. وعندما تتوقف مجموعة OpenSearch عن العمل، يعود التطبيق تلقائياً إلى محرك FTS5 الأصلي.
صلة نتائج متعددة الطبقات باستخدام استعلام "should"
بدلاً من الاعتماد على المطابقة التقريبية (fuzzy matching) وحدها، دمج الاستعلام ثلاثة بنود:
- مطابقة العبارة الدقيقة (Exact phrase match) – أعلى تعزيز (boost)، لمكافأة المستخدمين الذين كتبوا العنوان بشكل صحيح.
- وجود جميع المصطلحات (All terms present) – تعزيز متوسط، لالتقاط الاستعلامات التي تظهر فيها كل كلمة ولكن ليس بالضرورة بالترتيب.
- المطابقة التقريبية (Fuzzy match) – تعزيز منخفض، لتعمل كشبكة أمان للرموز (tokens) المكتوبة بشكل خاطئ.
حافظ هذا التسلسل الهرمي على الدقة للاستعلامات الصحيحة مع توفير بديل مرن للأخطاء الإملائية.
ضبط إعدادات المطابقة التقريبية (fuzzy settings)
فرض طول البادئة (prefix length) بمقدار 1 على مطابقة الحرف الأول من كل مصطلح قبل تفعيل المنطق التقريبي (fuzzy logic). حافظت هذه القاعدة على سرعة البحث ومنعت الانفجار في عدد المصطلحات المرشحة التي قد ترهق الذاكرة. كما وضع الفريق حداً أقصى لعدد توسعات المصطلحات (term expansions)، وهو إجراء وقائي آخر ضد الاستهلاك المفرط للموارد.
استراتيجية المزامنة
تعمل ثلاث عمليات متكاملة على إبقاء فهرس OpenSearch متوافقاً مع SQLite:
- مهمة cron لمزامنة البيانات الجديدة.
- عملية فحص الفروقات الليلية (Nightly diff pass) – للبحث عن عدم التطابق الذي قد يتسرب من التحديثات التدريجية.
- إعادة بناء كاملة أسبوعية – تعمل خلف اسم مستعار للفهرس (index alias)، ثم يتم تبديل الاسم المستعار في عملية واحدة، مما يضمن عدم توقف الخدمة (zero downtime).
تأثير ملموس بعد أسبوعين
- انخفضت الاستعلامات التي لا تعيد نتائج من 12% إلى 1.4%.
- ارتفع معدل التحويل من البحث إلى النقر بنسبة 9%.
- ظل متوسط زمن الاستجابة (median latency) أقل من 28 مللي ثانية، وهو ما يقع ضمن نطاق هدف تجربة المستخدم للمنصة.
تنبيهات ونقاط مقابلة
عملية الهجرة ليست ترقية "جاهزة للتشغيل" (plug-and-play). ويؤكد الفريق أنه لا ينبغي أبداً استبدال قاعدة البيانات الأساسية بمحرك بحث؛ حيث تظل SQLite هي المخزن المعتمد لجميع بيانات الفيديو الوصفية.
الخلاصة
أدى إضافة القدرة على تحمل الأخطاء الإملائية من خلال محرك بحث مخصص إلى تحويل طريق مسدود في رحلة المستخدم إلى تجربة سلسة وسريعة. توضح دراسة الحالة أن البنية التحتية المنضبطة – التي تحافظ على المخزن العلائقي كمصدر للحقيقة، وتطبق طبقات صلة النتائج، وتحمي المنطق التقريبي – يمكن أن تحقق مكاسب ملموسة دون التضحية بالاستقرار.