Ele.me の軽量分散時系列データベースの設計と調査!

著者について: Huang Jie は2015 年に Ele.me に入社し、現在はフレームワーク ツール部門のシニア開発マネージャーを務めています。彼は主に、Ele.me の監視システムと監視システムを取り巻くツールを担当しています。

1. 背景

Ele.me の時系列データベースに対する需要は主にさまざまな監視システムから来ており、主に監視指標の保存に使用されています。当初はグラファイトを使用していましたが、後に多次元インジケーターの必要性が生じ、主に 1 つのインジケーターに複数のタグを追加してシリーズを形成し、計算のためにタグをフィルタリングおよびグループ化するようになりました。当時、グラファイトではニーズを満たすことはほとんどできませんでした。

現在、業界では次のようなタイプの TSDB が広く使用されています。

• InfluxDB: 多くの企業が使用しており、Ele.me も監視システムの一部に InfluxDB を使用しています。複数のディメンションとフィールドをサポートし、TSDB の特性に合わせてストレージが最適化されているのが利点ですが、オープンソース部分はサポートされていません。多くの企業が独自のクラスタリングを行っていますが、そのほとんどはインジケーター名に基づいているため、単一ポインターのホットな問題が発生します。 Ele.me は現在同様のアプローチを採用していますが、ホットスポットの問題は非常に深刻です。大規模なインジケーターはすでに最大のサーバーを使用していますが、クエリのパフォーマンスはまだ理想的ではありません。シリーズシャーディングで実行する場合、コストはまだ少し高くなります。
• Graphite: 指標の書き込みとクエリに基づいて、多くの計算機能がありますが、コンピュータールームや複数のクラスターでのクエリなど、多次元クエリをサポートするのは困難です。もともと、Ele.me はビジネス レイヤーの監視インジケーターを Graphite に保存しており、うまく機能していました。しかし、アクティブノードを追加した後、いくつかの要件を満たすことが困難になりました。ストレージ構造の特性上、多くのIOを占有していました。現在のオンラインデータによれば、書き込み増幅は数十倍以上でした。
• OpenTSDB: HBase をベースにしているため、ストレージ層を自分で気にする必要がなく、クエリの集計のみで済むのが利点です。ただし、HBase ホットスポットの問題もあります。同社は過去にも、クエリパフォーマンスを最適化するために、ホットスポットや部分的なクエリ集約を HBase に委任するなど、OpenTSDB のいくつかの問題を解決するために HBase ベースの TSDB を使用していましたが、依然として HBase/HDFS に大きく依存していました。
• HiTSDB: Alibabaが提供するTSDB。ストレージには HBase も使用します。データ構造とインデックスに多くの最適化が行われました。詳しくは研究していません。興味のある学生は Alibaba Cloud で試すことができます。
• Druid: Druid は実際には OLAP システムですが、時系列データの保存にも使用できますが、アーキテクチャ図を見て諦めました。
• ElasticSearch (ES): 一部の企業では、ストレージに直接 ES を使用しています。実際のテストは行われていませんが、ES は実際の TSDB ではないと常に感じています。
• atlas: Netflix が制作したフルメモリ TSDB。過去数時間のデータはすべてメモリ内に保存されており、履歴データは外部に保存する必要があります。詳細は詳しく研究されていません。
• beringei: Facebook が制作したフルメモリ TSDB です。最新のデータもメモリに保存されています。まだ潜伏段階のはずです。

最終的に、私たちは分散時系列データベースを自分たちで実装することに決めましたが、それには次のような問題を解決する必要がありました。

• 軽量で、現在は Zookeeper のみに依存します。
• シリーズに基づくシャーディングはホットスポットを解決し、真の水平拡張を実現します。
• リアルタイム書き込みとリアルタイムクエリ。主に監視システムで使用されるため、クエリのパフォーマンスは良好であるはずです。
• Ele.me は現在、複数のアクティブ サーバーと監視システムを使用しているため、単一データ ルームの書き込みと複数データ ルームの集計クエリをサポートする必要があります。
• 自動ロールアップ機能が必要です。たとえば、ユーザーが 10 秒の精度でデータを入力すると、システムはそれを分、時間、または日レベルに自動的にロールアップし、レポートなどの長い時間範囲のクエリをサポートします。
• SQL のようなクエリ メソッドをサポートします。
• 複数のコピーをサポートし、システム全体の信頼性を向上します。 1 つのコピーが存続している限り、サービスは正常に提供できます。コピー部数が指定されます。

