Base de données vectorielle : Qdrant stabilise et améliore ses performances

RocksDB n’est plus le moteur de stockage de Qdrant

Les ingénieurs ont choisi RocksDB comme backend du stockage des charges utiles et des vecteurs « clairsemés » (sparse vectors). Il s’agit d’une base de données qui stocke de manière persistante et distribuée des paires clés-valeurs en mémoire vive ou sur des disques flash. Elle a été développée et donnée à la communauté open source par Meta (ex-Facebook). Fork de LevelDB de Google, cette technologie à « usage général » est (plus ou moins bien) exploitée par bon nombre d’éditeurs et fournisseurs.

Son avantage, pour Qdrant, c’était « sa capacité à gérer des lectures et des écritures aléatoires ». Or, malgré sa réputation de couteau suisse, RocksDB ne prend pas tous les cas de figure à la perfection.

« Un exemple clé est le compactage, un processus qui réorganise les données sur le disque pour maintenir les performances », indiquent les ingénieurs de Qdrant, dans un billet de blog. « En cas de forte charge d’écriture, le compactage peut devenir un goulet d’étranglement, entraînant des ralentissements importants », poursuivent-ils. « Pour Qdrant, cela se traduisait par d’énormes pics de latence à des moments aléatoires, provoquant des erreurs de temporisation lors de téléchargements importants, ce qui constituait un obstacle frustrant ».

La solution choisie par la startup ? Développer un backend de stockage « custom » optimisé pour la gestion de vecteurs.

Ce backend de stockage est divisé en quatre couches.

La Data Layer stocke les données sous forme de blocs de taille fixe, dont le nombre est ajustable selon la charge de travail. La Mask Layer utilise un bitmask pour indiquer quels blocs sont occupés, avec un faible surcoût de stockage. La couche nommée « Region » optimise l’occupation mémoire en suivant les écarts dans le bitmask. Un processus qui nécessiterait seulement 6 kilo-octets de RAM par gigaoctet de données. Enfin, la « Tracker Layer » doit assurer des recherches rapides en associant directement les identifiants aux emplacements des données.

« Contrairement à RocksDB, notre système offre des performances constantes en veillant à ce que les lectures et les écritures nécessitent un nombre constant d’opérations sur le disque, quelle que soit la taille des données », promettent les ingénieurs.

Ce n’est pas la première fois qu’un éditeur de base de données se sépare de RocksDB. Redis l’a par exemple remplacée par la technologie de Speedb, plus adaptée à sa fonction d’auto-tiering.  

Cela dit, Qdrant ne fournit pas de benchmark pour rendre compte de ses dires.

Un autre problème peut affecter les performances de la base de données vectorielles à l’échelle : les « voisins bruyants ». Cette expression renvoie, pour rappel, aux perturbations que peuvent causer des charges de travail concurrentes sur l’usage de ressources mutualisées dans une architecture multitenant.

C’est en vue de mitiger ce problème que Qdrant propose un mode « strict ».

« Il limite les opérations intensives comme le filtrage non indexé, la taille des lots et certains paramètres de recherche pour éviter toute surcharge du système », assure la startup. « Des protections supplémentaires, comme des restrictions sur la taille des données, les conditions de filtrage et les délais d’exécution, garantissent des performances rapides et fiables pour les applications exigeantes ».

Outre les enjeux de stabilités, Qdrant doit faire en sorte, comme l’ensemble des acteurs qui prennent en charge la recherche vectorielle, de réduire l’empreinte de la mémoire des vecteurs.

Pour cela, la startup dit avoir adapté une technique de compression habituellement utilisée par les moteurs de recherche à son implémentation de l’algorithme Hierachical Navigable Small Worlds (HNSW).

Pour rappel, cet algorithme orienté graphe propulse la recherche de similarité entre les vecteurs dans un espace de grande dimension.

