Jak dotazujete 10 miliard záznamů pod 100 ms?

Question

IT Interview Practice · Accepted Answer

Navrhujte nejprve podle **přístupového vzoru (access pattern)**, pak zvolte partitioning + správný index/PK tak, aby se každý jednotlivý dotaz dotkl malého ohraničeného výřezu — nikdy neskenoval 10 miliard řádků. Sub-100ms nad 10 miliardami záznamů není o rychlejším disku; je to o tom udělat working set malým.

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

## Přístupové vzory řídí vše

Než zvolíte technologii, ptejte se: **point lookup, nebo range/agregát?** „Získej posledních 20 objednávek uživatele X“ je point/range dotaz — chcete, aby mu partition a sort key přesně odpovídaly. „Sečti tržby podle regionu za tento měsíc“ je analytický sken — row store je špatný nástroj. Nejdřív si namodelovat dotaz je to, co odděluje návrh, který funguje, od toho, co vypadá rozumně, ale full-scanuje.

## Partitioning prořezává vyhledávací prostor

Rozdělte tabulku podle klíče, který se objeví v každém dotazu — obvykle **tenant_id + čas**. S časovými partitionami přečte dotaz na „posledních 7 dní“ 7 partitionů a ignoruje zbylé 3 roky. To je *partition pruning*: router eliminuje 99,9 % dat dřív, než se konzultuje jakýkoli index.

## Správný návrh indexu / PK

Uvnitř partitionu musí **primární klíč předsazovat filtrovací sloupce dotazu**. V DynamoDB: partition key = `tenant`, sort key = `timestamp` → range dotazy jsou O(log n) + sekvenční čtení. V columnar store jako **ClickHouse** nechává sorting key (`ORDER BY (tenant, ts)`) engine přeskočit granule a číst jen odpovídající bloky. Covering index se úplně vyhne dodatečnému načtení řádku.

## Volba úložiště

- **Point lookups, hodně zápisů:** NoSQL key-value (DynamoDB, Cassandra) — přibližně O(1) podle klíče, škáluje horizontálně.
- **Analytika/agregáty:** columnar (ClickHouse, BigQuery) — čte jen potřebné sloupce, vektorizovaně.
- **Nacachuj horké 1 %:** Redis vpředu pohltí opakovaná čtení pod 5 ms; 10 miliard řádků, ale pár milionů hot keys.

## Pohled z pohovoru

Tazatel chce vidět, že řeknete **„jaké jsou dotazy?“ před „jaká databáze?“**. Dobří kandidáti sáhnou po indexech; skvělí poznamenají, že index nad 10 miliardami řádků je sám o sobě obrovský — takže *nejdřív partitionujete, abyste zmenšili, co index pokrývá*. Pojmenování rozdělení row-vs-columnar a cache vrstvy signalizuje skutečnou zkušenost s měřítkem.

**Častá past:** navrhnout jeden obří B-tree index jako odpověď. Pomůže point lookupům, ale nedělá nic pro analytické skeny a jeho zápisy jsou úzkým hrdlem ingestion.

## Kompromisy a režimy selhání

- **Špatný partition key** = cross-partition scatter-gather, latence nabobtná. Volte klíč přítomný v dotazech.
- **Hot partition:** celebritní tenant zahltí jeden shard — přidejte salting suffix.
- **Zastaralost cache:** invalidujte při zápisu nebo akceptujte TTL lag.
- **Cena denormalizace:** často data duplikujete na přístupový vzor; úložiště je levné, 10sekundový dotaz ne.

Přístupové vzory řídí vše

Partitioning prořezává vyhledávací prostor

Správný návrh indexu / PK

Volba úložiště

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky