Contexte technique
Cortex, la plateforme de recherche interne de l’entreprise, utilisait initialement un moteur Lucene dédié pour indexer et interroger les contenus. Cette architecture reposait sur des index hors‑processus, un serveur de recherche séparé et une couche de synchronisation personnalisée. Le modèle de requête était limité à la syntaxe Lucene, et la consommation mémoire du service atteignait des niveaux élevés, notamment à cause du cache d’index et des structures de scoring.
Migration vers PostgreSQL full‑text search
Le projet a remplacé le backend Lucene par la recherche plein texte native de PostgreSQL, en ajoutant un analyseur de requêtes propriétaire et un système de pondération des résultats. Les index sont alimentés en continu via Change Data Capture (CDC), ce qui garantit que chaque modification de donnée devient immédiatement interrogeable. Cette approche a éliminé le besoin d’un serveur de recherche distinct, consolidant les données et les index dans la même base transactionnelle.
Performances mesurées
Après la migration, le percentile 95 (p95) de latence des appels d’API publics est passé de 13,3 s à 1,54 s, soit une amélioration de plus de 90 %. Le profil mémoire global a diminué d’environ 40 %, grâce à la suppression du cache Lucene et à l’utilisation des structures d’index de PostgreSQL, plus compactes. De plus, la plupart des modifications sont désormais recherchables en quelques secondes, contre plusieurs minutes auparavant, ce qui réduit le délai de mise à jour des résultats pour les utilisateurs finaux.
Implications et limites
Cette transition montre que PostgreSQL peut supporter des charges de recherche à grande échelle lorsqu’il est couplé à un parseur de requêtes adapté et à une alimentation CDC fiable. Cependant, la perte de certaines fonctionnalités avancées de Lucene, comme les analyzers linguistiques spécialisés et les requêtes géospatiales complexes, peut contraindre les cas d’usage très spécifiques. La scalabilité dépendra également de la capacité du cluster PostgreSQL à gérer le volume d’indexation en temps réel, notamment sous des pics de trafic. Enfin, la maintenance du code de parsing personnalisé introduit une surface de complexité supplémentaire qui doit être surveillée.
