Hur frågar du 10B poster under 100ms?

Question

IT Interview Practice · Accepted Answer

Designa för **åtkomstmönstret först**, välj sedan partitionering + rätt index/PK så att varje enskild fråga rör en liten, begränsad del — aldrig skannar 10B rader. Under 100ms över 10 miljarder poster handlar inte om en snabbare disk; det handlar om att göra working set:et litet.

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

## Åtkomstmönster styr allt

Innan du väljer teknik, fråga: **point lookup eller range/aggregat?** "Hämta användare X:s senaste 20 ordrar" är en point/range-fråga — du vill att partitionen och sort key matchar den exakt. "Summera intäkt per region denna månad" är en analytisk scan — en row store är fel verktyg. Att modellera frågan först är det som skiljer en design som fungerar från en som ser rimlig ut men full-scannar.

## Partitionering beskär sökrymden

Dela tabellen på en nyckel som förekommer i varje fråga — vanligtvis **tenant_id + tid**. Med tidspartitioner läser en fråga för "senaste 7 dagarna" 7 partitioner och ignorerar de övriga 3 åren. Detta är *partition pruning*: routern eliminerar 99,9% av datan innan något index konsulteras.

## Rätt index / PK-design

Inom en partition måste **primärnyckeln front-loada frågans filterkolumner**. I DynamoDB: partition key = `tenant`, sort key = `timestamp` → range-frågor är O(log n) + sekventiell läsning. I en columnar store som **ClickHouse** låter sorteringsnyckeln (`ORDER BY (tenant, ts)`) motorn hoppa över granules och bara läsa matchande block. Ett covering index undviker extrahämtningen av raden helt.

## Val av store

- **Point lookups, hög skrivning:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-aktigt på nyckel, skalar horisontellt.
- **Analys/aggregat:** columnar (ClickHouse, BigQuery) — läser bara nödvändiga kolumner, vektoriserat.
- **Cacha den heta 1%:en:** Redis framför absorberar upprepade läsningar på <5ms; 10B rader men några miljoner heta nycklar.

## Intervjuperspektiv

Intervjuaren vill se dig säga **"vilka är frågorna?" före "vilken databas?"**. Bra kandidater griper efter index; utmärkta noterar att ett index på 10B rader självt är enormt — så du *partitionerar först för att krympa vad indexet täcker*. Att namnge row-vs-columnar-uppdelningen och cache-nivån signalerar verklig skalerfarenhet.

**Vanlig fälla:** att föreslå ett enda gigantiskt B-tree-index som svaret. Det hjälper point lookups men gör inget för de analytiska scannerna, och dess skrivningar flaskhalsar ingestion.

## Avvägningar & felmoder

- **Fel partition key** = cross-partition scatter-gather, latensen sväller. Välj en nyckel som finns i frågorna.
- **Het partition:** en kändis-tenant överväldigar en shard — lägg till ett salting-suffix.
- **Cache-inaktualitet:** invalidera vid skrivning eller acceptera TTL-lag.
- **Denormaliseringskostnad:** du duplicerar ofta data per åtkomstmönster; lagring är billig, en 10-sekunders fråga är det inte.

Åtkomstmönster styr allt

Partitionering beskär sökrymden

Rätt index / PK-design

Val av store

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor