Pohrana i upitivanje povijesti transakcija za stotine milijuna računa

Question

IT Interview Practice · Accepted Answer

**Particionirajte knjigu (ledger) po računu i vremenu, držite nedavne podatke vrućima a stare hladnima i tretirajte retke kao append-only nepromjenjivu knjigu — tako da je povijest jednog računa mali, indeksirani isječak, nikad skeniranje milijardi redaka.** Obrazac pristupa uvijek je "jedan račun, raspon datuma", pa particionirajte da mu se poklopi.

## Arhitektura

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

## Kako funkcionira

- **Particioniranje po računu + vremenu.** Hashirajte account id u N bucketa, zatim range-particionirajte po mjesecu. Upit za jedan račun/mjesec pogađa točno jednu particiju — baza pruna ostale. To ograničava svako čitanje bez obzira na ukupnu veličinu.
- **Nepromjenjiva knjiga.** Nikada ne radite `UPDATE` transakcije; ispravci su novi reverzirajući retci. To daje audit trail, sigurnu replikaciju i omogućuje agresivno cachiranje (retci se nikad ne mijenjaju).
- **Hot/cold slojevanje.** Držite zadnja ~3 mjeseca na brzom SSD/Postgresu za nisku latenciju čitanja; kotrljajte starije particije u **S3/Parquet** (upitivano preko Athene/Trina) ili Glacier. 95% upita pogađa nedavne podatke, pa većina pohrane može biti jeftina.
- **Keyset paginacija.** Straničite s `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — ne `OFFSET`. Offset skenira i odbacuje preskočene retke; keyset traži izravno u indeksu, O(1) po stranici.

## Perspektiva intervjua

Ispitivač ispituje **izbor particijskog ključa** i **paginaciju**. Dobri odgovori kažu "particioniraj po računu"; odlični objašnjavaju **zašto keyset pobjeđuje OFFSET** na dubokim stranicama, zašto je **knjiga nepromjenjiva** (mogućnost audita, bez borbe za zaključavanje) i kako **slojevanje** smanjuje trošak. Zamka je jedna divovska tablica s kompozitnim indeksom — radi dok indeks ne prestane stati u RAM i svako čitanje postane vezano za disk.

## Kompromisi i neuspjesi

- **Particijski ključ je teško promijeniti.** Odaberite račun+vrijeme unaprijed; ponovno particioniranje stotina milijuna redaka kasnije je migracijski projekt.
- **Cross-account upiti pate.** "Ukupni volumen preko svih računa" sada se fana preko particija — gurnite to u OLAP rollup umjesto toga.
- **Cold čitanja su spora.** Dohvaćanje izvatka starog 3 godine iz Glaciera traje minutama; postavite očekivanja korisnika ili pripremite (pre-warm) na zahtjev.
- **Vruće particije.** Račun-kit ili tekući mjesec mogu biti hotspot; sub-particionirajte ili cachirajte.
- **Kada ne:** milijuni redaka (ne stotine milijuna) stanu u jednu indeksiranu Postgres tablicu — ne gradite slojevanje koje vam neće trebati. Posegnite za ovim na skali gdje indeks jedne tablice prestane stati u memoriju.

Arhitektura

Kako funkcionira

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja