Kako upitati 10 milijardi zapisa ispod 100 ms?

Question

IT Interview Practice · Accepted Answer

Dizajnirajte prvo za **obrazac pristupa (access pattern)**, zatim odaberite particioniranje + pravi indeks/PK tako da svaki pojedini upit dotakne mali, ograničen dio — a nikada ne skenira 10 milijardi redaka. Ispod 100 ms preko 10 milijardi zapisa nije o bržem disku; radi se o tome da radni skup (working set) bude sićušan.

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

## Obrasci pristupa pokreću sve

Prije odabira tehnologije, pitajte: **point lookup ili range/agregacija?** "Dohvati zadnjih 20 narudžbi korisnika X" je point/range upit — želite da se particija i sort key točno poklope s njim. "Zbroji prihod po regiji ovaj mjesec" je analitičko skeniranje — row store je pogrešan alat. Modeliranje upita prvo razlikuje dizajn koji radi od onog koji izgleda razumno ali radi full scan.

## Particioniranje smanjuje prostor pretrage

Podijelite tablicu ključem koji se pojavljuje u svakom upitu — obično **tenant_id + vrijeme**. S vremenskim particijama, upit za "zadnjih 7 dana" čita 7 particija i ignorira ostale 3 godine. To je *partition pruning*: router eliminira 99,9% podataka prije nego što se konzultira ijedan indeks.

## Ispravan dizajn indeksa / PK-a

Unutar particije, **primarni ključ mora prvo staviti stupce filtera upita**. U DynamoDB-u: partition key = `tenant`, sort key = `timestamp` → range upiti su O(log n) + sekvencijalno čitanje. U columnar storeu poput **ClickHousea**, sorting key (`ORDER BY (tenant, ts)`) omogućuje engineu da preskoči granule i čita samo odgovarajuće blokove. Covering index u potpunosti izbjegava dodatno dohvaćanje retka.

## Izbor storea

- **Point lookupi, visok upis:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish po ključu, horizontalno skalira.
- **Analitika/agregacije:** columnar (ClickHouse, BigQuery) — čita samo potrebne stupce, vektorizirano.
- **Cachirajte vrući 1%:** Redis sprijeda apsorbira ponovljena čitanja u <5 ms; 10 milijardi redaka ali nekoliko milijuna vrućih ključeva.

## Perspektiva intervjua

Ispitivač želi vidjeti da kažete **"koji su upiti?" prije "koja baza?"**. Dobri kandidati posežu za indeksima; odlični primjećuju da je indeks na 10 milijardi redaka sam po sebi ogroman — pa *prvo particionirate da smanjite ono što indeks pokriva*. Imenovanje podjele row-vs-columnar i cache sloja signalizira stvarno iskustvo sa skalom.

**Uobičajena zamka:** predlaganje jednog divovskog B-tree indeksa kao odgovora. Pomaže point lookupima ali ne čini ništa za analitička skeniranja, a njegovi upisi guše unos.

## Kompromisi i načini otkazivanja

- **Pogrešan particijski ključ** = cross-partition scatter-gather, latencija naraste. Odaberite ključ prisutan u upitima.
- **Vruća particija:** slavni tenant preplavi jedan shard — dodajte salting sufiks.
- **Zastarjelost cachea:** invalidirajte pri upisu ili prihvatite TTL zaostajanje.
- **Trošak denormalizacije:** često duplicirate podatke po obrascu pristupa; pohrana je jeftina, upit od 10 sekundi nije.

Obrasci pristupa pokreću sve

Particioniranje smanjuje prostor pretrage

Ispravan dizajn indeksa / PK-a

Izbor storea

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja