Dans les coulisses de l'ingénierie d'Alibaba pour adapter pgvector à l'échelle du milliard de vecteurs

Les bases de données vectorielles ont traversé trois phases depuis 2023 : d'abord, le support des types vectoriels et des opérateurs de distance de base. Puis sont venus les index de voisins approximatifs comme IVF et HNSW, ramenant les temps de réponse à des millisecondes. La troisième phase, la préparation à la production à grande échelle, s'est avérée la plus difficile. L'équipe PolarDB pour PostgreSQL d'Alibaba Cloud a documenté son approche dans un article technique qui détaille exactement ce qu'il a fallu pour transformer l'extension open-source pgvector en un moteur capable de stocker des milliards de vecteurs et de renvoyer des résultats en millisecondes.

Quantification : adapter des vecteurs plus grands à des empreintes plus petites

Le premier goulot d'étranglement est le coût de stockage et de calcul. Un seul vecteur float32 de 768 dimensions pèse environ 3 Ko. Multipliez cela par un milliard et vous obtenez 3 To de données brutes avant les index. PolarDB pour PostgreSQL prend désormais en charge trois schémas de quantification en complément des index IVF et HNSW : la quantification de produit (PQ), la quantification scalaire (SQ) et la quantification aléatoire de bits (RaBitQ). Chacun compresse un vecteur entre un quart et un soixante-quatrième de sa taille d'origine, tout en gardant la précision contrôlable. L'équipe a souligné qu'aucun schéma unique ne convient à tous les scénarios, le bon choix dépend de la taille du jeu de données, de la concentration des caractéristiques et de la dimensionnalité. PQ divise les vecteurs en sous-segments et entraîne un dictionnaire de codes par segment, offrant une compression élevée mais un coût d'entraînement important. SQ mappe chaque dimension float32 linéairement vers int8 ou int4, ce qui en fait l'option la plus rentable. RaBitQ utilise une transformation orthogonale aléatoire plus une quantification à 1 bit, avec une borne inférieure de précision prouvable en théorie.

Améliorations des performances : gestion des E/S et de l'espace libre à l'échelle du milliard

Les index construits sur pgvector standard suivent le gestionnaire de buffer de PostgreSQL : chaque page écrite passe par le buffer partagé, acquiert un verrou, génère des journaux d'écriture anticipée et est vidée de manière asynchrone. Lorsque les index atteignent des centaines de gigaoctets, ce chemin devient le principal goulot d'étranglement. PolarDB a introduit des lectures-écritures par lots pour la construction d'index et une fenêtre de préchargement pour les requêtes. Les tests internes ont montré une amélioration de 1,5 à 2 fois de la vitesse de construction et d'interrogation à l'échelle du milliard de vecteurs. Un second point douloureux est apparu sous des insertions soutenues : lorsque des pages libres apparaissent dans un index, une nouvelle insertion devait scanner séquentiellement les pages de données pour trouver de l'espace disponible. L'équipe a introduit un mécanisme efficace de gestion de la carte d'espace libre (FSM). Dans les tests avec des insertions soutenues à l'échelle du milliard de lignes, la contention des E/S a chuté de 90 % et la latence d'écriture p99 est devenue nettement plus stable. Combiné à un framework de nettoyage d'index remanié qui fait passer le gonflement d'une croissance linéaire à un état stable, le système maintient une stabilité à long terme même sous des charges de travail avec beaucoup d'écritures et de suppressions.

Améliorations de l'écosystème : polar_vectorboost automatise la recherche hybride

Les équipes adoptant la récupération vectorielle devaient souvent écrire manuellement de grandes quantités de logique de requête de fusion, intégrer des colonnes, tokeniser, réinjecter des données, recommander des index, puis gérer des échelles incohérentes, un classement de fusion manquant et une stabilité du rappel. L'extension interne de PolarDB, polar_vectorboost, compresse ces opérations SQL à haute fréquence en un seul appel de fonction. Un seul appel peut ajouter une colonne d'incorporation, tokeniser automatiquement le texte, réinjecter des données, recommander un index et enregistrer des métadonnées. Pour la recherche hybride, il supporte deux algorithmes de fusion : le Reciprocal Rank Fusion (RRF), insensible à l'échelle, et une approche pondérée normalisée min-max. Il joint également automatiquement les termes tsquery avec OR pour éviter l'effondrement du rappel que peut causer la jointure AND par défaut de plainto_tsquery. Un ensemble de fonctions de diagnostic, vérifiant les types de colonnes, la cohérence des dimensions, l'état des index et les vecteurs NULL ou de norme zéro, aide les développeurs à détecter les problèmes avant qu'ils n'atteignent la production.

Scénarios à grande échelle : pgvector distribué pour une capacité au niveau du pétaoctet

Le stockage sur un seul nœud atteint finalement un plafond, et le débit d'écriture est limité par un seul CPU. PolarDB pour PostgreSQL a achevé l'adaptation distribuée de pgvector. L'approche centrale repose sur trois mécanismes : distribuer les données vectorielles sur des shards, chacun avec son propre index ; gérer les requêtes inter-shards avec un modèle scatter-gather ; et supporter le rééquilibrage dynamique des shards. Le résultat est trois changements qualitatifs. Le stockage s'étend horizontalement jusqu'à l'ordre du pétaoctet. Le débit d'écriture s'étend approximativement linéairement avec le nombre de nœuds. Et la reprise après échec devient au niveau du shard plutôt qu'au niveau de la base de données. L'équipe a noté que dans les scénarios vectoriels, la capacité distribuée ne concerne pas seulement la capacité, elle détermine si le système reste durable sous une croissance à long terme.

Capacités fondamentales : ce qui le rend de qualité production

Les capacités de récupération vectorielle reposent sur la couche fondamentale de la base de données. La pile fondamentale de PolarDB pour PostgreSQL comprend une optimisation approfondie du noyau avec réplication physique, un réseau à haute vitesse RDMA et un stockage partagé distribué. Un passage à l'échelle vers le haut ou vers le bas en quelques secondes est possible grâce à une architecture à un écrivain et plusieurs lecteurs avec une capacité de l'ordre du téraoctet. Un moteur de requêtes parallèles inter-machines exécute SQL en coopération entre les nœuds pour accélérer les requêtes analytiques. Pour les magasins vectoriels à l'échelle du milliard, les shards chauds résident dans un niveau à haute vitesse tandis que les shards froids sont déplacés vers le stockage objet, équilibrant coût et performance. L'équipe a soutenu que la capacité vectorielle se concentre principalement sur la couche de récupération, tandis que la disponibilité globale en production dépend de la fondation sous-jacente de la base de données. Chacune des cinq dimensions aborde un goulot d'étranglement technique clé plutôt qu'une seule métrique de performance, et ensemble, elles transforment pgvector d'une extension open-source en un moteur intégré capable de gérer des milliards de vecteurs avec des temps de réponse de l'ordre de la milliseconde.