InfluxDB vs. TimescaleDB

1. Which Time-Series Database is Better: TimescaleDB vs InfluxDB
2. TimescaleDB vs. InfluxDB: purpose built differently for time-series data
3. SQL vs. Flux: Choosing the right query language for time-series data

Which Time-Series Database is Better: TimescaleDB vs InfluxDB

SQL vs. Flux: Choosing the right query language for time-series data

TimescaleDB vs. InfluxDB: purpose built differently for time-series data

Time-series DB 계의 대표적인 제품인 InfluxDB 와 TimescaleDB 비교 글들 몇 가지 읽고 핵심 내용만 발췌 요약.

리소스 사용량

• 디스크 사용량 : 대부분의 column-oriented 방식 DB와 마찬가지로 InfluxDB 가 훨씬 우수하다(cardinality 가 낮을 수록 - 중복도가 높은 경우 - 그 차이는 더 크다).
• 메모리 사용량 : cardinality 가 낮을 때는 InfluxDB 가 더 적게 사용하지만 cardinality 증가할 때 변동성(volatility)이 커서 cardinality 가 높아지면 InfluxDB 의 소비량이 TimescaleDB 보다 많아진다.
• 주목할 점 : InfluxDB 메모리 사용 한계치를 제한할 수 있는 방법이 없다는거다. 이때문에 insert 시 메모리 부족으로 DB 가 다운될 수도 있다고 한다. 

 

성능

• insert : cardinality 가 낮은 경우에는 InfluxDB 가 TimescaleDB 보다 2배 이상 우수하다. 하지만 cardinality 가 높아질 수록 InfluxDB 성능 저하가 큰 편이서 cardinality 가 어느 정도 이상되면 TimescaleDB 의 성능이 InfluxDB 보다 우수하게 나타난다.
• read : 간단한 query 에서는 둘이 큰 차이 없지만 query 복잡해질 수록 (월등히) TimescaleDB 가 우수하다.
• 주목할 점 : 100K+ 이상의 높은 cardinality 에서 InfluxDB 는 안전성과 성능에 문제가 있다고 한다. 

회사/커뮤니티 지원, 지원 툴 등의 부분은 스킵.

SQL 대 Flux

Flux 은 일부 작업을 간편하게 해줄 수 있지만 학습 곡선과 지원 도구의 문제가 따른다.

Flux 를 만들게 된 이유 2가지.

• time-series 데이터의 query 는 SQL 로는 어렵다.
• time-series 데이터의 query 에는 SQL 의 Relational algebra 보다 flow-based functional 모델이 더 적합하다.

TimescaleDB 엔지니어의 반론. 

1. Flux 구문이 상대적으로 덜 장황하긴 하지만 그것만으로 프로그래밍 언어의 복잡도가 낮아지는 건 아니다. 새로운 언어를 익히기 위한 학습 곡선과 특정 function 을 처음부터 새로 개발해야 하는 것 등 역시 고려되어야 한다.
   그리고 특정 도메인의 문제를 풀기 위해 SQL 확장성을 이용할 수 있는데 이때 기존 DB 지식을 활용할 수 있지만 비표준 언어로는 그것이 힘들다.
2. SQL 에서는 흐름 기반 처리에서 단계별 처리를 연결하여 점진적?/증분적? 으로 해결하는게 쉽지 않은게 사실이다. Flux 는 pipe-forward ("|>") 연산자 도입 등으로 사용자에게 더 큰 제어 기능을 제공하긴 하지만 반대급부로 이로 인해 DB 자체의 힘을 약화 - query planner 성능 저하 - 시켜 버렸다. 더 큰 제어권을 얻는 대신 사용자는 DB 전문 지식이 더 필요하게 돼버렸다.

그래서 ...

• InfluxDB
  • 데이터가 InfluxDB 에 적합하다면 그리고 향후 변경하지 않을거라면
  • 쉽게 시작할거라면 (schemaless 하니까)
  • 디스크 용량이 중요하다면
• TimescaleDB
  • 다양하고 복잡한 질의를 위해 관계형 모델이 필요하다면
  • 연관 프로그램이 요건에 따라 계속 변경, 진화되어야 한다면
  • 데이터의 cardinality 가 높다면, metrics 가 많다면