Come interroghi 10B di record sotto i 100ms?

Question

IT Interview Practice · Accepted Answer

Progetta prima per il **pattern di accesso**, poi scegli il partitioning + l'index/PK giusto così che ogni singola query tocchi una fetta piccola e limitata — mai uno scan di 10B di righe. Sotto i 100ms su 10 miliardi di record non si tratta di un disco più veloce; si tratta di rendere minuscolo il working set.

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

## I pattern di accesso guidano tutto

Prima di scegliere la tecnologia, chiediti: **point lookup o range/aggregate?** "Prendi gli ultimi 20 ordini dell'utente X" è una query point/range — vuoi che partition key e sort key la assecondino esattamente. "Somma il fatturato per regione questo mese" è uno scan analitico — un row store è lo strumento sbagliato. Modellare prima la query è ciò che separa un design che funziona da uno che sembra ragionevole ma fa full-scan.

## Il partitioning riduce lo spazio di ricerca

Suddividi la tabella per una chiave che compare in ogni query — di solito **tenant_id + time**. Con partizioni temporali, una query per "ultimi 7 giorni" legge 7 partizioni e ignora gli altri 3 anni. Questo è il *partition pruning*: il router elimina il 99,9% dei dati prima ancora di consultare un index.

## Design corretto di index / PK

All'interno di una partizione, la **primary key deve mettere in testa le colonne di filtro della query**. In DynamoDB: partition key = `tenant`, sort key = `timestamp` → le range query sono O(log n) + lettura sequenziale. In un columnar store come **ClickHouse**, la sorting key (`ORDER BY (tenant, ts)`) permette al motore di saltare i granuli e leggere solo i blocchi corrispondenti. Un covering index evita del tutto il fetch aggiuntivo della riga.

## Scelta dello store

- **Point lookup, alta scrittura:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish per chiave, scala orizzontalmente.
- **Analytics/aggregati:** columnar (ClickHouse, BigQuery) — legge solo le colonne necessarie, vettorizzato.
- **Metti in cache l'1% caldo:** Redis davanti assorbe le letture ripetute a <5ms; 10B di righe ma pochi milioni di chiavi calde.

## Prospettiva del colloquio

L'intervistatore vuole vederti dire **"quali sono le query?" prima di "quale database?"**. I buoni candidati ricorrono agli index; gli eccellenti notano che un index su 10B di righe è esso stesso enorme, quindi *partizioni prima per ridurre ciò che l'index copre*. Nominare la divisione row-vs-columnar e il tier di cache segnala vera esperienza di scala.

**Trappola comune:** proporre un unico gigantesco B-tree index come risposta. Aiuta i point lookup ma non fa nulla per gli scan analitici, e le sue scritture creano un collo di bottiglia sull'ingestione.

## Compromessi e modalità di guasto

- **Partition key sbagliata** = scatter-gather cross-partition, la latenza esplode. Scegli una chiave presente nelle query.
- **Partizione calda:** un tenant celebrità sopraffà uno shard — aggiungi un suffisso di salting.
- **Cache stale:** invalida in scrittura o accetta il lag del TTL.
- **Costo della denormalizzazione:** spesso duplichi i dati per pattern di accesso; lo storage è economico, una query da 10 secondi no.

I pattern di accesso guidano tutto

Il partitioning riduce lo spazio di ricerca

Design corretto di index / PK

Scelta dello store

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate