Comment construire une recherche full-text sur plus de 100M d'enregistrements ?

Question

IT Interview Practice · Accepted Answer

Utilisez un moteur de recherche dédié — **Elasticsearch/OpenSearch bâti sur un index inversé** — alimenté depuis votre DB source via **CDC**, et shardez l'index pour l'échelle. Votre base de données primaire (Postgres/MySQL) ne peut pas faire de recherche textuelle classée par pertinence sur des centaines de millions de lignes ; un `LIKE '%term%'` scanne chaque ligne. Un moteur de recherche inverse le problème.

```text
Source DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)   (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                     ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter to shards ─▶ gather ─┴─ Shard N ── ranked by BM25
```

## Index inversé — pourquoi c'est rapide

Un index normal mappe ligne → valeurs. Un **index inversé** mappe *terme → liste des documents le contenant*. Rechercher « database scaling » consulte deux courtes posting lists et les intersecte — O(documents correspondants), pas O(tous les documents). C'est ce qui rend possible une recherche sous-100ms sur plus de 100M de documents. Le texte est d'abord **analysé** : tokenisé, mis en minuscules, stemmé (« running » → « run »), stopwords retirés — pour que les requêtes matchent les variantes.

## Ingestion via CDC

Ne faites pas de dual-write (l'app écrit dans la DB *et* dans ES) — un échec les laisse incohérents. À la place, streamez les changements avec le **Change Data Capture** : **Debezium** suit le write-ahead log de la DB, publie les changements de lignes vers **Kafka**, et un indexer les applique à Elasticsearch. Cela garde la recherche **eventually consistent** avec la source et survit aux pannes d'ES (les événements rejouent depuis Kafka).

## Sharding & pertinence

L'index est découpé en **shards** (chacun un index Lucene autonome), répartis sur des nœuds ; les **réplicas** ajoutent du throughput de lecture et de la HA. Une requête fait un scatter vers tous les shards, chacun retourne son top-k, et le coordinator fusionne. La pertinence utilise **BM25** par défaut — fréquence du terme × fréquence inverse dans les documents — ajustable avec des boosts, synonymes et pondérations de champs.

## Perspective d'entretien

Les examinateurs vérifient si vous (1) recourez au bon outil au lieu de `LIKE`, (2) savez *comment* fonctionne l'index inversé, et (3) résolvez le **problème de synchronisation** sans dual-writes. Bien : « utiliser Elasticsearch ». Excellent : vous nommez CDC/Debezium pour l'ingestion, BM25 pour le ranking, et acceptez l'eventual consistency comme le compromis pour l'échelle.

**Piège courant :** traiter Elasticsearch comme votre source de vérité. C'est un index dérivé — non durable/transactionnel comme votre DB. Reconstruisez-le depuis la source au besoin.

## Compromis et pannes

- **Eventual consistency :** la recherche est en retard sur les écritures de la latence du pipeline CDC (généralement sous la seconde).
- **Douleur de la réindexation :** les changements de mapping/analyzer nécessitent une réindexation complète — utilisez des alias pour des swaps sans downtime.
- **Pagination profonde :** la page 10 000 est coûteuse (scatter-gather) — utilisez `search_after`, pas `from/size`.
- **Shard chaud / skew :** distribution inégale des documents ; choisissez une bonne routing key et assez de shards dès le départ (ils sont fixés à la création).
- **Le tuning de pertinence est continu :** les défauts de BM25 correspondent rarement à l'intention métier — attendez-vous à itérer.

Index inversé — pourquoi c'est rapide

Ingestion via CDC

Sharding & pertinence

Perspective d'entretien

Compromis et pannes

Questions connexes