Kako poizvedujete po 10 milijardah zapisov v manj kot 100 ms?

Question

IT Interview Practice · Accepted Answer

Načrtujte najprej za **vzorec dostopa (access pattern)**, nato izberite particioniranje + pravi indeks/PK, tako da katera koli posamezna poizvedba dotakne majhno, omejeno rezino — nikoli ne skenira 10 milijard vrstic. Pod-100 ms čez 10 milijard zapisov ni o hitrejšem disku; je o tem, da naredite delovno množico (working set) drobno.

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

## Vzorci dostopa poganjajo vse

Preden izberete tehnologijo, vprašajte: **točkovni pregled (point lookup) ali obseg/agregat?** "Pridobi zadnjih 20 naročil uporabnika X" je točkovna/obsegovna poizvedba — želite, da se particija in sort key ujemata točno z njo. "Seštej prihodek po regijah ta mesec" je analitično skeniranje — row store je napačno orodje. Modeliranje poizvedbe najprej je tisto, kar loči zasnovo, ki deluje, od take, ki izgleda razumna, a polno skenira.

## Particioniranje obrezuje iskalni prostor

Razdelite tabelo po ključu, ki se pojavi v vsaki poizvedbi — običajno **tenant_id + čas**. S časovnimi particijami poizvedba za "zadnjih 7 dni" prebere 7 particij in ignorira ostala 3 leta. To je *obrezovanje particij (partition pruning)*: usmerjevalnik izloči 99,9% podatkov, preden se konzultira kateri koli indeks.

## Pravilna zasnova indeksa / PK

Znotraj particije mora **primarni ključ postaviti filterske stolpce poizvedbe na začetek**. V DynamoDB: partition key = `tenant`, sort key = `timestamp` → obsegovne poizvedbe so O(log n) + sekvenčno branje. V stolpčni (columnar) shrambi, kot je **ClickHouse**, sorting key (`ORDER BY (tenant, ts)`) omogoča pogonu, da preskoči granule in bere le ujemajoče se bloke. Prekrivni indeks (covering index) povsem izogne dodatnemu pridobivanju vrstice.

## Izbira shrambe

- **Točkovni pregledi, visoki zapisi:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish po ključu, horizontalno skalira.
- **Analitika/agregati:** stolpčni (ClickHouse, BigQuery) — bere le potrebne stolpce, vektorizirano.
- **Predpomni vročih 1%:** Redis spredaj absorbira ponovljena branja pri <5 ms; 10 milijard vrstic, a nekaj milijonov vročih ključev.

## Pogled s stališča razgovora

Izpraševalec želi videti, da rečete **"kakšne so poizvedbe?" pred "katera podatkovna baza?"**. Dobri kandidati posežejo po indeksih; odlični pripomnijo, da je indeks na 10 milijardah vrstic sam po sebi ogromen — zato *najprej particionirate, da skrčite, kar indeks pokriva*. Poimenovanje delitve row-vs-columnar in cache sloja signalizira resnično izkušnjo z obsegom.

**Pogosta past:** predlaganje enega orjaškega B-tree indeksa kot odgovor. Pomaga pri točkovnih pregledih, a ne stori ničesar za analitična skeniranja, njegovi zapisi pa so ozko grlo zajema.

## Kompromisi in načini odpovedi

- **Napačen particijski ključ** = medparticijski scatter-gather, latenca naraste. Izberite ključ, prisoten v poizvedbah.
- **Vroča particija:** znani (celebrity) tenant preplavi en shard — dodajte solni pripon (salting suffix).
- **Zastarelost predpomnilnika:** razveljavite ob zapisu ali sprejmite TTL zaostanek.
- **Strošek denormalizacije:** pogosto podvojite podatke na vzorec dostopa; shramba je poceni, 10-sekundna poizvedba ni.

Vzorci dostopa poganjajo vse

Particioniranje obrezuje iskalni prostor

Pravilna zasnova indeksa / PK

Izbira shrambe

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja