Bases de données vectorielles vs bases de données NewSQL
Introduction
Les bases de données vectorielles excellent dans le stockage et l’interrogation d’incorporations vectorielles à haute dimension, permettant aux applications d’IA de trouver des similarités sémantiques et perceptuelles grâce à des structures d’index spécialisées optimisées pour la recherche de plus proches voisins. Les bases de données NewSQL combinent les garanties ACID et le modèle relationnel des bases de données SQL traditionnelles avec la scalabilité horizontale et les caractéristiques de performance auparavant associées uniquement aux systèmes NoSQL.
Mais c’est là que les choses deviennent intéressantes : à mesure que les applications d’entreprise intègrent de plus en plus des capacités d’IA aux côtés de charges de travail transactionnelles critiques, les frontières entre ces catégories de bases de données spécialisées commencent à s’estomper. Les systèmes NewSQL ajoutent la prise en charge des vecteurs, tandis que les bases de données vectorielles renforcent leurs capacités transactionnelles et leurs garanties de cohérence des données.
Pour les architectes et les développeurs qui conçoivent des systèmes de données en 2025, comprendre quand tirer parti de chaque technologie — et quand elles peuvent se compléter — est devenu essentiel pour créer des applications qui équilibrent fonctionnalités d’IA avancées et fiabilité et cohérence de niveau entreprise. La décision exige un examen attentif de vos charges de travail spécifiques, de vos modèles d’accès aux données et de vos exigences de cohérence, plutôt que de simplement choisir l’option la plus tendance.
Le paysage actuel des bases de données : la spécialisation règne
Vous souvenez-vous de l’époque où les bases de données relationnelles étaient considérées comme la solution universelle pour pratiquement tous les besoins de persistance des données ? Cette époque est bel et bien derrière nous. Le paysage moderne des données a évolué vers un riche écosystème de solutions conçues pour des usages spécifiques, chacune optimisée pour des types de données, des modèles d’accès et des caractéristiques opérationnelles particuliers.
Dans ce paysage de plus en plus spécialisé :
Les bases de données relationnelles traditionnelles continuent d’exceller dans les charges de travail transactionnelles avec des schémas bien définis et de fortes exigences de cohérence
Les bases de données documentaires gèrent des données flexibles de type JSON avec des structures imbriquées et une flexibilité de schéma
Les magasins clé-valeur offrent un accès simple aux données ultrarapide avec une surcharge minimale
Les bases de données orientées graphe rendent les données riches en relations efficacement interrogeables et navigables
Les bases de données de séries temporelles gèrent efficacement les points de données chronologiques avec un stockage et des requêtes optimisés pour le temps
Les magasins à colonnes larges distribuent d’immenses jeux de données structurées sur des clusters avec des optimisations orientées colonnes
Les bases de données vectorielles et les systèmes NewSQL représentent deux innovations importantes dans cet écosystème spécialisé :
Les bases de données vectorielles se sont imposées comme une infrastructure essentielle pour les applications d’IA, comblant efficacement l’écart entre les modèles qui génèrent des incorporations et les applications qui doivent les interroger efficacement. L’essor de l’IA générative, de la recherche sémantique et des systèmes de recommandation les a rendues de plus en plus centrales dans les applications modernes.
Les bases de données NewSQL sont apparues pour résoudre le défi apparemment contradictoire consistant à maintenir le modèle relationnel et les garanties ACID de SQL tout en atteignant la scalabilité horizontale auparavant possible uniquement avec les systèmes NoSQL. Elles sont devenues essentielles pour les applications qui ont besoin à la fois d’intégrité transactionnelle et de capacité à évoluer sur une infrastructure distribuée.
Ce qui rend cette comparaison particulièrement pertinente, c’est le nombre croissant d’applications d’entreprise qui ont besoin à la fois des capacités alimentées par l’IA des bases de données vectorielles et de la fiabilité transactionnelle des systèmes NewSQL.
Pourquoi vous pourriez devoir choisir entre ces types de bases de données
Si vous lisez ceci, vous êtes probablement confronté à l’un de ces scénarios :
Vous ajoutez des fonctionnalités d’IA à une application d’entreprise critique : peut-être disposez-vous d’une application existante utilisant une base de données NewSQL et devez-vous désormais intégrer une recherche sémantique ou des recommandations.
Vous concevez l’architecture d’une nouvelle application avec des exigences à la fois d’IA et transactionnelles : vous construisez une plateforme qui nécessite à la fois une recherche de similarité vectorielle et des transactions ACID fiables.
Vous évaluez les approches spécialisées par rapport aux approches unifiées : Vous pesez le pour et le contre entre l’utilisation de bases de données spécialisées pour différentes charges de travail et la recherche d’une solution unique répondant à plusieurs besoins.
Vous êtes préoccupé par la cohérence des données entre les composants d’IA et transactionnels : Vous devez vous assurer que les fonctionnalités alimentées par l’IA fonctionnent avec des données cohérentes et à jour.
Vous préparez votre architecture pour l’avenir : Vous voulez comprendre comment ces technologies pourraient converger ou se compléter à mesure que votre application évolue.
En tant que personne ayant mis en œuvre ces deux types de systèmes dans divers secteurs, je peux vous dire que faire le bon choix nécessite de comprendre non seulement ce dans quoi chaque type de base de données excelle, mais aussi comment leurs différences architecturales influencent vos exigences spécifiques en matière de cohérence, d’évolutivité et de schémas de requêtes.
Bases de données vectorielles : l’épine dorsale de la recherche IA moderne
Fondements architecturaux
Au cœur de leur fonctionnement, les bases de données vectorielles comme Milvus et Zilliz Cloud reposent sur un concept puissant : représenter les éléments de données comme des points dans un espace à haute dimension où la proximité équivaut à la similarité. Leur architecture comprend généralement :
Des moteurs de stockage vectoriel optimisés pour des tableaux numériques denses pouvant aller de quelques dizaines à plusieurs milliers de dimensions
Des index ANN (Approximate Nearest Neighbor) comme HNSW, IVF ou PQ qui rendent la recherche vectorielle à l’échelle du milliard réalisable
Des optimisations de calcul de distance pour calculer la similarité à l’aide de métriques comme le cosinus, la distance euclidienne ou le produit scalaire
Des sous-systèmes de filtrage qui combinent la recherche vectorielle avec des contraintes de métadonnées
Des mécanismes de sharding conçus spécifiquement pour distribuer les charges de travail vectorielles
L’idée clé : les bases de données vectorielles sacrifient l’exactitude parfaite de la recherche exacte du plus proche voisin au profit des gains de performance spectaculaires des méthodes approximatives, rendant ainsi pratiques à grande échelle des applications de recherche par similarité auparavant irréalisables.
Ce qui distingue les bases de données vectorielles
D’après mon expérience dans la mise en œuvre de ces systèmes, ces capacités font vraiment briller les bases de données vectorielles :
Compromis précision-performance réglables : La capacité d’ajuster les paramètres d’index afin d’équilibrer la vitesse de recherche et la précision des résultats
Prise en charge des enregistrements multi-vecteurs : Stocker plusieurs vecteurs d’embedding par élément pour représenter différents aspects ou modalités
Capacités de recherche hybride : Combiner la similarité vectorielle avec le filtrage traditionnel pour obtenir des résultats précis
Flexibilité des métriques de distance : Prendre en charge différentes mesures de similarité pour différents types d’embeddings
Filtrage des métadonnées : Restreindre les résultats en fonction d’attributs traditionnels parallèlement à la similarité vectorielle
Les innovations récentes ont encore élargi leurs capacités :
Recherche hybride sparse-dense : Combiner les forces de la correspondance traditionnelle par mots-clés avec la compréhension sémantique
Reranking par cross-encoder : Affiner les résultats initiaux de recherche vectorielle avec des modèles plus intensifs en calcul
Mise à l’échelle serverless : Ajuster automatiquement les ressources en fonction des charges de requêtes et d’indexation
Pipelines de récupération multi-étapes : Orchestrer des flux de récupération complexes avec des étapes de filtrage et de reranking
Zilliz Cloud et Milvus : à la tête de l’écosystème des bases de données vectorielles
Parmi l’écosystème croissant des solutions de bases de données vectorielles, Zilliz Cloud et le projet open source Milvus se sont imposés comme des acteurs importants :
Milvus est une base de données vectorielle open source largement adoptée, qui a gagné en popularité auprès des développeurs créant des applications d’IA. Créée pour gérer la recherche de similarité vectorielle à grande échelle, elle fournit la base de nombreux systèmes de production dans des domaines allant des moteurs de recommandation à la recherche d’images. Le projet bénéficie d’une solide communauté et est conçu avec la performance et l’évolutivité à l’esprit.
Zilliz Cloud est la version en service géré de Milvus, offrant les mêmes fonctionnalités de base sans la complexité opérationnelle. Pour les équipes de développement qui cherchent à mettre en œuvre des capacités de recherche vectorielle sans consacrer de ressources à la gestion de bases de données, Zilliz Cloud offre un chemin simplifié vers la production. Cette approche cloud-native s’aligne sur les pratiques de développement modernes, où les équipes préfèrent de plus en plus consommer les bases de données sous forme de services plutôt que gérer elles-mêmes l’infrastructure sous-jacente.
Cas d’utilisation populaires : bases de données vectorielles
Les bases de données vectorielles transforment divers secteurs grâce à leur capacité à alimenter des applications fondées sur la similarité :
Génération augmentée par récupération (RAG) : Les bases de données vectorielles connectent les modèles de langage à des sources d’information pertinentes. Les utilisateurs peuvent poser des questions complexes comme « Quels ont été nos résultats de ventes du T2 en Europe ? » et recevoir des réponses précises tirées directement de documents internes, ce qui garantit que les réponses sont factuelles et à jour.
Recherche sémantique : Les bases de données vectorielles permettent une recherche en langage naturel qui comprend l’intention de l’utilisateur plutôt que de simplement faire correspondre des mots-clés. Les utilisateurs peuvent effectuer des recherches avec des requêtes conversationnelles comme « destinations de vacances abordables pour les familles » et recevoir des résultats sémantiquement pertinents, même lorsque ces mots exacts n’apparaissent pas dans le contenu.
Systèmes de recommandation : Les plateformes de commerce électronique, les services de streaming et les plateformes de contenu utilisent les bases de données vectorielles pour fournir des recommandations personnalisées fondées sur la similarité sémantique plutôt que sur le simple filtrage collaboratif. Cette approche réduit le problème du « démarrage à froid » pour les nouveaux articles et peut mieux expliquer pourquoi des recommandations sont formulées.
Recherche d’images et visuelle : Les détaillants et les plateformes visuelles utilisent les bases de données vectorielles pour permettre la fonctionnalité de recherche par image. Les utilisateurs peuvent téléverser une photo pour trouver des produits, des œuvres d’art ou des designs visuellement similaires, ce qui est particulièrement précieux dans la mode, la décoration intérieure et les domaines créatifs.
Détection d’anomalies : Les systèmes de sécurité et de surveillance exploitent les bases de données vectorielles pour identifier des schémas inhabituels qui ne correspondent pas aux comportements attendus. Cela est particulièrement précieux pour la détection des fraudes, la sécurité des réseaux et le contrôle qualité dans la fabrication.
Bases de données NewSQL : faire évoluer les transactions sans compromis
Fondements architecturaux
Les bases de données NewSQL comme Google Spanner, CockroachDB et SingleStore sont apparues face à un défi fondamental : comment conserver les garanties ACID et le modèle relationnel dont dépendent les applications d’entreprise tout en obtenant l’évolutivité horizontale nécessaire aux charges de travail modernes. Leur architecture comprend généralement :
Des moteurs SQL distribués qui préservent la sémantique SQL standard tout en fonctionnant sur des clusters
Des protocoles de consensus sophistiqués (comme Paxos ou Raft) qui garantissent la cohérence des données dans les environnements distribués
Des systèmes de partitionnement automatique qui distribuent les données entre les nœuds tout en maintenant l’intégrité transactionnelle
Un contrôle de concurrence optimiste ou multiversion pour un débit élevé sans sacrifier la cohérence
Des moteurs d’exécution distribués qui parallélisent les opérations de requête à travers le cluster
L’idée centrale : en repensant la façon dont les bases de données relationnelles gèrent le consensus distribué, la coordination des transactions et l’exécution des requêtes, les systèmes NewSQL atteignent une évolutivité horizontale sans abandonner le modèle SQL ni les garanties ACID sur lesquels les applications s’appuient.
Ce qui distingue les bases de données NewSQL
Ayant déployé des bases de données NewSQL dans des environnements d’entreprise, j’ai trouvé ces capacités particulièrement précieuses :
Transactions distribuées : Maintien des garanties ACID sur des nœuds géographiquement distribués
Évolutivité horizontale : Ajout de capacité en ajoutant simplement davantage de nœuds au cluster
Compatibilité SQL : Prise en charge des interfaces et outils SQL standard malgré l’architecture distribuée
Rééquilibrage automatique : Redistribution des données à mesure que le cluster grandit ou rétrécit sans intervention manuelle
Modèles de cohérence forte : Fournir une cohérence linéarisable pour les opérations critiques lorsque nécessaire
Les innovations récentes ont encore amélioré les capacités NewSQL :
Déploiements multirégion : Couvrir plusieurs régions géographiques tout en maintenant des garanties de cohérence
Traitement transactionnel/analytique hybride (HTAP) : Prendre en charge les charges de travail OLTP et OLAP depuis la même base de données
Offres serverless : Tarification basée sur la consommation avec mise à l’échelle automatique
Capacités de streaming intégrées : Traiter les flux de données parallèlement aux opérations de base de données traditionnelles
Moteurs de stockage spécialisés : Optimiser pour différentes caractéristiques de charge de travail au sein du même système
Cas d’utilisation populaires : Bases de données NewSQL
Les bases de données NewSQL excellent dans les scénarios où les bases de données relationnelles traditionnelles atteignent des limites de mise à l’échelle, mais où les applications nécessitent toujours une forte cohérence :
Plateformes SaaS mondiales : Les plateformes logicielles multilocataires exploitent les bases de données NewSQL pour évoluer horizontalement entre les datacenters tout en maintenant l’intégrité transactionnelle pour les opérations de chaque client. La capacité d’ajouter de la capacité en ajoutant des nœuds plutôt qu’en effectuant une mise à l’échelle verticale permet à ces entreprises de se développer efficacement tout en préservant le modèle SQL sur lequel leurs applications ont été construites.
Systèmes financiers : Les applications bancaires et fintech utilisent les bases de données NewSQL pour combiner les exigences strictes de cohérence des transactions financières avec la capacité de passer à l’échelle pour des millions d’utilisateurs et de transactions. Leurs solides garanties de cohérence assurent l’exactitude des soldes de comptes et des historiques de transactions, tandis que l’architecture distribuée offre à la fois une évolutivité et une résilience face aux pannes régionales.
Plateformes e-commerce : Les détaillants en ligne mettent en œuvre des bases de données NewSQL pour gérer des volumes de transactions massifs pendant les périodes de forte affluence tout en maintenant la cohérence des stocks, du traitement des commandes et des données clients. Le modèle de mise à l’échelle horizontale leur permet d’augmenter temporairement la capacité lors des pics saisonniers sans reconstruire leur architecture de données.
Backends de jeux : Les plateformes de jeux multijoueurs utilisent les bases de données NewSQL pour gérer les données des joueurs, les inventaires et les économies en jeu avec des exigences strictes de cohérence. L’architecture distribuée prend en charge des millions de joueurs simultanés dans des régions mondiales tout en garantissant que l’état critique du jeu reste cohérent et que les transactions telles que les achats ou les échanges conservent les propriétés ACID.
Systèmes de dossiers médicaux : Les institutions médicales déploient des bases de données NewSQL pour gérer les dossiers patients qui nécessitent à la fois une cohérence stricte pour les données de soins critiques et la capacité de s’étendre à travers les réseaux hospitaliers. L’interface SQL maintient la compatibilité avec les applications de santé existantes, tandis que l’architecture distribuée offre résilience et capacité de mise à l’échelle.
Gestion des données IoT : Les plateformes IoT industrielles utilisent les bases de données NewSQL comme système d’enregistrement pour l’état et la configuration des appareils tout en conservant la capacité de passer à l’échelle pour des millions d’appareils connectés. Les transactions ACID assurent une gestion fiable des appareils, tandis que l’architecture évolutive gère la croissance continue des systèmes connectés.
Comparaison directe : Base de données vectorielle vs base de données NewSQL
| Fonctionnalité | Bases de données vectorielles (Milvus, Zilliz Cloud) | Bases de données NewSQL (CockroachDB, Spanner) | Pourquoi c’est important |
| Modèle de données principal | Vecteurs à haute dimension avec métadonnées | Tables relationnelles avec schéma SQL traditionnel | Détermine comment vous modélisez les concepts de votre domaine et quelles opérations sont efficaces |
| Capacité de requête principale | Recherche par similarité et requêtes de plus proches voisins | Requêtes SQL avec transactions distribuées | Définit les opérations fondamentales que votre application peut effectuer efficacement |
| Modèle de cohérence | Généralement cohérence éventuelle avec options ajustables | Cohérence forte avec garanties ACID | Influence l’exactitude de l’application et son comportement lors d’opérations concurrentes |
| Approche de mise à l’échelle | Optimisée pour la recherche par similarité à forte intensité de lecture | Mise à l’échelle équilibrée pour les lectures et les écritures | Affecte la manière dont votre base de données évolue avec l’augmentation des données et du trafic |
| Support transactionnel | Limité ou inexistant | Transactions ACID complètes sur des clusters distribués | Détermine la fiabilité des opérations métier critiques |
| Force principale | Trouver des éléments similaires à partir d’embeddings | Mise à l’échelle horizontale des charges de travail relationnelles | Aligne les forces de la base de données avec les besoins principaux de votre application |
| Langage de requête | API spécifiques aux vecteurs, fonctions de similarité | SQL standard avec extensions distribuées | Influence la courbe d’apprentissage des développeurs et l’expressivité des requêtes |
| Intégration IA | Prise en charge native des embeddings et de la similarité | Nécessite souvent des extensions ou des systèmes distincts | Détermine la préparation prête à l’emploi pour les fonctionnalités alimentées par l’IA |
| Géo-distribution | Généralement mono-région avec réplication | Prise en charge multi-région native avec contrôles de cohérence | Affecte le déploiement mondial des applications et la latence |
| Familiarité de développement | Nouveau paradigme pour la plupart des équipes | Modèle SQL familier avec considérations distribuées | Impacte l’intégration des équipes et la vélocité de développement |
Les bases de données vectorielles en action : exemples de réussite concrets
Les bases de données vectorielles excellent dans ces cas d’utilisation :
Génération augmentée par récupération (RAG) pour les connaissances d’entreprise
Un cabinet de conseil mondial a mis en œuvre un système RAG utilisant Zilliz Cloud pour alimenter sa plateforme interne de connaissances. Il a converti des millions de documents, de présentations et de rapports de projet en embeddings stockés dans une base de données vectorielle. Lorsque les consultants posent des questions, le système récupère le contexte le plus pertinent depuis leur base de connaissances et le transmet à un grand modèle de langage afin de générer des réponses précises et contextuellement pertinentes.
Cette approche a considérablement amélioré la découverte des connaissances, réduit le temps de recherche de 65 % et garanti que les réponses étaient ancrées dans l’expérience et les méthodologies réelles du cabinet plutôt que dans des sorties génériques de LLM. La base de données vectorielle a été essentielle pour permettre une récupération en temps réel dans d’immenses collections de documents tout en maintenant des temps de réponse aux requêtes inférieurs à la seconde.
Voir d’autres études de cas RAG :
Shulex utilise Zilliz Cloud pour faire évoluer et optimiser ses services VOC
Découvrez comment MindStudio exploite Zilliz Cloud pour renforcer la création d’applications d’IA
RAG agentique pour les workflows complexes
Le RAG agentique est un framework RAG avancé qui améliore le framework RAG traditionnel en intégrant des capacités d’agent intelligent. Un fournisseur de technologies de santé a construit un système de RAG agentique qui utilise la recherche vectorielle pour alimenter un outil d’aide à la décision clinique. Le système stocke les connaissances médicales, les recommandations thérapeutiques et les antécédents de cas de patients sous forme d’embeddings dans une base de données vectorielle. Lorsque les médecins saisissent des scénarios patients complexes, le système agentique :
Décompose la requête complexe en sous-questions
Effectue des recherches vectorielles ciblées pour chaque sous-question
Évalue et synthétise les informations récupérées
Détermine si des recherches supplémentaires sont nécessaires
Fournit une réponse complète, fondée sur des preuves
Cette implémentation avancée a réduit le temps de décision clinique de 43 % et amélioré la précision des recommandations thérapeutiques de 28 % dans des études de validation. La capacité de la base de données vectorielle à effectuer plusieurs recherches de similarité rapides avec différents contextes était essentielle au processus de raisonnement en plusieurs étapes de l’agent.
DeepSearcher, créé par les ingénieurs de Zilliz, est un excellent exemple de RAG agentique et constitue également une alternative locale et open source à Deep Research d’OpenAI. Ce qui distingue DeepSearcher, c’est sa combinaison unique de modèles de raisonnement avancés, de fonctionnalités de recherche sophistiquées et d’un assistant de recherche intégré. En s’appuyant sur Milvus (une base de données vectorielle haute performance créée par Zilliz) pour l’intégration de données locales, il fournit des résultats de recherche plus rapides et plus pertinents tout en permettant un remplacement facile des modèles pour des expériences personnalisées.
Recherche sémantique au-delà des mots-clés
Une entreprise de technologie juridique a remplacé sa recherche traditionnelle basée sur les mots-clés par une approche alimentée par une base de données vectorielle, permettant aux avocats d’effectuer des recherches dans la jurisprudence, les lois et les documents juridiques avec des requêtes en langage naturel au lieu d’une syntaxe de recherche booléenne. Sa base de données vectorielle a indexé les embeddings de millions de documents juridiques, capturant le sens sémantique de concepts juridiques complexes.
Après l’implémentation, la pertinence de la recherche s’est améliorée de 48 %, l’abandon de recherche a diminué de 35 %, et les avocats ont déclaré gagner en moyenne 3 à 5 heures par semaine sur les tâches de recherche juridique. La base de données vectorielle gérait l’ensemble de leur corpus juridique de plus de 12 millions de documents tout en maintenant des temps de réponse aux requêtes constants inférieurs à 100 ms.
Voir plus d’études de cas sur la recherche sémantique :
HumanSignal offre une découverte de données plus rapide grâce à Milvus et AWS
Credal AI débloque une GenAI sécurisée et gouvernable avec la base de données vectorielle Milvus
Tokopedia a réalisé une recherche 10 fois plus intelligente avec Milvus
Recherche d’images alimentée par l’IA
Une plateforme de gestion d’actifs numériques a implémenté la recherche visuelle à l’aide d’une base de données vectorielle afin de stocker les embeddings des bibliothèques d’images de ses clients. Les équipes marketing pouvaient désormais téléverser des images de référence pour trouver des ressources visuellement similaires dans toute leur médiathèque — une capacité impossible avec leur précédente recherche basée sur les métadonnées.
Cette fonctionnalité a augmenté l’engagement des utilisateurs de 56 % et réduit de 62 % le temps passé à rechercher des ressources adaptées. La base de données vectorielle gérait efficacement des bibliothèques allant de milliers à des millions d’images par client tout en maintenant une latence de recherche inférieure à 200 ms, même pour les plus grandes collections.
Voir plus d’études de cas sur la recherche d’images :
Les bases de données NewSQL en action : réussites concrètes
Les bases de données NewSQL excellent dans ces scénarios :
Montée en charge d’une plateforme financière mondiale
Une entreprise fintech a migré son système de traitement des paiements d’une base de données relationnelle traditionnelle vers une base de données NewSQL distribuée afin de soutenir son expansion internationale. Son ancien système avait du mal à gérer les transactions interrégionales et ne pouvait pas évoluer horizontalement pour répondre à la demande croissante.
La mise en œuvre NewSQL a utilisé un déploiement multirégion avec des transactions distribuées afin de garantir la cohérence des paiements dans l’ensemble des opérations mondiales. Cette architecture a réduit la latence du traitement des paiements de 73 % pour les clients internationaux tout en maintenant de strictes garanties ACID pour les transactions financières. Le système gère désormais plus de 12 000 transactions par seconde pendant les périodes de pointe avec une disponibilité de 99,995 %, tout en conservant l’interface SQL familière que leur équipe de développement maîtrisait déjà.
Transformation d’une plateforme e-commerce
Une entreprise e-commerce en forte croissance a remplacé sa mise en œuvre MySQL partitionnée par une base de données NewSQL afin d’éliminer les limitations de mise à l’échelle rencontrées lors des pics d’achats saisonniers. Son approche précédente nécessitait une logique applicative complexe pour gérer les transactions entre partitions et peinait à assurer une gestion cohérente des stocks entre les partitions.
La solution NewSQL a fourni un partitionnement automatique tout en maintenant l’intégrité transactionnelle pour les commandes, les stocks et les données clients. Cette mise en œuvre a absorbé une augmentation de 300 % du volume de transactions pendant le Black Friday sans dégradation des performances, a réduit les interruptions liées à la base de données de plusieurs par mois à zéro au cours de l’année écoulée, et a supprimé le besoin de logique de partitionnement au niveau applicatif, permettant aux développeurs de se concentrer sur les fonctionnalités plutôt que sur la distribution des données.
Mise à l’échelle d’une application SaaS
Une entreprise de logiciels B2B a déplacé son application multi-tenant d’une base de données relationnelle traditionnelle vers une plateforme NewSQL afin de soutenir sa base croissante de clients entreprise. Son ancienne base de données à instance unique ne pouvait pas évoluer pour répondre aux besoins des plus grands clients et créait des défis d’isolation des performances entre les tenants.
La base de données NewSQL leur a permis d’évoluer horizontalement à mesure que le nombre de clients augmentait, tout en maintenant une isolation stricte entre les données des tenants. Les performances pour les grands clients entreprise se sont améliorées de 220 %, les coûts opérationnels de la base de données ont diminué de 40 % malgré le traitement de 5 fois plus de données, et l’équipe a conservé son code applicatif existant basé sur SQL avec des modifications minimales.
Évaluer vous-même vos solutions de recherche vectorielle
VectorDBBench est un outil d’évaluation open source conçu pour les utilisateurs qui ont besoin de systèmes de stockage et de récupération de données haute performance, en particulier des bases de données vectorielles. Cet outil permet aux utilisateurs de tester et de comparer les performances de différents systèmes de bases de données vectorielles à l’aide de leurs propres jeux de données et de déterminer celui qui convient le mieux à leurs cas d’utilisation. Avec VectorDBBench, les utilisateurs peuvent prendre des décisions éclairées fondées sur les performances réelles des bases de données vectorielles plutôt que sur des affirmations marketing ou des preuves anecdotiques.
VectorDBBench est écrit en Python et distribué sous la 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 déterminés à améliorer ses fonctionnalités et ses performances.
Consultez le classement VectorDBBench pour un aperçu rapide des performances des bases de données vectorielles courantes.
Cadre de décision : choisir la bonne architecture de base de données
Après avoir aidé de nombreuses organisations à prendre cette décision, j’ai élaboré ce cadre pratique :
Choisissez une base de données vectorielle lorsque :
La recherche de similarité alimentée par l’IA est votre proposition de valeur principale - Votre application s’articule principalement autour de la recherche d’éléments apparentés sur la base d’une similarité sémantique ou perceptuelle
Vous travaillez avec des embeddings issus de modèles d’apprentissage automatique - Vos données existent naturellement sous forme de vecteurs provenant de modèles de langage, d’encodeurs d’images ou d’autres systèmes d’IA
Des résultats approximatifs sont acceptables pour améliorer les performances - Votre cas d’utilisation peut tolérer la précision imparfaite des algorithmes ANN en échange de la rapidité
Les schémas de requêtes se concentrent sur « qu’est-ce qui est similaire à ceci ? » - Vos opérations principales consistent à trouver les plus proches voisins dans un espace à haute dimension
De fortes garanties transactionnelles sont moins critiques que les performances de recherche - Votre application privilégie une recherche de similarité rapide plutôt que de strictes garanties de cohérence
Choisissez une base de données NewSQL lorsque :
L’intégrité transactionnelle n’est pas négociable - Votre application traite des données financières, de santé ou d’autres données critiques nécessitant des garanties ACID
Vous devez faire évoluer horizontalement des charges de travail relationnelles - Vous avez atteint les limites de mise à l’échelle des SGBDR traditionnels, mais devez conserver le modèle relationnel
La compatibilité SQL est une exigence - Votre équipe et vos outils sont construits autour de SQL et des concepts relationnels
La cohérence multirégion est importante - Votre application doit maintenir la cohérence au-delà des frontières géographiques
Vous gérez à la fois des charges de travail OLTP et analytiques - Votre application doit prendre en charge efficacement les opérations transactionnelles et analytiques
Envisagez une approche hybride lorsque :
Votre application comporte des charges de travail clairement distinctes - Certaines fonctionnalités nécessitent une recherche de similarité, tandis que d’autres requièrent des garanties transactionnelles
Les données circulent naturellement entre les composants transactionnels et d’IA - Votre workflow implique le traitement de données transactionnelles pour l’analyse par l’IA
Différentes équipes maintiennent différents composants de l’application - Votre organisation dispose d’équipes distinctes pour le traitement des transactions et les fonctionnalités d’IA
Les exigences de latence diffèrent selon les composants - Certaines opérations nécessitent des réponses en moins d’une milliseconde, tandis que d’autres peuvent tolérer des latences plus longues
Envisagez NewSQL avec des extensions vectorielles lorsque :
Votre besoin principal est transactionnel avec une recherche vectorielle occasionnelle - Une forte cohérence est votre exigence principale, avec quelques capacités d’IA
La simplicité opérationnelle prime sur les performances spécialisées - La gestion d’un seul système de base de données est plus prioritaire que la maximisation des performances de recherche vectorielle
Vos besoins en recherche vectorielle sont modérés - Tant en termes de taille de collection que de dimensionnalité
La cohérence des données entre transactions et vecteurs est critique - Vous avez besoin que les opérations vectorielles voient des données immédiatement cohérentes après les transactions
Réalités de mise en œuvre : ce que j’aurais aimé savoir plus tôt
Après avoir implémenté les deux types de bases de données dans plusieurs organisations, voici des considérations pratiques souvent négligées :
Planification des ressources
Les bases de données vectorielles nécessitent généralement une mémoire importante pour les index, souvent 2 à 3 fois ce que vous pourriez estimer initialement d’après la taille des données brutes
Les bases de données NewSQL peuvent avoir des besoins en CPU plus élevés que les SGBDR traditionnels en raison de la surcharge des protocoles de consensus distribués
Les schémas de mise à l’échelle diffèrent fondamentalement : les bases de données vectorielles évoluent souvent avec les dimensions des embeddings et la taille de la collection, tandis que les bases de données NewSQL évoluent généralement avec le volume des transactions et la complexité des requêtes
Expérience de développement
Les paradigmes de requête diffèrent considérablement entre ces types de bases de données, exigeant de votre équipe de développement des modèles mentaux différents
Les bases de données NewSQL introduisent des concepts de systèmes distribués comme les niveaux de cohérence et la tolérance au partitionnement, avec lesquels les développeurs SQL traditionnels peuvent ne pas être familiers
La recherche vectorielle nécessite de comprendre les modèles d’embedding, la réduction de dimensionnalité et les métriques de similarité, avec lesquels les développeurs de bases de données traditionnels peuvent ne pas avoir d’expérience
Réalités opérationnelles
Les besoins en surveillance varient considérablement, les bases de données vectorielles nécessitant une attention particulière aux performances des index et les bases de données NewSQL se concentrant sur les métriques de consensus et la latence des transactions distribuées
Les stratégies de sauvegarde et de récupération diffèrent sensiblement, les bases de données NewSQL disposant souvent de capacités de restauration à un instant donné plus sophistiquées
Les opérations de maintenance comme les mises à niveau de version peuvent être plus complexes dans les systèmes distribués, nécessitant souvent une orchestration minutieuse pour maintenir la disponibilité
Conclusion : choisissez le bon outil, mais restez flexible
Le choix entre les bases de données vectorielles et les bases de données NewSQL ne consiste pas à désigner un vainqueur : il s’agit d’adapter votre architecture de base de données à vos exigences spécifiques en matière de cohérence, de schémas de requête et de scalabilité.
Si votre cas d’utilisation principal consiste à trouver des éléments similaires ou des relations sémantiques, une base de données vectorielle constitue probablement une bonne fondation. Si votre besoin fondamental est de disposer de transactions scalables avec de fortes garanties de cohérence, une base de données NewSQL est probablement votre point de départ.
Les architectures de données les plus sophistiquées que j’ai contribué à construire n’évitent pas les bases de données spécialisées : elles les adoptent tout en créant des interfaces propres qui masquent la complexité aux développeurs d’applications. Cette approche vous offre les avantages de performance des systèmes spécialisés tout en maintenant la vitesse de développement.
Quelle que soit la voie que vous choisissez, l’essentiel est de construire avec suffisamment de flexibilité pour évoluer à mesure que vos exigences et le paysage des bases de données continuent de changer. La convergence entre les capacités vectorielles et le traitement des transactions distribuées de NewSQL ne fait que commencer, et les architectures les plus réussies seront celles capables de s’adapter pour intégrer le meilleur des deux mondes.
Continuer à lire
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
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.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.