Benchmarks de Performance : Quel Système Vectoriel Choisir ?

Méthodologie de benchmark

Principes d'un bon benchmark

Un benchmark de bases vectorielles pertinent repose sur trois piliers fondamentaux : la reproductibilité, la pertinence des scénarios et la transparence des résultats.

Les benchmarks publiés par les éditeurs sont souvent optimistes : conditions idéales, warm cache, configuration sur-mesure. Un benchmark interne doit reproduire vos conditions de production : taille réelle du dataset, patterns de requêtes, matériel disponible, contraintes de coûts.

Méfiez-vous des benchmarks mono-critère : une solution ultra-rapide en lecture pure peut s'effondrer lors d'insertions concurrentes. Privilégiez les benchmarks multi-dimensionnels : latence P50/P95/P99, throughput, recall, consommation mémoire, coût par million de requêtes.

Datasets de référence

Les benchmarks académiques et industriels utilisent des datasets standardisés pour garantir la comparabilité des résultats. Ces datasets diffèrent par leur taille, dimensionnalité et distribution statistique.

Pour un benchmark représentatif de votre cas d'usage : générez 10-100K embeddings depuis vos données réelles avec votre modèle de production (OpenAI text-embedding-3, Cohere, etc.), puis extrapolez avec un dataset public de taille similaire.

Scénarios de test réalistes

Les benchmarks doivent simuler des workloads réalistes, pas seulement des lectures séquentielles sur données chaudes. Voici les scénarios standards :

Pattern de charge réaliste pour un système RAG en production : 70% recherches simples, 20% recherches avec filtres, 5% insertions, 5% updates/deletes. Pic de trafic à 3x le trafic moyen pendant 30 minutes. Tester la dégradation gracieuse (graceful degradation) : que se passe-t-il quand le système sature ?

Reproductibilité

Un benchmark n'a de valeur que s'il est reproductible. Toute variation non documentée rend les comparaisons invalides.

Checklist de reproductibilité

• Infrastructure : CPU (modèle exact), RAM (quantité et vitesse), SSD (IOPS, latence), réseau (latence inter-nœuds pour clusters)
• Versions logicielles : version exacte de la base vectorielle, système d'exploitation, kernel, drivers GPU si applicable
• Configuration index : algorithme (HNSW, IVF), paramètres (M, ef_construction, nlist, nprobe), quantization (FP32, FP16, INT8, PQ)
• Données : dataset utilisé + checksum, ordre d'insertion (shuffled ou séquentiel), seed aléatoire
• Protocole de mesure : durée du warm-up, nombre d'itérations, gestion des outliers, percentiles calculés
• Charge concurrente : nombre de threads/workers, taux d'arrivée des requêtes (constant ou Poisson)

## Configuration
Hardware: AWS c5.4xlarge (16 vCPU, 32GB RAM, gp3 SSD 3000 IOPS)
OS: Ubuntu 22.04 LTS (kernel 5.15)
Vector DB: Qdrant 1.7.4
Dataset: SIFT10M (10M vectors, 128 dimensions)

## Index Configuration
Algorithm: HNSW
Parameters:
  - m: 16
  - ef_construction: 200
  - ef_search: 100 (varied for recall curves)
Quantization: None (FP32)

## Test Protocol
- Warm-up: 100K queries before measurement
- Test duration: 300 seconds steady state
- Concurrent clients: 10 threads
- Query rate: 1000 QPS target (rate limited)
- Measurements: 3 full runs, median reported

## Results
Median latency (p50): 12.3ms
P95 latency: 28.7ms
P99 latency: 45.2ms
Recall@10: 98.7%
Throughput: 987 QPS (sustained)
Memory usage: 4.2GB (index only)

Partagez vos scripts : publier le code de benchmark (Python avec multiprocessing, Locust, etc.) permet à d'autres de valider vos résultats. Les projets ann-benchmarks (GitHub) et VectorDBBench fournissent des frameworks standardisés.

Biais et limites

Tout benchmark comporte des biais implicites. Savoir les identifier évite les mauvaises décisions.

Limites intrinsèques

Un benchmark statique ne capture pas la variabilité réelle :

• Évolution du dataset : performances d'un index sur 1M vecteurs ≠ performances après croissance à 50M
• Saisonnalité : un système optimisé pour charge constante peut crasher lors d'un pic x10 le Black Friday
• Drift de distribution : l'index HNSW optimal pour embeddings 2023 peut être sous-optimal pour embeddings 2025 (nouveau modèle)
• Effets de production : multi-tenancy, quotas, rate limiting, failover changent radicalement les performances observées

Recommandation : compléter les benchmarks one-shot par du monitoring continu en production. Alerter si latence P99 > SLA, re-benchmarker trimestriellement, tester en staging les nouvelles versions avant upgrade.

Métriques essentielles

Latence (p50, p95, p99)

La latence mesure le temps entre l'envoi d'une requête et la réception de la réponse. Contrairement à la latence moyenne (trompeuse), les percentiles révèlent l'expérience utilisateur réelle.

Comprendre les percentiles

• P50 (médiane) : 50% des requêtes sont plus rapides. Indicateur de performance "typique".
• P95 : 95% des requêtes sont plus rapides. Un utilisateur sur 20 subit une latence supérieure.
• P99 : 99% des requêtes sont plus rapides. Métrique critique pour SLA (1 requête sur 100).
• P99.9 : pour systèmes haute disponibilité (1 requête sur 1000 impactante).

Pourquoi P99 diverge : garbage collection, compaction d'index, cache miss, contention réseau, throttling temporaire. Un système avec P50=10ms mais P99=500ms est inutilisable en production.

Calculer les percentiles avec Python

import numpy as np
import time

# Mesurer 1000 requêtes
latencies = []
for _ in range(1000):
    start = time.perf_counter()
    result = vector_db.query(query_vector, top_k=10)
    latencies.append((time.perf_counter() - start) * 1000)  # en ms

# Calculer percentiles
print(f"P50: {np.percentile(latencies, 50):.1f}ms")
print(f"P95: {np.percentile(latencies, 95):.1f}ms")
print(f"P99: {np.percentile(latencies, 99):.1f}ms")
print(f"P99.9: {np.percentile(latencies, 99.9):.1f}ms")

SLA typiques : Chatbot temps réel (P95 < 100ms), recherche e-commerce (P95 < 200ms), batch processing (P99 < 5s acceptable).

Throughput (QPS - Queries Per Second)

Le throughput mesure le nombre de requêtes traitées par seconde. Contrairement à la latence (perspective utilisateur), le throughput est une métrique système.

Relation latence-throughput

Loi de Little : Throughput = Concurrency / Latency

Avec 10 clients concurrents et latence moyenne de 50ms : QPS = 10 / 0.05 = 200 QPS

Mesurer le throughput saturé (max QPS)

from concurrent.futures import ThreadPoolExecutor
import time

def single_query():
    vector_db.query(random_vector(), top_k=10)
    return 1

# Lancer 50 threads pendant 60 secondes
start = time.time()
with ThreadPoolExecutor(max_workers=50) as executor:
    futures = []
    while time.time() - start < 60:
        futures.append(executor.submit(single_query))

    total_queries = sum(f.result() for f in futures)

qps = total_queries / 60
print(f"Throughput saturé: {qps:.0f} QPS")

Interpréter les résultats : si QPS plafonne malgré l'ajout de threads, le goulot est CPU, RAM ou I/O. Monitor CPU usage : 100% = saturation complète.

Recall@K

Recall@K mesure la précision de la recherche approximative : quel pourcentage des K vrais plus proches voisins sont retournés ?

Calcul du Recall@10

# Ground truth: recherche exhaustive (brute force)
true_neighbors = brute_force_search(query, top_k=10)  # 10 IDs exacts

# Recherche approximative (HNSW)
approx_neighbors = hnsw_index.query(query, top_k=10)  # 10 IDs approximatifs

# Intersection
common = set(true_neighbors) & set(approx_neighbors)
recall_at_10 = len(common) / 10  # Ex: 9/10 = 0.90 = 90%

Trade-off Recall vs Vitesse

Recall minimum acceptable : RAG chatbot = 95%+, moteur recherche e-commerce = 90%+, recommandations produits = 85%+ suffisant.

Temps d'indexation

Le temps d'indexation impacte la fraîcheur des données. Indexer 1M nouveaux documents par jour nécessite un throughput d'insertion ≥ 12 vecteurs/seconde.

