테이블 파티셔닝을 해야 하는 시점은 언제 일까요?

현업에서 마주하는 파티셔닝의 목적은 크게 2가지입니다. 하나는 로그를 기록하는 테이블인 경우 로그 보관 기간을 초과한 레코드를 정기적으로 삭제하고 싶을 때인데요. 보통 로그 테이블은 레코드 수와 데이터의 양이 매우 큰 성격을 가지기 때문에, 예를 들어 1년이 지난 로그를 지울 때 파티션이 없다면 DELETE문을 써야 하는데 사실 이러면 답이 없죠. (테이블도 잠기고 부하도 크고 다 삭제될 때까지의 시간도 기약하지 못하기 때문) 하지만 날짜로 레인지 파티셔닝을 해 두면 삭제할 때 파티션 단위로 truncate하면 되기 때문에 작업이 순식간에 끝납니다. 상황에 따라 다른 저장소로 아카이빙하기도 좋구요. 다른 하나는 읽기, 쓰기 부하를 분산하기 위해서입니다. 이 경우 해시 파티션을 사용하거나 DBMS가 해시 파티션을 지원하지 않으면 리스트 파티션을 사용하는데요. 경험적으로 보면.. 이런 방식이 효과를 가질 정도의 대용량 데이터는 드뭅니다. 특히 MySQL 같은 경우 과도한 파티션은 INSERT 속도를 떨어뜨리는 부작용도 있죠. 질문 주신 분께선 대용량 데이터 운영을 말씀하셨지만, 어떤 목적으로 파티셔닝을 하시겠다고 밝히지 않으셔서 더 자세한 답변은 어려울 것 같습니다. 다만, 이미 데이터가 쌓인 상태에서 파티션을 나누기 시작하는게 아니라.. 미리 파티션을 나눠두고 적재를 시작하는게 맞습니다.

좀 다른 이야기지만.. 파티셔닝은 문제 해결의 수단 중 하나로 보시고.. 저장하는 데이터의 성격을 먼저 고민하시는게 어떨까 싶습니다. 관련한 경험이 많지는 않지만 천만 정도의 데이터는 흔하다고 알고 있는데, RDB에 운영 데이터가 개발 당사자가 고민이 될 정도의 속도로 쌓인다면, 저라면 설계가 레거시화 된 상황이 아닌가 먼저 확인할 것 같습니다.