L'équipe d'ingénierie d'un service d'hébergement de vidéos a remplacé son index SQLite FTS5 par un cluster OpenSearch, faisant passer le taux de requêtes sans résultat de 12 % à 1,4 % et augmentant le taux de clic sur recherche de 9 %, tout en maintenant une latence inférieure à 28 ms.
Pourquoi le passage est devenu urgent
L'extension de recherche plein texte de SQLite (FTS5) est attrayante : elle réside dans le même fichier que le reste des données, ne comporte aucun coût de licence et renvoie instantanément les correspondances pour les jetons (tokens) exacts. Cependant, les journaux de la plateforme ont montré qu'une douzaine de pour cent des recherches des utilisateurs ne renvoyaient absolument rien. Les fautes d'orthographe telles que « intersteller » ou « avengrs endgame » – le genre de fautes de frappe que l'on fait sur les claviers mobiles – en étaient les principaux coupables.
Un correctif rapide utilisant des trigrammes (fragments de trois caractères) a réduit le taux de recherches vides à 7 %, mais a introduit deux problèmes. Premièrement, l'index a gonflé pour atteindre plus de trois fois sa taille d'origine, faisant grimper les coûts de stockage et ralentissant les mises à jour. Deuxièmement, la pertinence en a souffert ; la recherche floue (fuzzy matching) renvoyait un mélange bruyant de vidéos sans rapport, déroutant les utilisateurs au lieu de les guider.
L'équipe a conclu qu'un moteur de recherche dédié, doté d'une tolérance native aux fautes de frappe et d'un système de scoring de pertinence sophistiqué, était nécessaire.
Construction du pipeline OpenSearch
Conserver SQLite comme source de vérité
OpenSearch servait de réplica jetable et en lecture seule. Toutes les métadonnées vidéo restaient dans SQLite ; l'index de recherche pouvait être reconstruit sans risque de perte de données. En cas de panne du cluster OpenSearch, l'application basculait automatiquement sur le moteur FTS5 d'origine.
Pertinence par couches avec une requête « should »
Au lieu de s'appuyer uniquement sur la recherche floue, la requête combinait trois clauses :
- Correspondance de phrase exacte – boost le plus élevé, récompensant les utilisateurs qui ont correctement saisi le titre.
- Tous les termes présents – boost moyen, capturant les requêtes où chaque mot apparaît, mais pas nécessairement dans l'ordre.
- Correspondance floue (fuzzy match) – boost faible, agissant comme un filet de sécurité pour les jetons mal orthographiés.
Cette hiérarchie préservait la précision pour les requêtes propres tout en offrant une solution de repli permissive pour les fautes de frappe.
Réglage des paramètres de recherche floue
Une longueur de préfixe de 1 forçait la correspondance du premier caractère de chaque terme avant que la logique floue ne s'active. Cette règle permettait de maintenir la rapidité de la recherche et d'éviter l'explosion du nombre de termes candidats qui peut surcharger la mémoire. L'équipe a également plafonné le nombre maximum d'expansions de termes, un autre garde-fou contre l'utilisation incontrôlée des ressources.
Stratégie de synchronisation
Trois processus complémentaires maintiennent l'index OpenSearch aligné avec SQLite :
- Une tâche cron pour synchroniser les nouvelles données.
- Un passage de différence (diff) nocturne – recherche les incohérences qui auraient échappé aux mises à jour incrémentielles.
- Une reconstruction complète hebdomadaire – s'exécute derrière un alias d'index, puis remplace l'alias en une seule opération, garantissant une absence totale d'interruption de service.
Impact mesurable après deux semaines
- Les requêtes sans résultat sont passées de 12 % à 1,4 %.
- La conversion recherche-clic a augmenté de 9 %.
- La latence médiane est restée inférieure à 28 ms, bien en deçà de l'objectif d'expérience utilisateur de la plateforme.
Avertissements et contre-arguments
La migration n'est pas une mise à niveau prête à l'emploi. L'équipe souligne que la base de données principale ne doit jamais être remplacée par un moteur de recherche ; SQLite reste le magasin faisant autorité pour toutes les métadonnées vidéo.
L'essentiel
L'ajout d'une tolérance aux fautes de frappe via un moteur de recherche dédié a transformé une impasse notable dans le parcours utilisateur en une expérience fluide et rapide. Cette étude de cas montre qu'une architecture disciplinée – en conservant le magasin relationnel comme source de vérité, en superposant la pertinence et en sécurisant la logique floue – peut apporter des gains mesurables sans sacrifier la stabilité.