테이블 partitioning이란 무엇인가요?

Question

Accepted Answer

**partitioning**은 큰 테이블을 컬럼 값에 따라 더 작은 물리적 조각(**파티션**)으로 나눕니다 — 쿼리에게는 여전히 하나의 논리적 테이블로 보입니다. 데이터베이스가 관련 파티션만 스캔하거나 유지보수하게 하여 매우 큰 테이블의 성능과 관리성을 향상시킵니다.

## partitioning이 어떻게 동작하는가

```sql
-- 거대한 orders 테이블을 order date로 RANGE 파티셔닝
CREATE TABLE orders (id INT, order_date DATE, amount DECIMAL)
PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- orders는 하나의 논리적 테이블이지만, 연도별 파티션으로 분리 저장됨
```

테이블은 하나의 논리적 개체이지만, 물리적으로는 파티션에 저장됩니다. 쿼리와 삽입은 자동으로 올바른 파티션으로 갑니다.

## 핵심 이점: partition pruning

```sql
-- 파티션 키로 필터링된 쿼리는 관련 파티션만 스캔
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → 데이터베이스가 orders_2023을 완전히 건너뛰고 orders_2024만 스캔 ("partition pruning")
```

**partition pruning**이 주된 성능 이득입니다: 파티션 키로 필터링된 쿼리는 관련 파티션만 건드리고 나머지는 건너뜁니다 — 수십억 행 스캔을 관련 부분집합만의 스캔으로 바꿉니다.

## partitioning 전략

```text
RANGE → 값 범위로 (날짜, 숫자 범위) — 시계열 데이터에 흔함
LIST  → 이산 값 목록으로 (지역, 범주)
HASH  → 키의 해시로 (파티션 간 고른 분포)
```

## 기타 이점

```text
✓ 유지보수 — 전체 파티션을 드롭하여 오래된 데이터 드롭/아카이브 (DELETE 대비 즉시)
  예: DROP TABLE orders_2020 — DELETE WHERE year = 2020보다 훨씬 빠름
✓ 파티션당 더 작은 index; 파티션 간 병렬 연산
✓ 거대한 테이블을 관리 가능한 조각으로 관리
```

## partitioning을 언제 사용하는가

```text
✓ 쿼리가 자연스러운 파티션 키로 필터링하는 매우 큰 테이블 (수억/수십억 행)
  (로그, 이벤트, order에는 종종 시간/날짜)
✓ 오래된 데이터를 정기적으로 아카이브/드롭하는 시계열 데이터
✗ 작은/중간 테이블 — partitioning은 거의 이득 없이 복잡성만 더함
  (적절한 인덱싱으로 보통 충분)
→ partitioning은 매우 큰 테이블에 인덱싱을 보완함; 대체가 아님.
```

## 왜 중요한가

테이블 partitioning은 **매우 큰 테이블**을 관리하고 조회하는 중요한 기법이며, 이해하는 것은 대규모 데이터베이스 작업에 가치 있는 시니어 수준 지식입니다.

테이블이 수억 또는 수십억 행으로 자라면, index가 걸린 쿼리와 유지보수 연산조차 느려질 수 있으며, partitioning은 테이블을 더 작은 물리적 조각으로 나눠 이를 해결합니다.

핵심 성능 이점은 **partition pruning**입니다 — 파티션 키로 필터링된 쿼리는 관련 파티션만 스캔(나머지 건너뜀)하여, 거대한 테이블의 스캔 데이터를 극적으로 줄입니다(특히 날짜로 필터링되는 시계열 데이터에 흔함).

쿼리 성능을 넘어, partitioning은 주요 **유지보수 이점**을 제공합니다: 오래된 데이터의 아카이브나 삭제가 즉시 가능해집니다(전체 파티션 드롭 vs 수백만 행의 느리고 비싼 `DELETE` — 보존 정책이 있는 로그/이벤트 데이터에 상당한 운영적 이점), 더불어 파티션당 더 작은 index와 병렬 연산도 있습니다.

**전략**(날짜/숫자 범위에 RANGE — 시계열에 흔함; 이산 값에 LIST; 고른 분포에 HASH)과 결정적으로 **언제 partitioning을 사용할지**(자연스러운 파티션 키가 있는 매우 큰 테이블, 특히 정기적 아카이브가 있는 시계열 — 인덱싱으로 충분하고 partitioning이 복잡성만 더하는 작은/중간 테이블에는 *아님*)를 이해하는 것은 성숙한 판단을 반영합니다.

매우 큰 테이블 관리는 확장된 시스템의 실제 과제이고, partitioning(partition pruning과 효율적 유지보수)이 그에 대한 표준 도구이므로 — 인덱싱을 대체가 아니라 보완 — 테이블 partitioning을 이해하는 것은 데이터베이스 확장성에 가치 있는 시니어 수준 지식이며, 특히 대규모, 시계열, 또는 대용량 데이터 시스템에 관련되고 규모 있는 데이터베이스 관리에 대한 이해를 보여주는 주제입니다.