徹底解説！時系列データベース HiTSDB: 分散ストリーミング集約エンジン

[[226527]]

背景

Alibaba グループ内の顧客にサービスを提供する際に、HiTSDB 時系列データベース エンジンは、グループのビジネス特性に基づいて多くのターゲットを絞った最適化を行ってきました。しかし、HiTSDB クラウド製品を改良する過程で、パブリック クラウド上の特定のユーザー向けにターゲットを絞った最適化を実装することが難しいことが徐々にわかってきました。

同時に、パブリック クラウドの顧客は、HiTSDB の使用時に集計クエリによって発生する問題がますます多くなっていることに気づいています。たとえば、返されるデータ ポイントが多すぎるとスタック オーバーフロー エラーが発生する、集計ポイントが多すぎると OOM が発生する、集計が完了できずインスタンスが完全に停止する、などです。これらの問題は主に、元の集約エンジン アーキテクチャの欠陥によって発生します。

そのため、評価を行った後、HiTSDB 開発チームは、ストレージ モデルの変換、インデックス作成方法のアップグレード、新しいストリーミング集約の実装、データの移行、パフォーマンス評価など、新しい集約エンジン アーキテクチャを中心に HiTSDB エンジンをアップグレードすることを決定しました。この記事では、主にこれら 5 つの側面に焦点を当て、特に「新しいストリーミング集約部分」に重点を置いています。

1. 時系列データ保存モデル:

1.1 時系列データの保存形式。

典型的な時系列データは 2 つの次元で表されます。 1 つの次元は時間軸を表します。時間が経つにつれて、データは継続的に追加されます。もう 1 つの次元は、インジケーターとデータ ソースで構成されるタイムラインです。データ ソースは、一連のラベルでマークされた一意のデータ収集ポイントです。たとえば、インジケーター cpu.usage のデータは、コンピューター ルーム、アプリケーション、インスタンスなどのディメンションで構成される収集ポイントから取得されます。このようにして、id+{timestamp, value} の時系列データ モデルを論理的に抽象化できます。このデータ モデルはどのように保存されますか?典型的なデータ保存のアイデアは 2 つあります。

• 時間ウィンドウの次元に従ってデータ ブロックを分割する方法。同じ自然な時間ウィンドウ内の連続データは、{1:00、2:00}->(id1、id2、id3、...、idN) のように隣接する位置に配置されます。このアプローチを使用する一般的な時系列データベースには、InfluxDB、Promethues、その他の TSMT 構造化データベースが含まれます。 OpenTSDB は単一値モデルであり、クエリを実行するときにインジケーター ディメンションが必要となるため、多少特殊です。したがって、最初に指標に従って第 1 レベルの分割を行い、次に時間ウィンドウに従って第 2 レベルの分割を行うことができます。本質的には、同じ時間枠内の連続データのままです。時間ウィンドウ分割方式の利点は、ウィンドウに応じて自然にデータをディスクに書き込むことができることです。高次元タグクエリの場合、基本的には連続スキャンになります。この方法のより難しい問題は、「順序が乱れる」という無秩序の問題です。時間ウィンドウの有効期限が切れた後のタイムポイントについては、Promethues はそれらを直接破棄します。この場合、InfluxDB のパフォーマンスが低下します。
• もう 1 つの方法は、タイムラインの次元に応じてデータ ブロックを分割し、(id1)->(1:00、2:00、3:00、...、23:00) のように、同じタイムライン上の隣接する位置にデータを配置することです。 HiTSDB はタイムライン ディメンション分割方式を使用します。現在、データは HBASE に保存され、基礎となる Rowkey はインジケーター + ラベル + 自然ウィンドウで構成されています。 Rowkey はタイムラインのデータ ポイントをサイズ順に結合し、データ ポイントは連続して隣接します。したがって、一部の低次元クエリには非常に効率的です。これまで私たちが接してきた IoT サービスのいくつかに基づくと、それらのほとんどは低次元のアクセスです。中次元のクエリでは、ストリーミング スキャンが使用されます。非常に高次元のタグに対するクエリの場合、HiTSDB は事前集計サービスを使用します (この記事では説明しません)。

