数億アカウントのトランザクション履歴を保存・クエリする

Question

IT Interview Practice · Accepted Answer

**台帳をアカウントと時間でパーティション分割し、最近のデータをホットに古いデータをコールドに保ち、行を追記専用の不変な台帳として扱います。こうすれば単一アカウントの履歴は小さくインデックスされたスライスになり、決して数十億行のスキャンにはなりません。** アクセスパターンは常に「1アカウント、日付範囲」なので、それに合わせてパーティション分割します。

## アーキテクチャ

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

## 仕組み

- **アカウント + 時間でパーティション分割。** アカウントidをNバケットにハッシュし、次に月でレンジパーティション分割します。1アカウント/月のクエリは正確に1パーティションに当たり、DBが残りを刈り込みます。これで総サイズに関わらずすべての読み取りが境界内に収まります。
- **不変な台帳。** トランザクションを決して `UPDATE` しません。修正は新しい逆仕訳行です。これで監査証跡、安全なレプリケーションが得られ、積極的にキャッシュできます（行は決して変わらない）。
- **ホット/コールド階層化。** 低レイテンシ読み取りのため直近約3か月を高速SSD/Postgresに保ち、古いパーティションを**S3/Parquet**（Athena/Trino経由でクエリ）やGlacierへ移します。95%のクエリは最近のデータに当たるので、大半のストレージは安価で済みます。
- **キーセットページネーション。** `OFFSET` ではなく `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` でページングします。OFFSETはスキップした行をスキャンして破棄しますが、キーセットはインデックスを直接シークし、ページあたりO(1)です。

## 面接での観点

面接官は**パーティションキーの選択**と**ページネーション**を探ります。良い回答は「アカウントでパーティション分割」と言います。優れた回答は、深いページで**なぜキーセットがOFFSETに勝つか**、なぜ**台帳が不変か**（監査性、ロック競合なし）、そして**階層化**がどうコストを削るかを説明します。罠は、複合インデックスを持つ単一の巨大テーブルです。インデックスがRAMに収まらなくなり、すべての読み取りがディスク律速になるまでは動きます。

## トレードオフと障害

- **パーティションキーは変更が困難。** アカウント + 時間を最初に選ぶこと。後で数億行を再パーティション分割するのは移行プロジェクトです。
- **クロスアカウントクエリが苦しむ。** 「全アカウントの総取引量」はパーティションにファンアウトします。それらはOLAPのロールアップに押し出します。
- **コールド読み取りは遅い。** Glacierから3年前の明細を取得するのに数分かかります。ユーザーの期待を設定するか、リクエスト時に事前ウォーム。
- **ホットパーティション。** 大口アカウントや当月がホットスポットになりえます。サブパーティション化するかキャッシュします。
- **不要な場合：** 数百万行（数億行ではない）は1つのインデックス付きPostgresテーブルに収まります。必要のない階層化を作らないこと。単一テーブルのインデックスがメモリに収まらなくなる規模で手を伸ばします。

アーキテクチャ

仕組み

面接での観点

トレードオフと障害

関連する質問