fr.wedoany.com Rapport : Google a dévoilé en version préliminaire la fonctionnalité HNSW accélérée par le moteur columnar pour AlloyDB, affirmant pouvoir multiplier par quatre le débit de recherche vectorielle.
AlloyDB est le service de base de données compatible PostgreSQL géré par Google. Cette nouvelle option s'adresse aux utilisateurs de pgvector — une extension PostgreSQL permettant de stocker, indexer et interroger les intelligences artificielles sous forme de vecteurs intégrés — et plus particulièrement aux équipes utilisant HNSW (Hierarchical Navigable Small World, graphe hiérarchique navigable à petite échelle) pour effectuer des recherches approximatives des plus proches voisins sur des ensembles de données très volumineux.
Cette nouvelle option exploite le moteur columnar d'AlloyDB — un cache mémoire qui stocke les données fréquemment interrogées au format columnar — pour conserver l'index HNSW en mémoire, évitant ainsi une partie de la surcharge liée à la gestion des tampons standard de PostgreSQL. Google indique que cela améliore le débit et le taux de rappel (une mesure du nombre de correspondances pertinentes dans les résultats de recherche). Lors de tests de référence sur l'ensemble de données GloVe 100 Angular contenant plus d'un million d'enregistrements, avec une limite de recherche fixée à 100 et un taux de rappel cible de 0,95, le nombre de requêtes par seconde a été multiplié par environ 4,2 à 4,9. À un niveau de débit équivalent, le taux de rappel s'est également amélioré : à environ 350 requêtes par seconde, l'activation du moteur columnar a fait passer le taux de rappel d'environ 0,78 à plus de 0,94, soit une augmentation de 0,163.
En termes de fonctionnement, PostgreSQL standard repose sur un cache de tampons partagés pour les opérations d'indexation, même lorsque les données sont déjà en mémoire. Ce processus implique toujours le verrouillage et le déverrouillage des pages, la gestion des verrous, la recherche dans la table des tampons et la gestion du remplacement des pages les moins récemment utilisées, ce qui peut augmenter la latence et réduire l'efficacité lors du parcours du graphe. AlloyDB modifie ce chemin en fixant directement l'index pgvector HNSW dans l'espace mémoire du moteur columnar, en adoptant une disposition mémoire spécialement conçue pour le modèle de parcours intensif de pointeurs requis par HNSW, contournant ainsi les goulots d'étranglement courants du gestionnaire de tampons. Google précise que cette amélioration ne provient pas simplement du déplacement des données du disque vers la RAM ; la comparaison de base suppose déjà que l'index PostgreSQL standard est entièrement mis en cache dans les tampons partagés, ce qui signifie que les gains de performance rapportés proviennent d'une architecture mémoire différente, et non d'un simple effet de cache.
Cette annonce reflète la pression croissante exercée sur les fournisseurs de bases de données pour prendre en charge la génération augmentée par récupération (RAG) et d'autres charges de travail d'IA reposant sur la recherche vectorielle. Dans ces systèmes, les opérateurs doivent souvent trouver un équilibre entre vitesse et précision lors de la recherche parmi des millions ou des milliards de vecteurs, en particulier sous un trafic de production. Pour les utilisateurs de PostgreSQL, pgvector est devenu l'un des outils les plus utilisés dans ce domaine, car il permet d'exécuter des fonctions vectorielles au sein de la pile relationnelle existante. HNSW est une méthode d'indexation populaire dans pgvector car elle offre une recherche approximative avec une latence inférieure à celle des méthodes exactes des k plus proches voisins, bien que les opérateurs doivent généralement faire un compromis sur le taux de rappel.
Google positionne AlloyDB comme une base de données capable de gérer les transactions relationnelles, l'analyse et la recherche vectorielle dans un même système. Outre HNSW, le service prend également en charge ScaNN (une autre option d'indexation vectorielle), tandis que la recherche standard des k plus proches voisins reste disponible pour les utilisateurs nécessitant un taux de rappel complet.
En ce qui concerne les compromis opérationnels, le moteur columnar utilise de la mémoire, ce qui reste une considération pratique pour les opérateurs de bases de données qui gèrent les coûts et la taille des instances. Google indique que, comme le moteur stocke les données vectorielles dans un format columnar compressé, l'empreinte mémoire est limitée. Google estime que ce compromis permet d'atteindre un niveau donné de performance de recherche vectorielle en utilisant moins de ressources de calcul, réduisant ainsi les besoins en infrastructures. Cette fonctionnalité ne nécessite aucune modification du code applicatif, car les utilisateurs peuvent continuer à utiliser la syntaxe SQL standard de pgvector. Pour l'utiliser, les utilisateurs d'AlloyDB doivent activer les indicateurs du moteur columnar et du cache d'index sur leur instance, créer un index HNSW via pgvector, puis ajouter cet index au cache du moteur columnar à l'aide d'une commande SQL.
Cette annonce offre à Google un autre moyen de différencier AlloyDB sur le marché des bases de données adaptées aux charges de travail d'IA, où les fournisseurs cloud et les équipes spécialisées en bases de données rivalisent en termes de débit, de latence et de qualité de recherche. Les tests de référence cités par Google ont été exécutés sur une machine AlloyDB C4A équipée de 16 processeurs virtuels.