1.2 タイミングモデルにおける注目の問題

生産環境では、ビジネス関係者が収集する指標の種類は多様であり、指標の収集サイクルも異なります。たとえば、cpu.usage インジケーターは急速に変化するため、ビジネス側から多くの注目を集めます。収集サイクルは通常、1 秒、5 秒、10 秒など、非常に短くなります。ただし、disk.usage 指標は比較的滑らかな変化傾向を示し、収集期間は通常 1 分、5 分、10 分などです。この場合、同じ指標に対してデータ保存を特別に処理しないと、ホット スポット問題が簡単に発生する可能性があります。ストレージ リソースがインジケーター タイプごとに分割されていると想定します。 20 のビジネスがあり、それぞれに 10 個のクラスターがあり、それぞれに 500 個のホストがあり、収集期間が 1 秒であるとします。すると、1 秒あたり 100,000 個の cpu.usage インジケーター データ ポイントが同じストレージ リソース インスタンスに配置されることになります。 disk.usage の収集期間は 1 分なので、別のストレージ リソースには約 1,666 個のインジケーター データ ポイントのみが保存されます。これにより、重大なデータの歪みが発生します。

1.2.1 バケット化

この種の問題に対する典型的な解決策はバケット化です。たとえば、インジケーターの種類に加えて、ビジネス名とホスト名がディメンション タグとして使用され、インジケーター cpu.usage がさまざまなバケットに分割されます。書き込み時に、データはタイムラインのハッシュ値に応じて異なるバケットに分散されます。 OpenTSDB もホットな問題を処理するためにバケット モードを使用しますが、ブロードキャスト読み取りが必要です。根本的な理由は、クエリ メソッドでは、特定の時間枠内でグローバル スキャンが必要になることです。したがって、OpenTSDB のバケット数を設定するには、バランス調整戦略が必要です。数が少なすぎると、ホットスポットでは依然として局所的な問題が残ります。数が大きすぎると、クエリ中のブロードキャスト読み取りのオーバーヘッドが非常に大きくなります。

比較すると、HiTSDB はブロードキャスト読み取りを回避し、クエリ効率を向上させます。クエリを実行すると、HiTSDB はまずクエリ ステートメントに基づいて正確なタイムラインを取得し、その後スキャン データを基盤となるストレージに送信します。特定のタイムラインを使用すると、バケットの場所を特定し、ブロードキャスト読み取りなしで対応するブロック領域からデータを取得できます。 HiTSDB がデータをクエリするときにヒットタイムラインを取得する方法については、転置インデックスのセクションを読めば読者の疑問は解消されると思います。

1.2.2 リージョンの事前分割

テーブルが作成されると、HBase はデフォルトで新しいテーブルにリージョンを割り当てます。すべての読み取りおよび書き込み要求は、同じ regionServer の同じリージョンにアクセスします。このとき、クラスター内の他のリージョン サーバーは比較的アイドル状態になり、負荷分散効果は得られません。この問題を解決するには、事前分割を使用します。新しいテーブルを作成するときは、バケットの数に基づいてカスタム事前分割アルゴリズムを使用して複数のリージョンを生成します。 byte[][] splitKeys =新しいbyte[bucketNumber-1][]; splitKeys[バケットインデックス-1] = (バケットインデックス&0xFF);

2. 逆インデックス:

2.1 時系列データにおける多次元タイムライン

多次元サポートは、あらゆる新世代の時系列データベースにとって非常に重要です。時系列データには多くの種類があり、そのソースは非常に複雑です。単一次元の時間に基づいて順序付けられた値だけでなく、多次元タイムラインに関連する多数の組み合わせも存在します。たとえば、CPU 負荷は、CPU コア、ホスト、アプリの 3 つの次元で説明できます。各ディメンションには、数百または数万のラベル値が含まれる場合があります。 sys.cpu.load cpu=1 ホスト=ipA アプリ=hitsdb。さまざまな次元を組み合わせると、タイムラインは簡単に百万レベルに到達できます。これらのタイムラインを管理し、インデックスを作成し、効率的なクエリを提供する方法は、時系列データベースで解決する必要がある重要な問題です。現在、時系列分野における主流のアプローチは、転置索引を使用することです。

