Bir video barındırma hizmetinin arkasındaki mühendislik ekibi, SQLite FTS5 indeksini bir OpenSearch kümesiyle değiştirerek, sıfır sonuçlu sorguları %12'den %1,4'e düşürdü ve gecikmeyi (latency) 28 ms'nin altında tutarken arama-tıklama oranını %9 artırdı.
Geçiş neden acil hale geldi
SQLite'ın tam metin arama uzantısı (FTS5) oldukça caziptir: Verilerin geri kalanıyla aynı dosyada bulunur, lisans maliyeti taşımaz ve tam belirteç (token) eşleşmeleri için sonuçları anında döndürür. Ancak platformun günlükleri (logs), kullanıcı aramalarının yüzde on ikisinin hiçbir sonuç döndürmediğini gösterdi. "intersteller" veya "avengrs endgame" gibi —insanların mobil klavyelerde yaptığı türden— yazım hataları temel suçlulardı.
Trigramler (üç karakterli parçalar) kullanarak yapılan hızlı bir çözüm, boş arama oranını %7'ye düşürdü ancak iki soruna yol açtı. Birincisi, indeks orijinal boyutunun üç katından fazlasına çıkarak depolama maliyetlerini artırdı ve güncellemeleri yavaşlattı. İkincisi, alaka düzeyi (relevance) zarar gördü; bulanık eşleştirme (fuzzy matching), kullanıcıları yönlendirmek yerine kafalarını karıştıran, birbiriyle ilgisiz videolardan oluşan gürültülü bir karışım sundu.
Ekip, yerleşik yazım hatası toleransına ve gelişmiş alaka düzeyi puanlamasına sahip, özel olarak yapılandırılmış bir arama motorunun gerekli olduğu sonucuna vardı.
OpenSearch hattının (pipeline) oluşturulması
SQLite'ı doğruluk kaynağı (source of truth) olarak tutmak
OpenSearch, geçici ve salt okunur bir kopya (replica) olarak hizmet verdi. Tüm video meta verileri SQLite'ta kaldı; arama indeksi veri kaybı riski olmadan yeniden oluşturulabiliyordu. OpenSearch kümesi çöktüğünde, uygulama otomatik olarak orijinal FTS5 motoruna geri döndü.
"should" sorgusu ile katmanlı alaka düzeyi
Sadece bulanık eşleştirmeye güvenmek yerine, sorgu üç maddeyi birleştirdi:
- Tam ifade eşleşmesi – en yüksek artış (boost), başlığı doğru yazan kullanıcıları ödüllendirir.
- Tüm terimlerin mevcut olması – orta düzey artış, her kelimenin geçtiği ancak mutlaka sırayla gelmediği sorguları yakalar.
- Bulanık eşleşme (Fuzzy match) – düşük artış, yanlış yazılmış belirteçler (tokens) için bir güvenlik ağı görevi görür.
Bu hiyerarşi, temiz sorgular için hassasiyeti korurken, yazım hataları için toleranslı bir yedek seçenek sundu.
Bulanık (fuzzy) ayarların optimize edilmesi
1 birimlik bir önek uzunluğu (prefix length), bulanık mantık devreye girmeden önce her terimin ilk karakterinin eşleşmesini zorunlu kıldı. Bu kural, aramanın hızlı kalmasını sağladı ve belleği aşırı yükleyebilecek aday terim patlamasını önledi. Ekip ayrıca, kontrolsüz kaynak kullanımına karşı bir başka koruma önlemi olarak, terim genişletmelerinin maksimum sayısına da sınır getirdi.
Senkronizasyon stratejisi
Üç tamamlayıcı süreç, OpenSearch indeksini SQLite ile uyumlu tutar:
- Yeni verileri senkronize etmek için bir cron işi.
- Gece boyunca yapılan fark taraması (diff pass) – artımlı güncellemelerden kaçan uyumsuzlukları tarar.
- Haftalık tam yeniden oluşturma – bir indeks takma adı (alias) arkasında çalışır ve ardından takma adı tek bir işlemle değiştirerek sıfır kesinti (zero downtime) sağlar.
İki hafta sonraki ölçülebilir etki
- Sıfır sonuçlu sorgular %12'den %1,4'e düştü.
- Arama-tıklama dönüşümü %9 arttı.
- Medyan gecikme (latency), platformun kullanıcı deneyimi hedefinin oldukça altında kalarak 28 ms'nin altında kaldı.
Uyarılar ve karşı görüşler
Bu taşıma işlemi, "tak ve çalıştır" tarzında bir yükseltme değildir. Ekip, birincil veritabanının asla bir arama motoruyla değiştirilmemesi gerektiğini vurguluyor; SQLite, tüm video meta verileri için yetkili depo (authoritative store) olmaya devam ediyor.
Özetle
Özel olarak yapılandırılmış bir arama motoru aracılığıyla yazım hatası toleransı eklemek, kullanıcı yolculuğundaki belirgin bir çıkmazı pürüzsüz ve hızlı bir deneyime dönüştürdü. Bu vaka çalışması; ilişkisel depoyu doğruluk kaynağı olarak tutan, alaka düzeyini katmanlandıran ve bulanık mantığı koruyan disiplinli bir mimarinin, kararlılıktan ödün vermeden ölçülebilir kazanımlar sağlayabileceğini gösteriyor.