Historique de la question
La transition de la recherche lexicale à la récupération sémantique a fondamentalement modifié les exigences en matière d'infrastructure de données au cours de la dernière décennie. La recherche d'information précoce reposait sur des indices inversés et le scoring TF-IDF, mais les systèmes d'IA multimodaux modernes nécessitent des recherches de proximité dans des espaces vectoriels de haute dimension qui dépassent souvent 1000 dimensions. Ce changement s'est intensifié avec la prolifération de modèles basés sur des transformateurs, générant des milliards d'embeddings denses que les bases de données traditionnelles ne peuvent pas scanner efficacement par brute force. Le défi s'est transformé d'un simple stockage à la maintenance de graphes de voisins les plus proches approximatifs à travers des nœuds géographiquement dispersés tout en préservant la cohérence avec les systèmes sources transactionnels.
Le problème
Les bases de données vectorielles font face à des contraintes uniques sous le théorème CAP car le calcul exact des k-plus proches voisins nécessite une connaissance globale de l'ensemble de données, rendant la tolérance aux partitions et la faible latence mutuellement exclusives à l'échelle des milliards de vecteurs. Les embeddings de haute dimension consomment une mémoire significative — souvent 4 Ko par vecteur avec 1024 dimensions utilisant float32 — créant des problèmes de gravité des données qui compliquent le déploiement edge. De plus, la "malédiction de la dimensionnalité" rend les index spatiaux basés sur des arbres inefficaces, nécessitant des algorithmes basés sur des graphes comme HNSW qui sont coûteux à mettre à jour de manière incrémentale. Maintenir la cohérence entre des données transactionnelles mutables dans PostgreSQL et des indices vectoriels immuables introduit des anomalies de double écriture, tandis que la réplication inter-régionale des index aggrave les coûts de bande passante en raison des tailles de charge utile des embeddings.
La solution
Une architecture basée sur des cellules utilisant des graphes hiérarchiquement navigables et de petites mondes avec une compression par quantification de produit permet des requêtes sous 10 ms tout en réduisant l'empreinte mémoire de 90 %. Les cellules vectorielles régionales ingèrent des embeddings via des flux Apache Kafka avec des connecteurs CDC Debezium, assurant que les bases de données sources restent isolées de la surcharge de construction d'index. Le sharding dynamique utilise le hachage sensible à la localité pour acheminer les requêtes vers des partitions spécifiques, réduisant l'espace de recherche de milliards à des millions de candidats. Un modèle éventuellement cohérent avec versionnement vectoriel et tombstones de suppression douce permet des mises à jour d'index non bloquantes, tandis que le consensus Raft coordonne les changements de métadonnées à travers les cellules sans centraliser le chemin de requête chaud.
Description du problème
Une plateforme de commerce visuel mondiale "LuxeSearch" maintient 400 millions de SKUs de produits dans les catégories mode et mobilier, nécessitant une recherche de similarité visuelle où les utilisateurs téléchargent des photos pour trouver des articles identiques ou complémentaires. L'infrastructure Elasticsearch héritée s'est effondrée sous la charge computationnelle des calculs de similarité cosinus à travers des embeddings CLIP de 768 dimensions, provoquant des pics de latence de 800 ms lors des périodes de pointe. De plus, les mises à jour des métadonnées des produits se produisent à raison de 50 000 transactions par seconde lors de ventes flash, entraînant une corruption de l'index lorsque des mises à jour simultanées entraient en conflit avec les opérations de recherche, entraînant une perte de revenus dépassant 2 millions de dollars par heure de dégradations.
Solution 1 : Cluster global monolithique
La proposition initiale déployait un seul cluster Milvus dans us-east-1 avec un cache CDN global pour des ensembles de résultats de requêtes. Cette approche offrait de fortes garanties de cohérence et simplifiait la surcharge opérationnelle en maintenant un état d'index unique. Cependant, la latence inter-régionale pour les utilisateurs d'APAC dépassait 180 ms, violant les exigences de l'application mobile de moins de 50 ms, et le risque de point de défaillance unique devenait inacceptable pendant la saison des achats des vacances lorsque les coûts d'indisponibilité augmentent de façon exponentielle.
Solution 2 : Indices régionaux par lot nocturne
Une architecture alternative proposait des indices régionaux FAISS reconstruits via des jobs de lot nocturnes à partir de snapshots S3. Cela offrait une latence de requête inférieure à 5 ms grâce à l'inférence CPU locale et supprimait les allers-retours réseau lors des recherches. Malheureusement, la fraîcheur des données de 24 heures entraînait des plaintes de clients concernant des "produits fantômes" apparaissant dans les résultats de recherche visuelle après que des articles étaient épuisés, et les fenêtres de maintenance de six heures requises pour la reconstruction de l'index violaient le SLA de temps de disponibilité de 99,99 %.
Solution choisie
L'équipe a mis en œuvre des cellules vectorielles autonomes utilisant Redis avec le module RedisSearch pour les indices chauds contenant le top 10 % des produits par volume de requêtes, soutenus par des graphes HNSW mappés en mémoire stockés dans S3 pour les données froides. Debezium capture les changements dans PostgreSQL dans Kafka, alimentant des constructeurs d'index locaux qui mettent en œuvre des mises à jour incrémentales HNSW utilisant le modèle outbox. La quantification des produits réduit les vecteurs float32 de 768 dimensions à des codes de 96 octets avec une précision de rappel@10 de 98 %. Cette solution a été choisie car elle fournit une cohérence réglable avec des sémantiques de lecture de vos écritures dans un délai de 500 ms, gère 100K mises à jour d'embeddings par seconde sans blocage de requêtes, et maintient une latence p99 de 8 ms à travers toutes les 12 régions mondiales.
Résultat
Après six mois d'opération en production, l'architecture a atteint 99,97 % de disponibilité, soutenu 50 millions de recherches visuelles quotidiennes et réduit les coûts d'infrastructure de 40 % par rapport à la proposition monolithique grâce à un tiering intelligent. La métrique de rappel@10 s'est stabilisée à 99,2 %, dépassant les exigences commerciales, et le système a réussi à absorber une montée en charge de 300 % de trafic pendant le Black Friday sans intervention manuelle ni tempêtes de cache.
Pourquoi la distance euclidienne devient-elle inefficace dans des espaces de haute dimension, et comment cela impacte-t-il la sélection d'index ?
Dans des espaces de haute dimension dépassant 100 dimensions, le ratio entre les voisins les plus proches et les plus éloignés converge vers 1 en raison de la concentration du volume à la surface de l'hypersphère, rendant les distances euclidiennes statistiquement indiscernables et spatialement non informatives. Ce phénomène invalide la partition spatiale basée sur des arbres tels que les kd-arbres ou les R-arbres, qui reposent sur une différenciation de distance significative pour émonder efficacement les branches de recherche. Par conséquent, des méthodes basées sur des graphes comme les index HNSW ou FAISS IVF deviennent nécessaires car elles naviguent à proximité à travers la connectivité relative des voisinages plutôt que les distances de coordonnées absolues, bien qu'elles nécessitent significativement plus de mémoire et des procédures de maintenance incrémentale complexes.
Comment gérez-vous le "problème de double écriture" lorsque la base de données transactionnelle et l'index vectoriel doivent être mis à jour atomiquement ?
Le problème de double écriture se produit lorsque des transactions distribuées échouent entre le stockage OLTP et la base de données vectorielle, entraînant des résultats de recherche retournant des éléments supprimés ou manquant de nouveaux embeddings en raison d' états de commit partiels. Au lieu de mettre en œuvre des protocoles de commit en deux phases qui nuiraient aux exigences de latence de moins de 10 ms, les architectes devraient employer le modèle d'outbox transactionnelle où PostgreSQL écrit dans une table outbox au sein de la même transaction ACID que le changement de données commerciales. Debezium lit cette outbox et publie de manière asynchrone dans Kafka, garantissant une livraison exactement-une-fois aux constructeurs d'index vectoriels ; les entrées vectorielles incluent des numéros de version monotoniques, et l'API de recherche filtre les résultats en validant contre le stockage de métadonnées OLTP pour exclure les versions obsolètes, masquant efficacement les incohérences sans bloquer les requêtes.
Quelles sont les implications mémoire des index ANN basés sur des graphes lors de mises à jour incrémentales, et comment atténuez-vous l'amplification des écritures ?
HNSW et des structures de graphes similaires nécessitent des mécanismes de verrouillage ou d'écriture sur copie pendant l'insertion d'arêtes, entraînant une amplification significative des écritures, car l'ajout d'un vecteur peut déclencher la reconnexion de plusieurs centaines d'arêtes pour maintenir la propriété de navigabilité hiérarchique. Dans des environnements à mémoire contrainte, cela crée des défauts de page et une pression de collecte des déchets qui dégradent la latence des requêtes de manière imprévisible lorsque l'ensemble de travail dépasse la capacité de DRAM. Les stratégies d'atténuation incluent l'utilisation de stockage par niveaux où les couches de graphes chauds résident en mémoire et les couches froides dans de la mémoire persistante ou des SSD NVMe rapides ; regrouper les mises à jour en micros segments qui se fusionnent de manière asynchrone pendant les périodes de faible trafic en utilisant des techniques de fusion structurée par journal ; et employer une construction de graphes sensible à la quantification où les vecteurs compressés déterminent la topologie du graphe tandis que les vecteurs bruts ne sont récupérés qu'au cours du réajustement final, réduisant ainsi le changement de mémoire de 70 % tout en maintenant des métriques de rappel cibles.