როგორ ააგებთ full-text search-ს 100M+ ჩანაწერზე?

Question

IT Interview Practice · Accepted Answer

გამოიყენეთ გამოყოფილი search engine — **Elasticsearch/OpenSearch, აგებული inverted index-ზე** — რომელიც თქვენი source DB-იდან **CDC**-ით იკვებება, და shard გააკეთეთ index-ს მასშტაბისთვის. თქვენს primary database-ს (Postgres/MySQL) არ შეუძლია relevance-ranked ტექსტური ძებნა ასეულობით მილიონ მწკრივზე; `LIKE '%term%'` ყოველ მწკრივს სკანირებს. search engine პრობლემას აბრუნებს.

```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 — რატომ არის სწრაფი

ჩვეულებრივი index ასახავს row → values. **inverted index** ასახავს *term → იმ დოკუმენტების სია, რომლებიც მას შეიცავს*. "database scaling"-ის ძებნა ორ მოკლე posting list-ს ეძებს და კვეთს — O(შესატყვისი დოკუმენტები), არა O(ყველა დოკუმენტი). სწორედ ეს ხდის შესაძლებელს 100ms-ზე ნაკლებ ძებნას 100M+ დოკუმენტზე. ტექსტი ჯერ **analyzed**-ია: tokenized, lowercased, stemmed ("running" → "run"), stopword-ები ჩამოგდებული — რომ query-ები ვარიანტებს ემთხვეოდეს.

## Ingestion CDC-ით

ნუ გააკეთებთ dual-write-ს (app წერს DB-ში *და* ES-ში) — ჩავარდნა მათ არათანმიმდევრულს ტოვებს. ამის ნაცვლად, stream გააკეთეთ ცვლილებებს **Change Data Capture**-ით: **Debezium** კითხულობს DB-ის write-ahead log-ს, row ცვლილებებს **Kafka**-ში აქვეყნებს და indexer მათ Elasticsearch-ზე იყენებს. ეს ინახავს search-ს **eventually consistent** source-თან და ES-ის ჩამქრალობას იტანს (event-ები Kafka-დან ხელახლა ეშვება).

## Sharding და relevance

index **shard-ებად** (თითო თვითდაფარული Lucene index) იყოფა, node-ებზე გაშლილი; **replica-ები** read throughput-ს და HA-ს ამატებს. query ყველა shard-ზე იშლება, თითო თავის top-k-ს აბრუნებს და coordinator ერთდება. relevance ნაგულისხმევად **BM25**-ს იყენებს — term frequency × inverse document frequency — რეგულირებადი boost-ებით, synonym-ებით და field weight-ებით.

## ინტერვიუს პერსპექტივა

ინტერვიუერები ამოწმებენ, (1) მიდიხართ თუ არა სწორ იარაღამდე `LIKE`-ის ნაცვლად, (2) იცით თუ არა *როგორ* მუშაობს inverted index, და (3) წყვეტთ თუ არა **sync პრობლემას** dual-write-ის გარეშე. კარგი: "გამოიყენე Elasticsearch." შესანიშნავი: ასახელებთ CDC/Debezium-ს ingestion-ისთვის, BM25-ს ranking-ისთვის და იღებთ eventual consistency-ს მასშტაბის ტრეიდ-ოფად.

**გავრცელებული ხაფანგი:** Elasticsearch-ის source of truth-ად მიჩნევა. ის derived index-ია — არა durable/transactional, როგორც თქვენი DB. ხელახლა ააგეთ source-იდან საჭიროებისას.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **Eventual consistency:** search write-ებს CDC pipeline-ის latency-ით ჩამორჩება (ჩვეულებრივ sub-second).
- **Reindex-ის ტკივილი:** mapping/analyzer ცვლილებებს სრული reindex სჭირდება — გამოიყენეთ alias-ები zero-downtime swap-ისთვის.
- **ღრმა pagination:** გვერდი 10,000 ძვირია (scatter-gather) — გამოიყენეთ `search_after`, არა `from/size`.
- **Hot shard / skew:** დოკუმენტების არათანაბარი განაწილება; აირჩიეთ კარგი routing key და საკმარისი shard-ები წინასწარ (ისინი ფიქსირებულია შექმნისას).
- **Relevance-ის რეგულირება მუდმივია:** BM25 ნაგულისხმევი იშვიათად ემთხვევა ბიზნეს-განზრახვას — მოელოდეთ იტერაციას.

Inverted index — რატომ არის სწრაფი

Ingestion CDC-ით

Sharding და relevance

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები