안녕하세요,

말씀하신 경우는 분석 워크로드(DW/DM, OLAP)와 과금 처리가 병행되어야 하는 '하이브리드 워크로드' 형태의 요구사항인 듯 합니다. 이미 CDR 데이터를 데이터베이스로 로딩하는 ETL 개발은 마친 것으로 보입니다. 개선을 위한 아키텍처 선택은 여러가지가 될 수 있습니다. 제가 생각한 후보들을 보자면...

1. 현재 구조를 유지 하면서 성능을 보장하고 여러 응용을 처리하자!

-> 현재는 단일 DWH 에 로그를 저장하고 분석하며 과금 처리하는 방식인데 이런 경우 성능을 높이려면 데이터를 필요한 만큼만 읽는 전략이 필요할 것 같습니다.  '파티셔닝' 전략을 세우는 것이죠. 아시다시피 PG에는 빌트인 파티셔닝(Oracle이나 기타 DBMS의 그것과 유사한) 기능이 없고 약간 다르게 구현해야 합니다.

http://www.postgresql.org/docs/8.3/interactive/ddl-partitioning.html

http://it.toolbox.com/blogs/oracle-guide/comparing-partitioned-tables-in-oracle-and-enterprisedbpostgresql-13261

http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation

파티셔닝과 관련해서는 위 링크들이 도움이 될겁니다.

 

2. 워크로드를 완전 분리하자!

-> 이런 경우는 DWH, DM을 분리하거나 DWH 이전에 ODS같은 스테이징 구조를 두는 방법입니다. 현재 데이터베이스(DWH)와는 별도로 분석전용 Data Mart를 구축하는 것입니다. 분석요구사항이 아마 전체 Raw 데이터를 다 필요로하지는 않을 겁니다. 그래서 분석 전용 데이터 모델을 별도의 데이터베이스로 분리하는 방법입니다. 이런 경우라면 DWH에 로딩하고 추가로 DM용도로 다차원 모델을 분리하여 구현하면 될것 같습니다.  유사한 선택으로 ODS / DWH 형태로 분리해도 되겠지요. 데이터를 ODS에 적재하면서 과금은 처리하고 그 ODS 데이터를 기반으로 다시 DWH를 구성하는 시나리오입니다.

http://wiki.postgresql.org/images/3/38/PGDay2009-EN-Datawarehousing_with_PostgreSQL.pdf

http://lethargy.org/~jesus/misc/BBPostgres.pdf

http://www.sun.com/third-party/srsc/resources/postgresql/postgre_success_dwp.pdf

 

3. 아키텍처 변경을 최소화 하면서 워크로드만 분리하고 싶다!

현재 하나의 데이터베이스에 계속 데이터를 쓰고, 그 데이터를 응용하고, 분석하기 때문에 성능 문제가 오는 것이 아니겠습니까?  현재 구조에서 데이터 로딩과 조회(SELECT) 응용만 분리해도 큰 성능 향상을 볼 것 같다는 생각이 듭니다. 구조를 변경하지 않고 로드를 분산하려면 Replication해서 응용에 따라 다른 인스턴스를 보게 하는 방법인데요. 단점이라면 추가로 하드웨어가 필요하며 Replication 구성/관리를 추가로 해야한다는 것이죠.

 

결론적으로 현재 상태에서 단순 '튜닝'만 생각하신다면 1번과 같은 파티셔닝 및 튜닝 절차를 고려하시고, 장기적으로 구조적으로 워크로드를 분리해야하는 이슈가 크다면 2, 3번과 같이 DWH, DM, ODS 레이터를 추가로 생각하는 방향으로 가는 것을 권해드립니다.

안녕하십니까 김영우님!

 

저를 기억하실지 모르시겠지만, 저는 또렷하게 기억하고있답니다..^^

실은 작년에도 비슷한 질문을 드린적이 있었는데, 자세한 설명을 해주셔서

아직도 기억에 남아있습니다.

 

부끄럽게도 아직 댓글을 보면 대략 멍- 한 상태입니다만..

신기하게도 계속 들러붙어 하다보니 댓글에서 조언해주신 내용이 정말 큰 도움이 되었습니다.

다시한번 감사드립니다.

 

 

현재 우리사에서 운영하고있는 빌링관련 프로그램 이외로 호통계 분석프로그램이 있습니다.

만들어진지도 오래되었고 해서 몇몇 개선점이 눈에 보이는데,

모델링이 어떻게 되어있는지, CDR이 무한정 한개의 테이블에 쌓이고있어

시간이 가면 갈수록 더욱 느려지는 현상이 발생하였습니다.

그래서 생각한게, 한달이 지난 자료는 다른 DB/테이블로 이동하고, 최근의 한달자료만 이용하면

어떨까 생각했습니다만, 이것도 파티셔닝이라고 할수있는지요? (아마도 트리거라는게 필요한 부분이겠지요?)

PG에 내장된 파티셔닝 기능이 없는것은 조금 의외입니다만,

조언해주신 다른 방법에 대해서 연구해보겠습니다!

 

아마도 두번째방법이, 제가 질문드린 사항과 근접한 대안인것같습니다.

원본 RAW 한 데이터에서 필요한 자료만 빼어 분석전용의 공간으로 분리하는것인데,

실제로도 이런형식으로 쓰이는것이 놀라운것같습니다.

(제가 제대로 이해한게 맞는지 모르겠네요)

 

세번째 대안은 잘 이해가 가지 않습니다만, 혹시 디스크의 레이드 개념처럼

DB를 똑같이 미러링 한 후, 그걸 전용으로 따로 이용한다는 뜻으로 생각해도 될까요?

그래서 하드웨어가 하나 더 필요하다고 말씀하신것이고...

 

 

 

 

실은 기존에 있는 체계를 제가 건드릴수는 없습니다..ㅠㅠ

현재 저는 별정 통신사에서 근무하는 계약직 학생인데... 과금이나, CDR같은

핵심되는 부분에 접근하기는 어렵기때문이지요,

 

하지만 업무상 CDR을 가공하고, 검색하는게 DB만한게 없다는걸 깨달았는데,

좀더 생각해보니 이 CDR을 DB화 하고, 시간, 일 마다 통계자료를 만들 수 있을것이란 생각을

하게되었습니다.

 

CDR 자료가 CSV 로 떨어지니까, 이 자료를 특정폴더로 sync 하는일은 어렵지 않을것이고..

그래서 새로운 체계를 구축하려고 하다보니 이것저것 배워야 할것이 많은것같습니다..

 

실은 답변해주신 내용의 10%라도 제대로 이해하고있는지 저 스스로도 의문입니다만,

이 부분에서 어떤게 필요하다라는것을 조언해주신것만으로도 큰 공부가 될것같습니다.

 

이름을 잊지 않고있고, 예전 답변으로 기억하기로는 CDR을 처리하는 업무를 해본적이 있다고하신터라

아마도 이분야 어디쯤 계시는것이 아닐까 생각됩니다만, 언젠가 뵙게되면

실례가 되지 않는선에서 식사라도 꼭 함께하고싶습니다,

답변해주셔서 감사합니다! ^^

 

 

 

 

 

실은 이 전에 한시간 넘게 쓴글이 있었는데-_-

시간이 지나서 로그아웃이 되버렸는지 공중에 날아가버려서 대략 힘이 빠져버렸네요...ㅎ

 

안녕하세요.

답변은 아니지만 위의 김영우님이 답변하신 부분에 대한 질문(?) 겸 개인적인 생각을 적습니다.

1. 현재 구조를 유지 하면서 성능을 보장하고 여러 응용을 처리하자! --> 파티셔닝

   : 저도 직접 사용해보지는 않았지만.. 도움말을 보니 부모테이블에서 필요한 부분만 상속받아 통계테이블을 만들어 사용하는것 같습니다..  보통의 경우에도 이 같은 방식으로 (집계테이블) 을 만들어서 사용 하는데... 파티셔닝을 사용하면 더 좋은 방법이 될수 있다라는것 같습니다..( 이부분은 저도 실제 테스트를 해보고 말씀을 드려야 할것 같습니다)

 

2번 문서를 잠깐 보았는데 모르곘습니다 ㅡㅜ 패스;

 

3번 Replication 구성

: 보통 pgpool로 구성을 할수가 있습니다. 하드웨어 여유가 되신다면.. 마스터서버1대, 차일드서버2대 총 3대로 구성하여 차일드 서버에 select만 주시면 부하는 많이 줄어들거라 생각됩니다. 저도 로컬에서 3개까지 테스트는 해보았습니다만, 실무적용은 아직 없습니다.. ( 동기화부분이 생명인데 실력이 부족어여)

 

제 생각으로는 1번 파티셔닝 방법이 실무적용방법으로는 제일 좋을것 같습니다..

 

 

 

 

안녕하세요, 성제호님.

한동안 프로젝트 때문에 정신이 없어서 이제야 글을 봤습니다.

 

말씀하신대로 '파티셔닝'을 잘 적용하면 현재 문제의 많은 부분을 해결할 것으로 보입니다. 현재는 제가 telco 도메인의 업무를 하지는 않고 있구요. 다만 로그 분석이 많은 인터넷 포털 업체에서 일하고 있습니다. 로그 처리라는게 분석모델은 산업군마다 다르겠지만 데이터 프로세싱 단계는 대부분 유사합니다. 일반적인 DWH 아키텍처라면 source 데이터의 생성/수집, ETL, DWH (DM) 적재/분석 단계에서 겪는 성능 이슈는 크게 다르지 않을 겁니다.

 

여기 게시판에 주제에 대해 작게 나누어 이야기하는 것도 좋구요. 개인적으로 연락하시고 싶으시면 warwithin@gmail.com 이나 휴대폰 01036031507로 연락주셔도 좋습니다.