Benchmark insertion bulk vs streaming

Impact sur la production : si votre pipeline génère 100K nouveaux embeddings/heure, vérifiez que l'insertion ne bloque pas les lectures (test workload mixte).

Utilisation CPU et mémoire

La consommation mémoire détermine le coût infrastructure. La charge CPU limite le throughput maximum.

Formules d'estimation mémoire

HNSW sans quantization (FP32) :

Memory = num_vectors * dimensions * 4 bytes * (1 + overhead_hnsw)
Overhead HNSW ≈ 1.5x (graphe + metadata)

Exemple: 10M vecteurs de 768 dimensions
= 10,000,000 * 768 * 4 * 1.5 = 46 GB

Avec quantization INT8 :

Memory = 10,000,000 * 768 * 1 * 1.5 = 11.5 GB (4x moins)

CPU usage : HNSW = 15-30% CPU par thread de recherche. Pour 1000 QPS avec latence 20ms : 1000 * 0.02 = 20 cores utilisés. Provisionner 30% de marge.

Taille des index

La taille sur disque de l'index impacte les coûts de stockage et les temps de backup/restore.

Coûts stockage cloud (AWS EBS gp3) : 0.08$/GB/mois. Pour 100M vecteurs HNSW FP32 (450 GB) = 36$/mois stockage seul.

Environnement de test

Configuration matérielle

Les benchmarks présentés dans cet article utilisent une configuration standardisée permettant la comparaison directe entre solutions.

Tests complémentaires haute volumetrie : pour les datasets 100M+ vecteurs, cluster de 3x r5.8xlarge (32 vCPUs, 256 GB RAM chacun) avec réseau 25 Gbps.

Pourquoi c5.4xlarge ?

• Représentatif d'un environnement production PME/startup
• Coût raisonnable : ~0.68$/heure on-demand (~500$/mois reserved)
• Assez de RAM pour tester jusqu'à 20M vecteurs 768D en HNSW
• CPU performance prédictible (pas de burstable comme t3)

Versions logicielles

Les versions exactes utilisées pour garantir la reproductibilité :

Paramétrage des systèmes

Chaque base vectorielle est configurée avec des paramètres optimisés (non défaut) pour éviter les biais. Objectif : recall@10 ≥ 95% pour toutes les solutions.

Qdrant (HNSW)

{
  "vectors": {
    "size": 768,
    "distance": "Cosine"
  },
  "hnsw_config": {
    "m": 16,                    // Connexions par node
    "ef_construct": 200,        // Précision construction
    "full_scan_threshold": 10000
  },
  "optimizers_config": {
    "indexing_threshold": 20000
  },
  "quantization_config": null   // Desactivé pour FP32 baseline
}

Weaviate (HNSW)

{
  "class": "Document",
  "vectorIndexType": "hnsw",
  "vectorIndexConfig": {
    "maxConnections": 32,        // Equivalent à M=16 (2x)
    "efConstruction": 200,
    "ef": 100                    // ef_search par défaut
  }
}

Milvus (HNSW)

index_params = {
  "metric_type": "COSINE",
  "index_type": "HNSW",
  "params": {
    "M": 16,
    "efConstruction": 200
  }
}

search_params = {
  "metric_type": "COSINE",
  "params": {"ef": 100}
}

FAISS (HNSW)

import faiss

index = faiss.IndexHNSWFlat(768, 16)  # dimension, M
index.hnsw.efConstruction = 200
index.hnsw.efSearch = 100

Standardisation : M=16, ef_construction=200, ef_search=100 pour tous. Variations testées : ef_search ∈ [10, 50, 100, 200, 500] pour courbes recall/latence.

Volumétrie testée

Les benchmarks couvrent 4 échelles représentant différents cas d'usage :

Focus principal : 10M vecteurs 768D, représentatif de 80% des projets RAG/recherche sémantique en production.

Benchmarks de latence

Latence pour 1M vecteurs

Sur 1 million de vecteurs 768D, toutes les solutions modernes offrent des latences excellentes. La différence est marginale à cette échelle.

Latence pour 10M vecteurs

À 10 millions de vecteurs, les différences s'accentuent. L'optimisation HNSW et la gestion mémoire deviennent critiques.

Latence pour 100M vecteurs

