Πώς κάνετε query σε 10 δισεκατομμύρια records κάτω από 100ms;

Question

IT Interview Practice · Accepted Answer

Σχεδιάστε πρώτα για το **access pattern**, μετά επιλέξτε partitioning + το σωστό index/PK ώστε κάθε μεμονωμένο query να αγγίζει ένα μικρό, φραγμένο κομμάτι — ποτέ να μη κάνει scan 10 δισ. rows. Το sub-100ms πάνω σε 10 δισεκατομμύρια records δεν αφορά έναν πιο γρήγορο δίσκο· αφορά το να κάνετε το working set μικροσκοπικό.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Τα access patterns καθορίζουν τα πάντα

Πριν επιλέξετε τεχνολογία, ρωτήστε: **point lookup ή range/aggregate;** Το "Πάρε τα τελευταία 20 orders του χρήστη X" είναι point/range query — θέλετε το partition και το sort key να το ταιριάζουν ακριβώς. Το "Άθροισε τα έσοδα ανά περιοχή αυτόν τον μήνα" είναι analytical scan — ένα row store είναι το λάθος εργαλείο. Το να μοντελοποιείτε πρώτα το query είναι που ξεχωρίζει έναν σχεδιασμό που δουλεύει από έναν που φαίνεται λογικός αλλά κάνει full-scan.

## Το partitioning κλαδεύει τον χώρο αναζήτησης

Σπάστε τον πίνακα με ένα key που εμφανίζεται σε κάθε query — συνήθως **tenant_id + time**. Με time partitions, ένα query για τις "τελευταίες 7 μέρες" διαβάζει 7 partitions και αγνοεί τα άλλα 3 χρόνια. Αυτό είναι *partition pruning*: ο router εξαλείφει το 99,9% των δεδομένων πριν συμβουλευτεί οποιοδήποτε index.

## Σωστός σχεδιασμός index / PK

Μέσα σε ένα partition, το **primary key πρέπει να βάζει μπροστά τις filter columns του query**. Στο DynamoDB: partition key = `tenant`, sort key = `timestamp` → τα range queries είναι O(log n) + sequential read. Σε ένα columnar store όπως το **ClickHouse**, το sorting key (`ORDER BY (tenant, ts)`) επιτρέπει στη μηχανή να παρακάμψει granules και να διαβάσει μόνο τα blocks που ταιριάζουν. Ένα covering index αποφεύγει εντελώς το επιπλέον row fetch.

## Επιλογή store

- **Point lookups, high write:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish ανά key, κάνει scale οριζόντια.
- **Analytics/aggregates:** columnar (ClickHouse, BigQuery) — διαβάζει μόνο τις απαραίτητες columns, vectorized.
- **Cache το hot 1%:** Redis μπροστά απορροφά επαναλαμβανόμενα reads σε <5ms· 10 δισ. rows αλλά λίγα εκατομμύρια hot keys.

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

Ο συνεντευκτής θέλει να σας δει να λέτε **"ποια είναι τα queries;" πριν το "ποια βάση δεδομένων;"**. Οι καλοί υποψήφιοι καταφεύγουν σε indexes· οι εξαιρετικοί σημειώνουν ότι ένα index πάνω σε 10 δισ. rows είναι το ίδιο τεράστιο — οπότε *κάνετε partition πρώτα για να συρρικνώσετε αυτό που καλύπτει το index*. Το να κατονομάζετε τον διαχωρισμό row-vs-columnar και το cache tier σηματοδοτεί πραγματική εμπειρία κλίμακας.

**Συνηθισμένη παγίδα:** να προτείνετε ένα γιγαντιαίο B-tree index ως την απάντηση. Βοηθά τα point lookups αλλά δεν κάνει τίποτα για τα analytical scans, και τα writes του γίνονται bottleneck στο ingestion.

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

- **Λάθος partition key** = cross-partition scatter-gather, το latency εκτοξεύεται. Επιλέξτε ένα key που υπάρχει στα queries.
- **Hot partition:** ένας celebrity tenant κατακλύζει ένα shard — προσθέστε ένα salting suffix.
- **Cache staleness:** κάντε invalidate στο write ή αποδεχτείτε TTL lag.
- **Κόστος denormalization:** συχνά διπλασιάζετε δεδομένα ανά access pattern· η αποθήκευση είναι φθηνή, ένα query 10 δευτερολέπτων όχι.

Τα access patterns καθορίζουν τα πάντα

Το partitioning κλαδεύει τον χώρο αναζήτησης

Σωστός σχεδιασμός index / PK

Επιλογή store

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

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

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