데이터베이스 테이블 파티션 partition 개념은?

 

 

 

데이터 많이 다루시는데 파티션을 한 번 제대로 이해해두면 쿼리 성능·운영 편의성·백업 전략까지 전반적으로 업그레이드됩니다. 

 

---

✅ 파티션(Partition) 개념 — 쉽게 설명

**파티션은 “하나의 테이블을 여러 조각으로 나눠 저장하는 기술”**입니다.
하지만 사용자(쿼리)는 여전히 한 테이블처럼 사용합니다.

예:
매일 200만 건씩 쌓이는 **거래 로그 테이블(transaction_log)**이 있다고 해보죠.

• 파티션 없음 → 10억 건 테이블에서 매번 범위 스캔
• 파티션 있음 → “2024년 테이블 조각” 또는 “2024-12월 조각”만 스캔

즉, 전체 테이블을 뒤지지 않아도 되는 구조입니다.

---

✅ 파티션은 언제 적용하는가? 2가지 경우

결론부터 말하면 둘 다 맞습니다.

① 초기 설계 단계에서 미리 파티션을 만들기 (가장 이상적)

대규모 서비스의 경우엔 처음부터 파티션을 고려해서 테이블을 설계합니다.

💡 이런 상황일 때:

• 데이터가 매일/매월 폭증하는 로그성 테이블
• 기간으로 조회하는 쿼리가 매우 많은 경우
• 오래된 데이터는 주기적으로 정리/백업해야 하는 경우
• MySQL/InnoDB, PostgreSQL, Oracle 등에서 성능 이슈가 예상되는 경우

미리 해두면:

• 데이터 정리(파티션 DROP)가 쉬움
• 테이블 락 최소화
• 쿼리 성능 예측가능

---

② 데이터가 너무 커져서 나중에 파티션 도입

실제로 실무에서는 이 케이스가 더 흔합니다.

예:
처음에는 하루 30만 건이라서 파티션 필요 없었는데
→ 2년 지나니 테이블이 몇 억 건으로 커짐 → 조회·백업·삭제가 느려짐
→ 그때 파티션 도입

이 경우 단점:

• 온라인 파티션 변경(Zero-downtime) 작업이 어렵거나 위험할 수 있음
• 백필(backfill) 및 리인덱싱 시간이 오래 걸릴 수 있음
• MySQL/MariaDB 등에서는 기존 테이블을 파티션 테이블로 바꾸기 위해 재생성 필요(락 발생 가능)

그럼에도 불구하고 성능 향상 효과가 매우 커서 충분히 시도하는 가치 있음.

---

✅ 파티션을 사용하는 목적 (핵심 4개)

1) 쿼리 성능 향상

대부분 기간 기반 조회를 많이 하죠?

예:

SELECT * FROM transaction_log
WHERE created_at BETWEEN '2024-12-01' AND '2024-12-31';

파티션이 있으면 DB는 해당 월 또는 해당 일의 파티션만 읽습니다.
이를 **Partition Pruning(가지치기)**라고 해요.

---

2) 데이터 관리가 쉬워짐 (삭제, 백업, 보관)

예: 1년 이상 지난 로그를 날려야 할 때

파티션 없으면:

DELETE FROM logs WHERE created_at < '2024-01-01'; 
-- 수백만 건 삭제 / 테이블 락 / Undo 증가 / 느림

파티션 있으면:

ALTER TABLE logs DROP PARTITION p2023;
-- 몇 초 내 끝남 / 락 거의 없음

---

3) 인덱스 관리가 효율적

인덱스도 파티션 단위로 생성 → 큰 테이블보다 훨씬 가볍게 작동합니다.

---

4) 스토리지 분리 가능

대형 시스템에서는 오래된 파티션을 저속 디스크로 옮기는 것도 가능(주로 Oracle, PostgreSQL).

---

✅ 파티션의 종류(실무에서 가장 많이 쓰는 2가지)

1) Range Partition (범위 기준)

가장 많이 사용됨.

예:

• 일자 기준
• 월 기준
• 연도 기준
• Numerical ID 범위 기준

MySQL 예:

PARTITION BY RANGE (YEAR_MONTH) (
  PARTITION p202412 VALUES LESS THAN (202501),
  PARTITION p202501 VALUES LESS THAN (202502)
);

---

2) Hash Partition (해시 기반 균등 분배)

Row를 특정 컬럼 값으로 '골고루' 분산시킴.

예:

PARTITION BY HASH(user_id) PARTITIONS 8;

→ 특정 유저만 막 쿼리 때릴 때도 HotSpot이 덜 생김.

---

❗ 파티션이 만능은 아님 — 안 써도 되는 경우

• 데이터량이 수백만 건 이하
• 주로 PK 또는 인덱스로 단건 조회
• 시간 기준 대량 삭제도 없음
• Insert volume이 낮음
• 테이블이 너무 작아 파티션 오버헤드가 더 큼

그런 경우 오히려 단순 IDX로 해결됨.

---

🔥 실무적으로 가장 중요한 포인트

✔ 파티션은 미리 설계하면 좋지만

실제로는 운영하면서 커지면 적용하는 경우가 더 많다.

✔ 기간 기반 데이터 조회가 많으면 거의 무조건 도움이 된다.

✔ 파티션 Drop만으로도 데이터 삭제가 개꿀이다.

✔ 파티션을 나누면 테이블은 하나처럼 쓰지만, 내부적으로는 “여러 테이블처럼” 동작한다.

---