Annonce de VDBBench 1.0 : benchmarking VectorDB open source avec vos charges de travail de production réelles
La plupart des benchmarks de bases de données vectorielles testent avec des données statiques et des index préconstruits. Mais les systèmes de production ne fonctionnent pas ainsi : les données circulent en continu pendant que les utilisateurs exécutent des requêtes, les filtres fragmentent les index, et les caractéristiques de performance évoluent radicalement sous des charges concurrentes de lecture/écriture.
Aujourd’hui, nous lançons VDBBench 1.0, un benchmark open source conçu dès le départ pour tester les bases de données vectorielles dans des conditions de production réalistes : ingestion de données en streaming, filtrage de métadonnées avec une sélectivité variable, et charges de travail concurrentes qui révèlent les véritables goulots d’étranglement du système.
Télécharger VDBBench 1.0 → | Voir le classement →
Pourquoi les benchmarks actuels sont trompeurs
Soyons honnêtes : il existe un phénomène étrange dans notre industrie. Tout le monde parle de « ne pas manipuler les benchmarks », et pourtant beaucoup adoptent précisément ce comportement. Depuis l’explosion du marché des bases de données vectorielles en 2023, nous avons vu de nombreux exemples de systèmes qui « excellent dans les benchmarks » mais « échouent lamentablement » en production, gaspillant du temps d’ingénierie et nuisant à la crédibilité des projets.
Nous avons constaté ce décalage de première main. Par exemple, Elasticsearch met en avant des vitesses de requête de l’ordre de la milliseconde, mais en coulisses, l’optimisation de son index peut à elle seule prendre plus de 20 heures. Quel système de production peut tolérer une telle indisponibilité ?
Le problème découle de trois failles fondamentales :
Jeux de données obsolètes : De nombreux benchmarks s’appuient encore sur des jeux de données hérités comme SIFT (128 dimensions), tandis que les embeddings modernes vont de 768 à 3 072 dimensions. Les caractéristiques de performance des systèmes fonctionnant sur des vecteurs 128D par rapport à des vecteurs 1024D+ sont fondamentalement différentes : les schémas d’accès mémoire, l’efficacité des index et la complexité computationnelle changent tous radicalement.
Métriques de vanité : Les benchmarks se concentrent sur la latence moyenne ou le QPS maximal, créant une image déformée. Un système avec une latence moyenne de 10 ms mais une latence P99 de 2 secondes offre une expérience utilisateur catastrophique. Le débit maximal mesuré sur 30 secondes ne vous dit rien sur les performances soutenues.
Scénarios trop simplifiés : La plupart des benchmarks testent des workflows basiques de type « écrire les données, construire l’index, interroger » — essentiellement des tests de niveau « Hello World ». La production réelle implique une ingestion continue de données tout en servant des requêtes, un filtrage complexe de métadonnées qui fragmente les index, et des opérations concurrentes de lecture/écriture qui se disputent les ressources.
Quoi de neuf dans VDBBench 1.0 ?
VDBBench ne se contente pas d’itérer sur des philosophies de benchmarking dépassées : il reconstruit le concept à partir des principes fondamentaux, avec une conviction directrice : un benchmark n’a de valeur que s’il prédit le comportement réel en production.
Nous avons conçu VDBBench pour reproduire fidèlement les conditions du monde réel selon trois dimensions critiques : l’authenticité des données, les modèles de charge de travail et les méthodologies de mesure des performances.
Examinons de plus près les nouvelles fonctionnalités proposées.
🚀 Tableau de bord repensé avec des visualisations pertinentes pour la production
La plupart des benchmarks se concentrent uniquement sur la sortie de données brutes, mais ce qui compte, c’est la façon dont les ingénieurs interprètent ces résultats et agissent en conséquence. Nous avons repensé l’interface utilisateur afin de privilégier la clarté et l’interactivité, ce qui vous permet d’identifier les écarts de performance entre les systèmes et de prendre rapidement des décisions d’infrastructure.
Le nouveau tableau de bord visualise non seulement les chiffres de performance, mais aussi les relations entre eux : comment le QPS se dégrade selon différents niveaux de sélectivité des filtres, comment le recall fluctue pendant l’ingestion en streaming, et comment les distributions de latence révèlent les caractéristiques de stabilité du système.
VDBbench dashboard
Nous avons retesté les principales plateformes de bases de données vectorielles, notamment Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone et OpenSearch, avec leurs dernières configurations et paramètres recommandés, afin de garantir que toutes les données de benchmark reflètent les capacités actuelles. Tous les résultats des tests sont disponibles sur le classement VDBBench.
🏷️ Filtrage par tags : le tueur de performance caché
Les requêtes réelles se produisent rarement de manière isolée. Les applications combinent la similarité vectorielle avec le filtrage de métadonnées (« trouver des chaussures qui ressemblent à cette photo mais coûtent moins de 100 $ »). Cette recherche vectorielle filtrée crée des défis uniques que la plupart des benchmarks ignorent complètement.
Les recherches filtrées introduisent de la complexité dans deux domaines critiques :
Complexité du filtre : davantage de champs scalaires et de conditions logiques complexes augmentent les exigences de calcul et peuvent entraîner un rappel insuffisant ainsi qu’une fragmentation de l’index de graphe.
Sélectivité du filtre : c’est le « tueur de performance caché » que nous avons vérifié à plusieurs reprises en production. Lorsque les conditions de filtrage deviennent très sélectives (en filtrant plus de 99 % des données), les vitesses de requête peuvent fluctuer de plusieurs ordres de grandeur, et le rappel peut devenir instable lorsque les structures d’index peinent avec des ensembles de résultats clairsemés.
VDBBench teste systématiquement différents niveaux de sélectivité de filtrage (de 50 % à 99,9 %), fournissant un profil de performance complet dans ce schéma de production critique. Les résultats révèlent souvent des chutes de performance spectaculaires qui n’apparaîtraient jamais dans les benchmarks traditionnels.
Exemple : lors des tests Cohere 1M, Milvus a maintenu un rappel constamment élevé à tous les niveaux de sélectivité de filtrage, tandis qu’OpenSearch a présenté des performances instables, avec un rappel fluctuant de manière significative selon les conditions de filtrage — tombant sous 0,8 dans de nombreux cas, ce qui est inacceptable pour la plupart des environnements de production.
Figure : QPS et rappel de Milvus et OpenSearch à différents niveaux de sélectivité de filtrage (test Cohere 1M).
🌊 Lecture/écriture en streaming : au-delà des tests d’index statiques
Les systèmes de production bénéficient rarement du luxe de données statiques. De nouvelles informations affluent en continu pendant que les recherches s’exécutent — un scénario dans lequel de nombreuses bases de données pourtant impressionnantes s’effondrent sous la double pression du maintien des performances de recherche et de la gestion des écritures continues.
Les scénarios de streaming de VDBBench simulent de véritables opérations parallèles, aidant les développeurs à comprendre la stabilité des systèmes dans des environnements à forte concurrence, en particulier la manière dont l’écriture des données affecte les performances des requêtes et dont les performances évoluent à mesure que le volume de données augmente.
Pour garantir des comparaisons équitables entre différents systèmes, VDBBench utilise une approche structurée :
Configurer des taux d’écriture contrôlés qui reflètent les charges de travail de production ciblées (par exemple, 500 lignes/s réparties sur 5 processus parallèles)
Déclencher des opérations de recherche après chaque tranche de 10 % d’ingestion des données, en alternant entre les modes sériel et concurrent
Enregistrer des métriques complètes : distributions de latence (y compris P99), QPS soutenu et précision du rappel
Suivre l’évolution des performances au fil du temps à mesure que le volume de données et la charge du système augmentent
Ces tests de charge contrôlés et incrémentaux révèlent dans quelle mesure les systèmes maintiennent stabilité et précision pendant une ingestion continue — un aspect que les benchmarks traditionnels capturent rarement.
Exemple : lors des tests de streaming Cohere 10M, Pinecone a maintenu un QPS et un rappel plus élevés tout au long du cycle d’écriture par rapport à Elasticsearch. Fait notable, les performances de Pinecone se sont nettement améliorées après la fin de l’ingestion, démontrant une forte stabilité sous charge soutenue, tandis qu’Elasticsearch a montré un comportement plus erratique pendant les phases d’ingestion active.
Figure : QPS et rappel de Pinecone vs. Elasticsearch dans le test de streaming Cohere 10M (taux d’ingestion de 500 lignes/s).
VDBBench va encore plus loin en prenant en charge une étape d’optimisation facultative, permettant aux utilisateurs de comparer les performances de recherche en streaming avant et après l’optimisation de l’index. Il suit et rapporte également le temps réel passé à chaque étape, offrant des informations plus approfondies sur l’efficacité du système et son comportement dans des conditions proches de la production.
Figure : QPS et rappel de Pinecone vs. Elasticsearch dans le test de streaming Cohere 10M après optimisation (taux d’ingestion de 500 lignes/s)
Comme le montrent nos tests, Elasticsearch a dépassé Pinecone en QPS — après l’optimisation de l’index. Mais lorsque l’axe des x reflète le temps réellement écoulé, il est clair qu’Elasticsearch a mis beaucoup plus de temps à atteindre ces performances. En production, ce délai compte. Cette comparaison révèle un compromis clé : débit maximal vs. délai de mise en service.
🔬 Des jeux de données modernes qui reflètent les charges de travail IA actuelles
Nous avons entièrement remanié les jeux de données utilisés pour le benchmarking des bases de données vectorielles. Au lieu d’anciens jeux de test comme SIFT et GloVe, VDBBench utilise des vecteurs générés à partir de modèles d’embedding de pointe comme OpenAI et Cohere, qui alimentent les applications d’IA d’aujourd’hui.
Pour garantir la pertinence, en particulier pour des cas d’utilisation comme la génération augmentée par récupération (RAG), nous avons sélectionné des corpus qui reflètent des scénarios d’entreprise et propres à certains domaines dans le monde réel :
| Corpus | Modèle d’embedding | Dimensions | Taille | Cas d’utilisation |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Base de connaissances générale |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Spécifique à un domaine (biomédical) |
| C4 | OpenAI | 1536 | 500K / 5M | Traitement de texte à l’échelle du Web |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Recherche à grande échelle |
Ces jeux de données simulent mieux les données vectorielles à haut volume et haute dimension d’aujourd’hui, permettant des tests réalistes de l’efficacité du stockage, des performances de requête et de la précision de récupération dans des conditions correspondant aux charges de travail IA modernes.
⚙️ Prise en charge des jeux de données personnalisés pour des tests spécifiques à l’industrie
Chaque entreprise est unique. Le secteur financier peut avoir besoin de tests axés sur les embeddings de transactions, tandis que les plateformes sociales s’intéressent davantage aux vecteurs de comportement des utilisateurs. VDBBench vous permet de réaliser des benchmarks avec vos propres données générées à partir de vos modèles d’embedding spécifiques pour vos charges de travail spécifiques.
Vous pouvez personnaliser :
Les dimensions des vecteurs et les types de données
Le schéma de métadonnées et les modèles de filtrage
Le volume de données et les modèles d’ingestion
Les distributions de requêtes qui correspondent à votre trafic de production
Après tout, aucun jeu de données ne raconte une meilleure histoire que vos propres données de production.
Comment VDBBench mesure ce qui compte réellement en production
Conception de métriques axée sur la production
VDBBench privilégie les métriques qui reflètent les performances réelles, et pas seulement les résultats de laboratoire. Nous avons repensé le benchmarking autour de ce qui compte réellement dans les environnements de production : la fiabilité sous charge, les caractéristiques de latence de queue, le débit soutenu et la préservation de la précision.
Latence P95/P99 pour l’expérience utilisateur réelle : La latence moyenne/médiane masque les valeurs aberrantes qui frustrent les utilisateurs réels et peuvent indiquer une instabilité sous-jacente du système. VDBBench se concentre sur la latence de queue comme P95/P99, révélant les performances que 95 % ou 99 % de vos requêtes atteindront réellement. C’est crucial pour la planification des SLA et la compréhension de l’expérience utilisateur dans le pire des cas.
Débit durable sous charge : Un système qui fonctionne bien pendant 5 secondes ne suffit pas en production. VDBBench augmente progressivement la concurrence pour trouver le nombre maximal de requêtes par seconde durable de votre base de données (
max_qps) — et non le pic atteint dans des conditions courtes et idéales. Cette méthodologie révèle dans quelle mesure votre système tient dans la durée et aide à une planification réaliste de la capacité.Rappel équilibré avec les performances: La vitesse sans précision n’a aucun sens. Chaque chiffre de performance dans VDBBench est associé à des mesures de rappel, afin que vous sachiez exactement quelle pertinence vous sacrifiez au profit du débit. Cela permet des comparaisons équitables, à périmètre identique, entre des systèmes aux compromis internes très différents.
Une méthodologie de test qui reflète la réalité
Une innovation clé dans la conception de VDBBench est la séparation des tests en série et des tests concurrents, ce qui aide à capturer le comportement des systèmes sous différents types de charge et révèle des caractéristiques de performance importantes pour différents cas d’utilisation.
Séparation de la mesure de latence:
serial_latency_p99mesure les performances du système sous une charge minimale, lorsqu’une seule requête est traitée à la fois. Cela représente le meilleur scénario possible pour la latence et aide à identifier les capacités de base du système.conc_latency_p99capture le comportement du système dans des conditions réalistes de forte concurrence, lorsque plusieurs requêtes arrivent simultanément et se disputent les ressources du système.
Structure du benchmark en deux phases:
Test en série: Exécution monoprocédée de 1 000 requêtes qui établit les performances et la précision de référence, en indiquant à la fois
serial_latency_p99et le rappel. Cette phase aide à identifier le plafond théorique de performance.Test de concurrence: Simule un environnement de production sous charge soutenue avec plusieurs innovations clés:
Simulation réaliste des clients: Chaque processus de test fonctionne indépendamment avec sa propre connexion et son propre ensemble de requêtes, évitant les interférences d’état partagé qui pourraient fausser les résultats
Démarrage synchronisé: Tous les processus commencent simultanément, garantissant que les QPS mesurés reflètent précisément les niveaux de concurrence annoncés
Ensembles de requêtes indépendants: Empêche des taux de réussite du cache irréalistes qui ne reflètent pas la diversité des requêtes en production
Ces méthodes soigneusement structurées garantissent que les valeurs max_qps et conc_latency_p99 indiquées par VDBBench sont à la fois précises et pertinentes pour la production, fournissant des informations utiles pour la planification de la capacité de production et la conception des systèmes.
Bien démarrer avec VDBBench 1.0
VDBBench 1.0 représente un changement fondamental vers un benchmarking pertinent pour la production. En couvrant l’écriture continue de données, le filtrage des métadonnées avec une sélectivité variable et les charges en streaming selon des schémas d’accès concurrents, il fournit l’approximation la plus proche des environnements de production réels disponible aujourd’hui.
L’écart entre les résultats de benchmark et les performances réelles ne devrait pas être un jeu de devinettes. Si vous prévoyez de déployer une base de données vectorielle en production, il vaut la peine de comprendre comment elle fonctionne au-delà des tests de laboratoire idéalisés. VDBBench est open-source, transparent et conçu pour prendre en charge des comparaisons significatives, à périmètre identique.
Ne vous laissez pas influencer par des chiffres impressionnants qui ne se traduisent pas en valeur de production. Utilisez VDBBench 1.0 pour tester les scénarios qui comptent pour votre entreprise, avec vos données, dans des conditions qui reflètent votre charge de travail réelle. L’ère des benchmarks trompeurs dans l’évaluation des bases de données vectorielles touche à sa fin—il est temps de prendre des décisions fondées sur des données pertinentes pour la production.
Essayez VDBBench avec vos propres charges de travail: https://github.com/zilliztech/VectorDBBench
Consultez les résultats de test des principales bases de données vectorielles: Classement VDBBench
Vous avez des questions ou souhaitez partager vos résultats? Rejoignez la conversation sur GitHub ou échangez avec notre communauté sur Discord.
Continuer à lire
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.