À mesure que les applications basées sur l’IA passent de l’expérimentation aux systèmes de production en temps réel, les attentes en matière de recherche de ressemblances vectorielles continuent d’augmenter de manière spectaculaire.Les équipes doivent maintenant soutenir des ensembles de données à l’échelle de milliards, une concurrence élevée, des budgets de latence stricts p99 et un niveau de simplicité opérationnelle qui réduit l’excès d’architecture au lieu de l’ajouter. ScyllaDB Vector Search a été construit en tenant compte de ces contraintes.Il offre un moteur unifié pour stocker des données structurées aux côtés d'emballages non structurés, et il atteint des performances qui dépassent les limites de ce qu'un système de base de données géré peut fournir à l'échelle.Les résultats de notre récent benchmark de 1 milliard de vecteurs à grande échelle montrent que ScyllaDB démontre à la fois une latence ultra basse et un comportement hautement prévisible sous charge. L’architecture en un coup d’œil Afin d’obtenir des performances d’un millisecond faible sur des ensembles vectoriels massifs, ScyllaDB adopte une architecture qui sépare les responsabilités de stockage et d’indexation tout en gardant le système unifié du point de vue de l’utilisateur. Les nœuds ScyllaDB stockent à la fois les attributs structurés et les intégrations vectorielles dans la même table distribuée. Pendant ce temps, un service dédié Vector Store – mis en œuvre dans Rust et alimenté par le moteur USearch optimisé pour supporter les latences millisecondes prévisibles de ScyllaDB – consomme les mises à jour de ScyllaDB via CDC et construit des indices approximatifs de voisinage (ANN) dans la mémoire SELECT … ORDER BY vector_column ANN_OF ? LIMIT k; Ils sont ensuite redirigés en interne vers le Vector Store, qui effectue la recherche de similitude et renvoie les lignes candidates.Cette conception permet à chaque couche de scaler de manière indépendante, en optimisant ses propres caractéristiques de charge de travail et en éliminant les interférences de ressources. Benchmarking de 1 milliard de vecteurs Pour évaluer les performances du monde réel, ScyllaDB a utilisant le dataset publicement disponible yandex-deep_1b, qui contient 1 milliard de vecteurs de 96 dimensions. La configuration a consisté en six nœuds: trois nœuds ScyllaDB fonctionnant sur des instances i4i.16xlarge, chacune équipée de 64 vCPU, et trois nœuds Vector Store fonctionnant sur des instances r7i.48xlarge, chacune avec 192 vCPU. Cette configuration matérielle reflète des déploiements de production réalistes où la base de données et les niveaux d'indexation des vecteurs sont fournis avec des profils de ressources différents. Les résultats se concentrent sur deux scénarios d'utilisation avec des objectifs de précision et de latence distincts (détails dans les sections suivantes). Un benchmark rigoureux Une plongée architecturale complète, comprenant des diagrammes, des compromis de performance et des résultats de référence étendus pour les ensembles de données de dimensions supérieures, peut être trouvée dans le blog technique Ces résultats complémentaires suivent le même schéma observé dans les tests 96-dimensionnels : une latence exceptionnellement faible, un débit élevé et une stabilité sur un large éventail de profils de charge simultanés. Créer un moteur de recherche vectoriel à faible latence pour ScyllaDB Créer un moteur de recherche vectoriel à faible latence pour ScyllaDB Scénario #1 – Latence ultra-basse avec rappel modéré Le premier scénario a été conçu pour les charges de travail telles que les moteurs de recommandation et les systèmes de personnalisation en temps réel, où l'objectif principal est une latence extrêmement faible et le rappel peut être modérément apaisé. Nous avons utilisé des paramètres d'index m = 16, ef-construction = 128, ef-search = 64 et distance d'Euclide. À environ 70% de rappels et avec 30 recherches simultanées, le système a maintenu une latence p99 de seulement 1,7 millisecondes et une p50 de seulement 1,2 millisecondes, tout en soutenant 25 000 requêtes par seconde. Lors de l'expansion de la fenêtre de débit (toujours en gardant la latence p99 en dessous de 10 millisecondes), le cluster a atteint 60 000 QPS pour k = 100 avec une latence p50 de 4,5 millisecondes, et 252 000 QPS pour k = 10 avec une latence p50 de 2,2 millisecondes. Scénario #2 – Un rappel élevé avec une latence légèrement plus élevée Le deuxième scénario vise les systèmes nécessitant un rappel presque parfait, y compris les pipelines de production sémantiques à haute fiabilité et augmentées par la récupération.Ici, les paramètres de l'index ont été considérablement augmentés à m = 64, ef-construction = 512, et ef-search = 512. Cette configuration augmente les exigences de calcul mais améliore considérablement le rappel. Avec 50 recherches et rappels simultanés approchant de 98%, ScyllaDB a maintenu la latence p99 en dessous de 12 millisecondes et p50 environ 8 millisecondes tout en fournissant 6 500 QPS. Lorsque le focus a été déplacé vers le débit maximal soutenu tout en gardant la latence p99 en dessous de 20 millisecondes et p50 en dessous de 10 millisecondes, le système a atteint 16 600 QPS. Même sous ces paramètres, la latence est restée notablement stable sur des valeurs de k de 10 à 100, démontrant un comportement prévisible dans des environnements où les limites de requête varient dynamiquement. Les résultats détaillés Le tableau ci-dessous présente le résumé des résultats pour certains niveaux représentatifs de concurrence. Recherche vectorielle unifiée sans la complexité Un grand avantage de l'intégration de Vector Search avec ScyllaDB est qu'il offre des avantages substantiels en termes de performance et de coûts de réseau. Le magasin vectoriel se trouve à proximité des données avec un simple saut réseau entre les métadonnées et le stockage intégré dans la même zone de disponibilité. Cette localisation, combinée au modèle d'exécution shard-per-core de ScyllaDB, permet au système de fournir une latence en temps réel et un débit massif même sous une charge lourde. En plus d’être rapide à l’échelle, la recherche vectorielle de ScyllaDB est également plus facile à exploiter. Son avantage clé est sa capacité à unifier la recherche structurée et non structurée dans un seul ensemble de données. Cela signifie que vous pouvez stocker les attributs traditionnels et les intégrations vectorielles côte à côte et exprimer les requêtes qui combinent la recherche sémantique avec la recherche conventionnelle. Par exemple, vous pouvez demander à la base de données de « trouver les cinq documents les plus similaires, mais seulement ceux appartenant à ce client spécifique et créés au cours des 30 derniers jours. »Cette approche élimine la douleur commune de maintenir des systèmes séparés pour les données transactionnelles et la recherche vectorielle, et supprime la fragilité op Cela signifie également qu'il n'y a pas de dérive ETL et aucun risque de double écriture. Au lieu d'envoyer des embeddings à une base de données vectorielle séparée tout en conservant des métadonnées dans un magasin de transactions, ScyllaDB consolide tout dans un seul système. Le seul pipeline dont vous avez besoin est l'étape computationnelle qui génère des embeddings en utilisant votre modèle LLM ou ML préféré. Une fois écrit, les données restent cohérentes sans coordination supplémentaire, backfills ou tâches de streaming complexes. Sur le plan opérationnel, ScyllaDB simplifie l'ensemble de la pile de récupération. Parce qu'il est construit sur l'architecture distribuée éprouvée de ScyllaDB, le système est hautement disponible, horizontalement évolutif et résilient à travers les zones et les régions de disponibilité. Au lieu d'exploiter deux ou trois technologies différentes - chacune avec sa propre surveillance, configurations de sécurité et modes d'échec - vous ne gérez qu'une seule. Carte de route Le produit est désormais en disponibilité générale. Cela inclut la fourniture de Cloud Portal, la facturation à la demande, une gamme complète de types d'instances et des optimisations de performance supplémentaires. L'évolution de l'autoservice est prévue pour le 1er trimestre. À la fin du 1er trimestre, nous allons introduire des capacités de filtrage natives, permettant aux requêtes de recherche vectorielle de combiner les résultats ANN avec les prédicats traditionnels pour une récupération hybride plus précise. En regardant plus loin, la feuille de route comprend le support de la quantification scalaire et binaire pour réduire l'utilisation de la mémoire, la fonctionnalité TTL pour l'automatisation du cycle de vie des données vectorielles et la recherche hybride intégrée combinant ANN et BM25 pour une pertinence lexicale et sémantique unifiée. Conclusion ScyllaDB a démontré qu’il est capable de fournir des performances de pointe dans l’industrie pour la recherche vectorielle à grande échelle, gérant un ensemble de données de 1 milliard de vecteurs avec une latence p99 aussi faible que 1,7 millisecondes et un débit allant jusqu’à 252 000 QPS. Ces résultats valident ScyllaDB Vector Search comme une solution unifiée et haute performance qui simplifie la complexité opérationnelle des applications d’IA en temps réel en co-localisant les données structurées et les intégrations non structurées. Les critères de référence actuels montrent l’état actuel de l’évolutivité de ScyllaDB. Avec les améliorations prévues dans la feuille de route à venir, y compris la quantification scalaire et le sharding, ces limites de performance devraient augmenter l’année prochaine.
