고성능 TSDB 벤치마크 VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB 및 InfluxDB는 다음에서 비교되었습니다. 이전 기사 40K 고유 시계열에 속하는 XNUMX억 개의 데이터 포인트가 있는 데이터세트에 대해

몇 년 전, Zabbix의 시대가 있었습니다. 각 베어메탈 서버에는 CPU 사용량, RAM 사용량, 디스크 사용량, 네트워크 사용량 등 몇 가지 지표만 있었습니다. 이렇게 하면 수천 대의 서버에서 얻은 측정 항목을 40만 개의 고유한 시계열에 맞출 수 있으며 Zabbix는 MySQL을 시계열 데이터의 백엔드로 사용할 수 있습니다. :)

현재 혼자 node_exporter 기본 구성을 사용하면 평균 호스트에서 500개 이상의 측정항목을 제공합니다. 많이있다 수출업자 다양한 데이터베이스, 웹 서버, 하드웨어 시스템 등에 대해 다양하고 유용한 측정항목을 제공합니다. 모두 점점 더 많은 응용 프로그램 스스로 다양한 지표를 설정하기 시작합니다. 많은 지표를 노출하는 클러스터와 포드가 있는 Kubernetes가 있습니다. 이로 인해 서버는 호스트당 수천 개의 고유한 측정항목을 노출하게 됩니다. 따라서 고유한 40K 시계열은 더 이상 고전력이 아닙니다. 이는 주류가 되고 있으며 단일 서버의 모든 최신 TSDB에서 쉽게 처리되어야 합니다.

현재 대량의 고유한 시계열은 무엇입니까? 아마도 400K 또는 4M일까요? 아니면 40m? 최신 TSDB를 이 수치와 비교해 보겠습니다.

벤치마크 설치

TSBS TSDB를 위한 훌륭한 벤치마킹 도구입니다. 필요한 시계열 수를 10으로 나눈 값을 전달하여 임의 수의 측정항목을 생성할 수 있습니다. 플래그 -규모 (이전의 -scale-var). 10은 각 호스트 또는 서버에서 생성된 측정값(메트릭) 수입니다. 벤치마크를 위해 TSBS를 사용하여 다음 데이터 세트가 생성되었습니다.

• 400K 고유 시계열, 데이터 포인트 간 60초 간격, 데이터는 전체 3일에 걸쳐 있으며 총 데이터 포인트 수는 최대 1.7억 개입니다.
• 4M 고유 시계열, 600초 간격, 데이터는 3일 동안 지속되며 총 데이터 포인트 수는 ~1.7억 개입니다.
• 40천만 개의 고유한 시계열, 1시간 간격, 데이터는 3일 동안, 총 데이터 포인트 수는 ~2.8억 개입니다.

클라이언트와 서버가 전용 인스턴스에서 실행 중이었습니다. n1-표준-16 Google 클라우드에서. 이러한 인스턴스의 구성은 다음과 같습니다.

• vCPU: 16
• RAM : 60GB
• 저장공간: 표준 1TB HDD. 120Mbps 읽기/쓰기 처리량, 초당 750회의 읽기 작업 및 초당 1,5K 쓰기를 제공합니다.

TSDB는 공식 Docker 이미지에서 추출되었으며 다음 구성으로 Docker에서 실행되었습니다.

• 빅토리아메트릭스:

  docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics

• 고전력을 지원하려면 InfluxDB(-e) 값이 필요합니다. 선적 서류 비치):

  docker run -it --rm -p 8086:8086 
  -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 
  -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g 
  -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 
  -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb

• TimescaleDB(구성은 다음에서 가져옴) 그것 파일):

MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432 
--shm-size=${SHARED}MB 
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data 
timescale/timescaledb:latest-pg10 postgres 
-cmax_wal_size=${WAL}MB 
-clog_line_prefix="%m [%p]: [%x] %u@%d" 
-clogging_collector=off 
-csynchronous_commit=off 
-cshared_buffers=${SHARED}MB 
-ceffective_cache_size=${CACHE}MB 
-cwork_mem=${WORK}MB 
-cmaintenance_work_mem=${MAINT}MB 
-cmax_files_per_process=100

데이터 로더는 16개의 병렬 스레드로 실행되었습니다.

이 문서에는 삽입 벤치마크 결과만 포함되어 있습니다. 선별적 벤치마크 결과는 별도의 기사로 공개될 예정입니다.

400K 고유 시계열

간단한 요소인 400K부터 시작하겠습니다. 벤치마크 결과:

• VictoriaMetrics: 초당 2,6M 데이터 포인트; RAM 사용량: 3GB; 디스크의 최종 데이터 크기: 965MB
• InfluxDB: 초당 1.2M 데이터 포인트; RAM 사용량: 8.5GB; 디스크의 최종 데이터 크기: 1.6GB
• 기간: 초당 849K 데이터 포인트; RAM 사용량: 2,5GB; 디스크의 최종 데이터 크기: 50GB

위 결과에서 볼 수 있듯이 삽입 성능과 압축률에서는 VictoriaMetrics가 승리합니다. 타임라인은 RAM 사용량 측면에서 우위에 있지만 데이터 포인트당 29바이트라는 많은 디스크 공간을 사용합니다.

다음은 벤치마크 중 각 TSDB의 CPU 사용량 그래프입니다.

위 스크린샷은 다음과 같습니다. VictoriaMetrics - 고유한 400K 측정항목에 대한 삽입 테스트 중 CPU 로드입니다.

위 스크린샷은 다음과 같습니다: InfluxDB - 고유 메트릭 400K에 대한 삽입 테스트 중 CPU 로드.

위 스크린샷은 다음과 같습니다. TimescaleDB - 400K의 고유 측정항목에 대한 삽입 테스트 중 CPU 로드입니다.

VictoriaMetrics는 사용 가능한 모든 vCPU를 사용하는 반면 InfluxDB는 vCPU 2개 중 ~16개를 충분히 활용하지 않습니다.

Timescale은 vCPU 3개 중 4~16개만 사용합니다. TimescaleDB 시간 척도 그래프에서 iowait 및 system의 비율이 높으면 I/O(입/출력) 하위 시스템에 병목 현상이 있음을 나타냅니다. 디스크 대역폭 사용량 그래프를 살펴보겠습니다.

위 스크린샷은 VictoriaMetrics - Unique Metrics 400K에 대한 삽입 테스트의 디스크 대역폭 사용량입니다.

위는 스크린샷입니다: InfluxDB - 고유 지표 400K에 대한 삽입 테스트 시 디스크 대역폭 사용량.

위 스크린샷은 TimescaleDB - 고유 측정항목 400K에 대한 삽입 테스트 시 디스크 대역폭 사용량입니다.

VictoriaMetrics는 20Mbps의 속도로 데이터를 기록하며 최대 속도는 45Mbps입니다. 피크는 트리의 대규모 부분 병합에 해당합니다. NGO.

InfluxDB는 160MB/s의 속도로 데이터를 쓰는 반면 1TB 드라이브는 제한되어야 한다 쓰기 처리량 120MB/s.

TimescaleDB는 쓰기 처리량을 120Mbps로 제한하지만 때로는 이 제한을 깨고 최대 값이 220Mbps에 도달합니다. 이러한 최고점은 이전 그래프에서 CPU 사용률이 부족한 최저점에 해당합니다.

입출력(I/O) 사용량 그래프를 살펴보겠습니다.

위 스크린샷은 다음과 같습니다. VictoriaMetrics - 400K 고유 지표에 대한 테스트 I/O 사용량을 삽입합니다.

위 스크린샷은 다음과 같습니다. InfluxDB - 400K 고유 지표에 대한 테스트 I/O 사용량을 삽입합니다.

위 스크린샷은 다음과 같습니다. TimescaleDB - 400K 고유 지표에 대한 테스트 I/O 사용량을 삽입합니다.

이제 TimescaleDB가 I/O 제한에 도달하여 나머지 12개의 vCPU를 사용할 수 없다는 것이 분명해졌습니다.

4M 고유 시계열

4M 시계열은 약간 어려워 보입니다. 하지만 우리 경쟁자들은 이 시험을 성공적으로 통과했습니다. 벤치마크 결과:

• VictoriaMetrics: 초당 2,2M 데이터 포인트; RAM 사용량: 6GB; 디스크의 최종 데이터 크기: 3GB.
• InfluxDB: 초당 330K 데이터 포인트; RAM 사용량: 20,5GB; 디스크의 최종 데이터 크기: 18,4GB.
• TimescaleDB: 초당 480K 데이터 포인트; RAM 사용량: 2,5GB; 디스크의 최종 데이터 크기: 52GB.

InfluxDB 성능은 1,2K 시계열의 경우 초당 400M 데이터 포인트에서 330M 시계열의 경우 초당 4K 데이터 포인트로 떨어졌습니다. 이는 다른 경쟁사에 비해 상당한 성능 손실이다. 이 손실의 근본 원인을 이해하기 위해 CPU 사용량 그래프를 살펴보겠습니다.

위 스크린샷은 다음과 같습니다. VictoriaMetrics - 고유한 4M 시계열에 대한 삽입 테스트 중 CPU 사용량입니다.

위 스크린샷은 다음과 같습니다: InfluxDB - 고유한 4M 시계열에 대한 삽입 테스트 중 CPU 사용량.

위 스크린샷은 TimescaleDB - 고유한 4M 시계열에 대한 삽입 테스트 중 CPU 사용량입니다.

VictoriaMetrics는 거의 모든 처리 장치(CPU) 전력을 사용합니다. 끝에 있는 드롭은 모든 데이터가 삽입된 후 나머지 LSM 병합에 해당합니다.

InfluxDB는 vCPU 8개 중 16개만 사용하는 반면 TimsecaleDB는 vCPU 4개 중 16개를 사용합니다. 그들의 그래프에는 어떤 공통점이 있나요? 높은 점유율 iowait, 이는 다시 I/O 병목 현상을 나타냅니다.

TimescaleDB의 점유율이 높습니다 system. 우리는 높은 전력으로 인해 많은 시스템 호출이 발생하거나 다수의 시스템 호출이 발생한다고 가정합니다. 사소한 페이지 오류.

디스크 처리량 그래프를 살펴보겠습니다.

위 스크린샷은 다음과 같습니다. VictoriaMetrics - 디스크 대역폭을 사용하여 4M 고유 메트릭을 삽입합니다.

위 스크린샷은 다음과 같습니다. InfluxDB - 디스크 대역폭을 사용하여 4M 고유 메트릭을 삽입합니다.

위 스크린샷은 다음과 같습니다. TimescaleDB - 디스크 대역폭을 사용하여 4M 고유 메트릭을 삽입합니다.

VictoriaMetrics는 최대 120MB/s 제한에 도달했으며 평균 쓰기 속도는 40MB/s였습니다. 피크 동안 여러 번의 무거운 LSM 융합이 수행되었을 가능성이 높습니다.

InfluxDB는 쓰기 제한이 200MB/s인 디스크에서 최대 340MB/s의 평균 쓰기 처리량 120MB/s를 다시 한번 짜냈습니다. :)

TimescaleDB는 더 이상 디스크 제한이 없습니다. 높은 비율과 관련된 다른 것에 의해 제한되는 것으로 보입니다. системной CPU 부하.

IO 사용량 그래프를 살펴보겠습니다.

위 스크린샷은 VictoriaMetrics - 고유한 4M 시계열에 대한 삽입 테스트 중에 I/O를 사용하는 것입니다.

위 스크린샷은 다음과 같습니다. InfluxDB - 고유한 4M 시계열에 대한 삽입 테스트 중에 I/O 사용.

위 스크린샷은 TimescaleDB - 고유한 4M 시계열에 대한 삽입 테스트 중 I/O 사용량입니다.

IO 사용 패턴은 디스크 대역폭 패턴을 반영합니다. InfluxDB는 IO가 제한되어 있는 반면 VictoriaMetrics 및 TimescaleDB에는 여유 IO 리소스가 있습니다.

40천만 개의 고유한 시계열

40천만 개의 고유 시계열은 InfluxDB에 비해 너무 컸습니다 :)

벤치마크 결과:

• VictoriaMetrics: 초당 1,7만 데이터 포인트; RAM 사용량: 29GB; 디스크 공간 사용량: 17GB.
• InfluxDB: 60GB 이상의 RAM이 필요해서 완료되지 않았습니다.
• TimescaleDB: 초당 330K 데이터 포인트, RAM 사용량: 2,5GB; 디스크 공간 사용량: 84GB.

TimescaleDB는 고유한 2,5M 및 4K 측정항목과 마찬가지로 400GB에서 매우 낮고 안정적인 RAM 사용량을 보여줍니다.

VictoriaMetrics는 100천만 개의 태그가 지정된 지표 이름이 모두 처리될 때까지 초당 40개 데이터 포인트의 속도로 천천히 확장되었습니다. 그런 다음 그는 초당 1,5-2,0M 데이터 포인트의 지속적인 삽입 속도를 달성했으므로 최종 결과는 초당 1,7M 데이터 포인트였습니다.

40M 고유 시계열에 대한 그래프는 4M 고유 시계열에 대한 그래프와 유사하므로 건너뛰겠습니다.

조사 결과

• 최신 TSDB는 단일 서버에서 수백만 개의 고유한 시계열에 대한 삽입을 처리할 수 있습니다. 다음 기사에서는 TSDB가 수백만 개의 고유한 시계열에서 선택을 얼마나 잘 수행하는지 테스트합니다.
• CPU 사용률이 부족하면 일반적으로 I/O 병목 현상이 발생함을 나타냅니다. 또한 한 번에 몇 개의 스레드만 실행할 수 있어 차단이 너무 거칠다는 것을 나타낼 수도 있습니다.
• I/O 병목 현상은 특히 클라우드 공급자의 가상화된 블록 장치와 같은 비 SSD 스토리지에서 존재합니다.
• VictoriaMetrics는 느리고 낮은 I/O 스토리지에 대한 최상의 최적화를 제공합니다. 최고의 속도와 최고의 압축률을 제공합니다.

다운로드 VictoriaMetrics 단일 서버 이미지 데이터에 사용해 보세요. 해당 정적 바이너리는 다음에서 사용할 수 있습니다. GitHub의.

여기에서 VictoriaMetrics에 대해 자세히 알아보세요. 기사.

업데이트: 게시됨 VictoriaMetrics와 InfluxDB의 삽입 성능을 비교하는 기사 재현 가능한 결과를 제공합니다.

업데이트 #2: 또한 읽어보세요 수직 확장성에 관한 기사 VictoriaMetrics vs InfluxDB vs TimescaleDB.

업데이트 #3: VictoriaMetrics는 이제 오픈 소스입니다.!

번역: https://t.me/VictoriaMetrics_ru1

출처 : habr.com