[개발생각] PostgreSQL의 하이퍼테이블 사용

기존에 통계 데이터를 minute, hour, day, month등의 테이블로 나누고, 테이블에 날짜키로 Insert를 했었다...

 

 

일반적인 데이터의 크기라면 상관이 없지만, 데이터가 빅데이터 수준으로 늘어나게 되면,

여러가지 문제가 생긴다.

 

인덱스가 커지게 되고, 해당 인덱스을 메모리상에 올리지 못하게 될때는, 디스크 IO가 폭발적으로 발생할수있다.

로우 삭제가 있는 테이블이라면, 추후에 VACUUM 오버헤드가 엄청나게 들어나게 된다.

(VACUUM 작업은 그냥 디스크 정리 같은거라고 생각하면 쉽다.)

삭제된 로우를 실제적으로 정리하면서, 인덱스도 지우고, 디스크도 정리하고 하는 작업인데,

테이블의 데이터가 빅데이터라면, cpu 오버헤드가 상당해진다.

 

이런 단점을 극복하기위해서 PostgreSQL은 extension으로 TimescaleDB기능인 하이퍼테이블을 지원한다.

해당 하이퍼테이블은 시계열 테이블이다.

 

하이퍼테이블은 일반 테이블처럼 하나의 물리 테이블이 아닌,

특정 시간대의 chunk로 데이터를 작게 나눠서 저장하기에, 데이터 조회/삭제/인덱스생성등의 작업등의 여러 오버헤드를 줄일수있다.

삭제나, 조회시 해당 chunk단위로만 동작하기에, 전체 데이터를 대상으로 동작하지 않기에,

훨씬 적은 데이터 대상으로 빠르게 처리가 가능하다.

 

또한 time_bucket 기능으로 특정 시간동안의 데이터를 어그리게이션(집계)하여 테이블에 반영할수도있어서,

기존처럼 minute, hour, day, month별 테이블에 각각 집계하여 insert하거나 집계 배치등을 통하지 않아도,

단순 쿼리를 통해, minute, hour,day, month등의 기준으로 자동으로 집계를 하도록 설정을 할수있다.

(이게 정말 개꿀이다!! 심지어 성능도 더 좋다니!!!)

 

이번 프로젝트에서도, 기존 통계테이블을 없애고, 하이퍼테이블과 타임버킷을 통해,

통계데이터를 PostgreSQL 쿼리만으로 집계하도록 바꿨다.

기존 집계하는 배치를 없앴고, PostgreSQL기능으로 집계가 자동적으로 되기에,

성능과 유지보수에도 더 좋아지게 되었다.

 

프로젝트 시작 초기에, ClickHouse디비를 눈여겨 봤었다...

상당히 빠른 시계열 컬럼디비로 파악을 했는데... 아쉽게도 이번 프로젝트에는 도입을 하지않았다.

도입을 하지않은 가장큰이유는,

너무나 생소하고 처음인 디비였기에, 성능, 기능이 아무리 뛰어나다고 하더라도, 

운영/노하우가 쌓이이지 않은 솔류션을 중요한 프로젝트에 바로 도입하기는 부담이 되었기 때문이다.

좀더 시간이 있었더라면, 여러 실험이나 테스트를 했겠지만, 

실험이나 테스트에서도 나오지 않는 여러 트러블등은 역시나... 운영하면서 100% 발생한다.

이때, 빠르게 대응하지 못한다면, 큰 부담으로 다가온다...

(이번에는 아쉽게 패쓰!!!!)

 

다음에 ClickHouse를 도입할수있으면 한번 해보고 싶긴하다... 빅데이터에서의 컬럼형 디비는 엄청나게 빠르니까!!!

(컬럼디비의 원조는 hbase가 아닐까?!! ㅋㅋ hbase의 column family개념이 컬럼 개념이였던듯!)