为数亿个账户存储与查询交易历史

Question

为数亿个账户存储与查询交易历史

IT Interview Practice · Accepted Answer

**按账户和时间对账本（ledger）分区，让近期数据保持热、旧数据变冷，并把行视为只追加的不可变账本——这样单个账户的历史就是一个小而有 index 的切片，绝不是对数十亿行的扫描。**访问模式永远是"一个账户，一个日期范围"，所以分区要与之匹配。

## 架构

```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 个桶，再按月做 range 分区。对一个账户/一个月的查询恰好命中一个 partition——DB 裁剪掉其余部分。无论总量多大，这都为每次读取设定了上界。
- **不可变账本。**绝不 `UPDATE` 一笔交易；更正是新的冲销行（reversing row）。这带来审计轨迹、安全的复制，并让你能激进地缓存（行从不改变）。
- **冷热分层。**把最近约 3 个月放在快速的 SSD/Postgres 上以实现低 latency 读；把较旧的 partition 滚动到 **S3/Parquet**（通过 Athena/Trino 查询）或 Glacier。95% 的查询命中近期数据，因此大部分存储可以很便宜。
- **Keyset 分页。**用 `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` 翻页——而非 `OFFSET`。offset 会扫描并丢弃跳过的行；keyset 直接寻址 index，每页 O(1)。

## 面试视角

面试官考察 **partition key 的选择**和**分页**。好的回答说"按账户分区"；出色的回答会解释在深页时**为什么 keyset 胜过 OFFSET**、为什么**账本是不可变的**（可审计性、无锁争用），以及**分层**如何削减成本。一个陷阱是用带组合 index 的单张巨表——它能用，直到 index 不再装得进 RAM，每次读都变成磁盘受限（disk-bound）。

## 权衡与故障

- **Partition key 难以更改。**预先选定账户+时间；日后对数亿行重新分区是一个迁移工程。
- **跨账户查询会吃亏。**"所有账户的总交易量"现在要跨 partition 扇出——把这类查询改推给 OLAP rollup。
- **冷读很慢。**从 Glacier 取一份 3 年前的对账单需要数分钟；设定用户预期或按请求预热。
- **热点 partition。**一个巨鲸账户或当前月份可能成为热点；对它再分区（sub-partition）或缓存。
- **何时不该用：**数百万行（而非数亿行）能装进一张有 index 的 Postgres 表——不要构建你用不上的分层。当单张表的 index 不再能装进内存的规模时，才求助于此。

架构

工作原理

面试视角

权衡与故障

相关问题