Il team di ingegneria dietro un servizio di video hosting ha sostituito il proprio indice SQLite FTS5 con un cluster OpenSearch, riducendo le query senza risultati dal 12% all'1,4% e aumentando il tasso di conversione search-to-click del 9%, mantenendo al contempo la latenza sotto i 28 ms.
Perché il passaggio è diventato urgente
L'estensione per la ricerca full-text di SQLite (FTS5) è molto attraente: risiede nello stesso file del resto dei dati, non comporta costi di licenza e restituisce i risultati istantaneamente per corrispondenze esatte di token. Tuttavia, i log della piattaforma hanno mostrato che circa il 12% delle ricerche degli utenti non restituiva alcun risultato. Gli errori di ortografia come "intersteller" o "avengrs endgame" – il tipo di refusi che le persone commettono sulle tastiere mobili – erano i principali responsabili.
Una rapida soluzione temporanea utilizzando i trigrammi (frammenti di tre caratteri) ha ridotto il tasso di ricerche vuote al 7%, ma ha introdotto due problemi. In primo luogo, l'indice è cresciuto fino a oltre tre volte la sua dimensione originale, gonfiando i costi di archiviazione e rallentando gli aggiornamenti. In secondo luogo, la pertinenza ne ha risentito; il fuzzy matching restituiva un mix caotico di video non correlati, confondendo gli utenti invece di guidarli.
Il team ha concluso che era necessario un motore di ricerca dedicato, con una tolleranza nativa ai refusi e un sistema sofisticato di punteggio della pertinenza (relevance scoring).
Costruire la pipeline OpenSearch
Mantenere SQLite come fonte di verità
OpenSearch fungeva da replica usa e getta in sola lettura. Tutti i metadati dei video rimanevano in SQLite; l'indice di ricerca poteva essere ricostruito senza rischiare la perdita di dati. Quando il cluster OpenSearch andava offline, l'applicazione tornava automaticamente al motore FTS5 originale.
Pertinenza a livelli con una query "should"
Invece di affidarsi esclusivamente al fuzzy matching, la query combinava tre clausole:
- Corrispondenza esatta della frase – boost massimo, premiando gli utenti che hanno digitato correttamente il titolo.
- Tutti i termini presenti – boost medio, intercettando le query in cui ogni parola appare, ma non necessariamente in ordine.
- Fuzzy match – boost basso, agendo come rete di sicurezza per i token scritti male.
Questa gerarchia ha preservato la precisione per le query corrette, offrendo comunque un sistema di fallback tollerante per i refusi.
Ottimizzazione delle impostazioni fuzzy
Una lunghezza del prefisso (prefix length) pari a 1 ha imposto che il primo carattere di ogni termine corrispondesse prima che la logica fuzzy entrasse in funzione. Questa regola ha mantenuto la ricerca veloce e ha evitato l'esplosione di termini candidati che può sovraccaricare la memoria. Il team ha inoltre limitato il numero massimo di espansioni dei termini, un ulteriore presidio contro l'uso incontrollato delle risorse.
Strategia di sincronizzazione
Tre processi complementari mantengono l'indice OpenSearch allineato con SQLite:
- Un cron job per sincronizzare i nuovi dati.
- Passaggio diff notturno – scansiona eventuali discrepanze che sono sfuggite agli aggiornamenti incrementali.
- Ricostruzione completa settimanale – viene eseguita dietro un alias dell'indice, per poi scambiare l'alias in un'unica operazione, garantendo zero tempi di inattività (downtime).
Impatto misurabile dopo due settimane
- Le query senza risultati sono scese dal 12% all'1,4%.
- La conversione search-to-click è aumentata del 9%.
- La latenza mediana è rimasta sotto i 28 ms, ampiamente entro l'obiettivo di esperienza utente della piattaforma.
Avvertenze e controargomentazioni
La migrazione non è un aggiornamento "plug-and-play". Il team sottolinea che il database primario non dovrebbe mai essere sostituito da un motore di ricerca; SQLite rimane il repository autorevole per tutti i metadati dei video.
In sintesi
L'aggiunta della tolleranza ai refusi tramite un motore di ricerca dedicato ha trasformato un evidente vicolo cieco nel percorso dell'utente in un'esperienza fluida e veloce. Il caso studio dimostra che un'architettura disciplinata – mantenendo il database relazionale come fonte di verità, stratificando la pertinenza e proteggendo la logica fuzzy – può produrre guadagni misurabili senza sacrificare la stabilità.