2. 全体デザイン

コンピューティングとストレージを分離するアーキテクチャを採用しており、コンピューティング層のLinProxyとストレージ層のLinStorageに分かれています。

例:

• LinProxy は主に、SQL 解析と中間集計計算を実行します。クロスクラスターでない場合は、LinProxy は必要ありません。単一クラスター内の各ノードには、クエリ サービスを提供するために LinProxy が埋め込まれています。
• LinDB クライアントは主にデータの書き込みに使用され、いくつかのクエリ API も備えています。
• LinStorage の各ノードはクラスターを形成し、ノード間で複製され、レプリカのリーダー ノードが読み取りおよび書き込みサービスを提供します。この設計は主に Kafka の設計に基づいています。 LinDB は、Kafka のようなデータ書き込みレプリケーション + 基礎となる時系列のストレージ層として理解できます。
• LinMaster は主にデータベース、シャード、レプリカの割り当てを担当し、LinStorage ストレージのスケジュール設定とメタデータ (現在は Zookeeper に保存されています) の管理を行います。 LinStorage ノードはすべて同等であるため、Zookeeper に基づいてクラスター内の 1 つのノードをマスターとして選択します。各ノードは、ハートビートの形式で自身のステータスをマスターに報告します。これらのステータスに基づいてマスタースケジュールが作成されます。マスターに障害が発生した場合、別のマスターが自動的に選択されます。このプロセスは基本的にサービス全体に対してロスレスであるため、ユーザーがそれを認識することはほとんどありません。

1. 書く

全体の執筆プロセスは次の 2 つの部分に分かれています。

• WAL レプリケーション、設計のこの部分は Kafka を参照します。ユーザーの書き込みが WAL に正常に書き込まれる限り、書き込みは成功したとみなされます (主にシステムの監視に使用されるため、データの一貫性についてはあまり保証されません)。これにより、システムの書き込みスループットを提供できます。
• ローカル書き込み:このプロセスは、WAL データを解析し、独自のストレージ構造に書き込むことです。ローカルストレージに書き込まれたデータのみ確認できます。

全体のプロセスは、各書き込みプロセスで完了する一部のシステムとは異なります。このプロセスを 2 つのステップに分割し、非同期にします。

WAL レプリケーション

現在、LinDB のレプリカ レプリケーション プロトコルは、主に複数のノード間での WAL のレプリケーションに基づいたマルチチャネル レプリケーション プロトコルを採用しています。各ノードへの WAL の書き込みは、独立した書き込み操作によって完了します。したがって、クライアントが対応するリーダーの WAL を正常に書き込むと、書き込み操作は成功したと見なされます。リーダーが配置されているノードは、対応する WAL を対応するフォロワーにコピーする責任があります。同様に、WAL が正常に書き込まれた場合、以下に示すようにレプリケーションは成功したとみなされます。

マルチチャネルレプリケーションプロトコル

リーダー レプリカへの書き込みは書き込み速度を正常に向上させますが、次のような問題も発生します。

• データの一貫性の問題。
• データ損失の問題。

上の図では、サーバー 1 がリーダーであり、例として 1 つの WAL をコピーするために 3 つのレプリケーションが使用されています。

現在、Server1 はシャードのリーダーであり、クライアントからの書き込みを受け入れます。 Server2 と Server3 は、Server1 からのレプリケーション要求を受け入れるフォロワーです。この時点では、1-WAL チャネルが現在のデータ書き込みチャネルであり、Server2 と Server3 は Server1 より遅れている可能性があります。

例:

プロセス全体を通して、次の指標に注意する必要があります。

• クライアントが書き込むときの追加インデックス。現在のクライアントが書き込む場所を示します。
• 各フォロワーにはレプリカ インデックスがあり、対応するフォロワーがリーダーで同期されたデータを消費する場所を示します。
• フォロワーの Ack インデックスは、フォロワーがローカル WAL に正常にコピーしたことを示します。
• フォロワーのコピー要求は、実際には特別なクライアントの書き込みに相当するため、対応する追加インデックスも存在します。

確認されたインデックスのみが処理済みとしてマークされます。リーダーの場合、最小の Ack インデックスよりも小さい WAL データを削除できます。このプロセス中に、Server2 または Server3 のいずれかに障害が発生した場合、対応する消費インデックスは移動せず、対応するサービスが復元された後にのみ処理が続行されます。

プロセス全体を通して、次のような状況が発生する可能性があります。

