Comment interroger 10 milliards d'enregistrements en moins de 100ms ?

Question

IT Interview Practice · Accepted Answer

Concevez d'abord pour le **pattern d'accès**, puis choisissez le partitionnement + le bon index/PK pour que chaque requête ne touche qu'une tranche petite et bornée — sans jamais scanner 10 milliards de lignes. Le sous-100ms sur 10 milliards d'enregistrements n'est pas une question de disque plus rapide ; il s'agit de rendre le working set minuscule.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Les patterns d'accès dirigent tout

Avant de choisir la techno, demandez : **point lookup ou range/aggregate ?** « Obtenir les 20 dernières commandes de l'utilisateur X » est une requête point/range — vous voulez que la partition et la sort key y correspondent exactement. « Sommer le revenu par région ce mois-ci » est un scan analytique — un row store est le mauvais outil. Modéliser d'abord la requête est ce qui distingue une conception qui fonctionne d'une qui semble raisonnable mais fait un full-scan.

## Le partitionnement élague l'espace de recherche

Découpez la table par une clé qui apparaît dans chaque requête — habituellement **tenant_id + time**. Avec des partitions temporelles, une requête pour « les 7 derniers jours » lit 7 partitions et ignore les 3 autres années. C'est le *partition pruning* : le router élimine 99,9% des données avant qu'un index ne soit consulté.

## Conception du bon index / PK

Au sein d'une partition, la **primary key doit placer en tête les colonnes de filtre de la requête**. Dans DynamoDB : partition key = `tenant`, sort key = `timestamp` → les range queries sont en O(log n) + lecture séquentielle. Dans un columnar store comme **ClickHouse**, la sorting key (`ORDER BY (tenant, ts)`) permet au moteur de sauter des granules et de ne lire que les blocs correspondants. Un covering index évite entièrement le fetch de ligne supplémentaire.

## Choix du store

- **Point lookups, écriture élevée :** NoSQL key-value (DynamoDB, Cassandra) — O(1) environ par clé, scale horizontalement.
- **Analytique/agrégats :** columnar (ClickHouse, BigQuery) — ne lit que les colonnes nécessaires, vectorisé.
- **Cacher les 1% chauds :** Redis en front absorbe les lectures répétées à <5ms ; 10 milliards de lignes mais quelques millions de clés chaudes.

## Perspective d'entretien

L'examinateur veut vous voir dire **« quelles sont les requêtes ? » avant « quelle base de données ? »**. Les bons candidats recourent aux index ; les excellents notent qu'un index sur 10 milliards de lignes est lui-même énorme — donc vous *partitionnez d'abord pour réduire ce que l'index couvre*. Nommer la distinction row-vs-columnar et le tier de cache signale une vraie expérience de l'échelle.

**Piège courant :** proposer un seul gigantesque index B-tree comme réponse. Il aide les point lookups mais ne fait rien pour les scans analytiques, et ses écritures créent un goulot à l'ingestion.

## Compromis et pannes

- **Mauvaise partition key** = scatter-gather cross-partition, la latence explose. Choisissez une clé présente dans les requêtes.
- **Partition chaude :** un tenant célébrité submerge un shard — ajoutez un suffixe de salting.
- **Cache périmé :** invalidez à l'écriture ou acceptez le lag du TTL.
- **Coût de dénormalisation :** vous dupliquez souvent des données par pattern d'accès ; le stockage est bon marché, une requête de 10 secondes ne l'est pas.

Les patterns d'accès dirigent tout

Le partitionnement élague l'espace de recherche

Conception du bon index / PK

Choix du store

Perspective d'entretien

Compromis et pannes

Questions connexes