Ukládání a dotazování historie transakcí pro stovky milionů účtů

Question

IT Interview Practice · Accepted Answer

**Partitionujte účetní knihu (ledger) podle účtu a času, držte nedávná data hot a stará cold a berte řádky jako append-only neměnnou účetní knihu — takže historie jednoho účtu je malý indexovaný výřez, nikdy sken miliard řádků.** Přístupový vzor je vždy „jeden účet, rozsah dat“, takže partitionujte tak, aby mu odpovídal.

## Architektura

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

## Jak to funguje

- **Partitionování podle účtu + času.** Zahashujte id účtu do N bucketů, pak range-partitionujte podle měsíce. Dotaz na jeden účet/měsíc zasáhne přesně jeden partition — DB zbytek prořízne. To ohraničuje každé čtení bez ohledu na celkovou velikost.
- **Neměnná účetní kniha.** Nikdy neděláte `UPDATE` transakce; opravy jsou nové storno řádky. To dává audit trail, bezpečnou replikaci a umožňuje agresivní caching (řádky se nikdy nemění).
- **Hot/cold tiering.** Držte poslední ~3 měsíce na rychlém SSD/Postgresu pro nízkou latenci čtení; starší partitiony rolujte do **S3/Parquet** (dotazovaného přes Athena/Trino) nebo Glacier. 95 % dotazů zasáhne nedávná data, takže většina úložiště může být levná.
- **Keyset stránkování.** Stránkujte pomocí `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — ne `OFFSET`. Offset skenuje a zahazuje přeskočené řádky; keyset se zanoří do indexu přímo, O(1) na stránku.

## Pohled z pohovoru

Tazatel zkoumá **volbu partition key** a **stránkování**. Dobré odpovědi říkají „partitionuj podle účtu“; skvělé vysvětlí, **proč keyset poráží OFFSET** u hlubokých stránek, proč je **ledger neměnný** (auditovatelnost, žádná lock contention) a jak **tiering** snižuje náklady. Pastí je jedna obří tabulka s kompozitním indexem — funguje, dokud se index nevejde do RAM, a pak se každé čtení stane disk-bound.

## Kompromisy a selhání

- **Partition key se těžko mění.** Volte účet+čas dopředu; přepartitionování stovek milionů řádků později je migrační projekt.
- **Cross-account dotazy trpí.** „Celkový objem napříč všemi účty“ se teď rozvětví napříč partitiony — ty tlačte do OLAP rollupu.
- **Cold čtení jsou pomalá.** Načtení 3 roky starého výpisu z Glacieru trvá minuty; nastavte očekávání uživatele nebo předehřejte na vyžádání.
- **Hot partitiony.** Velrybí účet nebo aktuální měsíc mohou být hotspot; sub-partitionujte nebo nacachujte.
- **Kdy ne:** miliony řádků (ne stovky milionů) se vejdou do jedné indexované Postgres tabulky — nestavte tiering, který nepotřebujete. Sáhněte po tomto v měřítku, kdy se index jedné tabulky přestane vejít do paměti.

Architektura

Jak to funguje

Pohled z pohovoru

Kompromisy a selhání

Související otázky