일간, 주간, 월간 등의 기간별 이력이나 통계 데이터의 처리를 어떻게 하시는 지 궁긍합니다.

[김기용]

회사에서 새 제품을 만들고 있는데, 일간, 주간, 월간 이력과 같은 기간별 데이터가 많습니다.
일간 데이터같은 경우, 데이터를 사용자가 지정한 주기로 삭제를 하게 되어있구요.

다른 프로젝트의 경우에도 이런 패턴은 꽤 빈번할 것 같은데, 어떤 식으로 DB가 설계되어 있고 구현되어 있는지가 궁긍합니다.

이전 제품에는 일간 데이터, 주간 데이터, 월간 데이터 테이블을 만들고 모두 집어넣은 다음에 Quartz를 이용해서 특정 시간에 기간별 쿼리를 통해서 삭제를 한 걸로 아는데요..
오늘 오전 회의에서 일간 데이터는 daily_data_091105, daily_data_091106, .... 같이 매일 테이블을 생성해서 데이터를 넣고,
지울 땐 그냥 테이블을 drop 하는 식으로 하기로 결정됐다고 하더군요.

개인적으로는 바뀐 방식이 쓰이는 걸 본 적이 없는데, 팀장님께서는 다른 데서도 저렇게 많이 한다고 하시더군요.
그래도 뭔가 느낌이 꺼림칙해서 반론을 제기해보려 했지만, 마땅히 반론이 생각이 나지 않더군요.;;

그래서 질문은..

1 ) 바뀐 방식이 실제로 많이 쓰이는 방법인지
2 ) 바뀌는 방식과 이전 방식을 비교해서 어떤 것이 더 나은 방법인지

이 두가지를 알고 싶습니다.

( 이런 비슷한 구조의 기능을 만들어 보신 분들의 조언도 환영합니다. )

[박성철]

1 ) 바뀐 방식이 실제로 많이 쓰이는 방법인지

많이 쓴다고 좋은 뜻은 아니지만 좌우간 많이 씁니다. ㅎㅎ

2 ) 바뀌는 방식과 이전 방식을 비교해서 어떤 것이 더 나은 방법인지

모든 선택에는 얻는 게 있으면 잃는 것도 있으니 어떤 것이 항상 더 나은 방
법이라고 할 수는 없을 것 같고
가능하면 기존 방식으로 하되 데이터가 너무 많고 날짜별로 거의 독립적이어
사 한 테이블에 넣을 필요가 없다면 후자도 가능한 방법이라고 생각합니다.
다만 Oracle의 Partitioning 같은 기술을 쓰면 한 테이블에 저장하면서도 테
이블을 나누는 효과도 있으니 함 고려해보세요.
그냥 깔끔하게 날려버리고 싶은데 한 테이블에 넣어두면 삭제하는데 너무 오
래 걸리고 부하도 심해서 그럴 수도 있으니 융통성 있게 판단하시면 될 것 같
습니다.

김기용 쓴 글:

[김기용]

두 분 다 답변 감사드립니다.

신승식님 답변 듣고 얼른 파티션에 대해서 공부하고, 팀장님께 말씀드렸습니다.
잠깐 테스트 해 보시더니, 쓸만하다고 판단하신 것 같고 Table Partitioning 을 하기로 거의 결정된 거 같습니다.

주로 웹 쪽만 많이 하다보니 대용량 데이터 처리에 대해서 별로 접할 일이 없었는데,
파티션이나 Archive 엔진(Mysql) 같은 것에 대해 처음 접근해 보게 되네요.

다시 한번 조언 주신 두 분께 감사드립니다.

2009년 11월 9일 오전 10:16, 박성철 <gyu...@gmail.com>님의 말:

[Sewon Ann]

제가 알기론, table partitioning 를 적용하시려면 partitioning 규칙을 일관성있게 잘 만드셔야 하는 것으로 알고 있습니다. (예를 들어 각 항목 id 앞 두자리가 년도이고, 이걸로 partitioning 한다던가 하는..)

그런데 건수가 얼마나 될 지 모르는데, daily 자료도 partitioning 을 적용하나요? 제 예전 환경에서는 일마다 쌓이는 건수가 상당히 많았음에도 불구하고 년간 partitioning 을 적용하였습니다.

기용님의 메일에서는 일간으로 table drop 을 말씀하셨는데, partitioning 을 적용하실 것이라면 어느 정도 규모로 partitioning 하는 게 효과적일 것인가에 대해 확인하실 필요가 있을 것 같네요.

2009/11/9 김기용 <drag...@gmail.com>

[용이]

NMS 개발하는 쪽에서는 Oracle 의 partitioning 을 많이 사용합니다.
저희는 감시를 위한 5분, 시간별,일별,주별, 월별 데이터를 쌓아놓는데
각 주기별로 보관주기가 다르기 때문에 Partitioning을 쓰지 않고는 해결할 수 없는 문제였지요.
처음 Partition을 사용했을때 겪었던 시행착오 몇가지를 혹시 도움이 될까 정리해 드리겠습니다.

1. 쿼리를 만드실때 Plan을 잘 짜서 Partition Index를 타도록 해야 합니다. 대용량 데이터가 쌓이면 시간이 지날
수록 selece 및 group by 연산할때 속도가 나오지 않습니다.
2. 이건 아주 기초적인 것인데, 특정 주기(해당 일, 해당 시간)의 데이터를 삭제할 때 간혹 delete를 사용하는 개발자가
있습니다. 대량의 데이터가 있을때 delete문은 속도가 무지하게 느리기 때문에 이때는 꼭 partition drop으로 특정
partition을 날려야 합니다.
3. partition을 관리하는 process가 별도로 동작하고 있어야 합니다. partition을 몇년간의 분량을 미리 만들
어 놓지 않을 것이라면 매일 또는 매월 앞으로 몇달간 또는 몇일간의 partition을 생성하고 보관주기가 지난
partition을 drop하는 batch process가 있으면 도움이 됩니다.

다 아시는 내용이겠지만 혹시 도움이 되실까 해서 정리해 보았습니다. ^^