Recherche plein texte dans Postgres : Elasticsearch vs. les alternatives

Recherche plein texte (Full Text Search)

• La recherche plein texte est une technique qui permet de trouver des éléments dans un corpus de textes selon la présence de mots-clés et d’expressions spécifiques
• La plupart des moteurs de recherche, comme Elasticsearch, utilisent l’algorithme BM25 pour classer les résultats
  • BM25 prend en compte la fréquence d’apparition d’un terme ainsi que son caractère distinctif à l’échelle de l’ensemble des documents
• La recherche plein texte est différente de la recherche de similarité ou de la recherche vectorielle, qui recherchent et classent les résultats selon une signification sémantique
• De nombreuses applications modernes combinent la recherche plein texte et la recherche de similarité ; on parle alors de recherche hybride, qui permet d’obtenir des résultats plus précis

Postgres FTS

Avantages

1. Simplicité

   • Postgres FTS ne nécessite aucune infrastructure supplémentaire et peut être utilisé avec tout service Postgres managé, comme AWS RDS
   • À long terme, cela fait gagner beaucoup de temps et évite bien des soucis, car il n’est pas nécessaire d’orchestrer ni de gérer un moteur de recherche externe

2. Recherche en temps réel

   • Avec Postgres FTS, les données peuvent être recherchées dès le commit
   • C’est très utile pour les entreprises qui construisent des expériences de recherche orientées utilisateur ou sensibles à la latence, comme les sites e-commerce ou les fintechs

3. Transactions Postgres et MVCC

   • Les transactions ACID de Postgres et le contrôle de concurrence multi-version (MVCC) garantissent la fiabilité des résultats FTS en cas d’accès concurrents et de mises à jour fréquentes

Inconvénients

1. Fonctionnalités incomplètes

   • L’ensemble limité de fonctionnalités de Postgres FTS peut être rédhibitoire pour certaines entreprises
   • Parmi les fonctionnalités manquantes : le scoring BM25, l’ajustement de la pertinence, les tokenizers personnalisés et le faceting

2. Dégradation des performances sur de très gros volumes de données

   • Postgres FTS fonctionne bien sur des tables contenant plusieurs millions de lignes, mais ses performances chutent nettement sur des tables comptant des dizaines de millions de lignes

3. Surcharge transactionnelle

   • La création d’un index GIN sur une colonne ajoute une légère latence, généralement de l’ordre de la milliseconde, aux transactions qui affectent cette colonne

À retenir

• Postgres FTS est idéal pour la recherche sur des tables de petite à moyenne taille qui ne nécessitent pas de requêtes FTS sophistiquées
• Les notions de « taille moyenne » et de « sophistication » sont volontairement floues, car elles dépendent des exigences de performance
• Heureusement, il est très simple de tester Postgres FTS et de migrer vers ou depuis cette solution

Elasticsearch

Avantages

1. Ensemble de fonctionnalités complet

   • Elasticsearch peut traiter presque tous les types de requêtes FTS
   • L’Elastic Query DSL (langage spécifique au domaine) est un standard des fonctionnalités de recherche plein texte

2. Hautes performances

   • D’après les benchmarks, Elasticsearch peut interroger des milliards de lignes en quelques millisecondes grâce à son moteur de recherche Lucene éprouvé et à son architecture distribuée

3. Plus qu’un moteur de recherche

   • Au-delà du FTS, Elasticsearch est aussi un moteur de requêtes analytiques, une base de données vectorielle, ainsi qu’une plateforme de sécurité et d’observabilité
   • De nombreuses organisations apprécient la simplicité qu’offre la consolidation de plusieurs services au sein d’Elasticsearch

Inconvénients

1. Pas un datastore fiable

   • De nombreuses entreprises ont regretté d’avoir choisi Elasticsearch comme datastore principal
   • Ce n’est pas une approche recommandée. Elasticsearch ne dispose ni de transactions ACID ni de MVCC, ce qui peut entraîner des incohérences et des pertes de données ; ses capacités relationnelles et sa cohérence en temps réel limitées compliquent aussi de nombreuses requêtes de base de données

2. Nécessité d’un pipeline ETL

   • Comme Elasticsearch n’est pas un datastore fiable, les organisations qui utilisent Postgres mettent généralement en place un pipeline ETL pour extraire, transformer et charger les données de Postgres vers Elasticsearch
   • Toute panne du pipeline ETL peut provoquer divers incidents de production ; il faut donc veiller attentivement à ce que les changements du schéma Postgres sous-jacent ne cassent pas le pipeline

3. Perte de fraîcheur des données

   • Les traitements ETL prennent du temps et s’exécutent de manière périodique
   • Les données qui arrivent dans Elasticsearch ont souvent plusieurs heures de retard par rapport à Postgres
   • Pour les applications qui doivent effectuer des recherches en temps réel sur des tables Postgres, cela peut être rédhibitoire

4. Coût

   • Il est surprenant d’entendre, dans plusieurs entreprises, qu’Elasticsearch est devenu leur plus gros poste de dépense logicielle
   • À mesure que le coût des clusters Elasticsearch a explosé, beaucoup de ces entreprises sont passées d’Elasticsearch Cloud à l’auto-hébergement, ce qui a réduit leurs dépenses cloud mais créé de nouveaux problèmes
   • Elasticsearch a la réputation d’être très difficile à exploiter, ajuster et administrer
   • Ces organisations embauchent des ingénieurs coûteux pour gérer leurs clusters Elasticsearch

À retenir

• Elasticsearch offre d’excellentes performances de recherche au prix d’une surcharge opérationnelle et d’une moindre fraîcheur des données
• Elasticsearch est recommandé lorsqu’une alternative plus légère n’est pas envisageable ou si l’on prévoit d’utiliser d’autres services Elasticsearch

Moteurs de recherche alternatifs

• Ces dernières années, des moteurs de recherche modernes comme Algolia, Meilisearch et Typesense ont émergé
• Ces moteurs sont généralement utilisés pour construire des expériences de recherche orientées utilisateur
• La recherche de Hacker News est elle aussi construite sur Algolia
• Chaque service se différencie sur certains aspects, mais il existe un point important à noter pour les développeurs qui cherchent une solution de recherche pour Postgres
• Aucune de ces solutions n’a été conçue spécifiquement pour Postgres
• Les utilisateurs de Postgres sont donc susceptibles d’y rencontrer des problèmes similaires à ceux d’Elasticsearch

Peut-on avoir le meilleur des deux mondes ?

• ParadeDB est un moteur de recherche plein texte conçu pour Postgres
• Basé sur une extension nommée pg_search, ParadeDB intègre dans Postgres Tantivy, une alternative à Lucene écrite en Rust
• Comme Postgres FTS, ParadeDB se connecte à une base Postgres existante auto-hébergée, sans infrastructure supplémentaire
• Comme Elasticsearch, ParadeDB offre les fonctionnalités d’un moteur de recherche plein texte avancé
• La compatibilité avec les services Postgres managés comme Amazon RDS devrait arriver prochainement

[galadbran]

Je me demandais ce qu’était le FTS de Postgres, et il s’avère que cela désignait une fonctionnalité intégrée.

[xguru]

Ces gens-là continuent d’améliorer le projet et de publier des articles liés, donc il a déjà été partagé plusieurs fois sur GeekNews.

ParadeDB - PostgreSQL pour la recherche
pg_bm25 - Une extension de recherche full-text pour Postgres offrant une qualité au niveau d’Elastic

[cometkim]

Les paradedb, pg_search et pg_bm25 mentionnés dans l’article sont tous le même projet.