Miten kyselet 10 miljardia tietuetta alle 100 ms:ssa?

Question

IT Interview Practice · Accepted Answer

Suunnittele **pääsykuvion (access pattern) mukaan ensin**, valitse sitten partitiointi + oikea indeksi/PK, jotta mikä tahansa yksittäinen kysely koskettaa pientä, rajattua siivua — ei koskaan skannaa 10 miljardia riviä. Alle 100 ms 10 miljardin tietueen yli ei ole nopeammasta levystä kiinni; kyse on työjoukon (working set) tekemisestä pieneksi.

```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ääsykuviot ohjaavat kaikkea

Ennen teknologian valintaa kysy: **point lookup vai range/aggregaatti?** "Hae käyttäjän X viimeiset 20 tilausta" on point/range-kysely — haluat partitio- ja sort-avaimen vastaavan sitä täsmälleen. "Summaa liikevaihto alueittain tässä kuussa" on analyyttinen skannaus — rivipohjainen store on väärä työkalu. Kyselyn mallintaminen ensin erottaa suunnitelman, joka toimii, siitä, joka näyttää järkevältä mutta täysskannaa.

## Partitiointi karsii hakutilaa

Jaa taulu avaimella, joka esiintyy jokaisessa kyselyssä — yleensä **tenant_id + aika**. Aikapartitioinnilla kysely "viimeiset 7 päivää" lukee 7 partitiota ja jättää huomiotta muut 3 vuotta. Tämä on *partition pruning*: router eliminoi 99,9 % datasta ennen kuin yhtäkään indeksiä konsultoidaan.

## Oikea indeksi- / PK-suunnittelu

Partition sisällä **primary keyn on nostettava eteen kyselyn suodatinsarakkeet**. DynamoDB:ssä: partitioavain = `tenant`, sort-avain = `timestamp` → range-kyselyt ovat O(log n) + peräkkäinen luku. Kolumnaarisessa storessa kuten **ClickHouse** lajitteluavain (`ORDER BY (tenant, ts)`) antaa moottorin ohittaa granulet ja lukea vain vastaavat lohkot. Covering-indeksi välttää ylimääräisen rivinhaun kokonaan.

## Storen valinta

- **Point lookupit, korkea kirjoitus:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-tyyppinen avaimella, skaalautuu horisontaalisesti.
- **Analytiikka/aggregaatit:** kolumnaarinen (ClickHouse, BigQuery) — lukee vain tarvittavat sarakkeet, vektoroitu.
- **Cachea kuumin 1 %:** Redis edessä imee toistuvat lukemiset <5 ms; 10 miljardia riviä mutta muutama miljoona kuumaa avainta.

## Haastattelunäkökulma

Haastattelija haluaa nähdä sinun sanovan **"mitkä ovat kyselyt?" ennen "mikä tietokanta?"**. Hyvät kandidaatit tarttuvat indekseihin; loistavat huomauttavat, että indeksi 10 miljardin rivin päällä on itsessään valtava — joten *partitioit ensin kutistaaksesi sen, mitä indeksi kattaa*. Rivi-vs-kolumnaari-jaon ja cache-tason nimeäminen signaloi todellista mittakaavakokemusta.

**Yleinen ansa:** ehdottaa yhtä jättimäistä B-tree-indeksiä vastaukseksi. Se auttaa point lookupeja mutta ei tee mitään analyyttisille skannauksille, ja sen kirjoitukset pullonkaulaavat sisäänoton.

## Kompromissit ja virhetilanteet

- **Väärä partitioavain** = cross-partition scatter-gather, latenssi paisuu. Valitse avain, joka esiintyy kyselyissä.
- **Kuuma partitio:** julkkis-tenant hukuttaa yhden shardin — lisää salting-suffiksi.
- **Cachen vanheneminen:** invalidoi kirjoituksessa tai hyväksy TTL-viive.
- **Denormalisoinnin kustannus:** duplikoit usein dataa per pääsykuvio; tallennustila on halpaa, 10 sekunnin kysely ei ole.

Pääsykuviot ohjaavat kaikkea

Partitiointi karsii hakutilaa

Oikea indeksi- / PK-suunnittelu

Storen valinta

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset