Kaip užklausti 10 mlrd. įrašų greičiau nei per 100 ms?

Question

IT Interview Practice · Accepted Answer

Projektuokite **pirmiausia pagal prieigos šabloną (access pattern)**, tada pasirinkite partitioning + tinkamą indeksą/PK, kad bet kuri viena užklausa liestų mažą, apribotą pjūvį — niekada neskenuotų 10 mlrd. eilučių. Mažiau nei 100 ms per 10 milijardų įrašų nėra apie greitesnį diską; tai apie darbinės aibės padarymą mažyte.

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

## Prieigos šablonai lemia viską

Prieš pasirenkant technologiją, klauskite: **point lookup ar range/agregatas?** „Gauti naudotojo X paskutinius 20 užsakymų" yra point/range užklausa — norite, kad partition ir sort key tiksliai ją atitiktų. „Sumuoti pajamas pagal regioną šį mėnesį" yra analitinis skenavimas — eilučių saugykla (row store) čia netinkamas įrankis. Užklausos modeliavimas pirmiausia yra tai, kas atskiria veikiantį dizainą nuo to, kuris atrodo pagrįstas, bet daro pilną skenavimą.

## Partitioning apkarpo paieškos erdvę

Skaidykite lentelę pagal raktą, kuris pasirodo kiekvienoje užklausoje — dažniausiai **tenant_id + laikas**. Su laiko partition užklausa „paskutinės 7 dienos" skaito 7 partition ir ignoruoja kitus 3 metus. Tai *partition pruning*: router pašalina 99,9% duomenų prieš konsultuojantis su bet kuriuo indeksu.

## Tinkamas indekso / PK dizainas

Partition viduje **pirminis raktas privalo priekyje turėti užklausos filtro stulpelius**. DynamoDB: partition key = `tenant`, sort key = `timestamp` → range užklausos yra O(log n) + nuoseklus skaitymas. Stulpelinėje saugykloje kaip **ClickHouse** sorting key (`ORDER BY (tenant, ts)`) leidžia varikliui praleisti granules ir skaityti tik atitinkančius blokus. Padengiantis (covering) indeksas visiškai išvengia papildomo eilutės paėmimo.

## Saugyklos pasirinkimas

- **Point lookups, dideli įrašymai:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-iška pagal raktą, skalinasi horizontaliai.
- **Analitika/agregatai:** stulpelinė (ClickHouse, BigQuery) — skaito tik reikiamus stulpelius, vektorizuota.
- **Kešuokite karštą 1%:** Redis priekyje sugeria pakartotinius skaitymus per <5ms; 10 mlrd. eilučių, bet keli milijonai karštų raktų.

## Interviu perspektyva

Interviuotojas nori pamatyti, kaip sakote **„kokios užklausos?" prieš „kokia duomenų bazė?"**. Geri kandidatai griebiasi indeksų; puikūs pastebi, kad indeksas per 10 mlrd. eilučių pats yra didžiulis — tad *pirma partitioning, kad sumažintumėte, ką indeksas dengia*. Įvardyti row-vs-columnar skirtumą ir kešo sluoksnį signalizuoja tikrą masto patirtį.

**Dažni spąstai:** siūlyti vieną milžinišką B-tree indeksą kaip atsakymą. Jis padeda point lookups, bet nieko nedaro analitiniam skenavimui, o jo įrašymai stabdo priėmimą.

## Kompromisai ir gedimų būdai

- **Neteisingas partition key** = cross-partition scatter-gather, latency išpampsta. Rinkitės raktą, esantį užklausose.
- **Karšta partition:** įžymybės tenant užvaldo vieną shard — pridėkite salting priesagą.
- **Kešo pasenimas:** invaliduokite įrašant arba priimkite TTL vėlavimą.
- **Denormalizacijos kaina:** dažnai dubliuojate duomenis kiekvienam prieigos šablonui; saugykla pigi, 10 sekundžių užklausa — ne.

Prieigos šablonai lemia viską

Partitioning apkarpo paieškos erdvę

Tinkamas indekso / PK dizainas

Saugyklos pasirinkimas

Interviu perspektyva

Kompromisai ir gedimų būdai

Susiję klausimai