Tim teknik di balik layanan hosting video mengganti indeks SQLite FTS5 mereka dengan klaster OpenSearch, memangkas kueri tanpa hasil dari 12% menjadi 1,4% dan meningkatkan tingkat klik-dari-pencarian sebesar 9% sambil tetap menjaga latensi di bawah 28 ms.
Mengapa peralihan ini menjadi mendesak
Ekstensi pencarian teks lengkap (FTS5) milik SQLite sangat menarik: ia berada di dalam file yang sama dengan data lainnya, tidak memerlukan biaya lisensi, dan memberikan hasil kecocokan secara instan untuk kecocokan token yang tepat. Namun, log platform menunjukkan bahwa sekitar dua belas persen pencarian pengguna tidak menghasilkan apa pun. Salah ketik seperti “intersteller” atau “avengrs endgame” – jenis typo yang sering dibuat orang pada keyboard seluler – adalah penyebab utamanya.
Sebuah solusi cepat menggunakan trigram (fragmen tiga karakter) menurunkan tingkat pencarian kosong menjadi 7%, tetapi menimbulkan dua masalah. Pertama, ukuran indeks membengkak hingga lebih dari tiga kali lipat ukuran aslinya, sehingga meningkatkan biaya penyimpanan dan memperlambat pembaruan. Kedua, relevansi menurun; pencocokan fuzzy menghasilkan campuran video yang tidak terkait secara berantakan, sehingga membingungkan pengguna alih-alih memandu mereka.
Tim menyimpulkan bahwa diperlukan mesin pencari yang dirancang khusus, dengan toleransi typo bawaan dan penilaian relevansi yang canggih.
Membangun pipeline OpenSearch
Tetap gunakan SQLite sebagai sumber kebenaran (source of truth)
OpenSearch berfungsi sebagai replika read-only yang dapat dibuang. Semua metadata video tetap berada di SQLite; indeks pencarian dapat dibangun kembali tanpa risiko kehilangan data. Ketika klaster OpenSearch mengalami gangguan, aplikasi secara otomatis beralih kembali ke mesin FTS5 yang asli.
Relevansi berlapis dengan kueri “should”
Alih-alih hanya mengandalkan pencocokan fuzzy, kueri tersebut menggabungkan tiga klausa:
- Exact phrase match – boost tertinggi, memberikan penghargaan bagi pengguna yang mengetik judul dengan benar.
- All terms present – boost menengah, menangkap kueri di mana setiap kata muncul tetapi tidak harus dalam urutan yang tepat.
- Fuzzy match – boost rendah, bertindak sebagai jaring pengaman untuk token yang salah ketik.
Hierarki ini menjaga presisi untuk kueri yang bersih sambil tetap menawarkan fallback yang toleran terhadap typo.
Menyetel pengaturan fuzzy
Panjang awalan (prefix length) sebesar 1 memaksa karakter pertama dari setiap istilah untuk cocok sebelum logika fuzzy diterapkan. Aturan ini menjaga pencarian tetap cepat dan mencegah ledakan istilah kandidat yang dapat membebani memori. Tim juga membatasi jumlah maksimum ekspansi istilah, sebuah pengaman lain terhadap penggunaan sumber daya yang tidak terkendali.
Strategi sinkronisasi
Tiga proses pelengkap menjaga indeks OpenSearch tetap selaras dengan SQLite:
- Cron job untuk menyinkronkan data baru.
- Nightly diff pass – memindai ketidakcocokan yang terlewat dari pembaruan inkremental.
- Weekly full rebuild – berjalan di balik alias indeks, lalu menukar alias tersebut dalam satu operasi tunggal, menjamin tanpa downtime.
Dampak terukur setelah dua minggu
- Kueri tanpa hasil turun dari 12% menjadi 1,4%.
- Konversi pencarian-ke-klik naik sebesar 9%.
- Median latensi tetap di bawah 28 ms, jauh di dalam target pengalaman pengguna platform.
Catatan dan poin kontra
Migrasi ini bukanlah peningkatan yang bersifat plug-and-play. Tim menekankan bahwa database utama tidak boleh digantikan oleh mesin pencari; SQLite tetap menjadi penyimpanan otoritatif untuk semua metadata video.
Intinya
Menambahkan toleransi typo melalui mesin pencari yang dirancang khusus mengubah jalan buntu yang nyata dalam perjalanan pengguna menjadi pengalaman yang lancar dan cepat. Studi kasus ini menunjukkan bahwa arsitektur yang disiplin – menjaga penyimpanan relasional sebagai sumber kebenaran, menyusun lapisan relevansi, dan mengamankan logika fuzzy – dapat memberikan keuntungan terukur tanpa mengorbankan stabilitas.