ParadeDB améliore ses performances de recherche BM25 après comparaison avec TIN

Contexte et enjeux du benchmark

PlanetScale a présenté TIN, une extension de recherche texte pour PostgreSQL, en affirmant une amélioration d'au moins huit fois par rapport à ParadeDB 0.25 sur leurs propres mesures. Le test partagé utilise le jeu de données StackExchange (150 M de documents), huit clients simultanés et une exécution de cinq minutes en mode lecture seule avec cache chaud. Les métriques publiées indiquent 81,9 QPS pour ParadeDB contre 33 QPS pour TIN, les valeurs plus élevées étant meilleures. Cette différence a incité l’équipe de ParadeDB à réexaminer son implémentation BM25 et à publier les optimisations qui ont permis de réduire l’écart.

Architecture de TIN versus ParadeDB

La différence fondamentale soulignée par PlanetScale réside dans l’utilisation du champ ctid de PostgreSQL comme identifiant de document. Un ctid représente la position physique d’une ligne dans le stockage en blocs (ex. (190,17) désigne la slot 17 du bloc 190). ParadeDB, basé sur la bibliothèque de recherche Tantivy, conserve un DocId u32 attribué selon l’ordre d’insertion et maintient une table de correspondance DocId ↔ ctid. TIN élimine cette table, ce qui, selon leurs benchmarks, réduit le nombre d’accès aléatoires lors des vérifications de visibilité et des opérations bitmap.

Optimisations appliquées par ParadeDB

Plutôt que de modifier l’identifiant de document, ParadeDB a ciblé trois leviers d’optimisation :

1. Réduction des accès aléatoires pendant le calcul BM25 : en exécutant la requête

EXPLAIN (ANALYZE, BUFFERS) SELECT id, title, by FROM hn_items WHERE title = 'database' ORDER BY pdb.score(id) DESC LIMIT 10;

sur le jeu de données Hacker News (28,7 M de documents), l’équipe a constaté que les fieldnorms (normes de champ) représentaient 83 % des accès aux pages, soit 1 513 pages, contre 311 pages pour les autres structures (postings, métadonnées). Cette concentration indique que le calcul de la longueur de chaque document était le principal goulot d’étranglement.

2. Attribution des accès aux pages : ParadeDB a introduit un mécanisme qui associe chaque accès à la structure de données responsable, permettant d’isoler rapidement les composantes les plus coûteuses et de les optimiser en priorité.

3. Optimisation du parcours des postings : en réorganisant la façon dont les listes de postings sont itérées, le moteur minimise les sauts de page et améliore la localisation des données en mémoire, réduisant ainsi le nombre de lectures disque lors de gros jeux de données comme StackExchange.

Analyse des performances et limites

Après ces ajustements, ParadeDB a réduit l’écart de QPS avec TIN, bien que les chiffres exacts post‑optimisation ne soient pas détaillés dans le texte. L’amélioration provient principalement d’une meilleure utilisation du cache et d’une réduction du coût des fieldnorms, plutôt que d’un changement d’identifiant de document. Cependant, la comparaison initiale reste partiellement biaisée : les paramètres de benchmark ont été modifiés (par exemple, désactivation de l’élision de termes fréquents) et TIN n’est pas open‑source, ce qui empêche une analyse de code approfondie. En conclusion, la performance de recherche texte dans PostgreSQL dépend davantage de la gestion des accès aux pages et de la structuration des listes de postings que du choix de l’identifiant de document. Les optimisations de ParadeDB démontrent que des gains substantiels sont possibles sans recourir à des modifications d’architecture majeures.