À 100 millions de vecteurs, la plupart des systèmes nécessitent un cluster ou de la quantization. Tests sur cluster 3 nodes (sauf FAISS standalone).

Recommandation : pour 100M+ vecteurs, privilégier quantization + sharding plutôt que HNSW pur. Accepter recall 95-97% pour gagner 3-5x sur latence et coûts.

Impact des filtres sur la latence

Les metadata filters (recherche vectorielle + WHERE clause) peuvent dégrader les performances de 2x à 10x selon la sélectivité et l'implémentation.

Latence avec filtres (10M vecteurs, filtre excluant 90% des vecteurs)

Best practice : optimiser les filtres

# Qdrant: créer un payload index sur les champs filtrés
client.create_payload_index(
    collection_name="docs",
    field_name="category",
    field_schema="keyword"  # Index hash pour égalité exacte
)

# Maintenant filter={"category": "tech"} est accéléré

Mesurer l'impact : toujours benchmarker avec VOS filtres de production. Un filtre par date (90% de sélectivité) est très différent d'un filtre par user_id (0.01% de sélectivité).

Graphiques comparatifs

Visualisation ASCII des résultats latence P95 selon la taille du dataset :

Latence P95 (ms) vs Taille du Dataset

250ms |
      |                                              ● Pinecone (100M)
200ms |                              ○ Weaviate (100M)
      |                          ○ Milvus (100M)
150ms |                      ● Qdrant (100M)
      |          ● FAISS (100M)
100ms |                  ○ Pinecone (10M)
      |              ○ Weaviate (10M)
 50ms |          ○ Milvus (10M)
      |      ● Qdrant (10M)
      |  ● FAISS (10M)
  0ms +------------------------------------------------
      1M                 10M                  100M

● = Solutions on-premise optimales (FAISS, Qdrant)
○ = Solutions full-featured (Weaviate, Milvus, Pinecone)

Benchmarks de throughput

QPS en lecture seule

Le throughput maximal en lecture pure (read-only workload, toutes données en cache).

QPS avec insertions concurrentes

Le workload mixte (80% lectures, 20% écritures) reflète la production réaliste.

Observation clé : Qdrant montre la meilleure stabilité sous charge mixte grâce au WAL optimisé et aux insertions asynchrones.

Scalabilité horizontale

Comment le throughput évolue en ajoutant des nœuds au cluster (10M vecteurs, sharding équilibré).

Throughput (QPS) vs Nombre de Nœuds

20K |
    |                            ● Qdrant
15K |                    ● Qdrant
    |            ● Qdrant        ○ Milvus
10K |    ● Qdrant       ○ Milvus
    |    ○ Milvus       ○ Weaviate
 5K |    ○ Weaviate
    |
  0 +---------------------------------------
    1         2         3         4  Nœuds

Scalabilité idéale (linéaire) = ligne en pointillés
● Qdrant: 95% efficiency (overhead minimal)
○ Milvus: 80% efficiency (consensus etcd)
○ Weaviate: 70% efficiency (GraphQL routing)

Limite pratique : au-delà de 8-10 nœuds, l'overhead réseau et consensus dégrade l'efficiency. Pour scale davantage, partitionner par tenant ou région.

Gestion de pics de charge

Simulation d'un pic de trafic x5 pendant 5 minutes (de 1000 QPS à 5000 QPS).

Graphiques comparatifs

Synthèse visuelle des résultats throughput par configuration :

Throughput Max (QPS) par Solution

15K |
    |  ■■■■■■■■■■■■■  FAISS (read-only)
10K |  ■■■■■■■■■    Qdrant (read-only)
    |  ■■■■■■■      Milvus (read-only)
 5K |  ■■■■■■        Weaviate (read-only)
    |  ■■■            Pinecone (read-only)
    |
    |  ●●●●●●●      Qdrant (mixte 80/20)
 2K |  ●●●●●        Milvus (mixte 80/20)
    |  ●●●●          Weaviate (mixte 80/20)
    |  ●●●            Pinecone (mixte 80/20)
  0 +----------------------------------------

■ = Read-only workload (optimal)
● = Mixed workload (réaliste)

Leçon principale : FAISS domine en read-only mais n'est pas viable pour production (pas de persistence). Qdrant offre le meilleur compromis performance/features.

Précision et recall

