Kif tagħmel query fuq 10B record taħt 100ms?

Question

IT Interview Practice · Accepted Answer

Iddisinja għall-**access pattern l-ewwel**, imbagħad agħżel il-partitioning + l-index/PK t-tajjeb biex kull query waħda tmiss biċċa żgħira u limitata — qatt ma tagħmel scan ta' 10B row. Sub-100ms fuq 10 biljun record mhux dwar disk aktar mgħaġġel; huwa dwar li tagħmel il-working set żgħir.

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

## L-access patterns imexxu kollox

Qabel ma tagħżel it-teknoloġija, staqsi: **point lookup jew range/aggregate?** "Ġib l-aħħar 20 order tal-utent X" hija point/range query — trid li l-partition u s-sort key jaqblu magħha eżatt. "Somom ir-revenue skont ir-reġjun dan ix-xahar" hija analytical scan — row store huwa l-għodda ħażina. Li tmudella l-query l-ewwel huwa dak li jissepara disinn li jaħdem minn wieħed li jidher raġonevoli imma jagħmel full-scan.

## Il-partitioning inaqqas l-ispazju tat-tfittxija

Aqsam it-table b'key li jidher f'kull query — normalment **tenant_id + time**. B'time partitions, query għal "l-aħħar 7 ijiem" jaqra 7 partitions u jinjora t-3 snin l-oħra. Dan huwa *partition pruning*: ir-router jelimina 99.9% tad-data qabel ma jiġi kkonsultat kwalunkwe index.

## Disinn t-tajjeb ta' index / PK

Fi ħdan partition, il-**primary key irid ipoġġi l-filter columns tal-query quddiem**. F'DynamoDB: partition key = `tenant`, sort key = `timestamp` → range queries huma O(log n) + sequential read. F'columnar store bħal **ClickHouse**, is-sorting key (`ORDER BY (tenant, ts)`) tħalli l-engine jaqbeż granules u jaqra biss blokki li jaqblu. Covering index jevita l-fetch żejjed tar-row għalkollox.

## Għażla tal-store

- **Point lookups, write għoli:** NoSQL key-value (DynamoDB, Cassandra) — kważi O(1) bil-key, jiskala orizzontalment.
- **Analytics/aggregates:** columnar (ClickHouse, BigQuery) — jaqra biss il-columns meħtieġa, vectorized.
- **Ikkaċċja l-hot 1%:** Redis quddiem jassorbi reads ripetuti taħt 5ms; 10B row imma ftit miljuni ta' hot keys.

## Perspettiva tal-intervista

L-intervistatur irid jarak tgħid **"x'inhuma l-queries?" qabel "liema database?"**. Kandidati tajbin jaqbdu l-indexes; l-eċċellenti jinnotaw li index fuq 10B row huwa nnifsu enormi — allura *ippartizzjona l-ewwel biex tnaqqas dak li jkopri l-index*. Li ssemmi l-firda row-vs-columnar u t-tier tal-cache jissinjala esperjenza vera ta' skala.

**Nassa komuni:** li tipproponi index B-tree ġgant wieħed bħala t-tweġiba. Jgħin point lookups imma ma jagħmel xejn għall-analytical scans, u l-writes tiegħu joħolqu bottleneck fl-inġestjoni.

## Trade-offs u modi ta' fallimenti

- **Partition key ħażin** = scatter-gather bejn partitions, il-latenza tikber. Agħżel key preżenti fil-queries.
- **Hot partition:** tenant ċelebri jgħarraq shard wieħed — żid salting suffix.
- **Cache staleness:** invalida fuq write jew aċċetta TTL lag.
- **Kost tad-denormalizzazzjoni:** ħafna drabi tidduplika data għal kull access pattern; il-ħżin huwa rħis, query ta' 10 sekondi mhux.

L-access patterns imexxu kollox

Il-partitioning inaqqas l-ispazju tat-tfittxija

Disinn t-tajjeb ta' index / PK

Għażla tal-store

Perspettiva tal-intervista

Trade-offs u modi ta' fallimenti

Mistoqsijiet relatati