L’encodage Delta doit permettre de « compresser les données en ne stockant que les différences entre les valeurs ». Cette approche serait moins gourmande en ressources CPU que les techniques de décompression telles lz4 ou gzip. La startup indique qu’elle mesure une baisse de 30 % de l’empreinte mémoire du graphe HNSW, sans dégradation notable des performances.

Ces vecteurs peuvent être désormais filtrés par noms, ce qui permet – par exemple – de trier des collections de vecteurs contenant à la fois des images et du texte.

Une indexation jusqu’à dix fois plus rapide grâce aux GPU

Reste le sujet de l’indexation. Les applications RAG sont pour la plupart « statiques ». Les bases de connaissances qu’elles encapsulent n’évoluent pas forcément tous les jours. Or, dans des scénarios de recherche sémantique – sur des sites Web, des plateformes d’e-commerce, des outils de suivi logistique –, la performance de l’indexation devient clé.

Pour cela, Qdrant a implémenté l’indexation en GPU, et ce, de manière agnostique.

Cette implémentation « maison » repose sur l’instrumentation de l’API Vulkan, prise en charge par les GPU Nvidia, AMD et Intel.

Pour rappel, les GPU sont avant tout des cartes consacrées au calcul vectoriel. Et il paraît donc logique que les éditeurs de base de données vectorielle s’en emparent. D’autant que ces puces sont maintenant accompagnées d’une grande quantité de mémoire vive vidéo (VRAM).

Pour autant, Qdrant assure que la diminution du temps d’indexation ne réclame pas d’utiliser des cartes haut de gamme. Quand une instance équipée d’un CPU de huit cœurs met 97,5 secondes à indexer 1 million de vecteurs de 1 536 dimensions, une autre dotée d’une Nvidia T4 en mettrait 19,1 secondes (et 12,6 secondes avec une instance Nvidia L4).

« L’indexation sur GPU offre désormais des vitesses jusqu’à 10 fois supérieures à celles des méthodes basées sur le CPU pour un prix de matériel équivalent », avance Qdrant.

Cela ne semble pourtant pas le cas dans le test présenté plus haut. L’instance dotée de 8 vCPU est facturée 195 dollars par mois, quand celle équipée de la Nvidia T4 et de 8vCPU coûte 533 dollars par mois. Dans le cas présent, l’indexation en GPU serait cinq fois plus rapide pour 2,7 fois le prix d’une indexation en CPU. Ce ne serait pas le bon calcul.

« C’est une bonne solution et votre vitesse d’indexation sera multipliée par deux. Au lieu d’ajouter des ressources CPU, vous pouvez ajouter un GPU. »

« Dans une situation où vous vous confrontez à une faible vitesse d’indexation, vous pourriez agrandir la taille de votre machine virtuelle et prendre huit vCPU de plus », considère Ivan Pleshkov, ingénieur senior Rust chez Qdrant et responsable de l’implémentation de cette technologie. « C’est une bonne solution et votre vitesse d’indexation sera multipliée par deux. Au lieu d’ajouter des ressources CPU, vous pouvez ajouter un GPU. Sur Google Cloud, la location d’une instance T4 vous coûtera presque autant, mais vous gagnerez clairement en rapidité », assure-t-il.

Or, à la location et à l’achat, les GPU ne sont pas aussi disponibles que les processeurs x86.

Et Qdrant de préciser que la prise en charge des GPU n’est pour l’instant disponible qu’en self-managed. « Nous introduirons prochainement la prise en charge [des GPU] dans Qdrant Cloud ».

Qdrant n’est pas le seul éditeur de base de données vectorielle à prendre en charge l’indexation en GPU. Ziliz (Milvus), LanceDB (le SGBD vectoriel utilisé par AnythingLLM) et Oracle la prenaient en charge avant lui. Cependant, les trois sociétés utilisent la librairie propriétaire CUDA de Nvidia, tandis que Vulkan est open source (c’est l’évolution d’OpenGL).