Trade-off recall vs latence

Le dilemme fondamental des index approximatifs : plus de précision = plus de latence.

Courbe Recall@10 vs Latence P95 (Qdrant, 10M vecteurs)

Recall@10
100% |                                        ● ef=1000
     |                              ● ef=500
 99% |                      ● ef=200
     |              ● ef=100
 98% |      ● ef=50
     |  ● ef=20
 97% |
 96% +--------------------------------------------------
     5ms   15ms   25ms   35ms   45ms   55ms  Latence P95

Point optimal: ef=100 (98.7% recall, 29ms latence)
Point ultra-rapide: ef=20 (97.1% recall, 8ms latence)
Point ultra-précis: ef=500 (99.4% recall, 52ms latence)

Règle pratique : commencer avec ef_search=100, mesurer recall sur un échantillon de vos données, ajuster selon vos contraintes latence/budget.

Recall selon les algorithmes d'index

Chaque algorithme d'indexation fait des compromis différents entre recall, vitesse et mémoire.

Impact de la quantification

La quantization réduit la précision des vecteurs pour économiser mémoire et accélérer les calculs.

Benchmark quantization (10M vecteurs 768D)

# Activer scalar quantization sur Qdrant
client.update_collection(
    collection_name="docs",
    quantization_config=models.ScalarQuantization(
        scalar=models.ScalarQuantizationConfig(
            type=models.ScalarType.INT8,
            quantile=0.99,  # Ignore outliers pour meilleure compression
        ),
    ),
)

Courbes Pareto performance-précision

Visualisation du front de Pareto : configurations optimales pour chaque point recall/latence.

Latence P95 (ms) vs Recall@10

 60ms |                                          ● HNSW FP32 ef=500
      |                              ● HNSW FP32 ef=200
 40ms |                      ● HNSW FP32 ef=100
      |              ● HNSW + Scalar Quant ef=100
 20ms |      ● IVF nprobe=64
      |  ● IVF+PQ nprobe=32
      |
  0ms +--------------------------------------------------
      88%    92%    95%    97%    98%    99%   Recall@10

Front de Pareto (configurations optimales) :
● 89% recall, 12ms → IVF+PQ (budget limité)
● 95% recall, 18ms → IVF nprobe=64
● 98% recall, 31ms → HNSW + Scalar Quant
● 99% recall, 52ms → HNSW FP32 ef=500

Interprétation : aucune configuration ne domine sur tous les critères. Choisir selon VOS contraintes métier : latence SLA, budget infrastructure, qualité requise.

Consommation de ressources

Utilisation mémoire

La consommation RAM détermine les coûts infrastructure et la faisabilité technique.

Consommation mémoire détaillée (10M vecteurs 768D)

Optimisation mémoire avec quantization

# Estimation mémoire pour 100M vecteurs 768D
FP32 baseline:     570 GB  (impossible single-node)
Scalar Quant INT8: 145 GB  (r5.8xlarge 256GB)
Product Quant:      85 GB  (r5.4xlarge 128GB)
Binary:             18 GB  (r5.xlarge 32GB)

Utilisation CPU

La charge CPU limite le throughput et impacte la latence sous charge.

CPU utilization à différents QPS (10M vecteurs, c5.4xlarge 16 vCPUs)

Règle dimensionnement : CPU utilization max 70% en production pour gérer les pics. Si CPU > 70% à charge nominale, scale horizontalement.

I/O disque

Les accès disque impactent principalement le démarrage et les cache miss, pas les performances steady-state.

Patterns I/O typiques

Cold start impact : charger 50 GB d'index depuis gp3 SSD = 2-3 minutes. Prévoir warm-up ou hot standby pour déploiements zero-downtime.

Bande passante réseau

Le trafic réseau dans un cluster vectoriel ou via API peut devenir un goulot d'étranglement.

Consommation réseau par type de charge

Dimensionnement réseau : pour 10K QPS mixte, provisionner minimum 2 Gbps (instances c5.2xlarge+). Monitorer network utilization dans CloudWatch.

Estimation des coûts cloud

Analyse TCO complet des différentes solutions selon la volumetrie (pricing AWS us-east-1, décembre 2024).

Coût mensuel pour différentes échelles (10M vecteurs 768D, 1000 QPS moyen)

Évolution des coûts avec la volumetrie

Coût mensuel vs Nombre de vecteurs (pricing Pinecone)

$5K  |
     |                                    ● 100M vecteurs
$3K  |                        ● 50M
     |              ● 10M
$1K  |      ● 1M
     |  ● 100K
$0   +----------------------------------------
     100K    1M     10M    50M    100M

Pinecone = scaling linéaire avec volumetrie
Self-hosted = scaling par paliers (taille instances)

Break-even analysis : Pinecone devient rentable vs Qdrant Cloud à partir de 50M+ vecteurs ou charges très variables (autoscaling).

Synthèse et recommandations

Tableau récapitulatif multi-critères

Synthèse de tous nos benchmarks pour 10 millions de vecteurs 768D en configuration optimisée.

Meilleur pour la latence ultra-faible

Si la latence est votre priorité absolue (chatbot temps réel, trading, recherche interactive).

Configuration optimale latence (Qdrant)

{
  "hnsw_config": {
    "m": 32,                  // Plus de connexions = meilleur recall
    "ef_construct": 400,      // Construction plus précise
    "max_indexing_threads": 8
  },
  "quantization_config": {
    "scalar": {
      "type": "int8",         // Compression 4x sans perte recall
      "quantile": 0.995
    }
  },
  "optimizer_config": {
    "memmap_threshold": 100000  // Force tout en RAM
  }
}

Budget nécessaire : $600-800/mois pour 10M vecteurs avec latence <30ms garanti.

Meilleur pour le throughput élevé

Pour maximiser les QPS (moteur de recherche, batch processing, analytics).

Architecture haute performance (15K+ QPS)

                    ┌──────────────┐
                    │ Load Balancer  │
                    │ (ALB/HAProxy)  │
                    └───────┬───────┘
                            │
             ┌─────────┼─────────┐
             │              │              │
    ┌────────┴──┐  ┌───┴──┐  ┌───┴──┐
    │ Qdrant       │  │ Qdrant │  │ Qdrant │
    │ Shard 1      │  │ Shard 2│  │ Shard 3│
    │ 5K QPS       │  │ 5K QPS │  │ 5K QPS │
    │ 3.3M vectors │  │ 3.3M v │  │ 3.3M v │
    └──────────────┘  └───────┘  └───────┘

Total: 15K QPS, latence P95 < 40ms

Conseil scaling : au-delà de 20K QPS, envisager region sharding (US-East + EU-West) plutôt qu'un cluster monolithique.

Meilleur pour la précision maximale

Quand chaque résultat compte (recherche médicale, légale, scientifique, compliance).

Script validation recall complet

# Vérifier recall sur votre dataset
import numpy as np
from qdrant_client import QdrantClient

def validate_recall(client, test_vectors, ground_truth, ef_values):
    results = {}

    for ef in ef_values:
        recalls = []

        for i, query_vector in enumerate(test_vectors[:100]):  # 100 queries test
            # Recherche approximative
            response = client.search(
                collection_name="test",
                query_vector=query_vector,
                limit=10,
                search_params={"ef": ef}
            )
            approx_ids = [hit.id for hit in response]

            # Ground truth (brute force précalculé)
            true_ids = ground_truth[i][:10]

            # Calcul recall@10
            intersection = len(set(approx_ids) & set(true_ids))
            recall = intersection / 10.0
            recalls.append(recall)

        results[ef] = np.mean(recalls)
        print(f"ef={ef}: Recall@10 = {results[ef]:.3f}")

    return results

# Usage
ef_values = [10, 20, 50, 100, 200, 500]
recall_results = validate_recall(client, test_vectors, ground_truth, ef_values)

SLA recall : documenter contractuellement le recall minimum (ex: "99%+ sur dataset de validation fourni par client"). Monitorer en continu avec alertes si recall < seuil.

Meilleur rapport qualité-prix

Optimiser le TCO sans sacrifier les performances essentielles (startup, PME, POC).

ROI Quantization (10M vecteurs)

Recommandation générale : commencer avec Qdrant + scalar quantization sur r5.xlarge. Migrer vers FP32 uniquement si recall mesuré insuffisant sur vos données.

Comment reproduire ces benchmarks

Scripts complets pour reproduire nos résultats ou benchmarker avec vos propres données.

