Stocker et Interroger des Embeddings à Grande Échelle

Les défis de la grande échelle

Qu'est-ce que "grande échelle" ?

La notion de "grande échelle" dans le contexte des bases vectorielles varie selon les cas d'usage, mais elle implique généralement des défis significatifs en termes de performance, coût et complexité opérationnelle.

Par exemple, Google Search indexe plusieurs milliards de documents avec des embeddings de 768-1024 dimensions. Spotify gère 100+ millions de pistes audio avec leurs embeddings acoustiques. Meta FAISS alimente les recommandations pour 3+ milliards d'utilisateurs.

À partir de 10 millions de vecteurs (dimension 768, float32), vous atteignez ~25GB de données brutes. Sans compression ni indexation optimisée, une simple recherche k-NN exacte prendrait 5-30 secondes. C'est à ce seuil que les stratégies de scaling deviennent indispensables.

Défis de stockage

Le stockage de millions ou milliards de vecteurs pose des défis multidimensionnels :

• Volume de données brut : Un embedding text-embedding-3-large (3072 dimensions, float32) occupe 12KB. 100M vecteurs = 1.2TB de stockage brut, sans compter les métadonnées et indexes.
• Coût RAM vs SSD : La RAM coûte $10-50/GB/mois en cloud, contre $0.10-0.50/GB pour le SSD. Pour 1TB en RAM : $10,000-50,000/mois !
• Latence d'accès : RAM = 100ns, SSD NVMe = 10-100µs, SSD SATA = 100µs-1ms, HDD = 5-10ms, S3 = 50-200ms
• Durabilité : Les données en RAM sont volatiles. Le stockage persistant nécessite WAL (Write-Ahead Logs), snapshots, réplication.
• Localité des données : Les vecteurs similaires doivent être co-localisés pour optimiser les accès disque (clustering spatial).

Scénario : 100M vecteurs × 1536 dimensions (OpenAI ada-002) × 4 bytes (float32)

Stockage brut : 100M × 1536 × 4 = 614.4GB
Avec index HNSW (2x overhead) : 614.4GB × 2 = 1.23TB
Avec réplication 3x : 1.23TB × 3 = 3.69TB

Coût RAM (AWS EC2 r7g) : 3.69TB × $40/GB = $147,600/mois
Coût SSD (gp3) : 3.69TB × $0.08/GB = $295/mois
Coût S3 (Standard) : 3.69TB × $0.023/GB = $85/mois

→ Le choix RAM vs SSD vs S3 a un impact de 500-1700x sur les coûts !
                    

Défis de performance

Les exigences de performance deviennent exponentiellement plus complexes à grande échelle :

• Latence p99 : Les applications en production ciblent p50 <20ms et p99 <100ms. À grande échelle, le tail latency (p99, p99.9) explose en raison des requêtes distribuées.
• Débit (QPS) : Les systèmes de recommandation nécessitent 10K-100K+ requêtes par seconde. Chaque milliseconde de latence supplémentaire réduit le débit maximal.
• Précision vs vitesse : Les algorithmes ANN (Approximate Nearest Neighbors) sacrifient la précision pour la vitesse. À grande échelle, un recall de 95% peut manquer des millions de résultats pertinents.
• Hot spots : Certains vecteurs (ex: articles tendance) reçoivent 1000x plus de requêtes. Sans sharding intelligent, cela crée des goulets d'étranglement.
• Cold start : Le chargement d'un index HNSW de 100GB peut prendre 5-15 minutes, impactant les déploiements et le disaster recovery.

Défis opérationnels

La complexité opérationnelle croît de manière non-linéaire avec l'échelle :

• Déploiements : Le rolling update de 50+ shards doit se faire sans interruption de service et sans dégradation de recall.
• Monitoring : Des milliers de métriques à surveiller (latence par shard, recall, cache hit ratio, mémoire, CPU, I/O disque, network).
• Debugging : Identifier qu'un seul shard sur 100 dégrade les performances p99 de tout le cluster est un défi majeur.
• Disaster recovery : Restaurer 10TB de données depuis S3 peut prendre plusieurs heures. Les stratégies de backup/restore doivent être testées régulièrement.
• Migrations de schéma : Re-indexer 1 milliard de vecteurs avec une nouvelle dimension (ex: passage de 768 à 1536) peut prendre plusieurs jours.
• Gestion des versions : Maintenir la compatibilité entre anciennes et nouvelles versions d'embeddings lors des migrations de modèles.

Défis de coût

Le coût total de possession (TCO) d'une infrastructure vectorielle à grande échelle comprend plusieurs composantes souvent sous-estimées :

• Compute : CPU/GPU pour l'indexation et les requêtes. À grande échelle, passer de CPU à GPU (RAPIDS cuVS, GPU-accelerated HNSW) peut diviser les coûts par 5-10x.
• Stockage : RAM, SSD, S3. Le tiering intelligent (données chaudes en RAM, tièdes en SSD, froides en S3) est essentiel.
• Network : À 100K QPS avec 1KB de payload, vous transférez 800GB/heure = 19TB/jour. Les coûts de bande passante inter-AZ peuvent atteindre $1000+/mois.
• Licensing : Certaines solutions vectorielles propriétaires facturent par million de vecteurs stockés ou par QPS.
• Personnel : Coût souvent dominant. Un ingénieur ML/Data coûte $150K-300K/an. Une équipe de 3-5 personnes = $500K-1.5M/an.

Scénario 1 : Pinecone (Managed Cloud)
- Pod-based : p2 pod (400GB index) × 3 replicas = $2,100/mois
- Serverless : $0.096/M read units ≈ $1,500-3,000/mois (50K QPS moyen)
→ Total : ~$2,500-3,000/mois

Scénario 2 : Qdrant Cloud (Managed)
- Cluster 8 nodes (32GB RAM each) = $1,600/mois
- Storage (500GB SSD) = $50/mois
→ Total : ~$1,650/mois

Scénario 3 : Self-Hosted (AWS EC2 + Qdrant OSS)
- EC2 r7g.4xlarge × 3 (128GB RAM) = $1,800/mois
- EBS gp3 2TB × 3 = $600/mois
- Load balancer, monitoring = $200/mois
- Personnel (20% FTE engineer) = $3,000/mois
→ Total : ~$5,600/mois

Conclusion : Managed solutions sont rentables jusqu'à ~50M vecteurs.
Au-delà, self-hosted devient compétitif si vous avez l'expertise interne.
                    

Stratégies de stockage

In-memory vs on-disk

Le choix entre stockage in-memory et on-disk est le trade-off fondamental qui dicte les performances et coûts :

Stockage In-Memory (RAM)

• Latence ultra-faible : Accès en 50-100ns, permettant des recherches <5ms p50, <15ms p99
• Débit élevé : 100K-500K QPS par serveur (limité par CPU, pas I/O)
• Coût prohibitif : $10-50/GB/mois en cloud. 1TB de RAM = $10K-50K/mois
• Scalabilité limitée : Serveurs RAM limités à 512GB-2TB. Au-delà, nécessite sharding intensif
• Solutions : FAISS (Meta), Redis Vector, Qdrant en mode in-memory

Stockage On-Disk (SSD)

• Coût réduit : $0.08-0.50/GB/mois pour SSD NVMe. 10-50x moins cher que RAM
• Scalabilité : Serveurs avec 10-100TB de SSD sont standards
• Latence accrue : +10-50ms vs RAM, dépend du pattern d'accès et du caching OS
• Persistance native : Données durables par défaut, simplifie disaster recovery
• Solutions : Milvus, Weaviate, Qdrant avec persistent storage, Elasticsearch

Tiered storage (chaud/froid)

Le tiered storage (stockage étagé) exploite le principe de Pareto : 80% des requêtes ciblent 20% des données. Cette approche permet d'optimiser drastiquement les coûts sans sacrifier la performance globale.

Architecture Tiering Classique

• Tier 1 (Chaud) - RAM : 5-20% des vecteurs les plus fréquemment accédés. Latence <5ms. Index HNSW en mémoire.
• Tier 2 (Tiède) - SSD NVMe : 30-60% des vecteurs avec accès réguliers. Latence 10-30ms. Index partiel en RAM.
• Tier 3 (Froid) - SSD SATA/HDD : 20-50% des vecteurs rarement accédés. Latence 50-200ms. Pas d'index en RAM.
• Tier 4 (Archivage) - S3/Glacier : Vecteurs historiques/archivés. Latence 200ms-12h. Récupération à la demande.

Données : 200M produits, vecteurs 768 dim = 614GB bruts

Segmentation :
- Tier 1 (RAM) : 10M produits populaires (30GB) → latence 3-8ms
- Tier 2 (SSD NVMe) : 100M produits actifs (300GB) → latence 15-40ms
- Tier 3 (SSD SATA) : 80M produits anciens (250GB) → latence 50-150ms
- Tier 4 (S3) : 10M produits archivés (34GB) → latence 1-5s (lazy load)

Coût total :
- RAM : 30GB × $40 = $1,200/mois
- SSD NVMe : 300GB × $0.30 = $90/mois
- SSD SATA : 250GB × $0.10 = $25/mois
- S3 : 34GB × $0.023 = $0.78/mois
→ Total : $1,316/mois (vs $24,560/mois full-RAM)

Performance : 85% requêtes <10ms, 98% <50ms, 99.5% <200ms
                    

Stratégies de Promotion/Dégradation (Hot/Cold Transition)

Le déplacement des vecteurs entre tiers doit être automatisé selon des métriques d'accès :

• LRU (Least Recently Used) : Simple, efficace pour la plupart des cas. Demande peu de tracking.
• LFU (Least Frequently Used) : Meilleur pour les workloads avec hot items stables (ex: produits best-sellers).
• Time-decay : Privilégie les données récentes. Idéal pour actualités, tendances, contenus temporels.
• Hybrid (LRFU) : Combine récence et fréquence. Complexe mais optimal pour workloads variés.
• ML-based : Prédit les futurs accès via modèles ML. Utilisé par Google, Meta pour leurs systèmes à très grande échelle.

Sharding et partitionnement

Le sharding (partitionnement horizontal) est indispensable dès que vos données dépassent la capacité d'un serveur unique. Il consiste à diviser les vecteurs en sous-ensembles indépendants distribués sur plusieurs nœuds.

Stratégies de Sharding

1. Hash-Based Sharding

• Principe : shard_id = hash(vector_id) % num_shards
• Avantages : Distribution uniforme, simple à implémenter, pas de hotspots
• Inconvénients : Toutes les requêtes de recherche doivent interroger tous les shards (scatter-gather), augmentant la latence p99
• Usage : Workloads équilibrés sans localité spatiale particulière

2. Range-Based Sharding

• Principe : shard_id = find_range(metadata_field) (ex: date, catégorie, user_id)
• Avantages : Requêtes avec filtres peuvent cibler 1 seul shard, réduisant latence et charge
• Inconvénients : Risque de hotspots si distribution non uniforme (ex: 80% des users actifs sur 1 shard)
• Usage : Applications multi-tenants, données temporelles, segmentation utilisateurs

3. Geo-Based Sharding

• Principe : Sharding par région géographique (US-East, EU-West, APAC)
• Avantages : Réduit la latence réseau (users EU → shard EU), conformité RGPD/résidency
• Inconvénients : Complexité de routage, requêtes cross-region coûteuses
• Usage : Applications globales avec forte localité utilisateurs

4. Semantic/Clustering-Based Sharding

• Principe : Clustering des vecteurs (K-means, HDBSCAN), chaque cluster = 1 shard
• Avantages : Requêtes de recherche ciblent 1-3 shards proches (routing intelligent), recall optimal
• Inconvénients : Complexité algorithmique élevée, rebalancing difficile, sensible aux drifts
• Usage : Systèmes avancés type Google Search, Meta FAISS, nécessite expertise ML

Réplication et haute disponibilité

La haute disponibilité (HA) est critique pour les systèmes de production. Un seul shard en panne peut dégrader le recall global de 5-10% ou rendre le service indisponible.

Stratégies de Réplication

Replication Factor (RF)

• RF=1 : Aucune réplication. Perte de données en cas de panne. Acceptable uniquement pour dev/test.
• RF=2 : 1 réplica. Tolère la panne d'1 node. Coût 2x. Standard pour production.
• RF=3 : 2 replicas. Tolère 2 pannes simultanées. Coût 3x. Recommandé pour systèmes critiques.
• RF=5+ : Multi-region, disaster recovery extrême. Utilisé par les GAFAM.

Modes de Réplication

• Synchrone : L'écriture attend la confirmation de tous les replicas. Garantit cohérence forte mais latence +20-50ms.
• Asynchrone : L'écriture retourne immédiatement, réplication en background. Latence faible mais risque de perte de données.
• Quorum-based (Raft, Paxos) : Écriture validée si majorité (ex: 2/3) des replicas confirment. Compromis cohérence/performance.

Disaster Recovery (DR)

• RPO (Recovery Point Objective) : Données perdues acceptables. Typiquement 5-60 minutes pour bases vectorielles.
• RTO (Recovery Time Objective) : Temps de restauration acceptable. Cible <1h pour prod, <15min pour critique.
• Backups : Snapshots incrémentaux vers S3 toutes les 1-6h. Retention 7-30 jours.
• Cross-region replication : Replicas asynchrones dans une région différente (US-East → EU-West).
• Restoration testing : Tester la restauration complète tous les mois (chaos engineering).

Calcul des besoins en stockage

Calculer précisément les besoins en stockage est essentiel pour dimensionner l'infrastructure et estimer les coûts.

Formule de Calcul de Base

Stockage Total = Vecteurs Bruts + Index + Métadonnées + Overhead

1. Vecteurs Bruts
Taille = num_vectors × dimensions × bytes_per_dimension

Exemple : 50M vecteurs, 768 dim, float32 (4 bytes)
= 50,000,000 × 768 × 4 = 153,600,000,000 bytes = 143GB

2. Index HNSW
Overhead = 1.5x à 3x selon les paramètres (M, efConstruction)
Typique : 2x pour M=16, efConstruction=200
= 143GB × 2 = 286GB

3. Métadonnées
ID (8 bytes) + metadata JSON (~200 bytes/vecteur en moyenne)
= 50M × 208 bytes = 10,400,000,000 bytes = 9.7GB

4. Overhead Système
WAL, logs, indexes secondaires : +10-20%
= (143 + 286 + 9.7) × 1.15 = 504GB

