TDengine 3.0のパフォーマンスはどのくらいですか? ワンクリックで IoT シナリオで TSBS テスト結果を再現する方法を説明します

つい最近、TSBS に基づいて、TDengine 3.0 テスト レポート シリーズの第 1 号「DevOps シナリオにおける TDengine 3.0 比較テスト レポート」をリリースしました。このレポートでは、時系列データ シナリオに基づいて TDengine の独自のアーキテクチャを検証しました。パフォーマンス上の利点とコスト管理レベルをもたらしました。この号では、引き続き、IoT シナリオでの書き込みおよびクエリにおける TDengine のパフォーマンスを TimescaleDB および InfluxDB と比較して調査していきます。「IoT シナリオにおける TDengine 3.0 パフォーマンス比較分析レポートはこちらです!」」は、時系列データベース (Time Series Database) の選択要件の開発者の参考として参照してください。

このレポートは、5 つのシナリオすべてで、TDengine の書き込みパフォーマンスが TimescaleDB および InfluxDB の書き込みパフォーマンスよりも優れていることを示しています。書き込みパフォーマンスは、TimescaleDB の最大 3.3 倍、InfluxDB の最大 16.2 倍であり、さらに、TDengine は書き込みプロセス中のコンピューティング (CPU) リソースとディスク IO オーバーヘッドの消費が最小限です。クエリに関しては、ほとんどのクエリ タイプにおいて、TDengine のパフォーマンスは InfluxDB や TimescaleDB よりも優れており、TDengine は複雑な混合クエリにおいて大きな利点を示しています。平均負荷とブレイクダウン頻度のクエリ パフォーマンスは、InfluxDB の 426 倍、53 倍です。 ; daily-activity と avg-load のクエリ パフォーマンスは、TimescaleDB の 34 倍と 23 倍です。 

この記事では、レポート結果の検証を容易にするために、テストデータや環境構築、その他のリンクを一つずつ説明し、必要な開発者がアクセスしてコピーできるようにします。さらに、このテスト レポートのデータは、物理環境を準備した後、ワンクリックでスクリプトを実行することで生成できます。テスト手順についてもこの記事で説明します。

1. テストの背景

1. テストシナリオの概要

このテストレポートでは、TSBS の IoT シナリオを基本データセットとして使用し、TSBS のフレームワークの下で仮想運送会社のフリートのトラック群の時系列データをシミュレートしました。各トラックには、3 つの測定値と 1 つの（ナノ秒分解能）タイムスタンプ、8 つのタグ値が含まれ、トラックのインジケーター情報（読み取り値）レコードには、7 つの測定値と 1 つ（ナノ秒分解能）のタイムスタンプ、8 つのタグ値が含まれます。データのスキーマ（スキーマ）は下図のとおりで、生成されたデータは10秒ごとに記録されます。IoT シナリオでは環境要因が導入されるため、各トラックには順序付けされていない欠落した時系列データが存在します。

サンプルデータ

ベンチマーク パフォーマンス評価全体には、次の 5 つのシナリオが含まれます。各シナリオの具体的なデータ規模と特性は、次の表に示されています。データが欠落しているため、単一のトラック データ レコードの平均値が取得されます。

	シーン 1 100 デバイス × 10 メトリクス	シナリオ 2 4,000 デバイス × 10 メトリクス	シナリオ 3 100,000 デバイス × 10 メトリクス	シナリオ 4 1,000,000 デバイス × 10 メトリクス	シナリオ 5 10,000,000 デバイス × 10 メトリクス
データ間隔	10秒	10秒	10秒	10秒	10秒
間隔	31日	4日	3時間	3分	3分
トラックの数	100	4000	100,000	1,000,000	10,000,000
個々のトラックの記録の数	241,145	31,118	972	16	16
データセット内のレコードの数	48,229,186	248,944,316	194,487,997	32,414,619	324,145,090

上の表からわかるように、5 つのシナリオの違いは主に、個々のトラックのレコード数とデータ セットに含まれるトラックの総数の違いであり、データの時間間隔は 10 秒に維持されます。5 つのシナリオのデータ規模は全体的に大きくなく、最大のデータ規模はシナリオ 5、最小のデータ規模はシナリオ 4 です。シナリオ 4 とシナリオ 5 では、トラックの数が比較的多いため、データセットがカバーする時間範囲は 3 分のみです。

2. データモデリング

TSBS フレームワークでは、TimescaleDB と InfluxDB が対応するデータ モデルを自動的に作成し、対応する形式でデータを生成します。この記事では、その具体的なデータ モデリング方法については繰り返し説明せず、TDengine のデータ モデリング戦略についてのみ紹介します。TDengine の重要なイノベーションは、その独自のデータ モデルです。デバイスごとに独立したデータ テーブル (サブテーブル) を作成し、同じコレクション タイプのデバイスをスーパー テーブル (スーパー テーブル) を通じて論理的および意味的に管理します。IoTシナリオのデータ内容として、診断情報と指標情報の時系列データを格納するテーブルをトラック（以下、機器とトラックは同義）ごとに2つ作成しました。上記のデータレコードでは、スーパーテーブルが 2 つあるため、トラック名を各トラックの識別 ID として使用できます。したがって、TDengine では、トラック名連結 d(r) をサブテーブルの名前として使用します。次のステートメントを使用して、それぞれ 3 つ、7 つの測定値、および 8 つのラベルを含む、diagnostics と readings という名前のスーパー テーブルを作成します。

 

次に、次のステートメントを使用して、r_truck_1 および d_truck_1 という名前のサブテーブルを作成します。

 

100 台のデバイス (CPU) のシナリオ 1 では、100 個のサブテーブルが作成され、4000 台のデバイスのシナリオ 2 では、対応するデータを保存するためにシステム内に 4000 個のサブテーブルが作成されることがわかります。TSBS フレームワークによって生成されたデータでは、ラベル情報トラックが null データ コンテンツであることが判明したため、トラックを識別できなかったすべてのデータを格納する d_truck_null(r_truck_null) テーブルを確立しました。

3. ソフトウェアのバージョンと構成

このレポートでは、TDengine、InfluxDB、TimeScaleDB の 3 種類のデータベースを比較します。使用したバージョンと構成については、以下で説明します。

01 TDエンジン 

TDengine 3.0 を直接採用し、パフォーマンス比較用のバージョンとして GitHub からコンパイルされた TDengine コードのクローンを作成します。gitinfo: 1bea5a53c27e18d19688f4d38596413272484900 サーバー上でコンパイル、インストール、実行します。

 

TDengine の設定ファイルでは、クエリに関連する 6 つの設定パラメータが設定されます。

 

最初のパラメータ numOfVnodeFetchThreads は、Vnode (仮想ノード) のフェッチ スレッドの数を 4 に設定するために使用されます。2 番目のパラメータ queryRspPolicy は、クエリ応答の高速応答メカニズムを有効にするために使用されます。3 番目のパラメータ compressMsgSize は、TDengine が 128000 バイトを超えることを許可します。トランスポート層 メッセージは自動的に圧縮されます。4 番目のパラメータは、CPU がサポートする場合、組み込みの FMA/AVX/AVX2 ハードウェア アクセラレーションを有効にします。5 番目のパラメータは、タグ列のフィルタ キャッシュを有効にするために使用されます。6 番目のパラメータはタスクキュー内のスレッド数を 24 に設定するために使用されます。 

IoT シナリオのテーブルの数はトラックのサイズの 2 倍であるため、TDengine はデフォルトで 12 個の vnode を作成します。つまり、作成されたテーブルはテーブル名に従って 12 個の仮想ノードにランダムに割り当てられ、LRU キャッシュが設定されます。 last_row キャッシュ モードに移行します。シナリオ 1 とシナリオ 2 では、stt_trigger は 1 に設定されます。このとき、TDengine は、1 つのテーブルへの書き込み量が最小行数に満たない場合に、データを収容するためのソート時系列テーブル (STT) ファイルを準備します。 STT ファイルに新しいデータを保存できない場合、システムはデータを STT に整理してからデータ ファイルに書き込みます。このレポートでは、シナリオ 3 では stt_trigger が 8 に設定され、シナリオ 4 および 5 では stt_trigger が 16 に設定されています。つまり、最大 16 個の STT ファイルの生成が許可されています。頻度の低いテーブルが多数あるシナリオでは、書き込みパフォーマンスを向上させるために STT の値を適度に増やす必要があります。

02 タイムスケールDB

同等の結果を保証するために、TimescaleDB バージョン 2.10.1 を選択しました。より良いパフォーマンスを得るために、TimescaleDB はシナリオごとに異なるチャンク パラメーターを設定する必要があります。さまざまなシナリオでのパラメーター設定を次の表に示します。

	シーン 1	シーン2	シーン3	シーン4	シーン5
デバイスの数	100	4000	100,000	1,000,000	10,000,000
チャンクの数	12	12	12	12	12
チャンク期間	2.58日	8時間	15点	15秒	15秒
チャンク内のレコードの数	2,009,550	10,372,680	8,103,667	1,350,610	13,506,045

上記のパラメータの設定に関しては、[TimescaleDB と InfluxDB] 比較レポートで推奨されている構成パラメータ設定を完全に参照して、書き込みパフォーマンス指標を最大化できるようにします。TimescaleDB と InfluxDB: 時系列データ用に異なる目的で構築: https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

03 流入DB

InfluxDB の場合、このレポートはバージョン 1.8.10 を使用します。InfluxDB の最新バージョン 2.x は、TSBS が適応していないため、ここでは使用しません。選択したバージョン 1.8.10 は、InfluxDB が TSBS フレームワークで実行できる最新バージョンです。構成に関しては、[TimescaleDB vs. InfluxDB] 比較レポートで推奨されている方法を引き続き使用して構成し、1000W デバイスがスムーズに書き込みできるようにバッファを 80GB に構成し、同時に時系列インデックス (TSI) を有効にします。時間。システムがデータを挿入してから 30 秒後にデータ圧縮を開始するようにシステムを構成します。

 

2. テスト手順

1. ハードウェアの準備

[TimescaleDB vs. InfluxDB] の比較で報告した環境に非常に近づけるために、基本的な動作プラットフォームとして Amazon AWS の EC2 が提供する r4.8xlarge タイプのインスタンスを使用します。これには、2 つのノード、1 つのサーバー、および一人のクライアント。クライアントとサーバーのハードウェア構成はまったく同じで、クライアントとサーバーは 10 Gbps のネットワーク接続を使用します。構成プロファイルは次のとおりです。

	CPU	メモリ	ディスク
サーバ	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD、3000 IOPS、スループット制限は 125 MiB/秒
クライアント	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD、3000 IOPS、スループット制限は 125 MiB/秒

2. サーバー環境の準備

テストスクリプトを実行するには、サーバーOSがubuntu20.04以上のシステムである必要があります。AWS EC2のサーバーシステム情報は以下のとおりです。

1. OS：Linux tv5931 5.15.0-1028-aws #32~20.04.1-Ubuntu SMP Mon Jan 9 18:02:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
2. Gcc: gcc バージョン 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
3. 基本環境のバージョン情報は次のとおりです: Go1.16.9 、 python3.8 、 pip20.0.2 (手動インストールは必要ありません。テスト スクリプトは自動的にインストールされます)
4. コンパイルの依存関係: gcc、cmake、build-essential、git、libssl-dev (手動でインストールする必要はありません。テスト スクリプトは自動的にインストールされます)

さらに、次の 2 つの構成を行う必要があります。

1. スクリプトがパスワードを公開しないように、クライアントとサーバーはシークレットなしで ssh アクセスを構成します。シークレットなしの構成ドキュメントを参照してください: https://blog.csdn.net/qq_38154295/article/details/121582534。
2. クライアントとサーバー間のすべてのポートが開いていることを確認してください。

3. テストスクリプトを取得する

テストの繰り返しを容易にし、面倒なダウンロード、インストール、構成、起動、結果の概要などの詳細を隠すために、TSBS テスト プロセス全体がテスト スクリプトにカプセル化されています。このテスト レポートを繰り返すには、最初にテスト スクリプトをダウンロードする必要があります。このスクリプトは一時的に ubuntu20.04 システムをサポートします。次の操作には root 権限が必要です。クライアント マシンで、テスト ディレクトリを入力してコードをプルし、デフォルトでは /usr/local/src/ ディレクトリを入力します。

 

構成ファイル test.ini でサーバーとクライアントの IP アドレス (ここで AWS のプライベート ネットワーク アドレスを構成できます) とホスト名を変更する必要があります。サーバーがパスワードなしで構成されていない場合は、次のことも必要です。サーバー上で root パスワードを設定します。このテストは IoT シナリオにあるため、caseType を iot に変更します。​ 

4. ワンクリックで比較テストを実行

次のコマンドを実行します。

 

テスト スクリプトは、TDengine、InfluxDB、TimescaleDB などのソフトウェアを自動的にインストールし、さまざまな比較テスト項目を自動的に実行します。現在のハードウェア構成では、テスト全体が実行されるまでに約 3 日かかります。テスト終了後、CSV 形式の比較テスト レポートが自動的に生成され、クライアントの /data2 ディレクトリの、load および query のプレフィックスに対応するフォルダーに保存されます。

3. 結論

これを読んだ後は、TDengine のデータ モデリング、3 つの主要なデータベース テスト バージョンと構成、およびワンクリックで再現するためのテスト スクリプトの使用方法について、より深く理解する必要があります。IoT シナリオにおける 3 つの主要なデータベースのテスト結果を確認したい場合は、上記の手順に従ってテスト結果を確認してください。ご質問がある場合は、時間内にご連絡ください。また、小さな T vx: tdengine1 を追加したり、TDengine ユーザー交換グループへの参加を申請したり、同じ考えを持つ開発者とテクノロジーや実際の戦闘についてチャットしたりすることもできます。