2.2 逆インデックスの基本的な組み合わせ

基本的なタイムラインの組み合わせのアイデアを逆順に並べると、次のようになります。

タイムラインの元の入力値:

反転ビルド後:

タイムライン cpu=3 および host=ipB を照会します。

交差を取得した後、クエリ結果は 7 になります。

2.3 逆ソートの問題と最適化のアイデア

逆ソートが直面する主な問題はメモリの拡張です。

• 投稿リストが長すぎます。 「コンピュータ室 = 杭州」などの高次元タグの場合、杭州には数千台、あるいは数万台のマシンが存在する可能性があり、投稿リストには数万個の 64 ビット ID を保存する必要があります。この問題を解決するアイデアは、投稿リストを圧縮することです。投稿リストを構築するときは、配列内の ID を並べ替えてから、デルタ エンコーディングを使用して圧縮します。
• タグのキーと値のペアを用語として直接使用する場合、メモリの使用量はその文字列のサイズによって異なります。文字列辞書を使用すると、メモリのオーバーヘッドも大幅に削減できます。

3. ストリーミング集約エンジン

3.1 HiTSDB集約エンジンの技術的な問題点

既存の HiTSDB 集約エンジンのパブリック クラウド ベータ テストおよび社内業務運用中に、次の問題が発見されました。

3.1.1 マテリアライゼーション実行モードではヒープメモリが爆発的に増加しやすい

次の図は、元のクエリ エンジンのアーキテクチャ図を示しています。 HiTSDB は HBase をストレージとして使用し、元のエンジンは Async HBase クライアントを介して HBase から時系列データを取得します。 HBase データの読み取りは時間のかかるプロセスであるため、通常の解決策は、非同期 HBase クライアント API を使用してシステムの並列性を効果的に向上させることです。しかし、元の集計エンジンでは、1) 複数の非同期 HBase API を起動して HBase の読み取りを開始し、2) クエリに含まれるすべての時系列データがメモリに読み込まれたときにのみ集計操作を開始するという、典型的なマテリアライゼーション実行方法を採用していました。 HBase スキャンの結果をメモリに具体化してから集約するこの方法では、HiTSDB がヒープ メモリをオーバーフローしやすくなります。特に、ユーザーが長い時間範囲にわたってクエリを実行したり、大量のタイムライン データをクエリしたりすると、大量の時系列データが関係するため、HiTSDB でヒープ OOM が発生し、クエリが失敗する可能性があります。

3.1.2 大規模クエリによる HBase のバーストの問題

HiTSDB が集計クエリを処理するときに基盤となる HBase をクラッシュさせやすい理由は 2 つあります。

• HBase は冗長なタイムライン データを読み取る場合があります。 HiTSDB タイムラインは、インジケーター + 時間ウィンドウ + ラベルのエンコード方式を使用して HBase に保存されます。一般的なクエリでは、ユーザーはメトリック、時間範囲、空間ディメンションのラベルを指定して、一致する値を検索します。空間ディメンションのラベル クエリ条件が、ラベル エンコーディング プレフィックスにすべて含まれているわけではありません。このような場合、HiTSDB 逆インデックスは、空間ディメンションのクエリ条件に基づいて特定の HBase クエリ条件を正確に特定できず、代わりに最初に読み取り、次にフィルターするアプローチを採用します。つまり、HBase は大量の冗長データを読み取る可能性があり、HBase の負荷が増加します。
• HiTSDB は、短期間に HBase 読み取り要求を大量に発行する場合があります。一方、HiTSDB は HBase のシャード ストレージを使用し、各シャードに対して少なくとも 1 つの読み取り要求が開始されます。一方、前述のマテリアライゼーションの実行方法により、クエリに含まれる HBase 読み取り要求は非同期で同時に送信され、非常に短時間に大量の読み取り要求を HBase に送信することが可能になります。このように、大規模なクエリは基盤となる HBase に過大な負荷をかける可能性があります。

