高性能 TSDB ベンチマーク VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics、TimescaleDB、InfluxDB を比較しました。 前の記事 40 の固有の時系列に属する XNUMX 億のデータ ポイントを含むデータセット上で。

数年前にはZabbixの時代がありました。 各ベア メタル サーバーには、CPU 使用率、RAM 使用率、ディスク使用率、ネットワーク使用率など、いくつかの指標しかありませんでした。 このようにして、数千のサーバーからのメトリクスを 40 の一意の時系列に適合させることができ、Zabbix は時系列データのバックエンドとして MySQL を使用できます :)

現在は一人で ノードエクスポーター デフォルト構成では、平均的なホストで 500 を超えるメトリックが提供されます。 沢山あります 輸出業者 さまざまなデータベース、Web サーバー、ハードウェア システムなどに使用されます。それらはすべて、さまざまな有用なメトリックを提供します。 全て ますます多くのアプリケーション さまざまな指標を自分たちで設定し始めます。 多くのメトリクスを公開するクラスターとポッドを備えた Kubernetes があります。 その結果、サーバーはホストごとに数千もの固有のメトリクスを公開することになります。 したがって、独自の 40K 時系列はもはやハイパワーではありません。 これは主流になりつつあり、単一サーバー上の最新の TSDB で簡単に処理できるはずです。

現時点での多数の一意の時系列は何ですか? おそらく400Kか4Mでしょうか？ それとも40m？ 最新の TSDB をこれらの数値と比較してみましょう。

ベンチマークのインストール

TSBS は、TSDB の優れたベンチマーク ツールです。 必要な時系列数を 10 で割った値 (フラグ) を渡すことで、任意の数のメトリクスを生成できます。 -規模 （前者 -scale-var）。 10 は、各ホストまたはサーバーで生成される測定値 (メトリック) の数です。 次のデータセットは、ベンチマークに TSBS を使用して生成されました。

• 400 万の一意の時系列、データ ポイント間の間隔は 60 秒、データは丸 3 日間にわたり、データ ポイントの合計数は約 1.7 億です。
• 4 万の一意の時系列、600 秒間隔、データ範囲は丸 3 日、合計データ ポイント数は約 1.7 億です。
• 40 万の一意の時系列、1 時間間隔、データ範囲は丸 3 日、合計データ ポイント数は約 2.8 億です。

クライアントとサーバーは専用のインスタンスで実行されていました n1-標準-16 Googleクラウドで。 これらのインスタンスには次の構成がありました。

• vCPU: 16
• RAM：60 GB
• ストレージ: 標準 1TB HDD。 120 Mbps の読み取り/書き込みスループット、750 秒あたり 1,5 の読み取り操作、XNUMX 秒あたり XNUMXK の書き込みを実現します。

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,6 秒あたり 3 万のデータ ポイント。 RAM使用量: 965 GB; ディスク上の最終データサイズ: XNUMX MB
• InfluxDB: 1.2 秒あたり 8.5 万のデータ ポイント。 RAM使用量: 1.6 GB; ディスク上の最終データサイズ: XNUMX GB
• タイムスケール: 849 秒あたり 2,5K データ ポイント。 RAM使用量: 50 GB; ディスク上の最終データサイズ: XNUMX GB

上記の結果からわかるように、挿入パフォーマンスと圧縮率では VictoriaMetrics が勝っています。 RAM 使用量ではタイムラインが優れていますが、データ ポイントごとに 29 バイトという大量のディスク領域を使用します。

以下は、ベンチマーク中の各 TSDB の CPU 使用率のグラフです。

上はスクリーンショットです: VictoriaMetrics - 固有の 400K メトリクスの挿入テスト中の CPU 負荷。

上はスクリーンショットです: InfluxDB - 固有メトリック 400K の挿入テスト中の CPU 負荷。

上はスクリーンショットです: TimescaleDB - 400K の一意のメトリックに対する挿入テスト中の CPU 負荷。

VictoriaMetrics は利用可能なすべての vCPU を使用しますが、InfluxDB は 2 個の vCPU のうち最大 16 個を十分に活用していません。

Timescale は 3 個の vCPU のうち 4 ～ 16 個のみを使用します。 TimescaleDB タイムスケール グラフ内の iowait と system の高い割合は、入出力 (I/O) サブシステムのボトルネックを示しています。 ディスク帯域幅使用率のグラフを見てみましょう。

上はスクリーンショットです: VictoriaMetrics - 固有のメトリクス 400K の挿入テストにおけるディスク帯域幅の使用量。

上はスクリーンショットです: InfluxDB - 固有メトリクス 400K の挿入テストでのディスク帯域幅使用量。

上はスクリーンショットです: TimescaleDB - 固有のメトリクス 400K の挿入テストでのディスク帯域幅使用量。

VictoriaMetrics は 20 Mbps でデータを記録し、最大 45 Mbps でデータを記録します。 ピークはツリー内の大きな部分的なマージに対応します LSM.

InfluxDB は 160 MB/秒でデータを書き込みますが、1 TB ドライブは 制限されるべきです 書き込みスループット 120 MB/秒。

TimescaleDB の書き込みスループットは 120 Mbps に制限されていますが、場合によってはこの制限を破り、ピーク値が 220 Mbps に達することがあります。 これらのピークは、前のグラフの不十分な CPU 使用率の谷に対応します。

入出力 (I/O) 使用率のグラフを見てみましょう。

上はスクリーンショットです: VictoriaMetrics - 400K の一意のメトリクスに対するテスト I/O 使用量を挿入します。

上はスクリーンショットです: InfluxDB - 400K の一意のメトリクスに対するテスト I/O 使用量を挿入します。

上はスクリーンショットです: TimescaleDB - 400K の一意のメトリクスに対するテスト I/O 使用量を挿入します。

TimescaleDB が I/O 制限に達しつつあるため、残り 12 個の vCPU を使用できないことが明らかになりました。

4M の固有の時系列

4M 時系列は少し難しそうです。 しかし、競合他社はこの試験に無事合格しています。 ベンチマーク結果:

• VictoriaMetrics: 2,2 秒あたり 6 万のデータ ポイント。 RAM使用量: 3 GB; ディスク上の最終データ サイズ: XNUMX GB。
• InfluxDB: 330 秒あたり 20,5K データ ポイント。 RAM使用量: 18,4 GB; ディスク上の最終データ サイズ: XNUMX GB。
• TimescaleDB: 480 秒あたり 2,5K データ ポイント。 RAM使用量: 52 GB; ディスク上の最終データ サイズ: XNUMX GB。

InfluxDB のパフォーマンスは、1,2 万時系列の 400 秒あたり 330 万データ ポイントから、4M 時系列の XNUMX 秒あたり XNUMX 万データ ポイントに低下しました。 これは、他の競合他社と比較して大幅なパフォーマンスの低下です。 この損失の根本原因を理解するために、CPU 使用率のグラフを見てみましょう。

上はスクリーンショットです: VictoriaMetrics - 固有の 4M 時系列の挿入テスト中の CPU 使用率。

上はスクリーンショットです: InfluxDB - 固有の 4M 時系列の挿入テスト中の CPU 使用率。

上はスクリーンショットです: TimescaleDB - 固有の 4M 時系列の挿入テスト中の CPU 使用率。

VictoriaMetrics は、処理装置 (CPU) の電力のほぼすべてを使用します。 最後のドロップは、すべてのデータが挿入された後の残りの LSM マージに対応します。

InfluxDB は 8 個の vCPU のうち 16 個のみを使用しますが、TimsecaleDB は 4 個の vCPU のうち 16 個を使用します。 彼らのグラフの共通点は何でしょうか? 高シェア iowait、これも I/O ボトルネックを示しています。

TimescaleDBは高いシェアを誇る system。 高電力の結果、多くのシステムコールまたは多数のコールが発生したと想定します。 マイナーページフォールト.

ディスク スループットのグラフを見てみましょう。

上はスクリーンショットです: VictoriaMetrics - ディスク帯域幅を使用して 4M の一意のメトリクスを挿入します。

上はスクリーンショットです: InfluxDB - ディスク帯域幅を使用して 4M の固有のメトリクスを挿入します。

上はスクリーンショットです: TimescaleDB - ディスク帯域幅を使用して 4M の一意のメトリクスを挿入します。

VictoriaMetrics はピーク時に 120 MB/秒の制限に達しましたが、平均書き込み速度は 40 MB/秒でした。 ピーク中に数回の強力な LSM 融合が実行された可能性があります。

InfluxDB は、書き込み制限が 200 MB/秒のディスク上で、平均書き込みスループットが 340 MB/秒、ピーク時に最大 120 MB/秒を絞り出します :)

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 秒あたり 29 万のデータ ポイント。 RAM使用量: 17 GB; ディスク容量の使用量: XNUMX GB。
• InfluxDB: 60GB を超える RAM が必要だったので完了しませんでした。
• TimescaleDB: 330 秒あたり 2,5K データ ポイント、RAM 使用量: 84 GB。 ディスク容量の使用量: XNUMXGB。

TimescaleDB は、固有の 2,5M および 4K メトリクスと同じ 400 GB で、非常に低く安定した RAM 使用量を示しています。

VictoriaMetrics は、100 万個のタグ付きメトリクス名がすべて処理されるまで、40 秒あたり 1,5 データ ポイントの速度でゆっくりとスケールアップしました。 その後、2,0 秒あたり 1,7 ～ XNUMX 万のデータ ポイントの持続的な挿入速度を達成したため、最終結果は XNUMX 秒あたり XNUMX 万のデータ ポイントになりました。

40 万の固有時系列のグラフは、4 万の固有時系列のグラフと似ているため、スキップしましょう。

所見

• 最新の 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