Lưu & truy vấn lịch sử giao dịch cho hàng trăm triệu tài khoản

Question

IT Interview Practice · Accepted Answer

**Partition sổ cái theo tài khoản và thời gian, giữ dữ liệu gần đây ở tier nóng và dữ liệu cũ ở tier lạnh, và coi mỗi dòng là ledger append-only bất biến — nhờ đó lịch sử của một tài khoản là một lát nhỏ có index, không bao giờ phải quét hàng tỷ dòng.** Mẫu truy cập luôn là "một tài khoản, một khoảng ngày", nên partition khớp đúng nó.

## Kiến trúc

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

## Cách hoạt động

- **Partition theo account + thời gian.** Hash account id vào N bucket, rồi range-partition theo tháng. Query một account/tháng chạm đúng một partition — DB tỉa (prune) phần còn lại. Điều này chặn trên chi phí mỗi read bất kể tổng kích thước.
- **Ledger bất biến.** Không bao giờ `UPDATE` một giao dịch; sửa sai là thêm dòng đảo (reversing). Cho ra audit trail, replicate an toàn, và cache thoải mái (dòng không đổi).
- **Phân tier nóng/lạnh.** Giữ ~3 tháng gần nhất trên SSD/Postgres nhanh để read độ trễ thấp; đẩy partition cũ sang **S3/Parquet** (truy vấn qua Athena/Trino) hoặc Glacier. 95% query chạm dữ liệu gần đây, nên phần lớn storage có thể rẻ.
- **Keyset pagination.** Phân trang bằng `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — không dùng `OFFSET`. Offset quét rồi vứt các dòng bỏ qua; keyset seek thẳng vào index, O(1) mỗi trang.

## Góc nhìn phỏng vấn

Người phỏng vấn dò **chọn partition key** và **pagination**. Câu trả lời khá nói "partition theo account"; câu xuất sắc giải thích **vì sao keyset thắng OFFSET** ở trang sâu, vì sao **ledger bất biến** (audit được, không tranh khoá), và **tiering** cắt chi phí ra sao. Bẫy là một bảng khổng lồ duy nhất với composite index — chạy tốt cho tới khi index không còn vừa RAM và mọi read thành disk-bound.

## Đánh đổi & lỗi

- **Partition key khó đổi.** Chọn account+time từ đầu; re-partition hàng trăm triệu dòng về sau là cả một dự án migration.
- **Query xuyên tài khoản chịu thiệt.** "Tổng volume của mọi tài khoản" giờ fan-out qua các partition — đẩy sang một OLAP rollup thay vì vậy.
- **Cold read chậm.** Lấy sao kê 3 năm trước từ Glacier mất vài phút; đặt kỳ vọng cho user hoặc pre-warm khi có yêu cầu.
- **Hot partition.** Một tài khoản "cá voi" hoặc tháng hiện tại có thể thành điểm nóng; sub-partition hoặc cache nó.
- **Khi nào không dùng:** vài triệu dòng (không phải hàng trăm triệu) vừa trong một bảng Postgres có index — đừng xây tiering bạn chưa cần. Chỉ dùng ở quy mô mà index của một bảng thôi cũng không còn vừa RAM.

Kiến trúc

Cách hoạt động

Góc nhìn phỏng vấn

Đánh đổi & lỗi

Câu hỏi liên quan