Bir geliştirici ekibi, OpenSearch'ü SQLite FTS5 ile eşleştirerek gecikmeyi 20 ms'nin altında tutarken, sonuçsuz kalan video aramalarını %11,4'ten %2,1'e düşürdü. Artık “blackpink jenny solo stag” yazan kullanıcılar, boş bir liste yerine doğru sonuç olan “BLACKPINK Jennie SOLO stage” ifadesini görüyor.

Bu değişikliğe neden ihtiyaç duyuldu

Bir video barındırma platformunun arama günlükleri tekrarlayan bir sorunu ortaya koydu: Latin alfabesiyle yazılmış bir başlıktaki tek bir yazım hatası, tüm eşleşmeleri yok edebiliyordu. Çince, Japonca ve Korece (CJK) metinlerde alt dizgileri (substring) eşleştirme yeteneğiyle takdir edilen SQLite'ın FTS5 uzantısı, bulanık eşleştirme (fuzzy matching) yapmıyor. Bir isimdeki veya şarkı başlığındaki tek bir yanlış yazılmış karakter, sorguyu tamamen bozuyor.

Mevcut iş akışı, SQLite'ı tek indeks olarak kullanıyordu. CJK sorgularını iyi yönetiyor ancak Latin alfabesiyle yapılan yazım hataları için bir güvenlik ağı sunmuyordu. Bu nedenle ekip, kanıtlanmış FTS5 katmanını göz ardı etmeden yazım hatası toleransı sağlayabilecek tamamlayıcı bir arama motorusu arayışına girdi.

OpenSearch nasıl eklendi

OpenSearch ön hat arama servisi olarak çalışırken, SQLite "doğruluk kaynağı" (source of truth) olarak kalmaya devam ediyor. İki sistem paralel olarak çalışıyor: Önce kullanıcı sorgusunu OpenSearch alıyor ve eğer yeterince hızlı yanıt verirse sonuçları gösteriliyor. OpenSearch zaman aşımına uğrarsa veya hata verirse, istek SQLite FTS5 indeksine geri dönüyor (fallback). Bu "hata korumalı" (fail-safe) tasarım, bir ağ aksaklığının arama çubuğunu asla boş bırakmamasını garanti ediyor.

Çoklu alan eşlemesi (Multi-field mapping)

Her video başlığı OpenSearch'te üç farklı şekilde indeksleniyor:

  • title.std – ASCII folding içeren standart bir analizör tarafından işlenir. Bu, aksanlı karakterleri normalize eder ve Latin alfabesiyle yapılan çoğu yazım hatasını yönetir.
  • title.cjk – bigramler (iki karakterli belirteçler) oluşturan bir CJK analizörü tarafından işlenir. Bu, FTS5'in Asya dilleri için sağladığı alt dizgi eşleştirme gücünü korur.
  • title.keyword – tam eşleşme aramaları ve sıralama için değiştirilmeden saklanır.

Ayrı alanlar, sorgunun tokenizasyon stratejilerini birbirine karıştırmadan her bir alfabe için doğru analizi uygulamasını sağlar.

Boost katmanları

Ekip, tek bir monolitik sorgu yerine sonuçları otomatik olarak sıralayan katmanlı bir sorgu oluşturdu:

  1. title.keyword üzerindeki tam ifade eşleşmeleri en yüksek boost değerini alır; böylece mükemmel eşleşmeler listenin başında yer alır.
  2. title.cjk üzerindeki CJK bigram eşleşmeleri orta düzeyde boost alır ve Asya dillerindeki arama kalitesini korur.
  3. title.std üzerindeki bulanık (fuzzy) Latin eşleşmeleri daha düşük bir boost alır; bu da yazım hatası toleranslı sonuçların, tam eşleşmeleri gölgelemeden görünmesini sağlar.

Katmanlı yaklaşım, ince ayar yapmayı kolaylaştırır: Bir boost değerini ayarlamak, tüm bir eşleşme sınıfının göreceli önemini değiştirir.

Akıllı bulanıklık (Smart fuzziness)

Sınırlı sayıda karakter değişikliğine izin veren "fuzziness" (bulanıklık), yalnızca Latin alanına uygulanır. Ekip, title.cjk için bulanıklığı devre dışı bıraktı çünkü CJK dillerinde tek bir karakter değişikliği genellikle anlamı tamamen değiştirir. Latin metinleri için sorgu, izin verilen düzenleme mesafesini kelime uzunluğuna göre ölçeklendiren ve tolerans ile alaka düzeyi arasında bir denge kuran OpenSearch'ün AUTO bulanıklık ayarını kullanır.

Performans ve geri dönüş (fallback) mantığı

Arama rutini, OpenSearch çağrısını bir try-catch bloğu içine alır:

  • Eğer OpenSearch 400 ms içinde yanıt verirse, sonuçları görüntülenir.
  • Eğer çağrı bir hata (exception) fırlatırsa veya zaman aşımını geçerse, sistem sorguyu anında SQLite FTS5 üzerinde yeniden çalıştırır.

Bu, ağ gecikmesinin veya hizmet kesintilerinin kullanıcı deneyimini asla bozmamasını sağlar. Arama gecikmesi 20 ms'nin altında kaldı.

Ölçülebilir etki

  • Latin alfabesiyle yapılan sorgularda sonuçsuz kalma oranları %11,4'ten %2,1'e düştü.
  • CJK sorguları için arama kalitesi değişmeden kaldı; bu da yeni CJK analizörünün orijinal FTS5 indeksinin güçlü yanlarını koruduğunu doğruladı.
  • Uçtan uca gecikme, 20 ms hedefinin rahatlıkla altında kaldı; yani eklenen katman kullanıcı arayüzünü (UI) yavaşlatmadı.

Dersler ve ödünleşimler (trade-offs)

  • Ayrı folding ve fuzziness kullanımı – Folding (karakterleri normalize etme) ve fuzziness (yazım hatalarını yönetme) farklı sorunları çözer. Bunları ayrı alanlarda tutmak, istenmeyen etkileşimleri önler.
  • Arama indeksini tek doğruluk kaynağı (source of truth) olarak kabul etmeyin – SQLite temel depolama alanı olmaya devam eder; OpenSearch ise türetilmiş ve yenilenebilir bir görünümdür. Bu, indeks kaymasını (index drift) önler ve hatalardan sonra kurtarma sürecini basitleştirir.
  • Boost katmanları ince ayarı kolaylaştırır – İlgili eşleşmeleri tek bir boost faktörü altında gruplandırmak, ayarlanması gereken parametre sayısını azaltır.

Sırada ne var?

Deney, mütevazı bir OpenSearch katmanının, SQLite FTS5'in kanıtlanmış CJK yeteneklerinden ödün vermeden çok dilli video başlıkları için yazım hatası toleransını önemli ölçüde artırabileceğini kanıtlıyor. Arama alakasallığının izleme süresini doğrudan etkilediği platformlar için bu iyileştirme, somut bir kullanıcı deneyimi kazanımına dönüşmektedir.