Πώς χτίζετε full-text search πάνω σε 100M+ records;

Question

IT Interview Practice · Accepted Answer

Χρησιμοποιήστε μια αποκλειστική search engine — **Elasticsearch/OpenSearch χτισμένη πάνω σε inverted index** — τροφοδοτούμενη από τη source βάση σας μέσω **CDC**, και κάντε shard το index για κλίμακα. Η primary βάση σας (Postgres/MySQL) δεν μπορεί να κάνει relevance-ranked text search πάνω σε εκατοντάδες εκατομμύρια rows· ένα `LIKE '%term%'` κάνει scan κάθε row. Μια 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 lists και τις τέμνει — O(matching docs), όχι O(all docs). Αυτό είναι που κάνει δυνατό το sub-100ms search πάνω σε 100M+ έγγραφα. Το κείμενο **αναλύεται** πρώτα: tokenized, lowercased, stemmed ("running" → "run"), τα stopwords πέφτουν — ώστε τα queries να ταιριάζουν παραλλαγές.

## Ingestion μέσω CDC

Μην κάνετε dual-write (η app γράφει στη βάση *και* στο ES) — μια αποτυχία τα αφήνει ασυνεπή. Αντ' αυτού, κάντε stream τις αλλαγές με **Change Data Capture**: το **Debezium** παρακολουθεί το write-ahead log της βάσης, δημοσιεύει αλλαγές rows στο **Kafka**, και ένας indexer τις εφαρμόζει στο Elasticsearch. Αυτό κρατά το search **eventually consistent** με την πηγή και επιβιώνει από ES downtime (τα events κάνουν replay από το Kafka).

## Sharding & relevance

Το index χωρίζεται σε **shards** (καθένα ένα αυτόνομο Lucene index), απλωμένα σε nodes· τα **replicas** προσθέτουν read throughput και HA. Ένα query κάνει scatter σε όλα τα shards, καθένα επιστρέφει το top-k του, και ο coordinator τα ενώνει. Η relevance χρησιμοποιεί **BM25** by default — term frequency × inverse document frequency — ρυθμιζόμενο με boosts, synonyms, και field weights.

## Οπτική συνέντευξης

Οι συνεντευκτές ελέγχουν αν (1) καταφεύγετε στο σωστό εργαλείο αντί για `LIKE`, (2) ξέρετε *πώς* δουλεύει το inverted index, και (3) λύνετε το **πρόβλημα συγχρονισμού** χωρίς dual-writes. Καλό: "χρησιμοποίησε Elasticsearch." Εξαιρετικό: κατονομάζετε CDC/Debezium για ingestion, BM25 για ranking, και αποδέχεστε eventual consistency ως το trade για κλίμακα.

**Συνηθισμένη παγίδα:** να αντιμετωπίζετε το Elasticsearch ως την πηγή αλήθειάς σας. Είναι ένα derived index — όχι durable/transactional όπως η βάση σας. Ξαναχτίστε το από την πηγή όταν χρειαστεί.

## Trade-offs & τρόποι αποτυχίας

- **Eventual consistency:** το search υστερεί από τα writes κατά το latency του CDC pipeline (συνήθως sub-second).
- **Πόνος reindex:** αλλαγές mapping/analyzer χρειάζονται πλήρες reindex — χρησιμοποιήστε aliases για zero-downtime swaps.
- **Deep pagination:** η σελίδα 10.000 είναι ακριβή (scatter-gather) — χρησιμοποιήστε `search_after`, όχι `from/size`.
- **Hot shard / skew:** ανομοιόμορφη κατανομή docs· επιλέξτε ένα καλό routing key και αρκετά shards εξαρχής (είναι σταθερά στη δημιουργία).
- **Το relevance tuning είναι διαρκές:** τα BM25 defaults σπάνια ταιριάζουν το business intent — περιμένετε επανάληψη.

Inverted index — γιατί είναι γρήγορο

Ingestion μέσω CDC

Sharding & relevance

Οπτική συνέντευξης

Trade-offs & τρόποι αποτυχίας

Σχετικές ερωτήσεις