시계열 데이터베이스는 시간에 따라 변하는 데이터를 저장하기 위해 설계되었습니다. 이것은 시간이 지남에 따라 수집된 모든 종류의 데이터일 수 있습니다. 예를 들어, 어떤 시스템에서 수집한 메트릭들이 이에 해당합니다.
우리는 다양한 종류의 시계열 데이터베이스를 가지고 있는데, 어떤 것을 사용해야 할까요? 이 글에서는 TimescaleDB와 InfluxDB, 두 주요 옵션 사이의 주요 차이점을 살펴볼 것입니다.
InfluxDB
InfluxDB는 InfluxData에 의해 만들어졌습니다. 이것은 Go 언어로 작성된 맞춤형, 오픈 소스, NoSQL 시계열 데이터베이스입니다.
이 데이터 저장소는 InfluxQL이라고 하는 SQL과 유사한 언어를 제공하여 개발자들이 자신들의 애플리케이션에 쉽게 통합할 수 있습니다. 또한 Flux라는 새로운 맞춤형 쿼리 언어도 있습니다. 이 언어는 일부 작업을 더 쉽게 만들 수 있지만, 맞춤형 쿼리 언어를 채택할 때 항상 학습 곡선이 있습니다.
Flux Query Example
from(db:"testing")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> exponentialMovingAverage()
- 이 데이터베이스에서는 각 측정값이 타임스탬프와 연관된 태그 세트와 필드 세트를 가집니다. 필드는 실제 측정 읽기 값들을 나타내며, 태그는 측정값들을 설명하는 메타데이터를 나타냅니다.
- 필드 데이터 유형은 float, int, string, boolean으로 제한되며, 데이터를 다시 쓰지 않고는 변경할 수 없습니다. 태그 값은 인덱싱됩니다. 이들은 문자열로 표현되며 업데이트할 수 없습니다.
- InfluxDB는 스키마나 인덱스를 만드는 것에 대해 걱정할 필요 없이 시작하기 쉽습니다. 그러나, 추가 인덱스를 만들거나, 연속 필드에 인덱스를 만들거나, 사후에 메타데이터를 업데이트하거나, 데이터 유효성을 강제하는 등의 능력이 없어 꽤 제한적이고 경직되어 있습니다.
- InfluxDB는 스키마가 없는 것이 아닙니다. 입력 데이터로부터 자동으로 생성되는 기본 스키마가 있습니다.
- InfluxDB는 장애 허용, 고가용성, 백업/복원과 같은 여러 도구를 처음부터 구현해야 했으며, 디스크 신뢰성에 대해 책임을 져야 합니다. 이러한 도구들과 많은 기능들, 예를 들어 HA는 엔터프라이즈 버전에서만 사용할 수 있습니다.
- InfluxDB 백업 도구는 전체 또는 증분 백업을 수행할 수 있으며, 특정 시점 복구에 사용할 수 있습니다.
- InfluxDB는 PostgreSQL 및 TimescaleDB보다 디스크 압축이 뛰어납니다.
TimescaleDB
TimescaleDB는 빠른 삽입과 복잡한 쿼리에 최적화된 오픈 소스 시계열 데이터베이스로, 전체 SQL을 지원합니다. PostgreSQL을 기반으로 하며, 시계열 데이터를 위한 NoSQL과 관계형 세계의 최고를 제공합니다.
이것은 TimescaleDB 쿼리 예제입니다
SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM testing
WHERE measurement = cpu and time > now() - '1 hour';
- TimescaleDB는 PostgreSQL 확장으로서 관계형 데이터베이스입니다.
- 이것은 새로운 사용자들에게 짧은 학습 곡선을 제공하고, pg_dump 또는 pg_backup과 같은 백업 도구와 고가용성 도구를 상속한다는 것을 의미합니다. 이것은 다른 시계열 데이터베이스에 비해 장점입니다.
- 또한 주된 복제 방법으로 스트리밍 복제를 지원하며, 고가용성 설정에서 사용할 수 있습니다. 장애 복구 및 백업과 관련하여, ClusterControl과 같은 외부 시스템을 사용하여 이 과정을 자동화할 수 있습니다.
- TimescaleDB에서는 각 시계열 측정값이 자신만의 행에 시간 필드와 그 뒤를 이어 여러 필드로 기록됩니다. 이 필드들은 float, int, string, boolean, 배열, JSON 블롭, 지리공간 차원, 날짜/시간/타임스탬프, 화폐, 바이너리 데이터 등이 될 수 있습니다.
- 필드(표준 인덱스), 여러 필드(복합 인덱스), 함수와 같은 표현식 또는 행의 부분 집합(부분 인덱스)에 대한 인덱스를 만들 수 있습니다. 이러한 필드 중 어느 하나를 부차적인 테이블로의 외래 키로 사용할 수 있으며, 이 테이블은 추가 메타데이터를 저장할 수 있습니다. 이와 같은 방식으로, 시스템에 필요한 스키마와 인덱스를 선택해야 합니다.
Performance
성능에 대해 이야기하자면, TimescaleDB comparison 블로그를 확인할 수 있습니다. 거기에서는 차트와 메트릭을 포함하여 두 데이터베이스 간의 상세한 성능 비교가 있습니다. 이 블로그에서 가장 중요한 정보 몇 가지를 살펴보겠습니다.
Insert
- 매우 낮은 카디널리티(예: 100개 장치)를 가진 워크로드의 경우 InfluxDB가 TimescaleDB보다 성능이 좋습니다.
- 카디널리티가 증가함에 따라 InfluxDB의 삽입 성능이 TimescaleDB보다 빠르게 떨어집니다.
- 중간에서 높은 카디널리티(예: 100개 장치에서 10개 메트릭 전송)를 가진 워크로드의 경우 TimescaleDB가 InfluxDB보다 성능이 좋습니다.
Read latency
- 간단한 쿼리의 경우 결과가 상당히 다양합니다. 어떤 경우에는 한 데이터베이스가 다른 것보다 확실히 우수한 반면, 다른 경우에는 데이터셋의 카디널리티에 따라 달라집니다. 이 차이는 종종 한 자리수에서 두 자리수 밀리초 범위에 있습니다.
- 복잡한 쿼리의 경우 TimescaleDB는 InfluxDB보다 훨씬 뛰어난 성능을 보이며, 더 다양한 쿼리 유형을 지원합니다. (여기서의 차이는 종종 몇 초에서 수십 초 범위에 있습니다.)
참고 :
'Database.' 카테고리의 다른 글
TimescaleDB는 무엇인가? (0) | 2023.12.29 |
---|---|
[MariaDB] ERROR 2002 (HY000): Can't connect to local server through socket '/tmp/mysql.sock' (1) | 2022.01.31 |