Hoe query je 10 miljard records onder 100ms?

Question

IT Interview Practice · Accepted Answer

Ontwerp eerst voor het **toegangspatroon**, kies dan partitionering + de juiste index/PK zodat elke afzonderlijke query slechts een kleine, begrensde slice raakt — nooit 10 miljard rows scant. Sub-100ms over 10 miljard records gaat niet over een snellere schijf; het gaat over de working set klein maken.

```text
Query ─▶ Router ──▶ Partitie (op tenant/tijd) ──▶ Index/PK-lookup ─▶ ~duizenden rows
   │                    (snoei 99,9% van de data)      (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? geef terug in <5ms
                        miss ▼
                   Columnar store (ClickHouse) voor aggregaties / scans
```

## Toegangspatronen bepalen alles

Vraag vóór je tech kiest: **point lookup of range/aggregatie?** "Haal de laatste 20 orders van gebruiker X" is een point/range-query — je wilt dat de partition en sort key er precies bij passen. "Sommeer omzet per regio deze maand" is een analytische scan — een row store is het verkeerde gereedschap. De query eerst modelleren onderscheidt een ontwerp dat werkt van een dat redelijk lijkt maar full-scant.

## Partitionering snoeit de zoekruimte

Splits de tabel op een sleutel die in elke query voorkomt — meestal **tenant_id + tijd**. Met tijdpartities leest een query voor "laatste 7 dagen" 7 partities en negeert de andere 3 jaar. Dit is *partition pruning*: de router elimineert 99,9% van de data vóór er ook maar een index wordt geraadpleegd.

## Juiste index / PK-ontwerp

Binnen een partitie moet de **primary key de filterkolommen van de query vooropzetten**. In DynamoDB: partition key = `tenant`, sort key = `timestamp` → range queries zijn O(log n) + sequentiële read. In een columnar store als **ClickHouse** laat de sorting key (`ORDER BY (tenant, ts)`) de engine granules overslaan en alleen matchende blocks lezen. Een covering index vermijdt de extra row-fetch volledig.

## Store-keuze

- **Point lookups, hoge write:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-achtig op sleutel, schaalt horizontaal.
- **Analytics/aggregaties:** columnar (ClickHouse, BigQuery) — leest alleen de benodigde kolommen, gevectoriseerd.
- **Cache de hot 1%:** Redis ervoor absorbeert herhaalde reads in <5ms; 10 miljard rows maar een paar miljoen hot keys.

## Interviewperspectief

De interviewer wil je **"wat zijn de queries?" horen zeggen vóór "welke database?"**. Goede kandidaten grijpen naar indexen; uitstekende merken op dat een index op 10 miljard rows zelf enorm is — dus je *partitioneert eerst om te verkleinen wat de index dekt*. Het benoemen van de row-versus-columnar-splitsing en de cache-laag signaleert echte schaal-ervaring.

**Veelvoorkomende valkuil:** één gigantische B-tree-index als het antwoord voorstellen. Het helpt point lookups maar doet niets voor de analytische scans, en de writes ervan vormen een bottleneck voor ingestie.

## Afwegingen & faalmodi

- **Verkeerde partition key** = cross-partition scatter-gather, latency explodeert. Kies een sleutel die in de queries voorkomt.
- **Hot partition:** een celebrity-tenant overweldigt één shard — voeg een salting-suffix toe.
- **Cache-staleness:** invalideer bij write of accepteer TTL-lag.
- **Denormalisatiekosten:** je dupliceert vaak data per toegangspatroon; opslag is goedkoop, een query van 10 seconden niet.

Toegangspatronen bepalen alles

Partitionering snoeit de zoekruimte

Juiste index / PK-ontwerp

Store-keuze

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen