Démystifier la divergence des résultats de benchmark : Milvus vs. Qdrant
Avec la popularité croissante de la GenAI, un nombre de plus en plus important de bases de données vectorielles est apparu sur le marché. Au début de l’année dernière, nous avons lancé VectorDB Bench afin de fournir des informations sur les performances des technologies émergentes de bases de données vectorielles.
Récemment, des développeurs fortement investis dans ce domaine nous ont contactés chez Zilliz, cherchant à comprendre les écarts importants entre les résultats de benchmark de Qdrant et nos conclusions dans VectorDB Bench. En particulier, ils avaient besoin d’éclaircissements sur les faibles performances de Milvus dans les résultats de benchmark de Qdrant. En réponse à ces demandes, notre équipe d’ingénierie chez Zilliz a lancé une enquête approfondie afin d’identifier les causes profondes de ces écarts.
Cet article de blog fournit une analyse technique approfondie des différences de benchmark, avec une attention particulière portée à l’écart de performance de Milvus. Sans plus attendre, entrons dans les détails de cette enquête.
Raison n° 1 : version obsolète de Milvus
Les écarts dans les résultats de benchmark proviennent principalement des différentes versions de Milvus utilisées lors des tests. Le rapport de benchmark de Qdrant, basé sur Milvus v2.1 et publié le 10 août 2022, ne reflète pas pleinement les avancées significatives réalisées dans les versions ultérieures. Consultez les données brutes de ce rapport. Depuis lors, Milvus a bénéficié d’améliorations considérables.
Dans Milvus v2.2.1, nous avons mis à niveau le moteur vectoriel (également connu sous le nom de Knowhere) et révisé la stratégie de parallélisme. Les mises à jour ultérieures de v2.2.3 ont apporté d’autres améliorations des performances de recherche. Notre livre blanc met en évidence ces avancées, démontrant que Milvus 2.2.3 est quatre fois plus rapide que Milvus 2.0 en termes de performances de requête (latence et débit) et d’évolutivité (collections à l’échelle du milliard et multiples réplicas).
Par la suite, v2.2.9 a amélioré les performances de recherche filtrée. Dans v2.2.12, nous avons introduit une meilleure efficacité de recherche avec une surcharge minimale pour les grandes valeurs de top-K, amélioré les performances d’écriture dans les scénarios avec clé de partition activée ou partitions multiples, et optimisé l’utilisation du CPU pour les machines plus puissantes. De plus, v2.3.2 a marqué une amélioration significative des performances grâce à une réduction de la copie des données lors du chargement et à de meilleures insertions en masse.
Ces améliorations continues ont profondément transformé les capacités de Milvus. Par conséquent, les benchmarks basés sur Milvus 2.1 ne reflètent plus avec précision les performances actuelles de la technologie. Pour mieux comprendre les dernières capacités de Milvus, les développeurs sont encouragés à consulter VectorDB Bench, qui utilise Milvus 2.3 pour les tests.
Raison n° 2 : utilisation incorrecte de Milvus
Le benchmark de Qdrant sur les performances de Milvus résulte en partie de la manière dont il n’a utilisé que des Growing Segments. Comme son nom l’indique, Milvus optimise avec deux types de segments : les Growing Segments et les Sealed Segments. Les Growing Segments reçoivent encore des données jusqu’à atteindre un seuil prédéfini. Ces segments privilégient une ingestion rapide des données et utilisent une stratégie de recherche par force brute, ce qui entraîne des performances de requête plus lentes.
D’autre part, les segments scellés ne reçoivent plus de données et disposent donc d’un index, ce qui entraîne des gains de performances significatifs. Milvus scelle automatiquement les segments en croissance lorsqu’ils atteignent un seuil prédéfini, permettant ainsi à ces données de bénéficier également des gains de performances lorsqu’elles sont utilisées avec un index.
Le benchmark de Qdrant s’est uniquement concentré sur l’utilisation des segments en croissance, ce qui a naturellement conduit aux performances plus lentes rapportées. Se concentrer uniquement sur les segments en croissance diffère de la manière dont Milvus est utilisé dans les applications réelles et va à l’encontre de l’objectif de la stratégie de segmentation contenue dans Milvus.
De plus, afin d’aider les utilisateurs à équilibrer la fraîcheur des données et l’efficacité de la recherche, Milvus v2.3 a introduit la prise en charge de l’index IVF-FLAT pour les index en croissance. En outre, Milvus v2.3.4 a introduit l’index Binlog pour les segments en croissance. Cette mise à jour permet l’utilisation d’index avancés tels qu’IVF ou Fast Scan dans ces segments, améliorant potentiellement les performances de recherche jusqu’à dix fois. Par conséquent, cette amélioration de fonctionnalité a rendu les résultats précédents du benchmark de Qdrant encore moins pertinents.
Raison n°3 : optimisation de Qdrant axée sur les benchmarks
Les performances exceptionnelles de Qdrant dans les benchmarks face à d’autres fournisseurs découlent de son utilisation de segments de très grande taille pour les benchmarks. Bien que cette stratégie ait produit des résultats remarquables dans les benchmarks, son applicabilité dans le monde réel est sujette à caution. Dans les bases de données vectorielles, la taille des segments est cruciale. L’accent mis par Qdrant sur les grands segments a amélioré les scores des benchmarks, mais pourrait compromettre la flexibilité opérationnelle dans l’utilisation quotidienne.
Les bases de données vectorielles efficaces doivent gérer des charges de travail diverses et des exigences de données évolutives. Les segments de très grande taille, bien qu’efficaces dans les benchmarks, peuvent avoir du mal avec les requêtes variées typiques des situations réelles. Ils introduisent une complexité de gestion et pourraient accroître les besoins en ressources.
Bien que les optimisations de Qdrant axées sur les benchmarks, comme les segments de très grande taille, affichent des performances impressionnantes, leur caractère pratique dans des environnements dynamiques et réels suscite des inquiétudes. Cela remet en question la pertinence globale de tels résultats de benchmarks dans les déploiements réels de bases de données vectorielles.
Réflexions finales : une voie vers des décisions équitables et éclairées
Lorsqu’il s’agit de bases de données vectorielles, des benchmarks fiables et complets sont essentiels. VectorDB Bench, conçu par Zilliz, fournit aux développeurs des données de performance issues de cas réels. Reconnaissant la difficulté d’atteindre une impartialité absolue dans les benchmarks, nous partageons nos analyses afin d’enrichir les connaissances collectives dans ce domaine.
Le ANN Benchmark est un outil précieux pour ceux qui recherchent des évaluations impartiales, fournissant des évaluations standardisées des bases de données vectorielles. À mesure que la technologie progresse dans ce domaine, nous soulignons la nécessité d’efforts de benchmarking clairs, transparents et collaboratifs. Les développeurs doivent accéder à des benchmarks fiables et précis ou effectuer leurs propres tests sur leurs données afin de prendre des décisions éclairées lors du choix d’une base de données vectorielle.
Continuer à lire
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.
Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights
Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.
Zilliz Cloud BYOC Upgrades: Bring Enterprise-Grade Security, Networking Isolation, and More
Discover how Zilliz Cloud BYOC brings enterprise-grade security, networking isolation, and infrastructure automation to vector database deployments in AWS