Recherche vectorielle : MariaDB veut détrôner les bases de données spécialisées

Weaviate, Qdrant, pgvector : MariaDB veut prouver l’inefficacité des solutions dédiées à la recherche vectorielle…

Justement, en parlant d’IA, MariaDB se lance, lui, aussi dans la prise en charge des données vectorielles.

Pour rappel, la vectorisation consiste en la transformation de données semi-structurées et non structurées en suite de nombres à virgule dans un espace à n dimension(s). Un algorithme permet de comparer ces nombres à virgule afin d’y trouver des similarités. C’est en vectorisant les questions et les documents dans lesquels se trouvent les réponses qu’il est possible de propulser les fameux systèmes RAG (Retrieval Augmented Generation). Un grand modèle de langage se charge d’analyser les données à sa disposition et de générer les réponses aux demandes des usagers.

Comme Oracle ou SAP, MariaDB considère que la prise en charge des vecteurs doit être native. L’éditeur estime que le recours aux bases de données dédiées, comme Pinecone ou Weaviate, ou l’ajout de plugins, tels pgvector dans PostgreSQL sont des sources de complication. Ces technologies induiraient des « coûts cachés » en matière de synchronisation de données et de maintenance.

« MariaDB est connue pour sa polyvalence, et c’est un élément central de notre objectif pour MariaDB Enterprise Platform 2025 », vante Vikas Mathur, chef de produit, MariaDB plc, dans un communiqué de presse. « L’intégration de la recherche vectorielle au serveur de base de données permet aux clients d’étendre la base de données qu’ils utilisent déjà dans toute leur organisation à de nouvelles applications d’intelligence artificielle ».

Pour prouver ses dires, MariaDB a fait appel à Small Datum. En août 2024, la société de consultance a comparé les performances du moteur de recherche vectorielle natif à celles de PostgreSQL et pgvector. Ainsi, MariaDB 11.7 permettrait de traiter 1,5 fois plus de requêtes par seconde avec le même objectif de rappel du contexte (proportion de faits présents dans les vecteurs récupérés pour générer la réponse). L’indexation serait également deux fois plus rapide qu’avec le couple PostgreSQL – pgvector. Selon ce même parangonnage, MariaDB dépasserait légèrement les performances de RediSearch et surpasserait celles de Qdrant et de Weaviate, deux bases de données spécialisées.

… sans faire les bons tests

Sous le capot, MariaDB s’appuie sur une version « légèrement » modifiée de Hierchical Navigable Small Worlds (HNSW), nommée MHNSW (M, pour MariaDB). Cet algorithme basé sur la théorie des graphes s’appuie sur une méthode de recherche des plus proches voisins. HNSW offre un compromis entre précision des informations trouvées et performances. HNSW est actuellement l’algorithme de recherche vectorielle le plus populaire sur le marché.

MariaDB couple MHNSW à son moteur InnoDB. L’éditeur a développé un type de données ainsi qu’un index spécifique. Au moment du test, l’éditeur n’avait pas encore implanté la mesure des distances par similarité cosinus, Jaccard ou en utilisant un « dot product ». Il exploite donc la distance euclidienne pour mesurer l’écart entre les vecteurs. Or, si elles prennent en charge trois à quatre techniques de mesure de distance, Qdrant et Weaviate utilisent par défaut la similarité cosinus, comme Oracle Database 23ai.

La plupart des bases de données qui prennent en charge la recherche vectorielle s’appuient sur la similarité cosinus parce qu’elle est dite « insensible à la magnitude ». La mesure de la distance euclidienne peut être affectée par la différence de longueur entre les vecteurs. « Par essence, la similitude cosinus se concentre sur la direction plutôt que sur la distance entre les vecteurs, ce qui la rend idéale pour l’analyse de données à haute dimension », note l’éditeur MyScale, dans un billet de blog. « La distance euclidienne peut poser des problèmes en matière de mise à l’échelle ».

En clair, pour observer des performances similaires aux parangonnages de Small Datum, il convient de normaliser les données vectorisées et d’en limiter le volume. La distance euclidienne est davantage utilisée pour mesurer la distance des données structurées, par exemple des mesures ou des coordonnées, mais aussi des images.

 MariaDB promet déjà de prendre en charge la similarité cosinus. Surtout, l’éditeur vante les capacités de son Enterprise Platform 25 avec une fonctionnalité qui n’est pas en disponibilité générale.

« La prise en charge des types de données et de la recherche vectorielle atteindra le statut de fonctionnalité stable en février 2025 et sera intégrée dans le serveur d’entreprise lors de la prochaine version de maintenance au printemps », affirme MariaDB.

Pour l’heure, les clients peuvent tester la préversion technique de la recherche vectorielle à travers Enterprise Server 11.4, tandis que la version communautaire (11.7 RC) intègre cette fonctionnalité pour les autres usagers. MariaDB promet déjà l’intégration avec les frameworks LangChain, Spring AI et LlamaIndex.

Une meilleure prise en charge des SSD

Outre la gestion des données au format JSON, et la prise en charge partielle de la recherche vectorielle, Enterprise Server 11.4 doit éliminer le recours à un outil externe dans la gestion des schémas avec les moteurs de sockage InnoDB, Aria et MyISAM. Ici, une fonction intégrée supervise les changements de schéma (Online Schema Change). Ces changements peuvent être effectués entre les serveurs primaires et les répliques, tout comme la gestion des partitions a été améliorée.

Aussi, Enterprise Server 11.4 fournit un optimiseur, c’est-à-dire un planificateur d’exécution de requêtes optimisées pour les SSD NVMe (et plus généralement pour des disques ayant des capacités de lecture supérieures à 400 Mo/sec). Cela permettrait de réduire les coûts tout en augmentant les vitesses d’exécution. L’éditeur annonce avoir simplifié la gestion des espaces dans les tables InnoDB et la configuration SSL (également, le chiffrement TLS est dorénavant activé par défaut). MariaDB ajoute que cette version apporte « des optimisations avancées des semi-jonctions, ainsi que de la sauvegarde et des réplications ». À noter qu’Enterprise Server est désormais disponible sous la forme d’une image Docker et qu’un opérateur Kubernetes est en préparation.

MaxScale 25.01 n’est plus sous licence BSL

Quant à MaxScale 25.01, il ajoute des outils de tests et de supervision au proxy. Un filtre permet de capturer le trafic d’une instance MaxScale en production et de le rejouer en vue de vérifier les performances, les effets d’une mise à jour sur le comportement d’une base de données ou de constater des problèmes d’exécutions des requêtes. Le routeur Diff, lui, compare le fonctionnement d’un serveur MariaDB dans une version spécifique avec un autre serveur dans une autre version.

Enfin, le module MariaDB Monitor de MaxScale intègre une option sécurisée empêchant le basculement en cas de perte de données certaine, un test d’écriture sur le serveur principal pour gérer les défaillances, et des commandes de basculement avec des arguments clé-valeur, incluant le mode maintenance pour l’ancien serveur principal.

Mais il y a aussi une mauvaise nouvelle : adieu la licence BSL pour MaxScale. À partir de la version 25.01, le proxy dépend d’une licence exclusivement propriétaire. L’éditeur justifie ce choix par la volonté « d’aligner la licence avec la valeur que [MaxScale] apporte aux entreprises ».

« Les anciennes versions de MaxScale resteront sous licence BSL. Ce changement de licence nous permettra d’allouer encore plus de ressources pour fournir des capacités avancées, des mises à jour plus rapides et un support amélioré adapté aux exigences de nos clients professionnels », promet MariaDB.

Cela ne concerne pas MariaDB Community Server ou Enterprise Server. Les deux « produits » demeurent sous licence GPL.

L’éditeur assure que cela ne change rien pour les clients actuels, qui pourront monter de version sans changer leurs habitudes. Or, les entreprises devront se poser la question de l’enfermement propriétaire. Elles risquent de de se tourner vers des solutions concurrentes sur base open source, en premier lieu ProxySQL.