Hvordan spør du 10B poster under 100ms?

Question

IT Interview Practice · Accepted Answer

Design for **aksessmønsteret først**, velg deretter partisjonering + riktig indeks/PK slik at enhver enkelt spørring berører en liten, avgrenset skive — aldri skanner 10B rader. Under-100ms over 10 milliarder poster handler ikke om en raskere disk; det handler om å gjøre arbeidssettet bittelite.

```text
Spørring ─▶ Router ──▶ Partisjon (på tenant/tid) ──▶ Indeks/PK-oppslag ─▶ ~tusenvis av rader
   │                    (beskjær 99.9% av data)          (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? returner om <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregeringer / scans
```

## Aksessmønstre driver alt

Før du velger teknologi, spør: **point lookup eller range/aggregering?** "Hent bruker X sine siste 20 ordrer" er en point/range-spørring — du vil at partisjonen og sort key skal matche den nøyaktig. "Summer omsetning per region denne måneden" er en analytisk scan — en row store er feil verktøy. Å modellere spørringen først er det som skiller et design som fungerer fra ett som ser fornuftig ut men full-scanner.

## Partisjonering beskjærer søkerommet

Del tabellen på en nøkkel som opptrer i hver spørring — vanligvis **tenant_id + tid**. Med tidspartisjoner leser en spørring for "siste 7 dager" 7 partisjoner og ignorerer de andre 3 årene. Dette er *partition pruning*: routeren eliminerer 99.9% av data før noen indeks konsulteres.

## Riktig indeks / PK-design

Innenfor en partisjon må **primary key front-loade spørringens filterkolonner**. I DynamoDB: partition key = `tenant`, sort key = `timestamp` → range-spørringer er O(log n) + sekvensiell lesning. I en columnar store som **ClickHouse** lar sorteringsnøkkelen (`ORDER BY (tenant, ts)`) motoren hoppe over granuler og lese kun matchende blokker. En covering index unngår den ekstra row-fetchen helt.

## Store-valg

- **Point lookups, høy write:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-aktig på nøkkel, skalerer horisontalt.
- **Analytics/aggregeringer:** columnar (ClickHouse, BigQuery) — leser kun nødvendige kolonner, vektorisert.
- **Cache den hot 1%:** Redis foran absorberer gjentatte lesninger på <5ms; 10B rader men noen få millioner hot keys.

## Intervjuperspektiv

Intervjueren vil se at du sier **"hva er spørringene?" før "hvilken database?"**. Gode kandidater griper til indekser; utmerkede bemerker at en indeks på 10B rader selv er enorm — så du *partisjonerer først for å krympe hva indeksen dekker*. Å navngi row-vs-columnar-splitten og cache-laget signaliserer ekte skalaerfaring.

**Vanlig felle:** å foreslå én gigantisk B-tree-indeks som svaret. Den hjelper point lookups men gjør ingenting for de analytiske scannene, og writene dens flaskehalser ingestion.

## Avveininger og feilmoduser

- **Feil partisjonsnøkkel** = cross-partition scatter-gather, latency baller på. Velg en nøkkel til stede i spørringer.
- **Hot partisjon:** en celebrity-tenant overvelder én shard — legg til en salting-suffiks.
- **Cache-staleness:** invalider ved write eller aksepter TTL-lag.
- **Denormaliseringskostnad:** du dupliserer ofte data per aksessmønster; lagring er billig, en 10-sekunders spørring er det ikke.

Aksessmønstre driver alt

Partisjonering beskjærer søkerommet

Riktig indeks / PK-design

Store-valg

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål