100M+ kayıt üzerinde full-text search'ü nasıl inşa edersiniz?

Question

IT Interview Practice · Accepted Answer

Özel bir search engine kullanın — **inverted index üzerine kurulu Elasticsearch/OpenSearch** — kaynak DB'nizden **CDC** aracılığıyla beslenen ve ölçek için index'i shard'layan. Primary veritabanınız (Postgres/MySQL), yüz milyonlarca satır üzerinde relevance-ranked text search yapamaz; bir `LIKE '%term%'` her satırı tarar. Bir search engine problemi tersine çevirir.

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

## Inverted index — neden hızlı

Normal bir index satır → değerler eşler. Bir **inverted index** *term → onu içeren document listesi* eşler. "database scaling" aramak iki kısa posting list'i arar ve kesiştirir — O(eşleşen doc), O(tüm doc) değil. 100M+ document üzerinde 100ms altı arama'yı mümkün kılan budur. Text önce **analyze** edilir: tokenize edilir, küçük harfe çevrilir, stem'lenir ("running" → "run"), stopword'ler düşürülür — böylece sorgular varyantlarla eşleşir.

## CDC ile ingestion

Dual-write yapmayın (app hem DB'ye *hem de* ES'e yazar) — bir hata onları tutarsız bırakır. Bunun yerine, değişiklikleri **Change Data Capture** ile stream'leyin: **Debezium** DB'nin write-ahead log'unu takip eder, satır değişikliklerini **Kafka**'ya publish eder ve bir indexer bunları Elasticsearch'e uygular. Bu, arama'yı kaynakla **eventually consistent** tutar ve ES kesintilerinde hayatta kalır (olaylar Kafka'dan replay olur).

## Sharding & relevance

Index, node'lara yayılmış **shard'lara** (her biri kendi kendine yeten bir Lucene index) bölünür; **replica'lar** read throughput ve HA ekler. Bir sorgu tüm shard'lara scatter olur, her biri top-k'sını döndürür ve coordinator merge eder. Relevance varsayılan olarak **BM25** kullanır — term frequency × inverse document frequency — boost'lar, synonym'ler ve field ağırlıkları ile ayarlanabilir.

## Mülakat perspektifi

Mülakatı yapanlar şunları kontrol eder: (1) `LIKE` yerine doğru araca başvurma, (2) inverted index'in *nasıl* çalıştığını bilme ve (3) dual-write olmadan **sync problemini** çözme. İyi: "Elasticsearch kullan." Harika: ingestion için CDC/Debezium'u, ranking için BM25'i adlandırırsınız ve ölçek için ödünleşim olarak eventual consistency'yi kabul edersiniz.

**Yaygın tuzak:** Elasticsearch'ü doğruluk kaynağınız olarak ele almak. O türetilmiş bir index'tir — DB'niz gibi durable/transactional değildir. Gerektiğinde onu kaynaktan yeniden inşa edin.

## Ödünleşimler ve hata modları

- **Eventual consistency:** arama, CDC pipeline latency'si kadar yazmaların gerisinde kalır (genellikle saniye altı).
- **Reindex sancısı:** mapping/analyzer değişiklikleri tam bir reindex gerektirir — sıfır kesintili takas için alias'lar kullanın.
- **Deep pagination:** sayfa 10.000 pahalıdır (scatter-gather) — `from/size` değil, `search_after` kullanın.
- **Hot shard / skew:** eşit olmayan doc dağılımı; iyi bir routing key ve önceden yeterli shard seçin (bunlar oluşturmada sabittir).
- **Relevance tuning süreklidir:** BM25 varsayılanları nadiren iş amacıyla eşleşir — iterasyon bekleyin.

Inverted index — neden hızlı

CDC ile ingestion

Sharding & relevance

Mülakat perspektifi

Ödünleşimler ve hata modları

İlgili sorular