5. Réplication (RF=3)
= 504GB × 3 = 1,512GB (≈1.5TB)

Résultat Final : ~1.5TB de stockage nécessaire
                    

Optimisations via Compression

La quantization permet de réduire drastiquement l'empreinte mémoire :

• Scalar Quantization (int8) : 4x réduction (float32 → int8). Perte de précision ~2-5%.
• Product Quantization (PQ) : 8-32x réduction. Perte de précision ~5-15%.
• Binary Quantization : 32x réduction. Perte de précision ~10-25%, uniquement pour certains cas d'usage.

Compression et quantification

Product Quantization (PQ)

La Product Quantization est la technique de compression la plus puissante pour les vecteurs de haute dimension. Inventée par Hervé Jégou (INRIA/Meta), elle est au cœur de FAISS.

Principe de Fonctionnement

PQ décompose un vecteur de dimension D en M sous-vecteurs de dimension D/M, puis quantifie chaque sous-vecteur indépendamment avec un codebook de k centroids (typiquement k=256).

Exemple : Vecteur 768 dimensions

Étape 1 : Décomposition
Vecteur original : [v1, v2, ..., v768] (768 × 4 bytes = 3KB)
Décomposer en M=8 sous-vecteurs de 96 dimensions chacun
→ sub1 = [v1...v96], sub2 = [v97...v192], ..., sub8 = [v673...v768]

Étape 2 : Quantification
Pour chaque sous-vecteur, trouver le centroid le plus proche parmi 256 (via k-means)
sub1 → centroid_id = 42
sub2 → centroid_id = 189
...
sub8 → centroid_id = 7

Étape 3 : Encodage
Vecteur compressé = [42, 189, ..., 7] (8 × 1 byte = 8 bytes)

Résultat : 3072 bytes → 8 bytes = 384x compression !
                    

Avantages et Inconvénients

• Compression extrême : 8x à 64x réduction typique (selon M et k)
• Recherche rapide : Distances asymmétriques pré-calculées (query vs codebooks)
• Perte de précision : Recall 85-98% selon les paramètres et données
• Complexité : Nécessite training des codebooks (K-means sur dataset représentatif)
• Trade-off M vs k : M=8, k=256 (standard) offre bon compromis compression/précision

Scalar Quantization

La Scalar Quantization (SQ) est la forme la plus simple de compression : convertir les floats 32-bit en entiers 8-bit (ou moins).

Principe

Chaque dimension est quantifiée indépendamment en mappant la plage [min, max] sur [0, 255] pour int8 :

quantized_value = (value - min) / (max - min) × 255

Exemple : dimension avec valeurs dans [-0.5, 0.8]
value = 0.3
quantized = (0.3 - (-0.5)) / (0.8 - (-0.5)) × 255 = 157
                    

Variantes

• SQ8 (8-bit) : float32 → int8. Compression 4x. Perte précision 2-5%. Standard.
• SQ4 (4-bit) : float32 → 4-bit. Compression 8x. Perte précision 8-12%. Expérimental.
• SQfp16 (half-precision) : float32 → float16. Compression 2x. Perte négligeable <1%.

Avantages vs PQ

• Simplicité : Pas de training requis, juste calcul de min/max par dimension
• Rapidité : Quantization/dequantization très rapides (opérations simples)
• Précision : Perte minimale (2-5% vs 5-15% pour PQ)
• Hardware-friendly : CPUs modernes ont des instructions SIMD optimisées pour int8

Binary quantization

La Binary Quantization pousse la compression à l'extrême : chaque dimension devient 1 bit (0 ou 1).

Principe

Pour chaque dimension :
bit = 1 si value > threshold (souvent 0 ou mean)
bit = 0 sinon

Exemple : vecteur [0.3, -0.5, 0.8, -0.1, 0.6]
Binarisé (threshold=0) : [1, 0, 1, 0, 1]
                    

Distance : Hamming au lieu d'Euclidean/Cosine

Les vecteurs binaires utilisent la distance de Hamming (nombre de bits différents), calculable extrêmement rapidement via XOR + popcount (1 instruction CPU).

Avantages et Limites

• Compression extrême : 32x pour float32 → binary. Vecteur 768 dim = 96 bytes au lieu de 3KB.
• Vitesse : Recherche 10-100x plus rapide que float32. GPUs peuvent traiter 100M+ vecteurs/seconde.
• Perte de précision majeure : Recall 60-85% typiquement. Inutilisable pour beaucoup d'applications.
• Cas d'usage limités : Acceptable pour pré-filtrage, re-ranking en deux étapes, ou données intrinsèquement binaires.

Compromis précision vs compression

Le choix de la technique de compression dépend du trade-off acceptable entre précision (recall), mémoire et latence.

Gains de stockage et performance

Les gains de compression se traduisent directement en réduction de coûts et amélioration des performances (paradoxalement).

Impact sur les Coûts (Exemple : 200M vecteurs, 1536 dim)

Scénario Baseline : Float32 sans compression
Stockage : 200M × 1536 × 4 bytes = 1.15TB
Coût RAM (AWS r7g) : 1.15TB × $40/GB = $46,000/mois
Coût SSD (gp3) : 1.15TB × $0.08/GB = $92/mois

Scénario avec SQ8
Stockage : 1.15TB / 4 = 288GB
Coût RAM : 288GB × $40 = $11,520/mois (↓4x réduction)
Coût SSD : 288GB × $0.08 = $23/mois (↓4x réduction)

Scénario avec PQ (M=8, k=256)
Stockage : 200M × 8 bytes = 1.6GB (index) + codebooks
Coût RAM : ~5GB total × $40 = $200/mois (↓230x réduction !)
Coût SSD : 5GB × $0.08 = $0.40/mois (↓230x réduction !)

RÉSULTATS
Passer de float32 à PQ peut diviser les coûts par 200x+ !
                    

Impact sur les Performances

Contre-intuitivement, la compression peut améliorer les performances :

• Moins de transferts mémoire : Vecteurs compacts = plus de vecteurs en cache CPU L1/L2/L3
• Vectorisation SIMD : Les CPUs modernes traitent int8 plus rapidement que float32 (AVX-512 VNNI)
• Moins de I/O disque : Si les vecteurs sont sur SSD, lire 8 bytes vs 3KB = 384x moins de latence I/O
• Meilleur parallélisme : Plus de vecteurs en RAM = moins de swapping, plus de threads productifs

Conclusion : PQ non seulement réduit les coûts de 200x, mais améliore aussi la latence de 50% et le débit de 2-3x !

Indexation distribuée

Index distribués vs centralisés

L'indexation distribuée devient nécessaire lorsque l'index dépasse la capacité mémoire d'un serveur unique (typiquement >50M vecteurs).

Index Centralisé (Single-Node)

• Architecture : Tous les vecteurs et l'index HNSW/IVF sur un seul serveur
• Avantages : Simplicité, pas de latence réseau, recall parfait (100%)
• Limites : Scalabilité verticale uniquement (512GB-2TB RAM max), SPOF (Single Point of Failure)
• Cas d'usage : <50M vecteurs, prototypes, entreprises de taille moyenne

Index Distribué (Multi-Node)

• Architecture : Index segmenté sur N shards (ex: 100M vecteurs = 10 shards de 10M)
• Avantages : Scalabilité horizontale quasi-illimitée, haute disponibilité (replicas), débit élevé
• Complexités : Latence réseau (+5-20ms), coordination (routing, aggregation), recall peut baisser (95-99%)
• Cas d'usage : >50M vecteurs, exigences HA/DR, scaling futur

Configuration :
- 50 shards de 10M vecteurs chacun
- 3 replicas par shard (RF=3) pour HA
- HNSW index (M=16, ef=200) par shard

Topologie :
Client → Load Balancer → Query Router
                           └→ Shard 1 (Primary + 2 Replicas)
                           └→ Shard 2 (Primary + 2 Replicas)
                           ...
                           └→ Shard 50 (Primary + 2 Replicas)

Flux de requête :
1. Client envoie query vector
2. Router détermine shards cibles (tous ou subset via routing intelligent)
3. Requêtes parallèles vers shards sélectionnés
4. Chaque shard retourne top-k local
5. Aggregator fusionne résultats (merge des top-k)
6. Retour des top-k globaux au client

Latence totale : max(latence_shards) + latence_aggregation
→ Typiquement 20-60ms p50, 80-200ms p99
                    

Stratégies de sharding d'index

Le sharding d'index peut être naïf (tous les shards interrogés) ou intelligent (routing sélectif).

Sharding Naïf (Scatter-Gather)

• Stratégie : Hash random sur vector_id, chaque requête interroge TOUS les shards
• Avantages : Distribution uniforme garantie, pas de hotspots, recall 100%
• Inconvénients : Latence p99 = pire latence parmi tous les shards (tail latency amplification)
• Formule latence : p99_global ≈ p99_shard × (1 + log(num_shards))
• Exemple : 50 shards avec p99=20ms → p99_global ≈ 100-120ms

Sharding Intelligent (Semantic Routing)

• Stratégie : Clustering spatial (K-means, HDBSCAN) + routing basé sur similarité du query vector
• Principe : Pré-calculer des centroids par shard. Pour chaque query, ne cibler que les 2-5 shards les plus proches.
• Avantages : Latence réduite de 5-10x (seulement 2-5 shards interrogés vs 50), débit augmenté
• Inconvénients : Recall 95-99% (risque de manquer vecteurs similaires dans shards non-interrogés), complexité algorithmique

# Pré-calcul (offline) :
for each shard:
    centroid[shard] = mean(all_vectors_in_shard)

# Au moment de la requête :
def search(query_vector, k=10):
    # 1. Calculer distances query ↔ centroids
    distances = [cosine(query_vector, centroid[i]) for i in range(num_shards)]

    # 2. Sélectionner top-3 shards les plus proches
    target_shards = argsort(distances)[:3]

    # 3. Requêtes parallèles uniquement sur ces shards
    results = parallel_search(target_shards, query_vector, k=k*2)

    # 4. Merger et retourner top-k
    return merge_results(results)[:k]
                    

Hybrid Sharding (Two-Stage)

Combinaison des deux approches pour optimiser recall ET latence :

1. Stage 1 (Fast) : Routing intelligent vers 2-3 shards, retour top-100 en 10-20ms
2. Stage 2 (Accurate) : Si recall insuffisant (évalué via score threshold), scatter-gather sur tous les shards
3. Résultat : 90%+ des requêtes servent en <20ms (fast path), 10% prennent 50-100ms (accurate path)

Construction d'index en parallèle

Construire un index HNSW sur 100M+ vecteurs peut prendre plusieurs heures à plusieurs jours sur un seul serveur. La parallélisation est cruciale.

Techniques de Parallélisation

1. Parallélisme Intra-Shard (Multi-threading)

• Construire l'index HNSW en utilisant tous les cœurs CPU disponibles
• FAISS, Hnswlib supportent nativement avec paramètre num_threads
• Speedup linéaire jusqu'à ~16-32 threads, puis rendements décroissants
• Exemple : 10M vecteurs, 1 thread = 4h, 32 threads = 15-20min

2. Parallélisme Inter-Shard (Distributed Build)

• Construire chaque shard indépendamment sur des serveurs différents
• Speedup parfait (10 shards = 10x plus rapide)
• Nécessite orchestration (Kubernetes Jobs, Spark, Ray)
• Exemple : 100M vecteurs, 10 shards parallèles, 32 threads/shard = ~20-30min total

apiVersion: batch/v1
kind: Job
metadata:
  name: build-vector-index-shard-{{ shard_id }}
spec:
  parallelism: 10  # 10 shards en parallèle
  completions: 10
  template:
    spec:
      containers:
      - name: index-builder
        image: vector-db:latest
        resources:
          requests:
            cpu: 32
            memory: 128Gi
        command:
        - python
        - build_index.py
        - --shard-id={{ shard_id }}
        - --input=s3://bucket/vectors/shard_{{ shard_id }}.parquet
        - --output=s3://bucket/indexes/shard_{{ shard_id }}.index
        - --threads=32
      restartPolicy: Never
                    

Optimisations

• Incremental loading : Charger vecteurs par batches (10K-100K) au lieu de tout en RAM
• GPU acceleration : RAPIDS cuVS peut accélérer la construction de 5-20x sur GPUs NVIDIA
• Pre-sorting : Trier les vecteurs par clustering avant build améliore la localité HNSW
• Checkpointing : Sauvegarder l'index partiellement construit toutes les 1M insertions

Réindexation sans downtime

Re-indexer des centaines de millions de vecteurs en production sans interruption de service est un défi majeur.

Stratégies de Réindexation Zero-Downtime

1. Blue-Green Deployment

• Principe : Construire le nouvel index complètement (Green) en parallèle de l'ancien (Blue)
• Étapes :
  1. Provisionner cluster Green (mêmes specs que Blue)
  2. Construire indexes sur Green (peut prendre heures/jours)
  3. Synchroniser les écritures (Blue → Green) pendant la construction
  4. Basculer le trafic Blue → Green (switch DNS/load balancer)
  5. Vérifier latence/recall sur Green
  6. Décommissioner Blue après 24-48h
• Avantages : Zero downtime, rollback instantané en cas de problème
• Coût : Double l'infrastructure temporairement (peut être prohibitif)

2. Rolling Reindex (Shard-by-Shard)

• Principe : Re-indexer un shard à la fois, sans doubler l'infra complète
• Étapes :
  1. Prendre shard_1 hors rotation (trafic redirigé vers replicas)
  2. Re-indexer shard_1 avec nouvelles configs
  3. Remettre shard_1 en rotation, valider
  4. Répéter pour shard_2, shard_3, ..., shard_N
• Avantages : Coût minimal (seulement RF+1 shards à la fois)
• Durée : Plus long (N × temps_build_shard), peut prendre jours/semaines
• Risque : Recall temporairement réduit (~5%) durant migration

3. Shadow Index (Canary)

• Principe : Construire nouvel index en shadow, router 1-5% trafic pour validation
• Étapes :
  1. Déployer nouveau index sur subset de shards
  2. Router 1% trafic vers shadow index
  3. Comparer métriques (latence, recall, erreurs) vs prod
  4. Augmenter progressivement (5%, 10%, 50%, 100%)
  5. Rollback si anomalies détectées
• Avantages : Détection proactive de problèmes, rollback facile
• Complexité : Nécessite routing sophistiqué et monitoring double

Mise à jour incrémentale

Les index HNSW supportent les insertions, mises à jour et suppressions dynamiques, mais avec des compromis de performance.

Opérations CRUD sur Index Dynamiques

Insertions (Add)

• Coût : O(log n) en moyenne, mais peut être coûteux si l'index est grand (>10M)
• Latence : 1-10ms par insertion sur index chaud, jusqu'à 100ms+ si cold
• Dégradation : Inserting 1M vecteurs dans index de 100M peut dégrader recall de 1-3% temporairement
• Optimisation : Batch insertions (10K-100K à la fois) pour amortiser le coût

Mises à jour (Update)

• HNSW ne supporte pas nativement les updates. Stratégie : Delete + Insert
• Coût : 2x celui d'une insertion (delete ~= insert en complexité)
• Alternative : Marquage deleted=true + insertion nouvelle version, cleanup asynchrone

Suppressions (Delete)

• Soft delete : Marquer vecteur comme supprimé, filtrer à la requête. Coût O(1). Standard.
• Hard delete : Supprimer physiquement du graph HNSW. Coût O(log n), complexe, rarement implémenté.
• Garbage collection : Compacter l'index périodiquement (nuit, weekends) pour retirer soft-deletes

Problème : Application e-commerce avec 50M produits, 100K nouveaux/jour, 50K updates/jour

Solution : Hybrid Index (Hot + Cold)

1. Index Principal (Cold) : 50M vecteurs, reconstruit 1x/semaine
   - Optimisé pour lecture (HNSW compact, PQ compression)
   - Pas d'insertions dynamiques

2. Index Delta (Hot) : Nouveaux/modifiés depuis dernier rebuild
   - Supporte insertions/updates rapides
   - Taille typ. 1-5% du principal (500K-2.5M vecteurs)

3. Requête : Interroger BEIDE indexes en parallèle, merger résultats
   - Latence : +2-5ms vs single index
   - Recall : 99%+ (Delta contient les updates récents)

4. Merge Hebdomadaire : Rebuild index principal incluant Delta
   - Effectué pendant heures creuses (weekend)
   - Hot-swap via Blue-Green deployment
   - Delta vidé après merge

Résultat :
- Insertions ultra-rapides (1-5ms) dans Hot index
- Recherches performantes (latence +5ms max)
- Index principal toujours optimisé
                    

Optimisation des recherches

Recherche distribuée et agrégation

Dans un système distribué, chaque requête de recherche doit être scatterée vers plusieurs shards, puis les résultats agrégés pour produire le top-k global.

Architecture Scatter-Gather

Flux d'une requête distribuée (k=10, 20 shards)

1. Client : Envoie query_vector au Query Router

2. Query Router :
   - Détermine shards cibles (tous ou subset)
   - Envoie requêtes parallèles : search(query_vector, k=20)
   - Timeout : 100ms (fail-fast)

3. Chaque Shard :
   - Exécute recherche HNSW locale
   - Retourne top-20 avec scores
   - Latence : 10-40ms

4. Aggregator :
   - Collecte résultats de tous les shards (20 × 20 = 400 vecteurs)
   - Merge : tri par score, dédoublonnage
   - Retourne top-10 global
   - Coût : O(N log N) où N = num_shards × k

5. Client : Reçoit top-10 final

Latence totale : max(latence_shards) + latence_aggregation + network
→ Typiquement 20-60ms p50, 80-200ms p99
                    

Stratégies d'Agrégation Avancées

1. Over-fetching

• Demander top-k_local = k_global × factor par shard (ex: factor=2-5)
• Améliore le recall global (réduit le risque de manquer top-k réels)
• Coût : Augmente network bandwidth et temps d'agrégation

2. Early Termination

• Si M shards sur N ont déjà retourné, et leurs scores min sont très élevés, stopper l'attente
• Réduit p99 latency (ne pas attendre les shards lents)
• Risque : Recall légèrement dégradé (1-2%)

3. Hedged Requests

• Envoyer requête au primary ET à un replica en parallèle
• Prendre la première réponse, annuler l'autre
• Réduit drastiquement p99 (tail latency), au prix de 2x la charge

Caching multi-niveaux

Le caching est crucial à grande échelle : exploiter la répétition des requêtes pour éviter les calculs coûteux.

Architecture de Cache Multi-Tiers

L1 Cache : In-Process (LRU local)

• Localisation : Mémoire du processus du Query Router
• Taille : 100MB-1GB (10K-100K entrées)
• Latence : 50-500µs (nanoseconds pour lookup)
• Hit Rate : 5-15% (requêtes identiques récentes)
• Implémentation : collections.OrderedDict (Python), lru_cache, ou lib dédiées

L2 Cache : Redis/Memcached (distribué)

• Localisation : Cluster Redis dédié (3-10 nodes)
• Taille : 10GB-100GB (1M-10M entrées)
• Latence : 1-5ms (network + lookup Redis)
• Hit Rate : 30-60% (requêtes populaires, dernières 24-48h)
• TTL : 1-24 heures (selon fraîcheur des données)

L3 Cache : CDN (pour API publiques)

• Localisation : CloudFlare, Fastly, CloudFront
• Usage : Requêtes GET avec query paramètres identiques
• Hit Rate : 60-90% pour APIs publiques (recherches répétitives)
• Latence : <10ms (edge locations)

Client → search(query_vector)
   ↓
1. L1 Cache (in-process) ?
   - HIT (5-15%) : retour immédiat (0.5ms) ✅
   - MISS : continuer ↓

2. L2 Cache (Redis) ?
   - HIT (30-60%) : retour rapide (2-5ms) ✅
   - MISS : continuer ↓

3. Vector Search (shards) :
   - Exécution complète (20-60ms)
   - Stocker résultats dans L2 + L1
   - Retour client

Résultat :
- 70-80% des requêtes servent depuis cache (<5ms)
- 20-30% requèrent recherche complète (20-60ms)
- Latence moyenne : 8-15ms (vs 30-50ms sans cache)
- Charge sur shards : divisée par 3-5x
                    

Cache Key Design

Pour les vecteurs, le cache key est problématique : deux vecteurs quasi-identiques devraient matcher, mais auront des hash différents.

• Approche naïve : hash(query_vector) - Ne fonctionne que pour requêtes strictement identiques
• Quantization : Arrondir dimensions à 2-3 décimales avant hash - Hit rate +10-20%
• LSH (Locality-Sensitive Hashing) : Vecteurs similaires → même hash - Hit rate +30-50%, mais faux positifs possibles
• Hybrid : LSH pour L2, exact hash pour L1 - Meilleur compromis

Pre-filtering efficace

Le pre-filtering permet de restreindre la recherche à un sous-ensemble de vecteurs selon des critères métier (catégorie, date, user_id, etc.).

Problématique

Exemple : "Trouver les 10 produits similaires dans la catégorie 'Electronics', publiés après 2023, avec rating >4.0"

Approche naïve : Rechercher top-1000 sans filtre, puis filter → peut retourner <10 résultats (recall catastrophique)

Stratégies de Filtering

1. Post-filtering (naïf)

• Rechercher top-k, puis filtrer les résultats
• Simple mais recall très faible si filtre sélectif (<1% des vecteurs)
• Workaround : Augmenter k (ex: k=10000), mais coût élevé

2. Pre-filtering (avec index secondaires)

• Maintenir des indexes secondaires (B-Tree, bitmap) sur métadonnées
• Filtrer AVANT la recherche vectorielle : WHERE category='Electronics' AND year>2023
• Recherche vectorielle uniquement sur subset filtré
• Recall parfait, latence +5-20ms (selon sélectivité filtre)

3. Filtered HNSW (native)

• Certaines implémentations (Qdrant, Weaviate) intègrent filtres dans le graph traversal HNSW
• Skip nodes qui ne matchent pas le filtre pendant la recherche
• Optimal en recall et latence

Batch queries

Le batching de requêtes permet d'amortir les coûts fixes (network, init) et d'augmenter le débit global.

Principe

Au lieu d'envoyer 100 requêtes individuelles (chacune avec overhead network ~1-2ms), regrouper en 1 batch de 100 queries.

Comparaison : Individual vs Batch

Individual Queries (100 requêtes séquentielles) :
- Latence par requête : 2ms (network) + 10ms (search) = 12ms
- Latence totale : 100 × 12ms = 1,200ms (1.2 secondes)
- Débit : 83 QPS

Batch Query (1 batch de 100) :
- Latence batch : 2ms (network) + 150ms (search parallèle) = 152ms
- Latence par requête (amortie) : 152ms / 100 = 1.52ms
- Débit : 658 QPS (8x amélioration !)
                    

Implémentation

• Client-side batching : Application accumule queries pendant 10-50ms, puis envoie batch
• Server-side batching : API Gateway accumule requests, forward en batch vers backend
• Taille optimale : 10-100 queries par batch (compromis latence vs débit)
• Timeout : Envoyer batch même incomplet après timeout (ex: 50ms) pour limiter latence

Load balancing

Le load balancing distribue les requêtes uniformément sur les replicas pour maximiser le débit et la disponibilité.

Stratégies de Load Balancing

1. Round-Robin

• Distribution cyclique : replica_1, replica_2, ..., replica_N, replica_1, ...
• Simple, uniformé, mais ignore la charge réelle des nodes

2. Least Connections

• Router vers le replica avec le moins de connexions actives
• Meilleur que Round-Robin si requêtes de durées variables

3. Weighted Round-Robin

• Attribuer poids selon capacité (ex: node avec 2x RAM reçoit 2x plus de requêtes)
• Utile pour clusters hétérogènes

4. Latency-Based (intelligent)

• Mesurer latence récente (p50, p99) de chaque replica
• Router vers replicas les plus rapides
• Optimal mais nécessite monitoring fin

5. Consistent Hashing

• Assigner requêtes à replicas via hash(query) % N
• Maximise cache hit rate (même query → même replica → même cache L1)
• Très efficace si caching local

Architectures distribuées

Architecture maître-esclave

L'architecture maître-esclave centralise les écritures sur un node maître, qui réplique vers plusieurs esclaves en lecture seule.

Composants

• Master Node : Reçoit toutes les écritures (insertions, updates, deletes), maintient l'index canonical
• Slave Nodes : Réplicas en lecture seule, synchronisés depuis le master via WAL (Write-Ahead Log)
• Load Balancer : Route écritures vers master, lectures vers slaves (round-robin)

Avantages et Inconvénients

• ✅ Simplicité : Une seule source de vérité, pas de conflits de concurrence
• ✅ Consistance forte : Toutes les écritures passent par le master
• ✅ Scaling en lecture : Ajout de slaves augmente le débit de lecture
• ❌ SPOF : Panne du master = système en lecture seule (ou indisponible)
• ❌ Bottleneck écriture : Scaling en écriture impossible
• ❌ Latence réplication : Eventual consistency entre master et slaves (lag 1-10s)

Architecture peer-to-peer

L'architecture peer-to-peer (P2P) distribue écritures et lectures sur tous les nodes sans hiérarchie.

Principes

• Pas de master : Tous les nodes sont équivalents, peuvent recevoir écritures et lectures
• Consensus distribué : Algorithmes comme Raft, Paxos, ou PBFT pour coordonner écritures
• Sharding automatique : Données partitionnées automatiquement (consistent hashing)
• Self-healing : Le cluster détecte et compense automatiquement les pannes

Implémentations

• Qdrant : Utilise Raft consensus, support natif du clustering
• Milvus : Architecture distribuée avec etcd pour coordination
• Weaviate : Clustering via gossip protocol

Trade-offs

• ✅ Haute disponibilité : Pas de SPOF, tolère N/2-1 pannes
• ✅ Scaling horizontal : Écritures et lectures scalent linéairement
• ✅ Auto-management : Rebalancing, healing automatiques
• ❌ Complexité : Consensus, split-brain, network partitions
• ❌ Latence écriture : +10-30ms due aux rounds de consensus
• ❌ Operational overhead : Monitoring, debugging plus complexes

Kubernetes et orchestration

Kubernetes simplifie le déploiement et la gestion d'infrastructures vectorielles distribuées à grande échelle.

Ressources Kubernetes pour Vector DBs

StatefulSets

• Pour nodes avec stockage persistant (Qdrant, Milvus)
• Identités stables (pod-0, pod-1, ...) nécessaires pour clustering
• Scaling ordonné : pod-N+1 démarre seulement après pod-N ready

PersistentVolumes

• Stockage durable pour indexes HNSW (survive aux restarts)
• SSD haute performance : gp3, io2 (AWS), Premium SSD (Azure)
• Snapshots automatiques via CSI drivers

Operators Spécialisés

• Qdrant Operator : Auto-configure clustering, scaling, backups
• Milvus Operator : Gestion lifecycle complet (install, upgrade, scaling)
• Custom Operators : Logique métier spécifique (auto-scaling basé sur QPS, re-indexing scheduled)

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: qdrant-cluster
spec:
  replicas: 3
  serviceName: qdrant-headless
  template:
    spec:
      containers:
      - name: qdrant
        image: qdrant/qdrant:v1.7
        resources:
          requests:
            cpu: "4"
            memory: 32Gi
          limits:
            cpu: "8"
            memory: 64Gi
        volumeMounts:
        - name: data
          mountPath: /qdrant/storage
        env:
        - name: QDRANT__CLUSTER__ENABLED
          value: "true"
        - name: QDRANT__CLUSTER__P2P__PORT
          value: "6335"
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: gp3
      resources:
        requests:
          storage: 500Gi
                    

Patterns d'Auto-Scaling

• HPA (Horizontal Pod Autoscaler) : Scale basé sur CPU, mémoire, custom metrics (QPS, latence p99)
• VPA (Vertical Pod Autoscaler) : Ajustement automatique des resource requests
• Cluster Autoscaler : Ajout/suppression de nodes selon les besoins
• KEDA : Auto-scaling basé sur métriques externes (queue depth, Prometheus metrics)

Service mesh et microservices

Un Service Mesh (Istio, Linkerd) apporte observabilité, sécurité et traffic management aux architectures vectorielles distribuées.

Avantages pour Vector DBs

Traffic Management

• Canary Deployments : Router 1-10% trafic vers nouvelles versions pour validation
• Circuit Breaker : Isoler automatiquement shards défaillants
• Retry & Timeout : Politiques de retry intelligentes (exponential backoff)
• Load Balancing avancé : Least-request, consistent hash, geo-proximity

Observabilité

• Distributed Tracing : Jaeger traces pour suivre requêtes cross-shards
• Métriques automatiques : Latence, error rate, débit par service sans code changes
• Service Map : Visualisation topologie et health du cluster

Sécurité

• mTLS automatique : Chiffrement inter-services transparent
• Zero-trust networking : Policies par service (shard-A ne peut pas accéder à shard-B)
• Rate limiting : Protection DDoS par client/endpoint

Exemples d'architectures de production

Stack :
- Vector DB : Qdrant cluster (10 shards, RF=3)
- Metadata : PostgreSQL (product details, inventory)
- Cache : Redis cluster (search results cache)
- API : FastAPI + Kubernetes
- Monitoring : Prometheus + Grafana + Jaeger

Data Flow :
User Search → API Gateway → Redis Cache ?
  └→ HIT : Return cached results (2ms)
  └→ MISS : Query Router → Qdrant shards (20ms)
        └→ Parallel fetch metadata from PostgreSQL
        └→ Return enriched results + cache

Scaling :
- Peak : 50K QPS during sales events
- Cache hit rate : 60-70%
- P99 latency : <100ms
- Cost : ~$15K/month (vs $50K+ without compression)
                    

Stack :
- Vector DB : Pinecone (managed, pod-based)
- Real-time : Kafka + Flink (embedding updates)
- Batch : Spark (offline similarity computation)
- ML : Kubeflow Pipelines (model training/serving)
- CDN : CloudFlare (API response caching)

Architecture Tiers :
- Hot Tier : 10M most popular items (in-memory)
- Warm Tier : 100M recent items (SSD)
- Cold Tier : 90M archived items (S3)

Performance :
- 500K QPS global
- P50 latency : 15ms
- P99 latency : 80ms
- Cache hit (CDN) : 85%
                    

Stack :
- Vector DB : Weaviate cluster (5 nodes)
- Full-text : Elasticsearch (hybrid search)
- Auth : Keycloak + RBAC per document
- Processing : Apache Airflow (ETL pipelines)
- Storage : MinIO (document storage)

Security :
- mTLS between all services
- Document-level permissions enforced
- GDPR compliance (user data deletion)
- Audit logs for all searches

Ops :
- Multi-region (US + EU for data residency)
- Disaster recovery : 4h RTO, 1h RPO
- Monitoring : 99.9% uptime SLA
- Cost : $8K/month (self-hosted vs $25K+ managed)
                    

Gestion des coûts

Modèle de coût par composant

Comprendre la répartition des coûts permet d'optimiser le TCO (Total Cost of Ownership) et d'identifier les leviers d'optimisation.

Coûts Cachés

• Data Transfer : Egress inter-region ($0.09/GB AWS), peut atteindre $1000+/mois à haute charge
• Backup & DR : Snapshots S3, réplication cross-region (+20-50% du coût storage)
• Monitoring : Prometheus, Grafana, logs centralisés ($500-2000/mois)
• Development/Test : Environnements non-prod souvent oubliés (+30-50% du coût prod)
• Compliance : Audits, certifications, encryption ($2000-10000/an)

Optimisation compute vs storage

Le trade-off fondamental : plus de compute pour moins de storage (compression) ou plus de storage pour moins de compute (pre-computing).

Stratégie Compute-Heavy

• Principe : Compression agressive (PQ), décompression à la volée
• Profil : Stockage minimal (8-32x compression), CPU intensif pour recherches
• Coût : Storage $200-500/mois, Compute $5000-15000/mois
• Cas d'usage : Workloads avec forte variance (traffic pics), cloud avec auto-scaling

Stratégie Storage-Heavy

• Principe : Vecteurs non-compressés ou SQ légère, index pré-optimisés
• Profil : Storage élevé (1-4x données brutes), CPU minimal pour recherches
• Coût : Storage $5000-20000/mois, Compute $1000-3000/mois
• Cas d'usage : Workloads stables, on-premise, latence ultra-critique

Cloud vs on-premise à grande échelle

Le calcul coût/bénéfice entre cloud et on-premise change drastiquement selon l'échelle.

Analyse Comparative (500M vecteurs, 3 ans)

Scénario Cloud (AWS)

Infrastructure :
- EC2 r7g.8xlarge × 20 (256GB RAM, 32 vCPU) = $96,000/an
- EBS gp3 100TB = $9,600/an
- Data Transfer (5TB/mois) = $5,400/an
- Load Balancers, NAT Gateway = $3,600/an

Personnel :
- 2 SRE (maintenance, scaling) = $300,000/an
- Managed services (RDS, ElastiCache) = $36,000/an

Total 3 ans : $1,350,000

Scénario On-Premise

Hardware (CAPEX) :
- Serveurs (20 × $15K) = $300,000
- Storage (100TB NVMe) = $150,000
- Network gear, UPS, cooling = $100,000
- Depreciation 3 ans : $550,000

OpEx :
- Datacenter (power, cooling, space) = $150,000/an
- Personnel (4 SRE, 1 HW engineer) = $750,000/an
- Maintenance hardware = $75,000/an

Total 3 ans : $3,475,000

Conclusion : Cloud = 2.5x moins cher à cette échelle
                    

Seuil de Rentabilité

Break-even point : ~1000+ serveurs (équivalent 2-5 milliards de vecteurs) où on-premise devient compétitif. Facteurs :

• Economies d'échelle : Hardware bulk pricing, negociation datacenter
• Optimisations custom : Hardware spécialisé (GPU, FPGA), networking dédié
• Expertise interne : Équipes SRE/DevOps expérimentées, moins de dépendance external
• Compliance : Régulations strict data residency, secteurs réglementés

Stratégies de réduction des coûts

1. Optimisation Infrastructure

• Spot Instances : 50-90% de réduction vs On-Demand. Utilisable pour batch jobs (index building, analytics)
• Reserved Instances : 30-60% réduction pour workloads prévisibles (3 ans commitment)
• Auto-scaling intelligent : Scale down pendant heures creuses, weekends (economies 20-40%)
• Instance rightsizing : Monitoring utilisation CPU/RAM, ajuster types instances

2. Optimisation Données

• Compression agressive : PQ peut réduire coûts stockage de 10-50x
• Data lifecycle : Archiver vecteurs anciens vers S3 Glacier (99% moins cher)
• Deduplication : Éliminer vecteurs quasi-identiques (gain 5-20% selon domain)
• Precision reduction : Float32 → Float16 sans impact significatif

3. Optimisation Opérationnelle

• Managed services : Pinecone, Qdrant Cloud réduisent coûts personnel de 60-80%
• Multi-cloud arbitrage : Choisir cloud le moins cher par région (GCP souvent 20-30% moins cher)
• Automation : IaC, CI/CD, monitoring réduisent temps intervention humaine
• FinOps : Monitoring coûts en temps réel, alertes budget, showback par team

TCO selon la volumétrie

Le TCO par vecteur diminue drastiquement avec l'échelle grâce aux economies of scale.

Observation clé : Le coût par vecteur diminue de 50x entre 1M et 10B vecteurs. Les investissements en optimisation (compression, caching, automation) ne sont rentables qu'à partir de 50M+ vecteurs.

Seuils de Changement d'Architecture

• 1M → 10M : Single-node suffit, focus sur réplication HA
• 10M → 100M : Premier sharding, introduction compression SQ8
• 100M → 1B : Compression PQ indispensable, caching L2
• 1B+ : Tiered storage, optimisations hardware custom, équipe SRE dédiée

Cas d'étude : millions de vecteurs

Cas 1 : E-commerce avec 50M de produits

Contexte : Marketplace global type Amazon avec 50M produits, 10M utilisateurs actifs, pics à 100K QPS pendant soldes.

Architecture Déployée

• Vector DB : Qdrant cluster, 10 shards, RF=3 (30 nodes total)
• Embeddings : OpenAI text-embedding-3-large (3072 dim) + compression PQ M=16
• Index size : 50M × 16 bytes = 800MB par shard (2.4GB total index)
• Metadata : PostgreSQL sharded (prix, stock, catégories)
• Cache : Redis cluster 500GB (24h TTL)

Challenges Résolus

• Hotspots : Produits viraux (iPhone) recevaient 1000x plus de traffic → Solution : consistent hashing + cache L1 local
• Seasonality : Traffic ×10 pendant Black Friday → Solution : auto-scaling horizontal + pre-warming cache
• Cold start : Déploiements causaient 5min downtime → Solution : Blue-Green avec health checks
• Precision vs coût : Float32 trop cher, Binary trop imprécis → Solution : PQ M=16 (recall 94%, coût /20)

Résultats

• Performance : P50=12ms, P99=45ms (SLA <100ms)
• Disponibilité : 99.95% uptime (SLA 99.9%)
• Coût : $18K/mois (vs $60K+ sans optimisations)
• Métier : +15% conversion rate, +8% panier moyen grâce à recherche sémantique

Cas 2 : Plateforme vidéo avec 100M de clips

Contexte : Plateforme type TikTok avec 100M clips vidéo, recherche par similarité visuelle, audio et transcription.

Architecture Multi-Modale

• Embeddings visuels : CLIP (512 dim) à 1 FPS → 5B vecteurs (500M clips × avg 10 frames)
• Embeddings audio : Whisper (1024 dim) à 1Hz → 3B vecteurs
• Embeddings texte : Transcriptions via text-embedding-ada-002 (1536 dim) → 100M vecteurs
• Total : 8.1B vecteurs, 45TB données brutes

Stratégie de Scaling

• Tiered par modalité :
  • Tier 1 (RAM) : Clips trending derniers 7 jours (10M clips)
  • Tier 2 (SSD) : Clips actifs derniers 30 jours (50M clips)
  • Tier 3 (S3) : Archives >30 jours (40M clips)
• Index séparés : 3 clusters Milvus spécialisés par modalité
• Compression différentiée : CLIP = PQ M=8, Audio = SQ8, Text = PQ M=12

Innovations Techniques

• Semantic routing : Clustering spatial pour ne cibler que 2-3 shards/100 (latence /10)
• Multi-modal fusion : Score = 0.5×visual + 0.3×audio + 0.2×text
• GPU acceleration : RAPIDS cuVS pour re-indexing 10x plus rapide
• Edge caching : CDN CloudFlare cache 90% résultats (API publique)

Métriques Production

• Scale : 500K recherches/sec en pic, 50M MAU
• Latence : P50=25ms, P99=120ms
• Precision : 91% recall@10 (vs 97% baseline non-compressé)
• Infrastructure : 200 servers, $150K/mois

Cas 3 : Base documentaire entreprise (10M docs)

Contexte : Multinationale 100K employés, 10M documents internes (PDFs, emails, wikis), recherche sémantique cross-lingue.

Exigences Spécifiques

• Sécurité : Document-level permissions, audit trails, data residency EU/US
• Multi-langue : 15 langues, embeddings multilingues (mBERT, LaBSE)
• Compliance : GDPR, SOX, retention policies automatiques
• Integration : SSO Active Directory, APIs legacy (SharePoint, Confluence)

Architecture Hybrid Cloud

• EU cluster : Weaviate self-hosted (GDPR compliance) → 3M docs EU
• US cluster : Pinecone managed → 7M docs US
• Cross-cluster search : Fedération via API Gateway avec RBAC
• Embeddings : multilingual-e5-large (1024 dim) + chunking 512 tokens

Pipeline ETL

• Ingestion : Apache Airflow, 50K docs/jour en pic
• Processing :
  1. OCR via Textract (PDFs scannés)
  2. Chunking intelligent (respect paragraphes, sections)
  3. Embedding via SentenceTransformers
  4. Enrichment métadonnées (auteur, date, classification auto)
• Data governance : Lineage tracking, PII detection automatique

Résultats Business

• Adoption : 70% employés utilisent quotidiennement (vs 15% ancien moteur)
• Efficacité : Temps recherche info divisé par 3 (45min → 15min/jour/employé)
• ROI : $2.5M/an economisés (productivité) vs $800K/an coût infrastructure
• Compliance : 100% audits passés, 0 incidents data breach

Leçons apprises

Erreurs Communes à Éviter

• Under-engineering early : Commencer single-node sans plan scaling → migration douloureuse à 50M+ vecteurs
• Over-engineering early : Déployer cluster 50 nodes pour 1M vecteurs → complexité et coûts inutiles
• Ignorer la compression : Coller aux float32 par « précaution » → coûts 10-50x supérieurs
• Négliger monitoring : Découvrir les bottlenecks en production → incidents récurrents
• Pas de disaster recovery : Losing 100M vecteurs = rebuild 2-7 jours

Best Practices Validées

• Start simple, scale smart : Single-node → replicas → sharding seulement quand nécessaire
• Measure twice, cut once : Benchmarker compression sur vraies données avant prod
• Plan for 10x growth : Architecture doit supporter 10x volume actuel sans refonte
• Automate everything : Scaling, healing, monitoring automatiques = économies long terme
• Managed when possible : Focus sur le métier, pas sur l'infrastructure sous 100M vecteurs

Patterns Architecturaux Récurrents

• Hybrid index : Index principal + delta pour updates continues
• Tiered storage : Hot/warm/cold selon patterns d'accès
• Multi-level caching : L1 local + L2 distribué + L3 CDN
• Circuit breakers : Isolation automatique des composants défaillants
• Semantic routing : 70-90% réduction latence via clustering spatial

Roadmap de scaling progressive

Une roadmap structurée permet d'éviter les migrations coûteuses et les re-architectures d'urgence.

Phase 1 : Foundation (0-10M vecteurs)

• Architecture : Single-node avec replicas (Qdrant, Weaviate)
• Focus : Stabilité, monitoring, métriques business
• Investments : CI/CD, IaC, observability stack
• Timeline : 3-6 mois développement, $50-200K budget

Phase 2 : Optimization (10-100M vecteurs)

• Architecture : Introduction compression (SQ8), caching L2
• Focus : Performance, réduction coûts
• Investments : Load testing, capacity planning, auto-scaling
• Timeline : 6-12 mois, $200-500K budget

Phase 3 : Scale-out (100M-1B vecteurs)

• Architecture : Sharding, compression PQ, tiered storage
• Focus : Distributed systems, consistency, disaster recovery
• Investments : SRE team, advanced monitoring, chaos engineering
• Timeline : 12-18 mois, $500K-2M budget

Phase 4 : Hyperscale (1B+ vecteurs)

• Architecture : Multi-region, edge computing, custom hardware
• Focus : Global latency, compliance multi-régions
• Investments : Research team, hardware partnerships
• Timeline : 18-36 mois, $2M+ budget