Tranzakciótörténet tárolása és lekérdezése több százmillió számlához

Question

IT Interview Practice · Accepted Answer

**Partícionáld a főkönyvet számla és idő szerint, tartsd a friss adatot forrón és a régit hidegen, és kezeld a sorokat append-only megváltoztathatatlan főkönyvként — így egy számla története egy kicsi, indexelt szelet, sosem milliárd sor szkenje.** A hozzáférési minta mindig "egy számla, egy dátumtartomány", ezért partícionálj ehhez illeszkedve.

## Architektúra

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Hogyan működik

- **Partícionálj számla + idő szerint.** Hasheld a számla id-t N vödörbe, majd range-partícionálj hónap szerint. Egy egy számla/hónap lekérdezés pontosan egy partíciót ér — a DB lemetszi a többit. Ez korlátozza minden olvasást a teljes mérettől függetlenül.
- **Megváltoztathatatlan főkönyv.** Sose `UPDATE`-elj egy tranzakciót; a javítások új sztornó sorok. Ez audit nyomvonalat, biztonságos replikációt ad, és lehetővé teszi az agresszív cache-elést (a sorok sosem változnak).
- **Forró/hideg rétegzés.** Tartsd az utolsó ~3 hónapot gyors SSD-n/Postgresen az alacsony latenciájú olvasásokhoz; jártasd a régebbi partíciókat **S3/Parquetbe** (Athenán/Trinón át lekérdezve) vagy Glacierbe. A lekérdezések 95%-a friss adatot ér, így a tárhely nagy része lehet olcsó.
- **Keyset lapozás.** Lapozz `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50`-nel — ne `OFFSET`-tel. Az offset szkenneli és eldobja a kihagyott sorokat; a keyset közvetlenül az indexre keres, O(1) oldalanként.

## Interjú szemszög

Az interjúztató a **partíciós kulcs választását** és a **lapozást** vizsgálja. A jó válaszok azt mondják "partícionálj számla szerint"; a kiváló válaszok megmagyarázzák, **miért veri a keyset az OFFSET-et** mély oldalaknál, miért **megváltoztathatatlan a főkönyv** (auditálhatóság, nincs lock-versengés), és hogyan **csökkenti a költséget a rétegzés**. Csapda egy óriási tábla egy összetett indexszel — működik, amíg az index már nem fér a RAM-ba és minden olvasás lemez-korlátossá válik.

## Kompromisszumok és hibák

- **A partíciós kulcs nehezen változtatható.** Válaszd a számla+időt előre; több százmillió sor újrapartícionálása később migrációs projekt.
- **A cross-account lekérdezések szenvednek.** A "teljes volumen minden számlán át" most partíciók között fan-outol — told ezeket inkább egy OLAP rollupba.
- **A hideg olvasások lassúak.** Egy 3 éves kivonat lekérése a Glacierből percekbe telik; állítsd be a felhasználói elvárásokat vagy melegíts elő igényre.
- **Forró partíciók.** Egy bálna-számla vagy az aktuális hónap hotspot lehet; sub-partícionálj vagy cache-eld.
- **Mikor ne:** milliónyi sor (nem több százmillió) elfér egy indexelt Postgres táblában — ne építs olyan rétegzést, amire nem lesz szükséged. Nyúlj ehhez azon a méreten, ahol egy tábla indexe már nem fér a memóriába.

Architektúra

Hogyan működik

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések