Jak zbudować wyszukiwanie pełnotekstowe po ponad 100 mln rekordów?

Question

IT Interview Practice · Accepted Answer

Użyj dedykowanego silnika wyszukiwania — **Elasticsearch/OpenSearch zbudowanego na odwróconym indeksie (inverted index)** — zasilanego z twojej źródłowej DB przez **CDC**, i sharduj indeks dla skali. Twoja podstawowa baza (Postgres/MySQL) nie poradzi sobie z wyszukiwaniem tekstowym rankowanym po trafności po setkach milionów wierszy; `LIKE '%term%'` skanuje każdy wiersz. Silnik wyszukiwania odwraca ten problem.

```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
```

## Odwrócony indeks — dlaczego jest szybki

Normalny indeks mapuje wiersz → wartości. **Odwrócony indeks** mapuje *term → listę dokumentów go zawierających*. Wyszukanie „database scaling" sprawdza dwie krótkie listy postingów i przecina je — O(pasujące dokumenty), a nie O(wszystkie dokumenty). To właśnie umożliwia wyszukiwanie poniżej 100 ms po ponad 100 mln dokumentów. Tekst jest najpierw **analizowany**: tokenizowany, sprowadzany do małych liter, stemmowany („running" → „run"), stopwordy odrzucane — aby zapytania pasowały do wariantów.

## Przyjmowanie danych przez CDC

Nie rób dual-write (aplikacja zapisuje do DB *i* do ES) — awaria pozostawi je niespójnymi. Zamiast tego strumieniuj zmiany przez **Change Data Capture**: **Debezium** śledzi write-ahead log bazy, publikuje zmiany wierszy do **Kafki**, a indexer aplikuje je do Elasticsearch. To utrzymuje wyszukiwanie **spójnym ostatecznie (eventually consistent)** ze źródłem i przetrwa awarię ES (zdarzenia są odtwarzane z Kafki).

## Shardowanie i trafność

Indeks jest dzielony na **shardy** (każdy to samowystarczalny indeks Lucene), rozłożone na węzły; **repliki** dodają throughput odczytu i HA. Zapytanie rozgałęzia się na wszystkie shardy, każdy zwraca swoje top-k, a koordynator scala wyniki. Trafność domyślnie używa **BM25** — częstotliwość termu × odwrotna częstotliwość dokumentowa — strojalnego boostami, synonimami i wagami pól.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówcy sprawdzają, czy (1) sięgasz po właściwe narzędzie zamiast `LIKE`, (2) wiesz, *jak* działa odwrócony indeks, oraz (3) rozwiązujesz **problem synchronizacji** bez dual-writes. Dobrze: „użyj Elasticsearch". Świetnie: nazywasz CDC/Debezium do przyjmowania, BM25 do rankowania i akceptujesz spójność ostateczną jako kompromis dla skali.

**Częsta pułapka:** traktowanie Elasticsearch jako źródła prawdy. To indeks pochodny — nie trwały/transakcyjny jak twoja DB. Odbuduj go ze źródła, gdy trzeba.

## Kompromisy i tryby awarii

- **Spójność ostateczna:** wyszukiwanie jest opóźnione względem zapisów o latency pipeline'u CDC (zwykle poniżej sekundy).
- **Ból reindeksacji:** zmiany mappingu/analizatora wymagają pełnej reindeksacji — użyj aliasów do zamiany bez przestoju.
- **Głęboka paginacja:** strona 10 000 jest kosztowna (scatter-gather) — użyj `search_after`, nie `from/size`.
- **Gorący shard / skew:** nierówny rozkład dokumentów; wybierz dobry klucz routingu i wystarczająco shardów z góry (są ustalone przy tworzeniu).
- **Strojenie trafności jest ciągłe:** domyślne BM25 rzadko pasuje do intencji biznesowej — spodziewaj się iteracji.

Odwrócony indeks — dlaczego jest szybki

Przyjmowanie danych przez CDC

Shardowanie i trafność

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania