179. 파티셔닝 (Partitioning) - 대용량 테이블 분할

핵심 인사이트: 10년 치 데이터가 쌓인 10억 건짜리 장부가 하나 있다. 여기서 작년 12월 장부만 찾으려니 책이 너무 무거워서 넘길 수가 없다. 파티셔닝은 이 거대한 장부를 '연도별'이나 '월별'로 쪼개서 각각의 가벼운 바인더에 나눠 담는, 대용량 DB 관리의 구원투수다.

Ⅰ. 테이블 파티셔닝 (Partitioning)의 개념

논리적으로는 하나의 큰 테이블로 보이지만, 물리적으로는 데이터베이스 내에 여러 개의 작은 테이블(파티션)로 쪼개어 분산 저장하고 관리하는 기법입니다. 보통 수천만 건 이상의 대용량 테이블(Very Large Database, VLDB)에서 I/O 성능 향상과 관리(백업/복구)의 편의성을 위해 필수적으로 적용됩니다.

Ⅱ. 파티셔닝의 장점 (효과)

장점	세부 설명
성능 향상 (Performance)	옵티마이저가 쿼리 조건에 맞는 파티션만 쏙 골라서 읽고, 나머지 파티션은 읽지 않고 건너뜁니다. 이를 파티션 프루닝(Partition Pruning, 가지치기) 이라고 하며, 디스크 I/O를 극적으로 줄여줍니다.
관리 편의성 (Manageability)	거대한 테이블 전체를 백업할 필요 없이 파티션 단위로 독립적인 백업/복구(Restore)가 가능합니다. 또한 오래된 데이터(예: 3년 지난 로그)를 삭제할 때 `DELETE` 대신 `DROP PARTITION` 명령어 한 방에 순식간에 데이터를 지울 수 있습니다.
가용성 향상 (Availability)	특정 파티션이 저장된 디스크에 장애가 나도, 나머지 정상 파티션의 데이터는 여전히 조회하고 서비스할 수 있습니다.

Ⅲ. 파티셔닝의 핵심 동작 원리: 파티션 키 (Partition Key)

테이블을 어떤 기준을 가지고 쪼갤 것인지를 결정하는 컬럼을 파티션 키(Partition Key) 라고 부릅니다. 예를 들어 주문일자(ORDER_DATE)를 파티션 키로 설정하면, DB 내부의 라우터가 INSERT 되는 데이터의 주문일자를 보고 알아서 2023년 파티션, 2024년 파티션으로 데이터를 던져서 나눠 담습니다.

Ⅳ. 파티셔닝의 한계 및 주의점

파티셔닝은 만병통치약이 아닙니다.

쿼리의 WHERE 절에 파티션 키(Partition Key) 컬럼이 포함되지 않으면, 옵티마이저가 어느 파티션에 데이터가 있는지 몰라 모든 파티션을 다 뒤져야 하는 참사(Full Partition Scan)가 발생합니다.
파티션을 너무 잘게 쪼개면(예: 일 단위 파티션을 10년 치 생성), 파티션 관리 구조체(메타데이터)가 뚱뚱해져서 딕셔너리 조회 부하가 생깁니다.

📢 섹션 요약 비유: 수만 장의 서류가 든 커다란 박스에서 서류 하나를 찾는 것은 끔찍합니다. 그래서 커다란 서랍장을 사서 '2023년 칸', '2024년 칸'으로 서류를 물리적으로 나눠(Partitioning) 담습니다. 겉보기엔 하나의 서랍장(논리적 단일 테이블)이지만, 서류를 찾을 때는 년도 칸(파티션 프루닝)만 열면 되니 속도가 날아갑니다.