1. Setup environnement de test

# Docker Compose pour Qdrant + monitoring
version: '3.8'
services:
  qdrant:
    image: qdrant/qdrant:v1.7.4
    ports:
      - "6333:6333"
    volumes:
      - "./qdrant_storage:/qdrant/storage"
    environment:
      - QDRANT__SERVICE__HTTP_PORT=6333
    deploy:
      resources:
        limits:
          memory: 32G
          cpus: '16'

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - "./prometheus.yml:/etc/prometheus/prometheus.yml"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

2. Script benchmark principal

#!/usr/bin/env python3
"""Benchmark complet bases vectorielles"""

import time
import numpy as np
import concurrent.futures
from statistics import median, quantiles
from qdrant_client import QdrantClient, models
from datasets import load_dataset  # HuggingFace datasets

class VectorBenchmark:
    def __init__(self, client, collection_name):
        self.client = client
        self.collection_name = collection_name
        self.latencies = []

    def setup_collection(self, vector_size=768, quantization=None):
        """Créer collection avec config optimisée"""
        config = models.VectorParams(
            size=vector_size,
            distance=models.Distance.COSINE
        )

        hnsw_config = models.HnswConfigDiff(
            m=16,
            ef_construct=200,
            full_scan_threshold=10000
        )

        self.client.create_collection(
            collection_name=self.collection_name,
            vectors_config=config,
            hnsw_config=hnsw_config,
            quantization_config=quantization
        )

    def load_test_data(self, num_vectors=10000):
        """Charger dataset SIFT ou générer aléatoirement"""
        # Option 1: Dataset réel
        # dataset = load_dataset("Qdrant/sift-small", split="train")
        # vectors = np.array([d["vector"] for d in dataset])

        # Option 2: Génération aléatoire (plus rapide pour tests)
        vectors = np.random.random((num_vectors, 768)).astype(np.float32)

        # Normalisation pour distance cosinus
        vectors = vectors / np.linalg.norm(vectors, axis=1, keepdims=True)

        return vectors

    def bulk_insert(self, vectors, batch_size=1000):
        """Insertion optimisée par batch"""
        points = []
        for i, vector in enumerate(vectors):
            points.append(models.PointStruct(
                id=i,
                vector=vector.tolist(),
                payload={"index": i, "timestamp": time.time()}
            ))

            if len(points) >= batch_size:
                self.client.upsert(
                    collection_name=self.collection_name,
                    points=points
                )
                points = []

        # Insérer le dernier batch
        if points:
            self.client.upsert(
                collection_name=self.collection_name,
                points=points
            )

    def warmup(self, query_vectors, num_warmup=100):
        """Warm-up pour stabiliser les performances"""
        print(f"Warm-up: {num_warmup} requêtes...")
        for i in range(num_warmup):
            query = query_vectors[i % len(query_vectors)]
            self.client.search(
                collection_name=self.collection_name,
                query_vector=query.tolist(),
                limit=10
            )

    def single_query(self, query_vector, ef_search=100):
        """Une requête avec mesure latence"""
        start = time.perf_counter()

        results = self.client.search(
            collection_name=self.collection_name,
            query_vector=query_vector.tolist(),
            limit=10,
            search_params=models.SearchParams(ef=ef_search)
        )

        latency_ms = (time.perf_counter() - start) * 1000
        return latency_ms, len(results)

    def throughput_test(self, query_vectors, duration_sec=60, max_workers=10):
        """Test throughput avec threads multiples"""
        print(f"Test throughput: {duration_sec}s avec {max_workers} threads")

        def worker():
            local_queries = 0
            start_time = time.time()

            while time.time() - start_time < duration_sec:
                query_idx = local_queries % len(query_vectors)
                query = query_vectors[query_idx]

                try:
                    self.single_query(query)
                    local_queries += 1
                except Exception as e:
                    print(f"Erreur: {e}")
                    break

            return local_queries

        # Exécution parallèle
        with concurrent.futures.ThreadPoolExecutor(max_workers=max_workers) as executor:
            futures = [executor.submit(worker) for _ in range(max_workers)]
            results = [f.result() for f in futures]

        total_queries = sum(results)
        qps = total_queries / duration_sec

        print(f"Résultats: {total_queries} requêtes en {duration_sec}s = {qps:.1f} QPS")
        return qps

    def latency_benchmark(self, query_vectors, num_queries=1000, ef_search=100):
        """Benchmark latence avec percentiles"""
        print(f"Test latence: {num_queries} requêtes (ef_search={ef_search})")

        latencies = []
        for i in range(num_queries):
            query = query_vectors[i % len(query_vectors)]
            latency_ms, _ = self.single_query(query, ef_search)
            latencies.append(latency_ms)

        # Calculer percentiles
        latencies.sort()
        p50 = median(latencies)
        p95 = np.percentile(latencies, 95)
        p99 = np.percentile(latencies, 99)

        print(f"Latences: P50={p50:.1f}ms, P95={p95:.1f}ms, P99={p99:.1f}ms")
        return {"p50": p50, "p95": p95, "p99": p99}

    def recall_test(self, query_vectors, ground_truth, ef_search=100, k=10):
        """Test recall vs ground truth"""
        print(f"Test recall@{k} (ef_search={ef_search})")

        recalls = []
        for i, query in enumerate(query_vectors[:100]):  # 100 queries test
            # Recherche approximative
            results = self.client.search(
                collection_name=self.collection_name,
                query_vector=query.tolist(),
                limit=k,
                search_params=models.SearchParams(ef=ef_search)
            )
            approx_ids = [hit.id for hit in results]

            # Comparer avec ground truth
            true_ids = ground_truth[i][:k]
            intersection = len(set(approx_ids) & set(true_ids))
            recall = intersection / k
            recalls.append(recall)

        avg_recall = np.mean(recalls)
        print(f"Recall@{k}: {avg_recall:.3f} ({avg_recall*100:.1f}%)")
        return avg_recall

