2. DBMS이야기/01. PostgreSQL

timescaledb 확장 모듈

ioseph 2020. 7. 15. 14:10

PostgreSQL로 시계열 자료 다루기

 

전통적인 방법 

 

  1. 일정 시간 간격으로 입력되는 원천 자료를 저장하는 테이블을 만들고,
  2. 그 자료량을 감안한 적당 크기가 되도록 하위 파티션 테이블을 만들고,
  3. 시간 간격별(1시간, 1일, 1주일 ...) 부분 집계 테이블을 만들고, 그 간격 주기로 집계작업을 위한 배치 작업을 만들고, 
  4. 일정 기간이 지나면 오래된 자료가 지워지도록 하위 파티션 테이블을 삭제 배치 작업도 만들고, 
  5. 원천 자료가 담기는 파티션 테이블의 하위 테이블들이 자동으로 추가 되도록 하는 트리거나 배치 작업을 만들어야 했습니다. 

 

참 성가신 방법이었습니다. 

 

시계열 데이터베이스

 

요즘 만들어지는 데이터베이스를 보면, 특히 '이 데이터베이스는 시계열 자료 처리에 특화 되어있다'이런 기능을 자랑하는 데이터베이스를 보면, 이런 성가신 데이터베이스 관리자 작업 없이, 그냥 정책들만 지정하면 위 모든게 자동으로 처리됩니다. 

 

timescaledb 확장 모듈

다운로드, 설치, 문서: https://www.timescale.com/

 

이 모듈이 PostgreSQL도 그렇게 변신하도록 합니다. 

 

  • 앞에서 설명한 1, 2, 5 번 작업은 create_hypertable() 함수가 담당하고, 
  • 3 번 작업은 자동 refresh 기능이 있는 진행형 구체화된 뷰를 만들어 처리하고, 
  • 4 번 작업은 청크 테이블 삭제 정책을 등록해서 처리합니다.
  • 윗 기능에다가 오래된 자료를 최대 90%까지 공간을 절약하는 읽기 전용 자료 압축 기능을 제공합니다. 
  • 또, 오래된 더 이상 변경이 되지 않을 자료에 대한 자동 cluster 명령 실행 기능(reorder라고 하네요)까지 덤으로 제공합니다.

장점

이런 것을 떠나서 이 확장 모듈의 백미는 이런 매력적인 기능들 보다, 응용프로그램 개발자가 시계열 자료 처리를 위해서 고생했던 성능 안나오는 부분 집계 작업, 이 빠진 자료 처리 방안 같은 것들을 time_bucket,  time_bucket_gapfill, locf, interpolate 같은 함수로 미리 다 만들어 놓았다는 것입니다. 

 

단점

여느 다른 시계열 데이터베이스보다 자료 입력 처리가 월등히 뛰어나지는 않습니다.  정말 어마무시한 자료를 순십간에 모두 처리해야 하는 요구사항이라면, 반드시 이 데이터베이스 앞에 실시간 처리용 무엇인가가 있어야합니다. 그것이 redis + grafana가 되든 엘라스틱이 되든간에, 전통적인 이중 기록 기법을 기반으로하는 관계형 데이터베이스가 감당하지 못할 것임을 염두해 두어야 합니다. 

 

이 모듈을 사용하겠다면, 다음 부분을 꼭 완벽하게 이해하고, 의도된 대로 작동하는지 꼭 확인하고 사용할 것을 알려드립니다. 

왜냐하면 그냥 도입했다가 다시 옛날로 돌아갈래, 이런 상황이 오면 그 작업량이 상당하기 때문입니다. 아쉽게도 이 부분에 대해서는 timescaledb 쪽에서 편하게 처리 하는 방법을 제공하고 있지는 않습니다. 

 

검토 대상

  • 담을 자료의 자료 구조
    현재, 시간과 그 외 부가 칼럼 하나까지만 합처서 하위 파티션을 만들 수 있습니다.  그 부가 칼럼은 해시 파티션 됩니다. 
    이 테이블은 참조키를 지정 할 수  없습니다. 이것도 고려해야 합니다.
  • 하나의 하위 파티션에 담길 자료량에 맞는 파티션 저장 기간 (통상 timescaledb 만든 쪽에서는 OS 메모리의 25%를 넘기지 않기를 권장하네요.)
  • 원천 자료 삭제 정책
  • 진행형 구체화 된 뷰(집계성 테이블)의 종류와 그 자료량, 오래된 집계 자료 삭제 방법과 정책
  • 자료 압축 정책 (압축 되면 DML이 안됩니다.)

 

마무리

PostgreSQL 확장 모듈 가운데 제대로 굵직한 모듈 하나를 살펴보았습니다. 이런 괜찮은 모듈들이 더 많아지고, 이것들이 다시 PostgreSQL 코어 개발 쪽에 다시 반영되어 점점 더 좋아지는 PostgreSQL이 되었으면 좋겠네요. 

이러기 위해서 보다 많이 써보고, 보다 많이 버그를 보고하고, 보다 많이 자기 생각을 개발자들과 나누고, 여건이 되면 그 개발에 참여하는 것이 필요합니다.