TimescaleDB
- PostgreSQL extension 의 일종으로 사용된다.
- PosgreSQL server 내에, 동일한 프로세스에서 실행된다.
- TimescaleDB를 사용하는 PosgreSQL DB에 있어서
연산은 먼저 TimescaleDB에 의해 처리되어,
TimescaleDB의 데이터 구조에 따라 어떻게 execute 될지 등이 결정된다.
- extension 으로써 구현되었다는 점으로 인해,
TimscaleDB 는 PostgreSQL 이 가지는 풍부한 기능 및 이점을 두루 활용할 수 있다.
- RDBMS로써, 마찬가지로 SQL 문법을 따른다.
- 시계열(time-series)에 대한 data 및 분석에 특화되어있다.
- hyperfunction 이라는 내장 함수를 사용한 query를 통해,
time-series data 처리 성능이 극대화 된다.
- hypertable 을 이용하게 된다.
- 물론, 해당 DB에서는 PostgreSQL table 도 함께 사용할 수 있다.
- 초 당, 그리고 노드 당 수백 만의 data point 를 write 한다.
- 수평적 확장에 용이하다. (cardinality)
- 최적의 알고리즘을 통해 94~97%의 압축률을 보여, 그만한 비용을 줄일 수 있다.
- 데이터 관리 기능도 지원한다.
- 압축, down-sampling, 데이터 수명 관리, 데이터 계층화 등이 있다.
- AWS 등 Cloud를 통해, fully-managed로 이용할 수도 있다.
- RDS 통한 것이 아니라, Cloud를 이용한 TimescaleDB instance를 제공받는 것이다.
- 자체 호스팅 방식으로 사용한다면,
PostgreSQL 인스턴스에 timescaleDB를 확장으로써 추가하는 것이다.
time-series data
- 시간 별로 수집 된 데이터를 통해, 시간 변화에 따른 양상을 쉽게 파악하여 분석에 활용한다.
- 주로 주가, CPU/memory 사용률, netwrok traffic 등에 시계열 데이터를 활용하곤 한다.
- 시간에 따른 값의 변화를 통해, 동향 파악 및 분석, 혹은 모니터링에 용이하다.
- 특히, 상관 관계가 있는 것들을 같이 묶어서 볼 수 있다는 점에서도 활용도가 크다.
- 시간이 중심이므로, timestamp 따위를 활용하게 된다.
- 거의 INSERT로 쓰인다.
- 보통, 시간 간격에 따라 새로운 데이터가 생성되어 쌓일 뿐이고
이전의 데이터를 UPDATE 하거나 누락된 데이터를 채워 넣는 일은 거의 없다.
- 데이터 변경 시에도, overwrite(덮어쓰기)가 아닌 INSERT 방식이다.
hypertable
- time-series data 다루기에 특화되어 있다.
- hypertable 내부에서 time-series data들은
time interval 을 기반으로 partition 된 chunk 들로써 구성된다.
- chunk는, PostgreSQL 테이블에 해당한다.
hypertable은, 이러한 테이블의 상위 테이블 격에 해당한다.
- hypertable 이용하는 입장에서는
일반 SQL 테이블을 이용하는 것과 이질감이 없도록 구현되어 있다.
- 이러한 구조는 TimescaleDB의 지속적인 집계, 압축, 보존 정책 등을 가능하게 해준다.
- storage를 절약하기 위해 데이터를 압축할 수 있는데, 기본적으로 chunk의 age에 따라
기존의 행 중심에서 열 중심으로 변환하여 압축한다는 특징이 있다.
- 이는, 긴 시간 범위의 데이터들에 대해 소량의 컬럼들을 쿼리할 때에 효율적이다.
(즉, 오래된 chunk 를 이용하게 될 때를 일컫는다.)
- 시계열 데이터를 다루는 APP에서는 보통
일정 기간 동안에 대한 raw data 만을 저장하고,
데이터 보존 규칙을 준수하기 위함 등의 이유로
오래된 data 는 삭제하거나 더 저렴한 storage 로 옮기는 형태이다.
- time 값을 기반으로 chunk 로써 삭제할 수 있다.
chunk 를 삭제한다는 것은 disk 에서 해당 file 을 통째로 삭제하는 것이므로,
개별 data를 삭제하는 것보다 빠르다.
(개별 data를 삭제하는 것은 테이블 조각 모음과 garbage collect에 대한
VACCUM 작업 비용이 많이 든다)
- 데이터 보존 정책을 통해, 데이터 삭제를 자동화를 쉽게 할 수 있다.
(혹은, 더 저렴한 storage 로 옮기는 tiering(계층화)을 해도 좋다.)
- partitioning 시 chunk size(
chunk_time_interval)는,
각기 활성화된 hypertable 로부터, index 크기도 고려한 하나의 chunk 가,
memory의 25% 이내에서 할당될 수 있게 세팅하도록 권장한다.
- 메모리가 64GB인 경우, 하루에 2/10GB 데이터를 write 한다면 1주일/일
- 적절한 chunk size 에 따라, 같은 chunk에 저장되는 근처의 range에 대한 data는
disk가 아닌 memory에서 가져오게 되기 때문에,
빠른 insert 및 query 성능을 기대할 수 있다.
- 모든 데이터에 걸친 global index 가 아닌
각 chunk에 local index를 두는 방식을 채택하여,
chunk의 data와 index가 memory에 함께 남게 된다.
- chunk size를 memory에 맞추는 것이 최고의 성능을 내긴 하지만
LRU(Least Recently Userd) caching 을 통해, 더 큰 chunk 일 때도 잘 동작할 수 있게 한다.
- chunk 내에서 data를 재정렬함으로써, query의 속도를 향상시킬 수도 있다.
- 대부분의 time-series data들이 시간 순서에 따라 insert 된다는 점에서
시간 기반의 chunk가 근처 시간 range의 data insert에 있어서는 효율적이게 해주지만
이러한 시간 순은, 오래된 데이터를 가지고 분석하는 query를 할 때에는
덜 효율적일 수 있다.
이 때, application 에서 주로 사용하는 query 패턴에 맞게,
chunk를 더 나은 방식으로 재정렬할 수 있다.