このような状況が発生すると、最悪のシナリオでは、HiTSDB が時系列データの書き込み要求を処理できなくなり、後続の新しいデータが失われることになります。

3.1.3 実行アーキテクチャが高度に結合されているため、機能の変更や追加が困難である

集計エンジンは主にパフォーマンス監視に使用され、固定クエリ モードを備えています。したがって、エンジン アーキテクチャは、クエリ、フィルタリング、充填/補間、および集計操作のロジックを高度に結合した単一モードを使用します。このエンジン アーキテクチャでは、監視アプリケーションの固定クエリに対して多くの問題が発生することはありません。ただし、HiTSDB は監視シナリオでの単純なクエリだけでなく、より多くのアプリケーション シナリオでの複雑なクエリも対象としています。

元のエンジン アーキテクチャに基づいて機能を追加したり、元の実装を変更したりすることは困難であることがわかりました。根本的な理由は、元の集計エンジンが従来のデータベースで一般的に使用されている実行アーキテクチャを採用していなかったことです。実行レイヤーは複数のカスタマイズ可能な実行演算子で構成されており、異なる実行演算子を組み合わせることでクエリ セマンティクスを完成させることができます。この問題は、製品開発の初期段階ではそれほど深刻に感じられませんでしたが、HiTSDB の適用シナリオの拡大や新機能の追加に深刻な影響を与える重要な要素です。

3.1.4 集約作業の効率化が必要

元のエンジンが集計操作を実行する場合、従来のデータベースで一般的に使用されている反復実行モードと同じ方法で集計操作を反復的に実行します。問題は、反復が実行されるたびに、ある時点が返されることです。反復実行では、毎回時点またはレコードが返されます。これは、OLTP クエリでアクセスする必要があるレコードの数が非常に少ないため、OLTP などのシナリオでは一般的です。ただし、HiTSDB に対するクエリでは大量のタイムライン データへのアクセスが必要になる場合があり、この実行方法は効率的ではありません。

その理由は次のとおりです。1) 時間点が処理されるたびに、一連の関数呼び出しが必要になり、パフォーマンスに影響します。 2) 反復ループの反復に含まれる関数呼び出しでは、新しいハードウェアでサポートされている SIMD 並列実行の最適化を利用できず、関数コードはインライン化やその他の一般的に使用される JVM ホットスポット最適化方法によって最適化することもできません。大量のデータのシナリオでは、現在一般的に行われている方法はベクトル化処理を導入することです。つまり、各反復で単一のレコードではなく行のバッチが返されます。たとえば、Google Spanner は行単位ではなくバッチ単位を使用し、Spark SQL も実行レイヤーでベクトル化実行モードを使用します。

3.2 ストリーミング集約エンジンの設計思想

HiTSDB のオリジナルの集計計算エンジンの問題を解決し、HiTSDB を最適化して商用運用をサポートするために、HiTSDB の集計計算エンジンを変換することを決定しました。次の図は、新しい集計クエリ エンジンの基本的なアーキテクチャを示しています。

3.2.1 パイプライン実行モード

従来のデータベース実行モードを参考にして、パイプライン実行モード (別名 Volcano / Iterator 実行モード) が導入されました。パイプラインにはさまざまな実行演算子が含まれています。クエリは、さまざまな実行演算子で構成される物理プラン ジェネレーターによって解析され、DAG または演算子ツリーに分解されます。 DAG のルート演算子は、クエリの実行を駆動し、クエリ結果を呼び出し元に返す役割を担います。実行レベルでは、トップダウンの需要主導型アプローチが採用され、ルート オペレーターが下位のオペレーターの実行を駆動します。このような実行エンジン アーキテクチャには、次の利点があります。

• このアーキテクチャアプローチは多くのデータベースシステムで採用されており、効果的であることが証明されています。
• インターフェース定義が明確であり、異なる実行計算演算子を他の演算子に影響を与えることなく個別に最適化できます。
• 拡張が容易: 新しいコンピューティング演算子を追加することで、機能を簡単に拡張できます。たとえば、現在のクエリ プロトコルでは、タグに対するクエリ条件のみが定義されます。インジケータ値 (cpu.usage >= 70% かつ cpu.usage <=90%) に対するクエリ条件をサポートする場合は、新しい FieldFilterOp を追加することでこれを実現できます。

各演算子は次のインターフェースを実装します。

• 開く: リソースの初期化と設定
• 次へ: 入力演算子の next() を呼び出して時系列のバッチを取得し、入力を処理して時系列のバッチを出力します。
• 閉じる: リソースを閉じて解放する

HiTSDB には次の演算子が実装されています。

• ScanOp: HBaseからタイムラインデータを非同期に読み取るために使用します。
• DsAggOp: ダウンサンプリング計算と塗りつぶし値の処理に使用されます
• AggOp: グループ集約操作に使用され、PipeAggOp、MTAggOpに分かれています。
• RateOp: タイムライン値の変化率を計算するために使用されます

3.2.2 計算演算子を実行します。バッチのタイムラインデータが計算単位となります。

バッチのタイムライン データは、コンピューティング エンジンの実行パフォーマンスを向上させるために、コンピューティング オペレーター間の単位として使用されます。そのアイデアは、OLAP システムで採用されているベクトル化処理モードから借用したものです。このようにして、Operator は、バッチの複数のタイムラインと各タイムラインの複数の時点を処理するときに、関数呼び出しのコストを削減し、ループの実行効率を向上させることができます。

各オペレーターは、入力からタイムライン バッチをストリーミング方式で取得し、処理して、タイムライン バッチを出力します。入力タイムライン バッチを保存する必要がないため、メモリ要件が削減されます。これは、演算子のセマンティクスによって入力が具体化される必要がある場合にのみ実行されます (以下で説明する集計演算子のさまざまな実装を参照してください)。

3.2.3.異なるクエリシナリオを区別し、それぞれ異なる集計演算子を使用して最適化します。

HiTSDB のオリジナルの集計エンジンは、マテリアライズ実行モードを使用します。重要な理由の 1 つは、時系列データの補間演算を処理することです。これは主に、時系列データの典型的な特徴がタイムラインの不整合であるためです。異なるタイムラインには異なるタイムスタンプのデータが含まれます。 HiTSDB は OpenTSDB プロトコルと互換性があり、補間の概念を導入しています。目的は、集計操作中に指定された補間方法を通じて、不揃いのタイムスタンプに計算値を挿入し、不揃いのタイムライン データを揃いのタイムラインに変換することです。補間は、同じグループ内のすべてのタイムラインを比較して、どのタイムスタンプで補間が必要かを判断することによって行われます (OpenTSDB のドキュメントを参照)。

集計クエリのパフォーマンスを最適化するために、さまざまな集計演算子を導入しました。目的は、さまざまなクエリのセマンティクスに基づいてさまざまな最適化を実行することです。一部の集計クエリでは補間が必要ですが、他の集計クエリでは必要ありません。補間が必要な場合でも、補間操作を実行するには、同じ集約グループのタイムライン データをメモリに読み込むだけで済みます。

• PipeAggOp: 集計クエリが以下の条件を満たす場合、

1) 補間は不要: クエリはダウンサンプリングを使用し、ダウンサンプリングされた値は null/NaN 以外の値で埋められます。このようなクエリの場合、ダウンサンプリング後にタイムライン データが整列して完全になるため、集計関数で使用される補間は不要になります。

2) 集計関数は、sum、count、avg、min、max、zerosum、mimmim、mimmax などの増分反復集計をサポートできます。すべての入力データをメモリに読み込まなくても、増分集計を使用できます。この実行演算子はパイプライン アプローチを採用しています。毎回、入力演算子から一連のタイムラインを取得し、グループを計算し、集計関数の一部の値を更新します。完了後、入力タイムラインをクリーンアップし、各グループの集計関数の値のみを保持できます。

• MTAgOp: 補間が必要であり、入力演算子はタイムライン ID を事前にグループ化する必要があり、元の集約エンジンによって採用された実行モードにフォールバックします。

MTAggOp では、最適化のためにグループ化集計方法を導入できます。

• GroupedAggOp: 補間が必要ですが、入力演算子により、タイムライン ID がタグに従って並べ替えられ、グループ化されることを保証できるため、パイプライン処理では 1 つのデータ グループのみを具体化する必要があります。この演算子は、グループ化されたすべてのタイムラインをメモリ内に保持するよりもメモリ要件が低く、異なるグループ間の並列集計操作をサポートします。

3.2.4 クエリオプティマイザとエグゼキュータ

実行演算子とパイプライン実行モードを導入した後、HiTSDB をクエリ オプティマイザーとエグゼキューターの 2 つの主要モジュールに分割できます。オプティマイザーは、クエリのセマンティクスと実行演算子のさまざまな特性に基づいてさまざまな実行プランを生成し、クエリ処理を最適化します。たとえば、HiTSDB は、上で説明した 3 つの集計演算子を使用し、さまざまなシナリオで異なる実行演算子を使用することで、クエリ実行中のメモリ オーバーヘッドを削減し、実行効率を向上させることができます。この処理方法は、集計エンジンの元の単一実行モードよりも最適化されています。

4. データ移行

HiTSDB の新しい集計エンジンで使用される基礎となるストレージ形式は、以前のバージョンと互換性がありません。パブリック クラウドのベータ期間中は、古いバージョンのインスタンス上で実行されているデータを新しい集約エンジンに移行する必要があります。同時に、ホット アップグレードに問題がある場合は、データ移行にロールバック機能も備え、新しいバージョンのデータ ポイントを古いデータ構造に変換して、バージョン ロールバックを実現する必要があります。全体的なソリューションは、ユーザーに次のような影響を及ぼします。アップグレード プロセス中は書き込みが認識されず、履歴データは読み取れません。

4.1 データ移行アーキテクチャ

• データの同時変換と移行: 元の HiTSDB データ ポイントは、書き込み時に分割されています。デフォルトでは 20 個の Salt があります。データ移行ツールは、各 Salt データ ポイントを同時に処理します。各「ソルト」にはプロデューサーとコンシューマーが存在します。プロデューサーは、データ ポイントを取得するために HBase Scanner を起動する責任があります。各スキャナーは HBase を非同期的にスキャンし、毎回 HBASE_MAX_SCAN_SIZE 行のデータ ポイントを取得します。次に、HBase 行キーを新しい構造に変換します。

最後に、行はキューに配置され、コンシューマーが消費するのを待機します。コンシューマーは毎回 HBASE_PUT_BATCHSIZE または HBASE_PUT_MIN_DATAPOINTS のデータを処理します。コンシューマーがバッチを正常に書き込むたびに、対応する「ソルト」のデータ処理場所が UID テーブルに記録されます。これにより、障害が発生して再起動したときに、プロデューサーが最後に成功したポイントから変換用のデータ ポイントの取得を開始することが容易になります。データ移行ツールは、HBase 操作に非同期の読み取りと書き込みを使用します。データのスキャンまたは書き込みが失敗した場合、限定的に試行します。試行回数を超えた場合、この「Salt」のデータ移行作業を終了し、他の「Salt」の作業には影響しません。次回ツールが自動的に再起動すると、すべてのデータが正常に変換されるまで、問題のある「Salt」データの移行が続行されます。

• フロー制御の制限: ほとんどの場合、プロデューサーはコンシューマーが HBase に書き込むよりも速く HBase データをスキャンします。キュー データのバックログがメモリに負担をかけるのを防ぎ、プロデューサーがデータをスキャンするときに HBase にかかる負担を軽減するために、フロー制御を設定します。キューのサイズが HBASE_MAX_REQUEST_QUEUE_SIZE に達すると、プロデューサーは HBase データのスキャンを一時的に停止し、コンシューマーが消費するまで待機します。キューのサイズが HBASE_RESUME_SCANNING_REQUEST_QUEUE_SIZE まで縮小されると、プロデューサーは再開します。
• プロデューサーとコンシューマーのプロセスの終了

すべてが正常に完了したときに終了する方法: すべてがうまくいき、プロデューサーがデータ スキャンを完了すると、キューに EOS (スキャンの終了) を置いて終了します。コンシューマーが EOS に遭遇すると、バッチが最後のバッチであることを認識し、バッチを正常に処理した後、自動的に終了します。

障害後にシャットダウンする方法: コンシューマーが問題に遭遇した場合: コンシューマーが HBase への書き込みに失敗すると、コンシューマーはフラグを設定してからスレッドを終了します。プロデューサーが次の HBASE_MAX_SCAN_SIZE をスキャンする準備ができると、まずフラグをチェックします。設定されている場合、対応するコンシューマー スレッドが失敗したことを認識して終了します。プロデューサーもスキャンを停止して終了します。プロデューサーに問題が発生した場合: プロデューサーがデータのスキャンに失敗した場合、処理方法は正常に完了した場合と同様です。すべての通知は、EOS をキューに送信することで完了します。次に再起動すると、Producer は最後に記録されたデータ処理位置から再スキャンします。

4.2 データ移行の一貫性

HiTSDB の現在のクラウド バージョンはデュアル ノード バージョンであるため、ノードのアップグレードが完了すると HiTSDB は自動的に再起動されます。自動起動スクリプトは、データ移行ツールを自動的に実行します。予防措置を講じない場合、2 つの HiTSDB ノードが同時にデータを移行します。データの損失や損傷はありませんが、HBase への書き込みと読み取りの負荷が大きくなり、ユーザーの通常の書き込みとクエリのパフォーマンスに重大な影響を及ぼします。

これを防ぐために、HBase の Zoo Keeper を通じて FileLock のようなロック (DataLock と呼ぶ) を実装し、1 つのノードだけがデータ移行プロセスを開始するようにしました。データ移行プロセスが開始されると、非ブロッキング tryLock() と同様の方法で、Zoo Keeper の特定のパス内に一時ノードが作成されます。ノードが正常に作成されると、DataLock が取得されます。ノードがすでに存在する場合、つまり別の HiTSDB によって作成された場合は、KeeperException が発生します。これは、ロックが取得されず、すぐに失敗が返されることを意味します。 DataLock が正常に取得されない場合、ノード上のデータ移行プロセスは自動的に終了します。 DataLock を取得したノードはデータ移行を開始します。

4.3 データ移行における「一度実行」

すべての「Salt」データ ポイントが正常に移行されると、新しいデータ行 (data_conversion_completed) が古い HBase テーブルに挿入されます。この行は、データ移行プロジェクトが正常に完了したことを表します。同時に、自動スクリプトは 12 時間ごとにデータ移行ツールを起動し、最後のデータ移行が完了するのを防ぎます。起動するたびに、まず「data_conversion_completed」フラグをチェックします。フラグが存在する場合、ツールは直ちに終了します。この操作では HBase を 1 回だけクエリするため、通常のヘルス チェックのコストよりも安価になります。したがって、データ移行ツールを定期的に起動しても、HiTSDB や HBase には影響しません。

4.4.データ移行の評価

効果: オンライン化後、100 を超えるインスタンスのデータの移行とホット アップグレードが問題なく完了しました。

5. クエリパフォーマンス評価

ケース 1: データ収集頻度 5 秒、クエリ ヒット数 1000、時間ウィンドウ 3600 秒

概要: 新しいクエリ集約エンジンにより、クエリ速度が 10 倍以上向上します。

他の

本稿では、高性能時系列データベースHiTSDBエンジンの商用運用開始前の最適化とアップグレードについて紹介し、HiTSDBエンジンの安定性、データ書き込みとクエリのパフォーマンス、新機能のスケーラビリティの向上を目指します。 HiTSDB は Alibaba Cloud で正式に商用運用が開始されました。当社は、HiTSDB のお客様により良いサービスを提供するために、ユーザーからのフィードバックに基づいて HiTSDB エンジンをさらに改善していきます。

【この記事は51CTOコラムニスト「アリババオフィシャルテクノロジー」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください