Les benchmarks des bases de données vectorielles révèlent d'importants écarts en temps de construction et en concurrence

Percona a publié un benchmark rigoureux comparant les performances de recherche vectorielle sur six moteurs de base de données, mettant en évidence des disparités significatives en matière de vitesse d'indexation, d'utilisation mémoire et de gestion de la concurrence. L'étude a évalué MariaDB, AliSQL, PostgreSQL avec pgvector, Valkey et Percona Search for MongoDB à l'aide d'un corpus de 990 000 embeddings OpenAI. Les résultats montrent que si certains moteurs excellent dans la construction rapide d'index, d'autres offrent une meilleure efficacité de stockage ou un débit élevé en situation de forte concurrence, fournissant ainsi des données cruciales pour les ingénieurs concevant des systèmes de génération augmentée par récupération (RAG).

Ce qui s'est passé

Le benchmark a chargé 990 000 vecteurs de 1 536 dimensions dans chaque moteur, construit un index HNSW et mesuré cinq métriques clés : le temps nécessaire pour créer un index interrogeable, l'empreinte de stockage et de mémoire, le rappel versus le débit, les performances sous clients concurrents et le comportement lors du renouvellement des données. Tous les tests ont été exécutés sur un matériel identique, un serveur Intel Xeon Gold 6230 doté de 80 processeurs logiques et de 187,5 Go de RAM, garantissant une comparaison équitable. L'orchestrateur a appliqué des limites de ressources cohérentes, telles qu'un pool de tampons InnoDB de 42,3 Go et des allocations mémoire spécifiques pour les caches de graphes, afin d'éviter tout biais de configuration.

Les résultats ont révélé des variations inattendues dans les opérations de base. Le temps de construction d'un index interrogeable variait de seulement 1,9 minute pour Percona Search à 6,7 heures pour AliSQL. L'efficacité du stockage variait également considérablement, MariaDB produisant le plus petit index à 3,9 GiB, tandis que Percona Search nécessitait 15,1 GiB. Fait notable, le moteur avec le plus petit index a pris le plus de temps pour le construire, illustrant un compromis courant entre compression et vitesse de construction. Ces conclusions suggèrent que le choix d'une base de données vectorielle nécessite de mettre en balance les besoins opérationnels immédiats, tels que la fréquence de ré-indexation, avec les coûts de stockage à long terme.

Les tests de concurrence ont exposé d'autres distinctions. Sous une charge de 32 clients concurrents, PostgreSQL avec pgvector a multiplié son débit par 21,7 par rapport aux performances d'un seul client. En revanche, les trois moteurs basés sur InnoDB—MariaDB 11.8, MariaDB 12.3 et AliSQL—ont montré presque aucune scalabilité, maintenant un débit d'environ 1x. Cependant, l'équipe de benchmark a retiré les chiffres spécifiques d'efficacité de concurrence pour ces trois moteurs après avoir découvert une limitation dans le banc d'essai. Le MariaDB Connector/C retenait le verrou de l'interpréteur Python pendant les attentes de socket, ce qui signifiait que certains clients attendaient le verrou plutôt que la base de données, faussant les métriques « en service ».

Comment cela fonctionne

Le benchmark a utilisé le jeu de données dbpedia-openai-1000k-angular, composé de 990 000 vecteurs float32. Chaque moteur a construit un index HNSW avec M=16, un paramètre standard contrôlant la connectivité de la structure de graphe. La performance des requêtes a été mesurée en utilisant différentes valeurs ef_search, qui déterminent le nombre de candidats explorés lors de la recherche. Le rappel a été calculé en utilisant la définition du seuil de distance issue d'ann-benchmarks, assurant la comparabilité avec la littérature existante. Pour les requêtes filtrées, la vérité terrain a été recalculée par force brute uniquement sur les lignes satisfaisant le prédicat, empêchant les moteurs d'être pénalisés pour l'exclusion correcte des éléments non correspondants.

Différents moteurs emploient des stratégies distinctes pour la recherche filtrée. PostgreSQL avec pgvector utilise une approche de post-filtrage où il collecte les candidats du graphe puis écarte ceux qui ne satisfont pas au prédicat. Si trop sont écartés, il s'arrête tôt, pouvant retourner moins de résultats que demandé. Percona Search utilise une stratégie de pré-filtrage, qui peut maintenir un débit plus élevé à mesure que les filtres se resserrent, mais peut sacrifier le rappel. MariaDB et AliSQL effectuent également un post-filtrage mais continuent la recherche, ce qui préserve le rappel mais peut augmenter considérablement la latence à mesure que la sélectivité du filtre diminue. Ces choix architecturaux impactent directement la capacité de chaque moteur à gérer des requêtes complexes du monde réel impliquant des filtres de métadonnées.

Détails clés

• Temps de construction de l'index : Percona Search était le plus rapide à 1,9 minute, tandis qu'AliSQL était le plus lent à 6,7 heures.
• Efficacité du stockage : MariaDB 11.8 et 12.3 ont produit les plus petits index à 3,9 GiB, contre 15,1 GiB pour Percona Search.
• Débit mono-client : À 0,99 de rappel, MariaDB 12.3 menait avec 277 QPS, suivi de Valkey à 264 QPS et de PostgreSQL à 210 QPS.
• Scalabilité de la concurrence : Le débit de PostgreSQL a augmenté de 21,7x avec 32 clients, tandis que les moteurs basés sur InnoDB montraient une scalabilité minimale due à la mise en file d'attente côté serveur.
• Recherche filtrée : La méthode de post-filtrage par défaut de PostgreSQL faisait chuter le rappel à 0,1034 à 1 % de sélectivité car elle s'arrêtait tôt après avoir écarté les candidats non correspondants.
• Renouvellement des données : MHNSW et VIDX mettent à jour le graphe à chaque insertion, rendant leur temps de chargement équivalent au temps de construction de l'index, contrairement à pgvector qui sépare la copie et la construction.

Pourquoi c'est important

Pour les ingénieurs logiciels développant des applications IA, ces benchmarks soulignent qu'aucun moteur unique ne domine toutes les catégories. Si votre application nécessite des ré-indexations fréquentes ou des mises à jour de modèles, la différence entre un temps de construction de 40 minutes pour PostgreSQL et une fenêtre de 6,7 heures pour AliSQL est opérationnellement significative. Inversement, si le coût de stockage est la contrainte principale, l'index compact de 3,9 GiB de MariaDB offre des économies substantielles par rapport aux autres options, malgré son processus de construction plus lent. Comprendre ces compromis aide les équipes à sélectionner une infrastructure alignée sur leurs schémas de charge de travail spécifiques, qu'elles privilégient la vitesse d'écriture, le débit de lecture ou la densité de stockage.

Les résultats de concurrence sont particulièrement pertinents pour les services à fort trafic. La capacité de PostgreSQL et de Valkey à faire évoluer le débit linéairement avec le nombre de clients suggère qu'ils sont mieux adaptés aux environnements comportant de nombreux utilisateurs simultanés. La performance plate des moteurs basés sur InnoDB sous charge concurrente indique des goulets d'étranglement potentiels dans leurs implémentations vectorielles actuelles ou leurs bibliothèques de connecteurs. Les ingénieurs doivent tenir compte de ces caractéristiques d'évolutibilité lors de la conception de l'architecture système, nécessitant potentiellement des stratégies supplémentaires d'équilibrage de charge ou de pooling de connexions pour les moteurs qui ne scalent pas bien nativement.

Ce que vous pouvez faire

• Évaluez votre fréquence de ré-indexation ; si vous mettez à jour les embeddings souvent, privilégiez les moteurs avec des temps de construction plus rapides comme PostgreSQL ou Valkey.
• Testez les performances de la recherche filtrée avec votre distribution spécifique de métadonnées, car les configurations par défaut peuvent entraîner un mauvais rappel ou une latence élevée.
• Considérez les coûts de stockage par rapport au temps de construction ; si l'espace disque est coûteux, les index plus petits de MariaDB peuvent justifier des fenêtres de construction plus longues.
• Effectuez des benchmarks de concurrence pour votre charge utilisateur prévue, en gardant à l'esprit que certains moteurs peuvent nécessiter plus d'instances pour gérer efficacement les requêtes parallèles.
• Examinez les bibliothèques de connecteurs pour les clients spécifiques au langage, car les limitations du banc d'essai dans cette étude suggèrent que les goulets d'étranglement au niveau du pilote peuvent masquer les performances de la base de données.
• Surveillez l'utilisation mémoire lors des constructions d'index, car le RSS de pointe variait de 14,3 Go à 48,8 Go, impactant les exigences de provisionnement de l'infrastructure.