[DB] 파티션을 써야 할 때

재고 개선 프로젝트를 진행하면서 관련 테이블에 파티션을 추가할지 말지가 고민되었습니다.

 

재고 테이블이기 때문에, 기존 테이블들에 파티션이 적용되어 있어 우선적으로 파티션 추가를 고려하였지만

DBA와 동료들과 이야기하면서 파티션의 장단점을 좀 더 생각해 볼 수 있었습니다.

 

파티션을 잘못 설정하면 오히려 성능이 안좋아지는데 이 경우는 제외하고

가장 많이 겪게 되는 파티션 추가의 단점은 아래 두 가지입니다

 

1. 파티션을 추가하면 모든 조회 쿼리에 파티션 키를 포함해야 한다.

2. 파티션 추가와 같은 부가적인 관리 비용이 발생한다.

 

이 단점을 상쇄할 만큼의 장점이 있어야 파티션 도입을 고민할 가치가 있습니다.

다음은 고려해볼 만한 몇 가지 포인트입니다.

 

데이터의 양이 많은 경우

데이터가 많아질 것 같아 파티션을 적용해야 한다고 생각할 수 있습니다.

 

그러나 이는 인덱스 설계만 잘하면 해결될 수 있는 문제입니다.

균등하게 분포된 100억 건의 데이터도 B-Tree 인덱스 깊이는 4~5 정도에 불과합니다.

 

인덱스도 충분히 효율적이므로, 파티션 없이 운영이 가능한지 먼저 확인해보는 것이 좋습니다.

파티션 없이 운영하다가 문제가 발생하면 그때 파티션을 적용하는 것도 괜찮습니다.

 

참고로, QPS나 CRUD 비율에 차이가 있겠지만 1억 건이 넘게 저장된 테이블도 파티션 없이 잘 운영됩니다.

 

삭제 정책이 있는 경우

기간에 따라 삭제 정책이 있는 경우 파티션이 유용합니다.

대량 데이터를 삭제할 때 긴 시간 트랜잭션을 유지하게 되는데

이로 인해 잠금 경합이 발생할 수 있고 리두 및 언두 로그가 쌓여 문제가 생길 수도 있습니다.

 

이런 상황에서 파티션이 있으면 단순 파티션 드롭으로 쉽게 삭제 처리가 가능합니다.

 

데이터 입수, 백업 등의 요구 사항이 있는 경우

데이터 입수가 있고 입수에 소요되는 시간이 중요할 때 파티션이 필요할 수 있습니다.

 

예를 들어, 요금제와 요금제 재고 테이블의 데이터 입수 시점이 비슷하게 맞춰야 하는 경우

파티션 수만큼 스레드를 생성해 비동기로 빠르게 처리할 수 있습니다.

 

그러나 대부분의 데이터 입수는 생성 일시나 수정 일시에 인덱스를 걸어도 해결되기 때문에

파티션이 진짜 필요한지는 잘 고민해봐야 합니다.

 

---

결론적으로, 기간에 따른 삭제 정책이 있는 경우를 제외하고는 파티션을 미리 적용할 필요는 적다고 판단됩니다.

파티션을 무작정 적용하기보다는 충분한 테스트를 통해 결정해야 합니다.