• リーダーレプリカインデックス > フォロワー追加インデックス。この場合、リーダーレプリカインデックスはフォロワー追加インデックスに従ってリセットする必要があります。レプリケーション シーケンスで説明されている 2 つの状況が考えられます。
• リーダーレプリカインデックス <>

この時点で Server1 に障害が発生した場合、Server2 と Server3 から新しいリーダーが選択されます。たとえば、Server2 がリーダーとして選択されます。

• Server2 は 2-WAL レプリケーション チャネルを開き、Server1 と Server3 にレプリケートします。 Server1 がダウンしているため、一時的に Server3 にのみレプリケートされます。このとき、データは 2-WAL に書き込まれます。
• Server1 がリカバリを開始すると、Server2 は Server1 への 2 WAL レプリケーション チャネルを開きます。同時に、Server1 は、Server2 と Server3 にコピーされていない 1-WAL 内の残りのデータを Server2 と Server3 にコピーします。

異常な状況では、WAL 内のデータは正常になりません。 ACK 後の削除により WAL がディスクを占有しすぎるため、WAL の SIZE および TTL クリーンアップ プロセスが必要になります。 SIZE と TTL により WAL がクリーンアップされると、いくつかのインデックスが乱れます。具体的な障害内容は上記の通りです。

マルチチャネルレプリケーションプロトコルによって発生する問題:

各チャネルには、各チャネルの最後のインデックスを格納する対応するインデックス シーケンスがあります。シングルチャネル レプリケーションでは、最後のインデックスを 1 つだけ保存する必要があります。この値段は実は悪くないです。

ローカル書き込み

背景

シャードレベルの書き込み分離が実現されます。つまり、各シャードには書き込みを担当する独立したスレッドがあり、特定のデータベースまたはシャードの書き込み量が急増しても、他のデータベースへの書き込みは発生しません。ただし、1 台のマシンで実行されるシャードが多すぎると、スレッドが多すぎる可能性があります。このような状況に遭遇した場合は、マシンを拡張するか、新しいデータベースを作成するときにシャードの数を適切に割り当てることで解決する必要があります。

シングルスレッドの書き込み操作であるため、多くの場合、マルチスレッド書き込みによって発生するロック競合の問題を考慮する必要はありません。

データ保存構造

説明: 単一ノード上の単一データベースのデータ構造を例に挙げます。

• データベースは単一のノード上に複数のシャードを持つことができ、すべてのシャードは同じインデックス データを共有します。
• すべてのデータはデータベース間隔に応じてタイムスライスで計算され、データファイルやインデックスファイルなどの特定のデータが保存されます。

この設計は主に TTL 処理の利便性を目的としています。データの有効期限が切れた場合は、対応するディレクトリを削除するだけです。各シャードにはセグメントがあり、間隔に応じて対応するタイムスライスのデータが格納されます。

では、なぜ各セグメントの下に Interval によって保存されるデータ ファミリがこれほど多くあるのでしょうか?

これは主に、LinDB が解決する主な問題が大量の監視データを保存することだからです。一般監視データは基本的にリアルタイムで書き込まれ、履歴データは書き込まれません。 LinDB 全体のデータ保存は LSM 方式に似ています。したがって、データ ファイル間のマージ操作によって発生する書き込み増幅を減らすために、最終的に考慮すべきことは、セグメント タイム スライスを分割することです。

以下は 10 秒間隔を例にしています。

• セグメントは日ごとに保存されます。
• 各セグメントは時間ごとにデータ ファミリに分割され、1 時間ごとに 1 つのファミリがあり、各ファミリのファイルには列ごとに特定のデータが格納されます。

執筆プロセス

例:

• システムは各シャードに対して書き込みスレッドを開始し、その書き込みスレッドがこのシャード上のすべての書き込み操作を担当します。
• まず、測定、タグ、フィールドに対応するデータをデータベース インデックス ファイルに書き込み、対応する測定 ID、時系列 ID、フィールド ID を生成して、主に文字列から整数への変換を完了します。これの利点は、すべてのデータ ストレージがデータ型で保存されるため、全体的なストレージ サイズを削減できることです。各データポイントには、cpu{host=1.1.1.1} load=1 1514214168614 のように、測定、タグ、フィールドなどのメタデータが占有されるため、ID に変換した後、cpu => 1 (測定 ID)、host=1.1.1.1 => 1 (時系列 ID)、load => 1 (フィールド ID) となり、最終データは 1 1 1514214168614=>1 として保存されます。これは、OpenTSDB の設計で考慮されています。
• インデックスの書き込みに失敗した場合、書き込み操作は失敗したとみなされます。失敗には2つの種類があります。 1 つはデータ書き込み形式の問題によるもので、直接的に失敗としてマークされます。もう 1 つは内部の問題によるもので、この場合は書き込みの失敗を再試行する必要があります。
• インデックスによって取得された ID を、書き込み時間とデータベース間隔の計算と組み合わせて使用​​し、どのセグメントのどのファミリに書き込む必要があるかを取得します。ファミリに書き込むときは、高いスループット要件を満たすためにメモリに直接書き込みます。メモリ データがメモリ制限に達すると、フラッシュ操作がトリガーされます。
• 書き込みプロセス全体は、最初にメモリに書き込み、次に Flusher スレッドがメモリ内のデータを対応するファイルにダンプします。このようにして、データのバッチを順番に書き込むことができます。同時に、フィールド タイプに応じて最新のデータがロールアップされるため、ディスク IO 操作がさらに削減されます。

2. クエリエンジン

LinDB クエリでは次の問題を解決する必要があります。

• 複数のコンピューター ルーム間のクエリを解決します。
• 効率的なストリーミング クエリ コンピューティング。

例:

• 複数のコンピュータルームや複数のクラスターでのクエリをサポートする必要があるため、LinProxy が導入されています。 LinProxy は主にユーザー指向のクエリ要求を担当します。
• SQL プランは、特定の SQL ステートメントを解析し、最終的な実行プランと計算する必要のある中間結果の関数を生成します。
• Zookeeper のメタデータを通じて、リクエストは特定の LinDB クラスター内の対応するサービスにルーティングされます。
• 各 LinConnect は LinDB クラスターとの通信を担当します。各 LinConnect は、対応するクラスターのメタデータのコピーを保存します。各メタデータが変更されるたびに、メタデータ情報がサーバーによって LinConnect にプッシュされます。このようにして、LinConnect は基本的にメタデータをほぼリアルタイムで更新できます。
• Aggregator Stream は、各 LinConnect の中間結果の最終的なマージと計算を主に担当します。
• LinProxy プロセス全体は非同期なので、IO を待機している間にスレッドを使用して計算を行うことができます。

各ノードは LinConnect からの要求を受信し、内部クエリと計算を実行し、中間結果を LinConnect に返します。詳しい手順については後ほど紹介します。

ノードクエリ

例:

• 図に示すように、クライアントからのクエリ要求によって、多数の小さなクエリ タスクが生成されます。各タスクには単一の責任があり、自身のタスクのみを実行し、その結果を次のタスクに渡します。したがって、すべてのクエリ コンピューティング タスクは、例外なく、IO/CPU タスクを分離して処理する必要があります。
• サーバー側クエリ全体では、パイプライン全体の処理を簡素化するためにアクター パターンが使用されています。
• いずれかのタスクの実行後に結果が生成されない場合、下流のタスクは生成されません。すべての下流タスクは、上流タスクに結果があるかどうかに基づいて決定されます。
• 最後に、基礎となる結果は、Reduce Aggregate を通じて最終結果に集約されます。

3. ストレージ構造

逆インデックス

転置インデックスは 2 つの部分に分かれています。現在、インデックス関連のデータは RocksDB に保存されています。

• 時系列の測定+タグに基づいて一意の ID を生成します (Luence のドキュメント ID に似ています)。
• タグの逆インデックスによれば、ID リストを指しています。 TSID リストは BitMap 形式で保存されるため、クエリ時に BitMap 操作を通じて必要なデータをフィルター処理できます。 BitMap は RoaringBitMap を使用します。
• 各タイプのデータは個別の RocksDB ファミリに保存されます。

メモリ構造

書き込み性能を向上させるために、現在の期間のデータがメモリに書き込まれます。メモリが一定の制限または時間に達すると、メモリ内のデータはファイルにダンプされます。

メモリストレージは現在書き込み可能なものと書き込み不可能なものに分かれています。現在、書き込み可能は通常のデータ書き込みを受信するために使用され、書き込み不可はファイルにダンプするために使用されます。ダンプが成功すると、書き込み不可能な部分がクリアされます。

書き込み可能なメモリ テーブルもメモリ容量の制限に達しているが、書き込み不可能な部分がまだダンプされていない場合は、データ書き込みに使用可能なメモリができるまで書き込みはブロックされます。目的は、過剰なメモリ使用による OOM を回避することです。

MemoryTable は、Map を使用して測定 ID → 測定ストアの関係を保存します。つまり、各測定は個別のストアに保存されます。

測定中の各 TSID に対応するデータは、測定ストアに保存されます。各 TSID に対応するデータはメモリ ブロックに保存されます。各メモリ ブロックは、配列リスト内の TSID の順序で格納されます。 TSID はビットマップに格納され、配列リスト内のメモリ ブロックの特定の位置はビットマップ内の TSID の位置によって特定されます。

ここでは、システム全体が Java で実装されており、Java の Map 構造はメモリ内に複数のストレージを必要とする小さなオブジェクト データの保存には適していないため、ストレージに Map を直接使用しない理由を説明します。

各 TSID はタイムラインに対応しているため、各タイムラインには複数のデータ ポイントが存在する場合があります。例えば、count の場合は count 値が 1 つだけであり、timer の場合は count、sum、min、max など複数の値が存在する場合があります。

各データ型はチャンクに保存されます。チャンクは、メモリの 2 つの部分 (インヒープとアウトヒープ) に格納されます。最新期間のデータはヒープ内に配置され、履歴データは圧縮されてヒープ外に配置されます。 LinDB の主な目的は監視データを保存することであり、監視データは主に最新期間のデータに関係するため、できるだけ多くの最新データをメモリに格納するようにしてください。

ファイル保存構造

ファイルストレージはメモリストレージに似ています。同じ測定のデータはブロックの形式で一緒に保存されます。クエリを実行する場合、測定 ID を使用して、測定データが保存されているブロックを検索します。

• オフセット ブロックは測定ブロックの後に格納され、各測定ブロックのオフセットが格納されます。各オフセットは 4 バイトで保存されます。
• オフセット ブロックには、各測定 ID をビットマップ形式で順番に格納する測定インデックス ブロックが格納されます。
• フッター ブロックはファイルの最後に保存され、主にバージョン (2 バイト) + 測定インデックス オフセット (4 バイト) + 測定インデックスの長さ (4 バイト) を保存します。
• データ ブロックはすべて数値であるため、Facebook の Gorilla 論文を参考にして XOR を使用して圧縮されます。

測定ブロック:

• 各測定ブロックは、測定 ID が測定内の TSID に置き換えられることを除いて、測定と同様の方法で保存されます。
• TS エントリは、TSID に対応する各列にデータを保存し、データの列には一定期間のデータ ポイントを保存します。

クエリロジック:

• DataFile が初めてロードされるとき、メモリに測定インデックスが配置され、測定インデックスの位置 N を通じて入力測定 ID が照会され、次にこの位置 N を通じてオフセット ブロック内の特定の測定ブロックのオフセットが照会されます。各オフセットは 4 バイトであるため、オフセット位置 = (N-1) * 4 となり、4 バイトを読み取って実際のオフセットを取得します。
• 同様に、TSID を通じて特定の TS エントリを見つけ、条件に従って特定の列データをフィルタリングして、最終的に読み取りたいデータを取得できます。

3. 開発の経緯

LinDB は 2 年前から同社の監視システムに正式に採用されています。 1.0から2.0へと開発が進み、2年以上安定して稼働しています。 RocksDB の問題を除けば、ほとんど問題はありませんでした。現在までに、3.0 のパフォーマンスは大幅に向上しました。基本的には、業界の成熟したソリューションに基づいてゆっくりと進化させてきました。

LinDB がなぜこんなに速いのかと尋ねる人もいました。実際、私たちは多くの TSDB の実践を参考にし、優れた設計を採用し、時系列の特性に基づいていくつかの最適化を行いました。

• 時系列は一般的にはバッチで書き込まれますが、ランダムな書き込みの一種でもあります。まず、ランダム書き込みをメモリ内の順次書き込みに変換し、最後にファイルを順次書き込みます。すべてのデータは順序どおりに並べられているため、クエリを実行するときにも順番に読み取られます。これは非常に重要です。
• 記述された測定値/タグ/フィールドを Int に変換し、転置インデックスを生成し、最後に TSID (Luence のドキュメント ID に類似) を生成します。これにより、最終的なデータ量が大幅に削減されます。結局のところ、文字列が指標の大部分を占めています。これは OpenTSDB と非常によく似ています。 InfluxDB は一定期間データをブロックに保存していますが、このデータは依然としてブロックの先頭に配置されます。これは、特に圧縮する場合のコストです。
• タイムスタンプを直接保存する他の TSDB とは異なり、ミリ秒レベルのタイムスタンプは通常 8 つのノードを占有します。時間順序の利点に基づいてデルタエンコード圧縮を使用するのも良いですが、最善の結果を実現したいと考えています。時間を表すには 1 ビットを使用します。具体的な方法は、上記の説明に従って時間の上位ビットと保存間隔を設定し、時間の上位ビットをディレクトリに配置し、上位ビットに基づいてデルタを計算することです。デルタは、データがあるかどうかを示すために 1 ビット形式で保存されます。監視データのほとんどは連続データであるため、そうすることは合理的です。そのため、時間データの保存スペースも大幅に削減されます。
• 指標の複数のフィールドのデータについては、各フィールドのデータの隣接ポイントは基本的に非常に類似していることがわかりました。 LinDB 2.0 はストレージに RocksDB を直接使用し、複数のフィールドをまとめて保存し、隣接するポイントを圧縮します。この方法では、圧縮率はあまり高くなく、フィールドがクエリされるたびにすべてのデータを読み取る必要があります。このため、LinDB 3.0 では列指向ストレージを独自に実装することを検討しました。圧縮率を向上させるために同じ列を一緒に保存し、クエリ時に必要なデータのみを読み取ります。 gzip、snappy、zlib は数値型にはあまり適していないため、圧縮全体には使用しませんでした。私たちは、現在多くの TSDB で採用されている Facebook の Gorilla 論文の xor メソッドを直接参照しました。
• 上記の基本的な順次読み取りに基づくと、問題はなくなります。 TSID ベースのクエリは、設計全体が TSID → データに基づいているため、問題がさらに少なくなります。したがって、逆の順序で見つかった TSID のグループに基づいて、データのランダム読み取りも解決する必要があります。上記のように、TSID をビットマップに配置し、ビットマップを通じてオフセットを計算してデータを直接見つけます。保存時の最適化により、バイナリ検索ではなく TSID クエリを正確に検索できます。
• もう 1 つのポイントは、新しいデータベースを作成するときに間隔を指定すると、LinDB が自動的にロールアップすることです。多くの Continue クエリを記述する必要がある InfluxDB とは異なり、LinDB ではこれらすべてが自動的に行われます。
• クエリ計算の並列ストリーミング。

つまり、一言でまとめると、効率的なインデックスと一連の値、そしてこれらの値をうまく活用する方法です。

自己監視

LinDB には独自の監視機能もいくつか備わっています。

概要

ダッシュボード

今後の展望

• クエリ関数を充実させる。
• メモリ使用量を最適化します。
• 自己監視の改善
• 可能であればオープンソース化することを計画してください。

比較テスト

以下は、InfluxDB と LinDB2.0 のクエリ パフォーマンスの比較です。 InfluxDB クラスタリングには商用バージョンが必要なので、すべてのテストはキャッシュなしの単一マシンのデフォルト構成で実行されます。サーバー構成 Alibaba Cloudマシン: 8コア16Gメモリ

大きな寸法

タグ: ホスト(40000)、ディスク(4)、パーティション(20)、サーバー ディスク監視をシミュレートします。シリーズの合計数は 320W で、各シリーズは 1 つのデータ ポイントを書き込みます。

小さな寸法の集合試験を1日以内に実施

タグ: ホスト(400)、ディスク(2)、パーティション(10)、サーバー ディスク監視をシミュレートします。シリーズの合計数は 8K、各シリーズは 1 日分のデータを書き込みます。各ディメンションは 2 秒ごとに 1 ポイントを書き込みます。各ディメンションは 1 日で合計 43200 ポイントを持ちます。すべてのディメンションには合計 43200 * 8000 ポイント、合計 345600000、つまり 3 億を超えるデータがあります。

7日以内に小規模の集合試験

タグ: ホスト(400)、ディスク(2)、パーティション(10)、サーバーディスク監視をシミュレートします。シリーズの合計数は8K、各シリーズは7日分のデータを書き込み、各ディメンションは5秒ごとに1ポイントを書き込み、各ディメンションは1日に合計17280ポイントを持ち、すべての日とすべてのディメンションの合計は172808000 7ポイント、つまり967680000、つまり9億ポイント以上です。

このテストは説明が必要です。 LinDB の自動ロールアップの恩恵を受けます。 InfluxDB が Continue Query を開いた場合は、問題ないと思います。