# Usage exemple
if __name__ == "__main__":
    client = QdrantClient(host="localhost", port=6333)
    benchmark = VectorBenchmark(client, "benchmark_test")

    # Setup
    print("1. Configuration collection...")
    benchmark.setup_collection(quantization=models.ScalarQuantization(
        scalar=models.ScalarQuantizationConfig(type=models.ScalarType.INT8)
    ))

    # Chargement données
    print("2. Chargement vecteurs...")
    vectors = benchmark.load_test_data(num_vectors=100000)
    query_vectors = vectors[:1000]  # 1000 queries de test

    print("3. Insertion bulk...")
    start = time.time()
    benchmark.bulk_insert(vectors)
    insert_time = time.time() - start
    print(f"Insertion: {len(vectors)} vecteurs en {insert_time:.1f}s = {len(vectors)/insert_time:.0f} vecteurs/sec")

    # Warm-up
    benchmark.warmup(query_vectors)

    # Benchmarks
    print("\n4. Benchmark latence...")
    latency_results = benchmark.latency_benchmark(query_vectors, ef_search=100)

    print("\n5. Benchmark throughput...")
    qps = benchmark.throughput_test(query_vectors, duration_sec=30, max_workers=8)

    # Résumé
    print("\n=== RÉSULTATS ===")
    print(f"Dataset: {len(vectors)} vecteurs 768D")
    print(f"Latence P95: {latency_results['p95']:.1f}ms")
    print(f"Throughput: {qps:.0f} QPS")
    print(f"Mémoire: {benchmark.client.get_collection(benchmark.collection_name).config}")

3. Exécution automatisée

#!/bin/bash
# Script complet de benchmark multi-solutions

echo "=== BENCHMARK BASES VECTORIELLES ==="
echo "Date: $(date)"
echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-type)"

# Démarrer les services
docker-compose up -d
sleep 30  # Attendre démarrage

# Benchmark Qdrant
echo "\n--- QDRANT BENCHMARK ---"
python3 benchmark_qdrant.py

# Benchmark Milvus (adapté)
echo "\n--- MILVUS BENCHMARK ---"
python3 benchmark_milvus.py

# Générer rapport
echo "\n--- RAPPORT FINAL ---"
python3 generate_report.py > benchmark_report_$(date +%Y%m%d).txt

echo "Benchmark terminé. Rapport: benchmark_report_$(date +%Y%m%d).txt"

Répéter nos tests : tous nos scripts sont sur GitHub. Adapter les paramètres (vector_size, ef_search) à votre cas d'usage pour obtenir des résultats représentatifs.