時系列データの急速な増加に伴い、スタンドアロンの時系列データベースではコンピューティング リソースが制限され、大量の時系列データの同時書き込みを処理できず、ビジネスの成長に伴う時系列データベースのパフォーマンス要件を満たすことが困難になっています。データベースは、時系列データ、処理能力、コンピューティング能力に対するビジネス システムのニーズを満たすために、水平方向の拡張をサポートする必要があります。線形性は、クラスタの処理能力を測定するための重要な参照指標の 1 つです。線形性が良いということは、同じビジネス負荷の下で、クラスタに必要なノードの数が少ないことを意味します。逆に、より多くのノードを追加する必要があり、ノード数の増加が原因である可能性もあります。ノード数が増加すると、パフォーマンスが低下します。
openGemini は 100+ ノードのクラスター サイズをサポートしており、48 ノードの書き込み直線性の測定値は約 76% です。この記事では主に、openGemini が高い書き込み直線性を維持するための 3 つのベスト プラクティス方法を共有します。
データの一括書き込み
データのバッチ書き込みとは、クライアントがクラスターにデータをバッチで書き込むことを意味します。その目的は、ネットワーク送信の数を減らし、クラスター内のロックとリリースの数を減らし、書き込みパフォーマンスを向上させることです。
上図に示すように、クラスタが横方向に拡張するにつれてデータノードの数が増加しますが、クライアントが一度に ts-sql に一括で書き込むデータ行数が変わらない場合、各 ts-sql に送信されるデータはデータ分割後のストアノードは(拡張前と比較して)少なくなりますが、一度に多くのデータを書き込める新しいデータノード(ts-store)によりクラスタの処理能力が強化されていますので、 ts-sql を ts-store に追加できます。一度に分散されるデータ量は、新しいノードのコンピューティング リソースを最大限に活用し、新しいノードの追加後にデータ処理効率が線形に増加することを保証します。つまり、良好な線形性を示します。 。具体的な手順は次のとおりです。
ts-sql構成を変更する
[http]...read-block-size=128 * 1024
read-block-size は、ts-sql が一度に読み込む際にクライアントが送信するデータのサイズを示し、デフォルトは 64KB です。
read-block-size の値は、バッチ書き込み中のバッチのサイズを参照できます。バッチが 64KB 未満の場合は、バッチ サイズを増やすことをお勧めします。ここでは、ts-sql による同時データ処理の数 (通常は vCPU コアの数) も考慮する必要があります。読み取りブロック サイズ * 同時データ数を収容するのに十分なスペースがメモリにあることを確認してください。データ クエリ用にメモリ スペースを確保することも考慮する必要があります (ここでの前提条件は、メモリ スペースが十分であるということです)。
ts-sql での書き込みリクエストのスケジューリングは上の図に示されており、そのプロセスは次のとおりです。
1. 設定された read-block-size に従ってネットワーク IO 内のデータを読み取ります。
2. 設定された同時実行数 (CPU コアの数) に従って読み取りブロックをスケジュールします。スケジューリング プロセス中に、バイナリ ストリームを openGemini が認識できる行に変換するためにアンマーシャルが実行されます。最終的に、データは対応する ts-store ノードに書き込みます
3. 今回書き込まれたすべてのブロックがスケジュールされるまで待機し、書き込み実行結果を返します。
時系列データの特性に合わせたインデックス期間
特定のタイムラインを持つビジネスの場合、インデックス期間をシャード期間の整数倍以上に設定すると、重複したインデックスが減り、シャード グループを切り替えるときのパフォーマンスのジッターが軽減され、書き込みパフォーマンスの安定性が向上します。書き込みパフォーマンスの直線性。
デフォルトでは、インデックス期間とシャード期間はどちらも 1 日に等しく、データは毎日新しいシャードグループに書き込まれます。シャードグループが切り替わるたびに、逆インデックスを再構築する必要があります。インデックスを再構築すると、パフォーマンスがある程度低下します。 。
インデックス期間の変更方法については、公式 Web サイトのドキュメントを参照してください。
https://docs.opengemini.org/zh/guide/schema/retention_policy.html
インデックス期間とは何ですか?
Index Duration は、ShardGroup 間で逆インデックスを再利用する時間範囲を指します。主な目的は、タイムラインが比較的固定されているシナリオだけでなく、タイムラインが変化するシナリオにも柔軟に対応することです。
タイムラインが不確実なシナリオでは、新しい ShardGroup サイクルが開始した後も、新しいタイムライン データが書き込まれる可能性があるため、新しい逆インデックスを再構築する必要があります。元のインデックスを再利用してもあまり意味がありません。インデックス期間を等しく設定することで、 to ShardDuration により、ShardGroup が切り取られるたびにインデックスが再作成されます。
ただし、ほとんどのシナリオではタイムラインが決定されているため、ストレージ エンジンによって作成されたタイムライン転置インデックスは長期間再利用でき、ShardGroup を切り替えるときにシャード用に新しい転置インデックスを再構築する必要はありません。シャード期間の整数倍以上。
保持ポリシー (略して RP) とは何ですか? また、それと Shard および ShardGroup との関係は何ですか?
図に示すように、openGemini では RP によってデータの保存期間 (Duration) が定義されており、期限が切れると自動的に削除されます。RP を有効にするには、DB に関連付ける必要があります。つまり、この DB 内のデータには、RP によって指定された有効期限が適用されます。DB 内に複数の RP を作成することもできます。
RP配下には複数のShardGroupがあり、openGeminiではShardGroupに従ってデータを管理しますが、これは論理的な概念であり、時間範囲はShardDurationによって決まります。ShardGroup は複数のシャードで構成されます。シャードはデータを保存するための最小単位です。データのバッチが到着すると、ハッシュ化され、タイムライン キーに従って複数のシャードに均等に分散されます。
デフォルトでは、次の表に示すように、期間とシャード期間には対応する時間範囲があります。
| 間隔 |
シャードの持続時間 |
| 6ヶ月以上 |
7日 |
| 2日～6ヶ月 |
1日 |
| 2日以内 |
1時間 |
ShardGroup を設定する目的は、よりきめ細かい方法でデータを管理することです。一方で、これによりデータ クエリが容易になります。クエリ ステートメントで指定された時間範囲を通じて、データがどの ShardGroup に属しているかを正確に特定できます。データがどのシャードに該当するかを判断できるということは、一方で有効期限切れやデータの削除を容易にします。たとえば、Duration (データ保持期間) が 1 月 1 日から計算されて 3 か月の場合、1 月 1 日のすべてのデータは ShardGroup-1 の下の 3 つのシャードに保存され、1 月 2 日のデータは 3 つのシャードに保存されます。新しい ShardGroup-2 の下のシャードなど。4 月 1 日までに、最初の ShardGroup-1 のデータは 3 か月を超えました。この時点で、Shard-1 と Shard-2 はバッチ処理でき、Shard-3 のデータは削除することができます。
構成可能なシャーディングキーをサポート
拡張後の ts-store バッチ データ処理機能を最大限に活用できる、read-block-size を増やす方法を以前に紹介しました。ここでは、クラスター書き込みの線形性も改善できる別の方法、つまり ShardKey を指定する方法を紹介します。参考ドキュメントを参照してください。
https://docs.opengemini.org/zh/guide/schema/measurement.html
openGemini 内では、データはデフォルトでタイムラインに従ってハッシュされ、異なる ts ストアに書き込まれますが、1 つのバッチに書き込まれるデータ量が変わらない場合、クラスターの拡張により ts ストアの数が増加します。 、各 ts-store によって処理されるデータの平均量が減少し、リソースが十分に活用されていません。
shardKey を構成することにより、openGemini は shardKey に対応する同じ値を持つタイムラインを 1 つのノードに配置します。これにより、書き込みとクエリのファンアウトが大幅に減少し、書き込みとクエリのパフォーマンスが向上します。実際のアプリケーションでは、ユーザーは必要に応じて適切な shardKey を設定できますが、shardKey によってグループ化されたデータが均等であることが最適であり、shardKey に従って分散された後、データが各 ts-store ノードに均等に分散されます。shardKey に対応する値に従ってグループ化した後、openGemini に書き込み、クロスノード転送を削減し、ts-store でのバッチ処理を改善します。同じ書き込みデータに対して、ts-store への書き込みリクエストの数は少ない回数から変化します。書き込み回数が増えると、1回あたりに書き込まれるデータ量が多くなります。ただし、クライアントが同じ ShardKey を持つデータを Batch に配置し、それを可能な限り openGemini に書き込む必要があるという前提条件があります。
例えば上図のように、データの中にホストというラベルがあったとすると、元のデータには複数のホストのデータが含まれており、書き込む際にはseriesKeyに従って分割されます。データ、ホスト=127.0。0.1の500個のデータがstore1に書き込まれ、host=127.0.0.2の500個のデータがstore2に書き込まれます。その後、データの2つのバッチが書き込まれ、store1とstore2が2つの書き込みリクエストを処理しますそれぞれ 500 個のデータ; ホストを shardKey に設定し、クライアントが事前にホストに従ってグループ化されている場合、データのバッチは 1 つのノードにのみルーティングされます。つまり、データの 2 つのバッチが書き込まれます。 store2 はそれぞれ 1,000 件のデータ書き込みリクエストを 1 回処理し、ストアが書き込みリクエストを処理する回数を減らし、全体的な書き込みパフォーマンスを向上させました。ストアノードを拡張すると、1つのノードに一括してデータを書き込むだけとなるため、ノード数の増加によって各ノードが処理するリクエスト数が増加することがなく、書き込みパフォーマンスの線形性が確保されます。
書き込みパフォーマンス直線性テスト結果(未指定の ShardKey)
データをバッチ処理 (64M バッチ処理) し、インデックス サイクルを構成する (インデックス サイクルは 7 日に設定され、データ サイクルは 1 日に設定される) ことにより、openGemini は 72 ノード (48 コア) 環境で書き込みパフォーマンスの直線性をテストしました。 、テスト モデルは 240 テーブル、seriesKey ハッシュに従って分割、300 万タイムライン/ノード、10 億ポイント/ノード、合計 2 億 1600 万タイムライン、同時実行数は 48/ノード、書き込みパフォーマンスの直線性76% に達する可能性があります。テスト結果は次のとおりです。
要約する
この記事では主に、書き込みパフォーマンスを向上させるための 3 つのベスト プラクティス方法を紹介します。
1. ts-store ノードを追加するとき、ts-sql のメモリが許せば、read-block-size をより大きく設定して、ts-sql の前のバッチで処理されるデータ量を増やし、送信されるデータの数を減らすことができます。 rpc リクエストの数により、ts-store のバッチ処理と拡張中の書き込みパフォーマンスの直線性が保証されますが、read-block-size と CPU コアの数の積が超えないことに注意してくださいts-sql のメモリ サイズ。
2. ラベルが比較的固定されており、あまり変化しない場合など、独自のデータの特性に基づくことができます。言い換えれば、タイムラインは固定されており、インデックス サイクルに達したときにインデックスを再構築する必要があるために生じる書き込みパフォーマンスのジッターを軽減するために、インデックス サイクルを大きく設定できます。
3. 複数のデータ ソースによって生成されたデータが比較的均一である場合、データ ソースの特性を表すことができる唯一のラベルを shardKey に設定します。これにより、同じデータ ソースからのデータを 1 つのノードに書き込むことができ、書き込み増幅が減少し、書き込み速度が向上します。書き込みパフォーマンスの直線性です。
上記の 3 つの方法は、書き込みパフォーマンスを向上させるだけでなく、書き込みの直線性の向上にも大きく役立ちます。
openGemini公式ウェブサイト：http://www.openGemini.org
openGemini オープンソース アドレス: https://github.com/openGemini
openGemini パブリック アカウント:
注目へようこそ~openGeminiコミュニティに参加して、一緒に未来を構築、管理、共有することを心から歓迎します!
オープンソース フレームワーク NanUI の作者がスチールの販売に切り替えたため、プロジェクトは中断されました。Apple App Store の無料リストのナンバー 1 はポルノ ソフトウェア TypeScript です。人気が出てきたばかりなのに、なぜ大手はそれを放棄し始めるのでしょうか。 ? TIOBE 10月リスト：Javaが最大の下落、C#はJavaに迫る Rust 1.73.0リリース AIガールフレンドにイギリス女王暗殺を勧められた男性に懲役9年の実刑判決 Qt 6.6正式リリース ロイター：RISC-Vテクノロジーが中米テクノロジー戦争の鍵となる 新たな戦場 RISC-V: 単一の企業や国に支配されない レノボ、Android PC の発売を計画