수십억 row를 가진 단일 테이블을 어떻게 파티셔닝하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**거대한 테이블을 partition key로 더 작은 물리적 자식 테이블로 나눠, 각 쿼리가 수십억 row를 스캔하는 대신 필요한 partition만 건드리게(partition pruning) 하십시오.** 50억 주문 row를 가진 테이블도 여전히 하나의 논리 테이블처럼 동작하지만, `WHERE`가 partition key로 필터링하면 엔진이 그 99%를 건너뜁니다.

## 파티셔닝된 테이블의 형태

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## 파티셔닝 전략 선택

- **Range** — 날짜/id 범위별. 시계열(주문, 로그, 이벤트)에 최적. 최근 데이터가 hot하게 유지되고 오래된 범위는 드롭하기 쉽습니다.
- **Hash** — `hash(key) % N`으로 N개 partition에 고르게 분산. 자연스러운 범위가 없고 균형 잡힌 부하를 원할 때 사용(예: `user_id`).
- **List** — 명시적 버킷(`region IN ('EU','US')`). tenant나 region 격리에 좋습니다.

```sql
-- Postgres: 월별 range partition, created_at으로 pruning
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- 이 쿼리는 전체 테이블이 아니라 orders_2025_01만 스캔합니다
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, 인덱스, 유지보수

- **Partition pruning**은 쿼리가 **partition key**로 필터링할 때만 작동합니다. 다른 것으로 필터링하면 모든 partition을 스캔합니다 — 1순위 실수.
- **Local index** = 자식당 하나의 인덱스(Postgres 기본값). partition과 함께 빌드/드롭이 저렴합니다. **Global index**(Oracle)는 모든 partition에 걸치며 — partition 간 고유 조회에 도움이 되지만 하나를 드롭할 때 재구축해야 합니다.
- **유지보수**가 O(partition)이 됩니다: 오래된 데이터를 `DROP TABLE orders_2019`(즉각적, 거대한 `DELETE` 없음)로 아카이브하고, 롤링 윈도우를 위해 `ATTACH`/`DETACH`합니다.

## 면접 관점

면접관은 당신이 **파티셔닝은 인덱싱이 아님**을 이해하는지 파고듭니다 — 파티셔닝은 스캔되는 데이터를 줄이고, 인덱스는 스캔 내에서 검사되는 row를 줄입니다. 흔히 둘 다 필요합니다. 좋은 답변은 range/hash/list를 짚고, 훌륭한 답변은 **partition key가 지배적 쿼리 필터와 일치해야 함**을 강조하고, 잘못된 key가 pruning을 죽인다고 경고하며, `DROP`을 통한 저렴한 아카이브를 언급합니다.

**트레이드오프:** cross-partition 쿼리(key 필터 없음, 또는 partition 간 고유 제약)는 느려지고 고유성 강제가 더 어렵습니다. 1천만 row 테이블은 파티셔닝하지 마십시오 — 이득 없이 운영 복잡성만 더합니다. 테이블이 거대하고 **그리고** 쿼리가 key로 자연스럽게 범위 지정될 때 파티셔닝하십시오.

파티셔닝된 테이블의 형태

파티셔닝 전략 선택

Pruning, 인덱스, 유지보수

면접 관점

관련 질문