Tallenna ja kysele transaktiohistoria sadoille miljoonille tileille

Question

IT Interview Practice · Accepted Answer

**Partitioi ledger tilin ja ajan mukaan, pidä tuore data kuumana ja vanha kylmänä, ja kohtele rivejä append-only-muuttumattomana ledgerinä — jotta yhden tilin historia on pieni, indeksoitu siivu, ei koskaan miljardien rivien skannaus.** Pääsykuvio on aina "yksi tili, päivämääräväli", joten partitioi vastaamaan sitä.

## Arkkitehtuuri

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

## Miten se toimii

- **Partitioi tilin + ajan mukaan.** Hashaa tilin id N buckettiin, sitten range-partitioi kuukauden mukaan. Kysely yhdelle tilille/kuukaudelle osuu täsmälleen yhteen partitioon — DB karsii loput. Tämä rajaa jokaisen luvun kokonaiskoosta riippumatta.
- **Muuttumaton ledger.** Älä koskaan `UPDATE`-tee transaktiota; korjaukset ovat uusia peruuttavia rivejä. Tämä antaa audit-jäljen, turvallisen replikoinnin ja sallii aggressiivisen cachauksen (rivit eivät koskaan muutu).
- **Kuuma/kylmä-tiering.** Pidä viimeiset ~3 kuukautta nopealla SSD:llä/Postgresissa matalan latenssin lukemisille; rullaa vanhemmat partitiot **S3:een/Parquetiin** (kyseltynä Athenan/Trinon kautta) tai Glacieriin. 95 % kyselyistä osuu tuoreeseen dataan, joten suurin osa tallennuksesta voi olla halpaa.
- **Keyset-sivutus.** Sivuta `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50`:llä — ei `OFFSET`:lla. Offset skannaa ja hylkää ohitetut rivit; keyset hakee indeksistä suoraan, O(1) per sivu.

## Haastattelunäkökulma

Haastattelija tutkii **partitioavaimen valintaa** ja **sivutusta**. Hyvät vastaukset sanovat "partitioi tilin mukaan"; loistavat vastaukset selittävät **miksi keyset voittaa OFFSET:n** syvillä sivuilla, miksi **ledger on muuttumaton** (auditoitavuus, ei lukkokilpailua) ja miten **tiering** leikkaa kustannusta. Ansa on yksittäinen jättitaulu komposiitti-indeksillä — se toimii, kunnes indeksi ei enää mahdu RAM:iin ja jokainen luku muuttuu levy-sidonnaiseksi.

## Kompromissit ja virhetilanteet

- **Partitioavain on vaikea muuttaa.** Valitse tili+aika etukäteen; satojen miljoonien rivien uudelleenpartitiointi myöhemmin on migraatioprojekti.
- **Cross-account-kyselyt kärsivät.** "Kokonaisvolyymi kaikkien tilien yli" leviää nyt partitioiden yli — työnnä ne OLAP-rollupiin sen sijaan.
- **Kylmät lukemiset ovat hitaita.** 3 vuotta vanhan tiliotteen hakeminen Glacieristä kestää minuutteja; aseta käyttäjäodotukset tai lämmittele pyynnöstä.
- **Kuumat partitiot.** Valas-tili tai kuluva kuukausi voi olla hotspot; ali-partitioi tai cachea se.
- **Milloin ei:** miljoonat rivit (ei satoja miljoonia) mahtuvat yhteen indeksoituun Postgres-tauluun — älä rakenna tieringiä, jota et tarvitse. Tartu tähän siinä mittakaavassa, jossa yksittäisen taulun indeksi lakkaa mahtumasta muistiin.

Arkkitehtuuri

Miten se toimii

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset