Cum interoghezi 10 miliarde de înregistrări sub 100ms?

Question

IT Interview Practice · Accepted Answer

Proiectează pentru **pattern-ul de acces mai întâi**, apoi alege partiționarea + indexul/PK-ul potrivit, astfel încât orice interogare individuală să atingă o felie mică, delimitată — să nu scaneze niciodată 10B de rânduri. Sub-100ms peste 10 miliarde de înregistrări nu înseamnă un disc mai rapid; înseamnă să faci working set-ul minuscul.

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

## Pattern-urile de acces determină totul

Înainte de a alege tehnologia, întreabă: **point lookup sau range/agregat?** "Ia ultimele 20 de comenzi ale utilizatorului X" este o interogare point/range — vrei ca partiția și cheia de sortare să se potrivească exact cu ea. "Însumează veniturile pe regiune luna aceasta" este un scan analitic — un row store este unealta greșită. Modelarea interogării mai întâi este ceea ce separă un design care funcționează de unul care pare rezonabil, dar face full-scan.

## Partiționarea reduce spațiul de căutare

Împarte tabela după o cheie care apare în fiecare interogare — de obicei **tenant_id + timp**. Cu partiții de timp, o interogare pentru "ultimele 7 zile" citește 7 partiții și le ignoră pe celelalte 3 ani. Aceasta este *partition pruning*: router-ul elimină 99,9% din date înainte de a consulta vreun index.

## Design corect al indexului / PK-ului

În cadrul unei partiții, **cheia primară trebuie să pună în față coloanele de filtrare ale interogării**. În DynamoDB: partition key = `tenant`, sort key = `timestamp` → interogările pe range sunt O(log n) + citire secvențială. Într-un columnar store precum **ClickHouse**, cheia de sortare (`ORDER BY (tenant, ts)`) permite motorului să sară peste granule și să citească doar blocurile care se potrivesc. Un index covering evită complet fetch-ul suplimentar de rând.

## Alegerea store-ului

- **Point lookups, scriere intensă:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish după cheie, scalează orizontal.
- **Analytics/agregate:** columnar (ClickHouse, BigQuery) — citește doar coloanele necesare, vectorizat.
- **Pune în cache cei 1% fierbinți:** Redis în față absoarbe citirile repetate la <5ms; 10B de rânduri, dar câteva milioane de chei fierbinți.

## Perspectiva de interviu

Intervievatorul vrea să te vadă spunând **"care sunt interogările?" înainte de "ce bază de date?"**. Candidații buni apelează la indecși; cei excelenți observă că un index pe 10B de rânduri este el însuși uriaș — așa că *partiționezi mai întâi pentru a micșora ce acoperă indexul*. A numi separarea row-vs-columnar și tier-ul de cache semnalează experiență reală la scară.

**Capcană obișnuită:** a propune un singur index B-tree gigantic ca răspuns. Ajută la point lookups, dar nu face nimic pentru scanurile analitice, iar scrierile lui devin blocaj la ingestie.

## Compromisuri și moduri de eșec

- **Cheie de partiție greșită** = scatter-gather între partiții, latența explodează. Alege o cheie prezentă în interogări.
- **Partiție fierbinte:** un tenant-celebritate copleșește un shard — adaugă un sufix de salting.
- **Cache învechit:** invalidează la scriere sau acceptă decalajul de TTL.
- **Costul denormalizării:** adesea duplici date per pattern de acces; stocarea este ieftină, o interogare de 10 secunde nu este.

Pattern-urile de acces determină totul

Partiționarea reduce spațiul de căutare

Design corect al indexului / PK-ului

Alegerea store-ului

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe