수억 개의 계정에 대한 거래 내역을 저장하고 쿼리하십시오

Question

IT Interview Practice · Accepted Answer

**원장(ledger)을 계정과 시간으로 파티셔닝하고, 최근 데이터는 hot하게 오래된 데이터는 cold하게 유지하며, row를 append-only immutable ledger로 취급하십시오 — 그러면 단일 계정의 내역이 수십억 row 스캔이 아니라 작고 인덱싱된 슬라이스가 됩니다.** 접근 패턴은 항상 "한 계정, 날짜 범위"이므로 그것에 맞게 파티셔닝하십시오.

## 아키텍처

```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개 버킷으로 hash한 뒤 월별로 range-partition하십시오. 한 계정/월 쿼리는 정확히 하나의 partition을 치고 — DB가 나머지를 가지칩니다. 이는 전체 크기와 무관하게 모든 read를 제한합니다.
- **Immutable ledger.** 트랜잭션을 절대 `UPDATE`하지 마십시오. 정정은 새로운 반대(reversing) row입니다. 이는 감사 추적, 안전한 복제를 제공하고, row가 절대 변하지 않으므로 공격적으로 캐시할 수 있게 합니다.
- **Hot/cold 계층화.** 최근 약 3개월은 저지연 read를 위해 빠른 SSD/Postgres에 유지하고, 오래된 partition은 **S3/Parquet**(Athena/Trino로 쿼리)나 Glacier로 넘기십시오. 쿼리의 95%가 최근 데이터를 치므로 대부분의 저장소는 저렴할 수 있습니다.
- **Keyset 페이지네이션.** `OFFSET`이 아니라 `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50`으로 페이징하십시오. offset은 건너뛴 row를 스캔하고 버리지만, keyset은 인덱스를 직접 seek합니다 — 페이지당 O(1).

## 면접 관점

면접관은 **partition key 선택**과 **페이지네이션**을 파고듭니다. 좋은 답변은 "계정으로 파티셔닝한다"이고, 훌륭한 답변은 깊은 페이지에서 **왜 keyset이 OFFSET보다 나은지**, **왜 ledger가 immutable한지**(감사 가능성, lock 경합 없음), 그리고 **계층화**가 비용을 줄이는 법을 설명합니다. 함정은 composite index를 가진 하나의 거대한 테이블입니다 — 인덱스가 더 이상 RAM에 맞지 않아 모든 read가 disk-bound가 될 때까지는 작동합니다.

## 트레이드오프 및 실패

- **Partition key는 바꾸기 어렵다.** 계정+시간을 미리 고르십시오. 나중에 수억 row를 재파티셔닝하는 것은 마이그레이션 프로젝트입니다.
- **Cross-account 쿼리가 어렵다.** "모든 계정의 총 거래량"은 이제 partition 간 팬아웃합니다 — 그런 것은 OLAP rollup으로 밀어내십시오.
- **Cold read는 느리다.** Glacier에서 3년 된 명세서를 가져오는 데 몇 분이 걸립니다 — 사용자 기대치를 설정하거나 요청 시 미리 warm하십시오.
- **Hot partition.** 고래(whale) 계정이나 현재 달이 핫스팟일 수 있습니다 — 서브파티셔닝하거나 캐시하십시오.
- **하지 않아야 할 때:** 수억이 아니라 수백만 row는 하나의 인덱싱된 Postgres 테이블에 맞습니다 — 필요 없는 계층화를 만들지 마십시오. 단일 테이블의 인덱스가 메모리에 더 이상 맞지 않는 규모에서 이것에 손을 뻗으십시오.

아키텍처

동작 방식

면접 관점

트레이드오프 및 실패

관련 질문