SingleStore vs pgvector : choisir la bonne base de données vectorielle pour vos applications d’IA
Qu’est-ce qu’une base de données vectorielle ?
Avant de comparer SingleStore et pgvector, explorons d’abord le concept de bases de données vectorielles.
Une base de données vectorielle est spécifiquement conçue pour stocker et interroger des vecteurs de grande dimension, qui sont des représentations numériques de données non structurées. Ces vecteurs encodent des informations complexes, telles que le sens sémantique d’un texte, les caractéristiques visuelles d’images ou les attributs de produits. En permettant des recherches de similarité efficaces, les bases de données vectorielles jouent un rôle essentiel dans les applications d’IA, permettant une analyse et une récupération des données plus avancées.
Les cas d’utilisation courants des bases de données vectorielles incluent les recommandations de produits en e-commerce, les plateformes de découverte de contenu, la détection d’anomalies en cybersécurité, l’analyse d’images médicales et les tâches de traitement du langage naturel (NLP). Elles jouent également un rôle crucial dans la génération augmentée par récupération (RAG), une technique qui améliore les performances des grands modèles de langage (LLMs) en fournissant des connaissances externes afin de réduire des problèmes tels que les hallucinations de l’IA.
Il existe de nombreux types de bases de données vectorielles disponibles sur le marché, notamment :
- Bases de données vectorielles conçues à cet effet telles que Milvus, Zilliz Cloud (Milvus entièrement géré)
- Bibliothèques de recherche vectorielle telles que Faiss et Annoy.
- Bases de données vectorielles légères telles que Chroma et Milvus Lite.
- Bases de données traditionnelles avec des extensions de recherche vectorielle capables d’effectuer des recherches vectorielles à petite échelle.
SingleStore est un système de gestion de base de données SQL relationnel et distribué, et pgvector est une base de données traditionnelle. Tous deux disposent de la recherche vectorielle comme extension. Cet article compare leurs capacités de recherche vectorielle.
SingleStore : aperçu et technologie de base
SingleStore a rendu la recherche vectorielle possible en l’intégrant directement dans la base de données, de sorte que vous n’avez pas besoin de bases de données vectorielles séparées dans votre pile technologique. Les vecteurs peuvent être stockés dans des tables de base de données classiques et recherchés avec des requêtes SQL standard. Par exemple, vous pouvez rechercher des images de produits similaires tout en filtrant par fourchette de prix, ou explorer des embeddings de documents tout en limitant les résultats à des départements spécifiques. Le système prend en charge à la fois la recherche sémantique utilisant FLAT, IVF_FLAT, IVF_PQ, IVF_PQFS, HNSW_FLAT et HNSW_PQ pour l’index vectoriel, ainsi que le produit scalaire et la distance euclidienne pour la correspondance de similarité. C’est extrêmement utile pour des applications comme les systèmes de recommandation, la reconnaissance d’images et les chatbots IA, où la correspondance de similarité est rapide.
Au cœur de SingleStore se trouvent la performance et le passage à l’échelle. La base de données distribue les données sur plusieurs nœuds, ce qui vous permet de gérer des opérations de données vectorielles à grande échelle. À mesure que vos données augmentent, vous pouvez simplement ajouter davantage de nœuds et tout est prêt. Le processeur de requêtes peut combiner la recherche vectorielle avec des opérations SQL, vous n’avez donc pas besoin d’effectuer plusieurs requêtes séparées. Contrairement aux bases de données uniquement vectorielles, SingleStore vous offre ces capacités dans le cadre d’une base de données complète, afin que vous puissiez créer des fonctionnalités d’IA sans gérer plusieurs systèmes ni traiter des transferts de données complexes.
Pour l’indexation vectorielle, SingleStore offre deux options. La première est la recherche exacte des k plus proches voisins (kNN), qui trouve l’ensemble exact des k plus proches voisins pour un vecteur de requête. Mais pour les très grands jeux de données ou une forte concurrence, SingleStore prend également en charge la recherche des plus proches voisins approximatifs (ANN) à l’aide de l’indexation vectorielle. La recherche ANN peut trouver k voisins proches beaucoup plus rapidement que la recherche kNN exacte, parfois de plusieurs ordres de grandeur. Il existe un compromis entre vitesse et précision : ANN est plus rapide, mais peut ne pas renvoyer l’ensemble exact des k plus proches voisins. Pour les applications avec des milliards de vecteurs qui nécessitent des temps de réponse interactifs et n’ont pas besoin d’une précision absolue, la recherche ANN est la solution à privilégier.
L’implémentation technique des indices vectoriels dans SingleStore comporte des exigences spécifiques. Ces indices ne peuvent être créés que sur des tables columnstore et doivent être créés sur une seule colonne qui stocke les données vectorielles. Le système prend actuellement en charge le format Vector Type(dimensions[, F32]), F32 étant le seul type d’élément pris en charge. Cette approche structurée rend SingleStore excellent pour des applications comme la recherche sémantique utilisant des vecteurs issus de grands modèles de langage, la génération augmentée par récupération (RAG) pour une génération de texte ciblée et la correspondance d’images basée sur des embeddings vectoriels. En combinant cela avec des fonctionnalités de base de données traditionnelles, SingleStore permet aux développeurs de créer des applications d’IA complexes à l’aide de la syntaxe SQL tout en maintenant les performances et l’évolutivité.
pgvector : vue d’ensemble et notions de base
pgvector est une extension PostgreSQL qui vous permet d’effectuer des opérations vectorielles directement dans votre base de données PostgreSQL. Cela signifie que vous pouvez stocker et interroger des embeddings vectoriels sans base de données vectorielle séparée.
pgvector dispose de capacités complètes d’opérations vectorielles : recherche native de similarité vectorielle, recherche exacte et approximative des plus proches voisins, et intégration avec l’indexation de PostgreSQL. Il prend en charge l’arithmétique vectorielle : addition et soustraction, ainsi que plusieurs métriques de distance : euclidienne, cosinus, produit interne.
Mécanismes de recherche et types d’indices
Par défaut, pgvector utilise la recherche exacte des plus proches voisins, qui offre un rappel parfait mais peut être lente avec de grands jeux de données. Pour de meilleures performances, pgvector propose la recherche approximative des plus proches voisins via l’indexation, ce qui échange une partie de la précision contre une vitesse nettement meilleure.
HNSW (Hierarchical Navigable Small World) : Introduit dans pgvector 0.5.0, HNSW crée une structure de graphe multicouche pour une traversée de recherche rapide. Il est connu pour ses excellentes performances et ses bons résultats, mais nécessite plus de mémoire qu’IVFFlat. Cet index convient aux applications qui nécessitent une recherche rapide et précise.
IVFFlat (Inverted File Flat) : La méthode IVFFlat regroupe les vecteurs dans l’espace vectoriel et utilise un processus de recherche en deux étapes. D’abord, elle trouve les clusters pertinents, puis effectue une recherche exacte au sein des clusters sélectionnés. Elle est plus efficace en mémoire que HNSW, mais peut être légèrement plus lente ou moins précise dans certains cas.
Limitations techniques
Une limitation technique de pgvector est sa limite dimensionnelle. Avec une taille de page par défaut de 8 KiB, l’extension peut stocker des données vectorielles en pleine précision (32 bits/4 octets) jusqu’à 2000 dimensions, car cela utilise 7,8125 KiB par vecteur. Avec la quantification scalaire (halfvec/16 bits/2 octets), les dimensions maximales augmentent à 4000, tout en utilisant 7,8125 KiB par vecteur.
Impact sur les modèles de langage modernes
Cela limite les applications RAG (Retrieval-Augmented Generation). La plupart des modèles d’embedding les plus performants du classement MTEB de HuggingFace dépassent ces limites dimensionnelles. Même avec la quantification scalaire halfvec, seuls trois modèles sont compatibles : gte-qwen2-7B-instruct, gte-qwen2-7B-instruct-fp16, bge-multilingual-gemma2.
Conseils d’implémentation
Lorsque vous utilisez pgvector, vous devriez expérimenter avec les index HNSW et IVFFlat afin de trouver le meilleur pour votre cas d’utilisation. Votre décision dépendra de plusieurs facteurs : taille du jeu de données, exigences de vitesse des requêtes, compromis de précision acceptables, contraintes de mémoire. Ajustez finement les paramètres d’index et évaluez différentes configurations pour trouver le point d’équilibre idéal pour votre cas d’utilisation.
Performance
Lorsque vous utilisez pgvector, gardez à l’esprit que l’ajout d’index approximatifs modifiera les résultats des requêtes, contrairement aux index de base de données traditionnels. C’est un point à prendre en compte pendant la phase de développement et de test afin de s’assurer que le compromis précision-performance correspond aux besoins de votre application. Surveillez et ajustez votre configuration à mesure que vos données et vos schémas d’utilisation évoluent.
Key Differences
Search Methodology
SingleStore : SingleStore propose des recherches de plus proches voisins exactes et approximatives (ANN). Son indexation vectorielle prend en charge FLAT, IVF_FLAT, IVF_PQ, HNSW_FLAT et HNSW_PQ. Cela vous offre des recherches de similarité hautes performances avec produit scalaire ou distance euclidienne. ANN est idéal pour les grands ensembles de données à faible latence lorsque vous pouvez tolérer certains compromis de précision.
pgvector : pgvector propose des opérations vectorielles natives dans PostgreSQL, y compris des recherches exactes et ANN. Il utilise HNSW et IVFFlat pour ANN ; HNSW est plus rapide mais plus gourmand en mémoire, tandis qu’IVFFlat équilibre mémoire et vitesse. Bien que pgvector soit très flexible, sa recherche exacte par défaut aura des difficultés avec les grands ensembles de données, sauf si vous l’optimisez avec ces index.
Data Handling
SingleStore : SingleStore place les données vectorielles dans des tables columnstore afin que vous puissiez interroger de manière transparente des données structurées et non structurées. Son approche pilotée par SQL combine la recherche vectorielle avec des requêtes de base de données standard, ce qui la rend idéale pour des cas d’usage hybrides comme la recherche d’embeddings de produits filtrés par prix ou par catégorie.
pgvector : En tant qu’extension de PostgreSQL, pgvector est étroitement couplé à la gestion des données relationnelles. Il vous permet de stocker des embeddings vectoriels aux côtés de données relationnelles traditionnelles, ce qui facilite la conception de votre schéma pour les applications qui ont besoin des deux types de données. Toutefois, les limites de dimension des vecteurs (2000-4000 selon la précision) peuvent limiter certaines applications LLM modernes.
Scalability and Performance
SingleStore : SingleStore évolue horizontalement en distribuant les données sur plusieurs nœuds ; les performances restent les mêmes à mesure que les données augmentent. Son architecture distribuée et son processeur de requêtes peuvent effectuer des opérations vectorielles et SQL en parallèle, ce qui réduit la surcharge des requêtes. L’indexation ANN rend les requêtes plus rapides pour les grands ensembles de données.
pgvector : L’évolutivité de pgvector repose sur les forces de PostgreSQL. Il peut bien gérer des ensembles de données modérés, mais peut rencontrer des difficultés avec de grands ensembles de données ou des charges de travail à forte concurrence. Le réglage des index et le clustering peuvent aider, mais la mise à l’échelle horizontale peut nécessiter des solutions de contournement supplémentaires comme le partitionnement.
Flexibility and Customization
SingleStore : SingleStore est simple ; vous pouvez effectuer une recherche vectorielle avec du SQL standard. Bien que cela facilite l’implémentation, les options d’indexation vectorielle sont limitées à des configurations spécifiques comme les tables columnstore, ce qui peut limiter la flexibilité pour des configurations personnalisées.
pgvector : pgvector est plus flexible, prend en charge l’arithmétique vectorielle et plusieurs métriques de similarité (euclidienne, cosinus, produit interne). Il convient mieux aux développeurs qui souhaitent expérimenter avec une indexation personnalisée, affiner les paramètres ou s’intégrer à l’écosystème PostgreSQL.
Integration and Ecosystem
SingleStore : En tant que base de données autonome, SingleStore est tout-en-un, ce qui réduit le besoin de systèmes séparés. Cette approche tout-en-un minimise la complexité d’intégration, mais peut manquer de l’écosystème des outils basés sur PostgreSQL.
pgvector : pgvector bénéficie de l’écosystème PostgreSQL, y compris la compatibilité avec les frameworks, outils et extensions populaires. C’est un choix solide si votre stack est déjà construite sur PostgreSQL.
Ease of Use
SingleStore : La conception axée sur SQL rend la configuration et l’interrogation faciles, idéale pour les équipes qui veulent déployer rapidement avec une courbe d’apprentissage minimale. Mais l’adaptation à ses contraintes d’indexation vectorielle peut nécessiter quelques ajustements.
pgvector : Les développeurs familiers avec PostgreSQL trouveront pgvector facile à utiliser. L’expérimentation et le réglage des index ajoutent une certaine complexité, mais aussi des possibilités d’optimisation spécifiques à votre cas d’usage.
Cost
SingleStore : En tant que base de données hautes performances de niveau entreprise, SingleStore peut avoir des coûts opérationnels plus élevés, en particulier pour les services managés ou les déploiements à grande échelle. La consolidation des systèmes peut compenser les coûts pour les organisations ayant des besoins de données variés.
pgvector : La nature open source de pgvector le rend rentable pour les petits projets. Mais la gestion de l’infrastructure PostgreSQL à grande échelle peut introduire des coûts cachés, comme du matériel supplémentaire ou de la maintenance.
Sécurité
SingleStore : SingleStore dispose de fonctionnalités de sécurité de niveau entreprise, comme le chiffrement des données, le contrôle d’accès basé sur les rôles et les journaux d’audit. Elles sont destinées aux cas d’utilisation ayant des exigences élevées en matière de conformité.
pgvector : pgvector hérite des fonctionnalités de sécurité de PostgreSQL.
Quand utiliser SingleStore
SingleStore est destiné aux grands systèmes de données distribués qui nécessitent de hautes performances et une grande évolutivité. Il peut combiner la recherche vectorielle avec des requêtes SQL pour réunir des données structurées et non structurées dans des applications comme les systèmes de recommandation alimentés par l’IA, la recherche de produits avec filtres et la recherche sémantique pour les charges de travail d’entreprise. L’architecture distribuée de SingleStore, ses options d’indexation ANN et sa conception tout-en-un le rendent parfait pour les scénarios où vous devez gérer des milliards de vecteurs avec des temps de réponse interactifs.
Quand utiliser pgvector
pgvector est destiné aux environnements déjà sur PostgreSQL ou lorsque la simplicité et le coût importent. Il convient aux applications de recherche vectorielle à plus petite échelle ou aux projets qui doivent combiner la recherche en texte intégral, les requêtes relationnelles traditionnelles et les opérations vectorielles dans la même base de données. Il est flexible avec les métriques de distance, les options d’indexation et s’intègre bien au riche écosystème de PostgreSQL pour les développeurs qui expérimentent avec des modèles d’embedding ou ajoutent la recherche vectorielle à une infrastructure PostgreSQL existante.
Conclusion
SingleStore et pgvector ont tous deux leurs propres forces en matière de recherche vectorielle. SingleStore est excellent pour les jeux de données distribués à grande échelle avec intégration SQL et hautes performances, tandis que pgvector est excellent pour la flexibilité, la facilité d’utilisation avec PostgreSQL et la rentabilité. Le choix dépend de votre cas d’utilisation – avez-vous besoin d’une évolutivité de niveau entreprise ou d’une solution légère au sein d’un environnement PostgreSQL existant. En évaluant vos types de données, vos besoins en performance et vos exigences d’écosystème, vous pouvez choisir l’outil qui convient à votre projet.
Lisez ceci pour obtenir un aperçu de SingleStore et de pgvector, mais pour les évaluer, vous devez le faire en fonction de votre cas d’utilisation. Un outil qui peut vous y aider est VectorDBBench, un outil de benchmarking open-source pour la comparaison de bases de données vectorielles. Au final, un benchmarking approfondi avec vos propres jeux de données et schémas de requêtes sera essentiel pour prendre une décision entre ces deux approches puissantes mais différentes de la recherche vectorielle dans les systèmes de bases de données distribuées.
Utiliser VectorDBBench open-source pour évaluer et comparer les bases de données vectorielles par vous-même
VectorDBBench est un outil de benchmarking open-source destiné aux utilisateurs qui ont besoin de systèmes de stockage et de récupération de données hautes performances, en particulier des bases de données vectorielles. Cet outil permet aux utilisateurs de tester et de comparer différents systèmes de bases de données vectorielles comme Milvus et Zilliz Cloud (le Milvus managé) en utilisant leurs propres jeux de données et de trouver celui qui correspond à leurs cas d’utilisation. Avec VectorDBBench, les utilisateurs peuvent prendre des décisions fondées sur les performances réelles des bases de données vectorielles plutôt que sur des affirmations marketing ou des ouï-dire.
VectorDBBench est écrit en Python et sous licence open-source MIT, ce qui signifie que chacun peut l’utiliser, le modifier et le distribuer librement. L’outil est activement maintenu par une communauté de développeurs engagés dans l’amélioration de ses fonctionnalités et de ses performances.
Téléchargez VectorDBBench depuis son dépôt GitHub pour reproduire nos résultats de benchmark ou obtenir des résultats de performance sur vos propres jeux de données.
Jetez un coup d’œil rapide aux performances des bases de données vectorielles grand public sur le VectorDBBench Leaderboard.
Lisez les blogs suivants pour en savoir plus sur l’évaluation des bases de données vectorielles.
Ressources supplémentaires sur VectorDB, GenAI et ML
Continuer à lire
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.
The Definitive Guide to Choosing a Vector Database
Overwhelmed by all the options? Learn key features to look for & how to evaluate with your own data. Choose with confidence.