Hogyan kérdezel le 10 milliárd rekordot 100ms alatt?

Question

IT Interview Practice · Accepted Answer

Tervezz **először a hozzáférési mintára**, majd válaszd meg a partícionálást + a megfelelő indexet/PK-t, hogy bármely egyedi lekérdezés egy kicsi, korlátozott szeletet érintsen — soha ne szkenneljen 10 milliárd sort. A 100ms alatti válasz 10 milliárd rekord felett nem gyorsabb lemezről szól; arról szól, hogy a working set apró legyen.

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

## A hozzáférési minták vezérelnek mindent

A technológia kiválasztása előtt kérdezd meg: **pontkeresés vagy tartomány/aggregáció?** A "kérd le X felhasználó utolsó 20 rendelését" egy pont/tartomány lekérdezés — azt akarod, hogy a partíció és a sort key pontosan ehhez illeszkedjen. A "összegezd a bevételt régiónként ebben a hónapban" egy analitikai szken — egy sortároló rossz eszköz erre. A lekérdezés elsődleges modellezése különbözteti meg a működő tervezést attól, amelyik ésszerűnek tűnik de teljes szkent végez.

## A partícionálás lemetszi a keresési teret

Oszd fel a táblát egy olyan kulcs szerint, amely minden lekérdezésben megjelenik — általában **tenant_id + idő**. Idő-partíciókkal egy "utolsó 7 nap" lekérdezés 7 partíciót olvas és figyelmen kívül hagyja a másik 3 évet. Ez a *partition pruning*: a router kiiktatja az adatok 99,9%-át, mielőtt bármely indexet megnéznének.

## Helyes index / PK tervezés

Egy partíción belül az **elsődleges kulcsnak elöl kell hoznia a lekérdezés szűrőoszlopait**. A DynamoDB-ben: partíciós kulcs = `tenant`, sort key = `timestamp` → a tartomány-lekérdezések O(log n) + szekvenciális olvasás. Egy oszlopos tárolóban, mint a **ClickHouse**, a sorting key (`ORDER BY (tenant, ts)`) lehetővé teszi, hogy a motor átugorjon granule-öket és csak illeszkedő blokkokat olvasson. Egy covering index teljesen elkerüli az extra sor-fetchet.

## Tárolóválasztás

- **Pontkeresések, magas írás:** NoSQL kulcs-érték (DynamoDB, Cassandra) — O(1)-szerű kulcs szerint, horizontálisan skálázódik.
- **Analitika/aggregációk:** oszlopos (ClickHouse, BigQuery) — csak a szükséges oszlopokat olvassa, vektorizált.
- **Cache-eld a forró 1%-ot:** egy Redis elöl felszívja az ismétlődő olvasásokat <5ms alatt; 10 milliárd sor de néhány millió forró kulcs.

## Interjú szemszög

Az interjúztató azt akarja látni, hogy azt mondod **"mik a lekérdezések?" a "melyik adatbázis?" előtt**. A jó jelöltek indexekért nyúlnak; a kiválók megjegyzik, hogy egy index 10 milliárd soron maga is hatalmas — ezért *először partícionálsz, hogy csökkentsd, amit az index lefed*. A sor-vs-oszlopos felosztás és a cache réteg megnevezése valódi méret-tapasztalatot jelez.

**Gyakori csapda:** egyetlen óriási B-tree indexet javasolni válaszként. Segít a pontkereséseknél de semmit nem tesz az analitikai szkeneknél, és az írásai szűk keresztmetszetet okoznak a beolvasásban.

## Kompromisszumok és hibamódok

- **Rossz partíciós kulcs** = cross-partition scatter-gather, a latencia felfúvódik. Válassz a lekérdezésekben jelen lévő kulcsot.
- **Forró partíció:** egy híresség-tenant túlterhel egy shardot — adj hozzá salting utótagot.
- **Cache állottság:** invalidálj íráskor vagy fogadd el a TTL lemaradást.
- **Denormalizációs költség:** gyakran duplikálsz adatot hozzáférési mintánként; a tárhely olcsó, egy 10 másodperces lekérdezés nem.

A hozzáférési minták vezérelnek mindent

A partícionálás lemetszi a keresési teret

Helyes index / PK tervezés

Tárolóválasztás

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések