Si i interrogoni 10 miliardë regjistra nën 100ms?

Question

IT Interview Practice · Accepted Answer

Projektoni së pari për **access pattern**, pastaj zgjidhni partitioning + index/PK-në e duhur që çdo query i vetëm të prekë një pjesë të vogël e të kufizuar — kurrë të mos skanojë 10 miliardë rreshta. Nën-100ms mbi 10 miliardë regjistra nuk ka të bëjë me një disk më të shpejtë; ka të bëjë me ta bërë working set-in i vockël.

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

## Access patterns nxisin gjithçka

Para se të zgjidhni teknologjinë, pyesni: **point lookup apo range/aggregate?** "Merr 20 porositë e fundit të përdoruesit X" është një query point/range — doni që partition dhe sort key të përputhen saktësisht me të. "Mblidh të ardhurat sipas rajonit këtë muaj" është një skanim analitik — një row store është vegla e gabuar. Modelimi i query-t së pari është ajo që ndan një dizajn që funksionon nga një që duket i arsyeshëm por bën full-scan.

## Partitioning pastron hapësirën e kërkimit

Ndani tabelën sipas një key që shfaqet në çdo query — zakonisht **tenant_id + time**. Me time partitions, një query për "7 ditët e fundit" lexon 7 partitions dhe injoron 3 vitet e tjera. Ky është *partition pruning*: router-i eliminon 99.9% të të dhënave para se të konsultohet ndonjë index.

## Dizajni i duhur i index / PK

Brenda një partition, **primary key duhet të vendosë kolonat e filtrit të query-t përpara**. Në DynamoDB: partition key = `tenant`, sort key = `timestamp` → range queries janë O(log n) + lexim sekuencial. Në një columnar store si **ClickHouse**, sorting key (`ORDER BY (tenant, ts)`) lejon engine-in të kapërcejë granulat dhe të lexojë vetëm blloqet që përputhen. Një covering index shmang plotësisht marrjen e rreshtit shtesë.

## Zgjedhja e store-it

- **Point lookups, shkrime të larta:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ish sipas key, shkallëzohet horizontalisht.
- **Analitikë/agregate:** columnar (ClickHouse, BigQuery) — lexon vetëm kolonat e nevojshme, të vektorizuara.
- **Cache 1%-in e nxehtë:** Redis para thith leximet e përsëritura në <5ms; 10 miliardë rreshta por vetëm disa milionë hot keys.

## Këndvështrimi i intervistës

Intervistuesi dëshiron t'ju shohë të thoni **"cilat janë query-t?" para "cila bazë të dhënash?"**. Kandidatët e mirë kapen pas indexes; ata të shkëlqyer vënë re se një index mbi 10 miliardë rreshta është vetë i madh — kështu që *partition-oni së pari për të zvogëluar atë që mbulon index-i*. Emërtimi i ndarjes row-vs-columnar dhe cache tier-it sinjalizon përvojë të vërtetë në shkallë.

**Kurthi i zakonshëm:** propozimi i një B-tree index gjigant si përgjigje. Ndihmon point lookups por nuk bën asgjë për skanimet analitike, dhe shkrimet e tij bëjnë bottleneck ingestion-in.

## Kompromiset & mënyrat e dështimit

- **Partition key i gabuar** = scatter-gather nëpër partitions, latency fryhet. Zgjidhni një key të pranishëm në query-t.
- **Hot partition:** një tenant celebriteti mbyt një shard — shtoni një salting suffix.
- **Cache staleness:** invalidoni në shkrim ose pranoni TTL lag.
- **Kosto e denormalizimit:** shpesh dyfishoni të dhëna për çdo access pattern; magazinimi është i lirë, një query 10-sekondësh nuk është.

Access patterns nxisin gjithçka

Partitioning pastron hapësirën e kërkimit

Dizajni i duhur i index / PK

Zgjedhja e store-it

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme