Simpan & query sejarah transaksi untuk beratus juta akaun

Question

IT Interview Practice · Accepted Answer

**Partition ledger mengikut akaun dan masa, kekalkan data terkini panas dan data lama sejuk, dan layan baris sebagai append-only immutable ledger — supaya sejarah satu akaun ialah kepingan kecil yang terindeks, tidak pernah imbasan berbilion baris.** Access pattern sentiasa "satu akaun, satu julat tarikh", jadi partition untuk sepadan dengannya.

## Seni bina

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

## Cara ia berfungsi

- **Partition mengikut akaun + masa.** Hash id akaun ke dalam N bucket, kemudian range-partition mengikut bulan. Sebuah query untuk satu akaun/bulan mengenai tepat satu partition — DB menyunting yang selebihnya. Ini membataskan setiap bacaan tanpa mengira saiz keseluruhan.
- **Immutable ledger.** Jangan sekali-kali `UPDATE` transaksi; pembetulan ialah baris pembalikan (reversing rows) baharu. Ini memberi jejak audit, replication yang selamat, dan membenarkan anda cache secara agresif (baris tidak pernah berubah).
- **Hot/cold tiering.** Kekalkan ~3 bulan terakhir pada SSD/Postgres pantas untuk bacaan latency rendah; gulingkan partition lebih lama ke **S3/Parquet** (di-query melalui Athena/Trino) atau Glacier. 95% query mengenai data terkini, jadi kebanyakan storan boleh murah.
- **Keyset pagination.** Halaman dengan `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — bukan `OFFSET`. Offset mengimbas dan membuang baris yang dilangkau; keyset menuju index secara terus, O(1) setiap halaman.

## Perspektif temu duga

Penemu duga menyiasat **pilihan partition key** dan **pagination**. Jawapan yang baik berkata "partition mengikut akaun"; jawapan yang hebat menerangkan **mengapa keyset mengalahkan OFFSET** pada halaman dalam, mengapa **ledger adalah immutable** (kebolehauditan, tiada pertikaian lock), dan cara **tiering** memotong kos. Perangkapnya ialah satu jadual gergasi tunggal dengan composite index — ia berfungsi sehingga index tidak lagi muat dalam RAM dan setiap bacaan menjadi terikat-disk.

## Pertukaran & mod kegagalan

- **Partition key sukar diubah.** Pilih akaun+masa di hadapan; me-repartition beratus juta baris kemudian ialah projek migrasi.
- **Query rentas akaun menderita.** "Jumlah volum merentas semua akaun" kini fan out merentas partition — tolak itu ke rollup OLAP sebaliknya.
- **Bacaan sejuk perlahan.** Mengambil penyata 3 tahun lalu dari Glacier mengambil masa beberapa minit; tetapkan jangkaan pengguna atau pre-warm atas permintaan.
- **Partition panas.** Sebuah akaun besar (whale) atau bulan semasa boleh menjadi hotspot; sub-partition atau cache ia.
- **Bila jangan:** jutaan baris (bukan beratus juta) muat dalam satu jadual Postgres terindeks — jangan bina tiering yang anda tidak perlukan. Gapai ini pada skala di mana index satu jadual berhenti muat dalam memori.

Seni bina

Cara ia berfungsi

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan