分散時系列データベースQTSDBの設計と実装

既存のオープンソースの時系列データベース InfluxDB は、単一マシンの操作のみをサポートしています。大量のデータが書き込まれる場合、クエリが遅くなり、マシンの負荷が高くなり、単一のマシンの容量が制限されます。

この問題を解決するために、360 インフラストラクチャ チームは、スタンドアロンの InfluxDB に基づくクラスター バージョンである QTSDB を開発しました。

1. QTSDBの簡単な紹介

QTSDB は、大量のデータの書き込みとクエリを処理するために使用される分散時系列データベースです。実装面では、オープンソースのスタンドアロン時系列データベース InfluxDB 1.7 をベースに開発された分散バージョンです。 InfluxDB 自体の特徴に加え、容量拡張やレプリカフォールトトレランスなどのクラスター機能も備えています。

主な機能は次のとおりです。

• 書き込みパフォーマンスとディスク領域の使用量の両方を考慮して、時系列データ用に特別に作成された高性能データ ストレージ。
• 複数の統計集計関数をサポートする、SQL のようなクエリ ステートメント。
• 期限切れのデータを自動的にクリーンアップします。
• 組み込みの継続クエリにより、ユーザーが事前に設定した集計操作を自動的に完了します。
• Golang で記述されており、他の依存関係がなく、展開と操作が簡単です。
• 大規模なデータストレージをサポートするためのノードの動的な水平拡張。
• レプリカ冗長設計、自動フェイルオーバー、高可用性のサポート。
• データ書き込みを最適化し、高スループットをサポートします。

2. システムアーキテクチャ

1. 論理ストレージ階層

InfluxDB アーキテクチャの最初の層はデータベースです。異なるデータ保持期間に応じてデータベースの下に異なる保持ポリシーが設定され、データベースの下に複数のストレージ コンテナーが形成されます。時系列データベースは時間ディメンションに関連付けられているため、同じ保存期間のコンテンツは一緒に保存され、期限が切れると簡単に削除できます。また、保持ポリシーでは、保持ポリシーの保持期間がさらに細分化され、各期間のデータがシャードグループに保存されます。この方法では、セグメント化されたシャード グループの有効期限が切れると、ストレージ エンジンから一部のデータが抽出されるのを避けるために、シャード グループ全体が削除されます。たとえば、データベース内のデータは 30 日間または 7 日間保持され、異なる保持ポリシーに基づいて保存されます。 7 日間のデータがさらに 1 日に分割されると仮定すると、それぞれ 7 つのシャード グループに保存されます。 8日目のデータが生成されると、それを書き込むために新しいシャードグループが作成され、1日目のシャードグループは削除されます。

これまでのところ、同じ保持ポリシーでは、送信された現在の時系列データは現在の期間にのみ該当します。つまり、最大のシャード グループにのみデータが書き込まれます。同時実行性を高めるために、シャード グループは複数のシャードに分割されます。これらのシャードはグローバルに一意であり、すべての物理ノードに分散されます。各シャードは、データの保存を担当する tsm ストレージ エンジンに対応します。

データへのアクセスを要求するときに、要求情報に基づいてデータベースと保持ポリシーをロックし、要求内の期間情報に基づいて特定のシャード グループをロックできます。書き込みの場合、書き込まれたデータの各部分は serieskey に対応します (この概念については後で説明します)。シリーズキーのハッシュ モジュロを取得することで、シャードを書き込み用にロックできます。シャードにはレプリカがあり、書き込み時にはマスターレスのマルチ書き込み戦略を使用して各レプリカに同時に書き込みます。クエリを実行する場合、クエリ要求に serieskey 情報がないため、シャード グループ内のすべてのシャードのみをクエリできます。シャードの場合、アクセス可能な物理ノードがレプリカから選択されます。

では、シャード グループにはシャードがいくつあるのでしょうか?データの全体的な順序に過度に干渉することなく最大限の同時実行性を実現するために、物理ノードとレプリカの数が決定された後、シャード グループ内のシャードの数は、マシンの数をレプリカの数で割った数になります。これにより、現在のデータがすべての物理ノードに均等に書き込まれるようになり、シャードが多すぎてもクエリの効率が影響を受けなくなります。たとえば、図のデータ クラスターには 6 つの物理ノードがあり、ユーザーがデュアル レプリカを指定しているため、シャードは 3 つあります。

2. クラスター構造

システム全体は、プロキシ、メタ クラスター、データ クラスターの 3 つの部分に分かれています。プロキシはリクエストを受信する役割を担い、ステートレスです。 LVSに接続して水平拡張をサポートします。メタ クラスターは、上記の論理ストレージ階層と物理ノードとの対応関係を保存し、ラフト プロトコルを通じてメタデータの強力な一貫性を保証します。ここで、メタ情報はメモリに保存され、ログとスナップショットはディスクに保存されます。データ クラスターは実際のデータ ストレージ ノードです。データはシャードに保存され、各シャードは TSM ストレージ エンジンに対応します。

リクエストが到着すると、LVS はプロキシをロックします。プロキシはまず、データベース、保持ポリシー、および期間に基づいてメタ クラスターでメタ情報を検索し、最後にシャードから物理ノードへのマッピングを取得します。このマッピング関係は、物理ノードからシャードへのマッピングに変換され、プロキシに返されます。最後に、このマッピング関係に基づいて、プロキシはデータ クラスターで指定された物理ノード内の特定のシャードにアクセスします。シャード下のデータアクセスについては後ほど紹介します。

3. データアクセス

1. 構文形式

InfluxDB は、リレーショナル データベースと同様のクエリ メソッドを提供し、リレーショナル テーブルとして表示されます: measurement。時系列データベースの時間は永続的な列です。その他の列は 2 つのカテゴリに分かれています。

• フィールド: 1 つのタイプはフィールドであり、時系列データの最も重要なデータ部分です。その値は、各時点での 2 台のマシン間の遅延など、時間の流れとともに継続的に追加されます。
• タグ: 別のタイプはタグです。これはフィールド値のマークであるため、すべて文字列タイプであり、値の範囲が非常に限られています。たとえば、ある時点での遅延フィールドの値は 2 ミリ秒であり、これはどのマシンからどのマシンまでの遅延かという 2 つのタグ属性に対応します。したがって、from と to の 2 つのタグを設計できます。

測定値の最初の行がキーであり、残りは値として見ることができます。このように、タグには tagkey と tagvalue があり、フィールドには fieldkey と fieldvalue があります。

2. データの読み取りと書き込み

書き込みデータの行が受信されると、次の形式に変換されます。

測定+タグキー1+タグ値1+タグキー2+タグ値2+フィールドキー+フィールド値+時間

行に複数のフィールドがある場合、データは複数のレコードに分割されて保存されます。 influxdb のストレージ エンジンは、measurement から fieldkey をストレージ キーとして、それに続く fieldvalue と time をストレージ値としてマップとして理解できます。これらの値は継続的に追加されます。ストレージ エンジンでは、これらの値は列としてまとめて保存されます。時間の経過とともに徐々に変化するデータなので、まとめて保存することで圧縮効果を高めることができます。また、ストレージキーからフィールドキーを取り除いた残りの部分が、前述のシリーズキーとなります。

前述のように、アクセス要求によってクラスター内のシャードがロックされる仕組み。ここでは、シャード内のアクセスについて紹介します。

InfluxDB クエリは SQL 構文に似ていますが、SQL ステートメントの散在した情報はストレージ エンジンに直接クエリできないため、SQL ステートメントをストレージ キーに変換するには何らかの戦略が必要です。 InfluxDB は、転置インデックスを構築して where の後のタグ情報をすべての関連する serieskeys のセットに変換し、select の後の fieldkey と各 serieskey を連結してストレージ キーを形成し、対応するデータを列ごとに取得できるようにします。

tsm ストレージ エンジンのストレージ キー内の serieskey を分析することで、逆インデックスを構築できます。新しいバージョンの influxdb は、データを保存する tsm ストレージ エンジンに対応する各シャードに逆インデックスを永続化します。これは、tsi ストレージ エンジンと呼ばれます。転置インデックスは 3 層マップと同等です。マップのキーは計測、値は 2 層のマップです。 2 層マップのキーは tagkey であり、対応する値は 1 層マップです。最初のレイヤー マップのキーは tagval であり、対応する値は serieskey セットです。このセット内の各 serieskey 文字列には、マップ インデックス パス上の測定値、タグキー、およびタグ値が含まれます。

この方法では、クエリ SQL を分析し、from の後の測定を使用して転置インデックスの第 3 レベルのマップをクエリし、第 2 レベルのマップを取得し、where の後の複数のフィルタリング ロジック ユニットを分析できます。 tagkey1=tagval1 を例にとり、これら 2 つの情報を第 2 レベル マップのキーとして使用し、最終値である serieskey セットを見つけます。このセット内の各 serieskey 文字列には、measurment、tagkey1、tagval1 が含まれます。これらは、現在のフィルタリング ロジック ユニットに適合する serieskey です。これらの論理単位の AND または OR ロジックに従って、対応する serieskey セットが交差して結合され、最終的にロジックを満たすすべての serieskey セットが SQL のセマンティクスに従ってフィルター処理されます。次に、これらのシリーズキーは選択後にフィールドキーと連結され、最終的なストレージキーが取得され、データを読み取ることができます。

集計関数を使用しないクエリ: 図に示すように、serieskey の場合、複数の fieldkeys を連結し、複数の列からデータを抽出する必要があります。それらが出てきた後の問題は、それらをどのようにして 1 行のデータに結合するかということです。 InfluxDB の行と列の制約は比較的緩く、列内のオフセットだけで行を決定することはできません。 Influxdb は、列データが行であるかどうかを判断する基準として serieskey と time を使用します。各 serieskey に対応する複数の列は、複数行の粒度でデータ ストリームに集約されます。複数の serieskeys に対応するデータ ストリームは、特定の順序で 1 つのデータ ストリームに集約され、最終結果セットとしてクライアントに返されます。

集計関数を使用したクエリ: この方法は、上記のクエリと正反対です。ここで、集計関数のパラメータ フィールドは、多数のシリーズ キーと連結されます。もちろん、最終的な目標は同じで、ストレージ キーを取得することです。複数のストレージ キーで複数のデータ ストリームを読み取ることができます。これらのデータ ストリームには 2 種類の処理が行われます。まず、それらは特定の順序でデータ ストリームに集約され、次に、このデータ ストリーム内の隣接するデータが特定の集約計算戦略に従って囲まれ、最終的な集約値が得られます。ここでの順序と戦略は、SQL ステートメントの group by 後の集計方法から取得されます。

複数のデータ ストリームのマージと集約は、シャード上のクエリ結果にも適用できます。

書くことは比較的簡単です。データ ストレージ エンジンと転置インデックスを直接更新するだけです。

3. 全体のプロセス

アクセスプロセス全体については上記で説明しました。全体的な概要は次のとおりです。これは、シャード上のクエリとシャード下のクエリの 2 つのステージに分かれています。

まず、アクセス要求は LVS を介してプロキシにロックされます。プロキシはメタ クラスターでメタ情報を検索し、要求情報に基づいてデータベース、リテンション ポリシー、およびシャード グループをロックして、多数のシャードを取得します。

書き込み操作の場合、書き込み中に使用されるシリーズキーに従って、シャードは書き込み用にロックされます。シャードには複数のコピーがあるため、データは複数のコピーに同時に書き込まれる必要があります。クエリの場合、シリーズ キーはリクエスト情報を通じて取得できないため、すべてのシャードをクエリし、アクセスするには各シャードの利用可能なコピーを選択する必要があります。

上記の処理の後、シャードから物理ノードへのマッピングが取得され、それが物理ノードからシャードへのマッピングに逆転されてプロキシに返されます。その後、プロキシはデータ クラスター内のノードにある対応するシャードにアクセスできるようになります。

シャード下の書き込みアクセスの場合、挿入ステートメントを分解し、ストレージのキーと値のペアに結合して TSM ストレージ エンジンに格納し、結合された serieskey に従って転置インデックスを更新する必要があります。

シャード下のクエリ アクセスの場合、SQL ステートメントを分析し、転置インデックスをクエリし、関連する serieskey セットを取得し、フィールドを連結して最終的なストレージ キーを形成し、データにアクセスします。そして、大量のデータがデータノード上のシャードにマージ・集約され、プロキシ上のデータにマージ・集約されます。

最後に、プロキシはアクセス結果をクライアントに返します。

4. トラブルシューティング

1. 戦略

前述のように、InfluxDB はシャードに対してレプリカのフォールト トレランスを提供します。書き込みデータがプロキシに送信されると、プロキシはマスターレス マルチ書き込みの形式でデータをすべてのシャード コピーに送信します。メタ クラスターは、ハートビートの形式でデータ ノードがオンラインかどうかを監視します。読み取り時には、同じシャードのオンライン データ ノードから読み取りノードをランダムに選択します。

書き込み中にデータノードが利用できない場合、データはプロキシの一時ファイルに書き込まれ、ネットワークが正常に戻ったときに一時的に保存されたデータが指定されたノードに送信されます。

2. 処理

（１）データクラスターの拡大

新しいノードがデータ クラスターに参加した場合、既存のデータの自動移行は現在サポートされていません。しかし、いくつかの努力はなされてきた。現在書き込まれているデータをできるだけ早く新しいノードに適用するために、新しいノードが追加されると、現在の時刻が現在のシャード グループの終了時刻として使用され、新しいデータ ノードの数に応じて新しいシャード グループが作成されます。この方法により、現在のデータ量を各データノードに即座に均等に分散することができ、各シャードグループに関連するメタ情報はメタクラスターに保存されるため、以前のデータの読み取りを妨げることはありません。

（２）データノードが一時的に利用できない

データ ノードが、短時間のネットワーク障害後の自己回復や、ハードウェア障害後の運用保守担当者による介入など、短期間の使用不可状態にあり、切断前のデータがデータ ノードにまだ保持されている場合、データ ノードは元の ID でデータ クラスターに参加できます。書き込みの場合、プロキシは使用不可期間中にこのデータ ノードのデータを一時的に保存し、データがクラスターに参加したときにこのデータの一部をデータ ノードに再度送信して、データの最終的な一貫性を確保します。

（３）データノードが長時間利用できない

何らかの理由でデータ ノードが元の ID を使用してクラスターに参加できない、または参加する必要がない場合は、運用および保守担当者が元の使用不可のデータ ノードを手動でオフラインにする必要があります。その後、このマシンが利用可能になると、新しいデータ ID を使用してクラスターに参加できます。これは、クラスターの容量を拡張することと同じです。

V. 結論

QTSDB クラスターは次のように実装されています。書き込み時にはシリーズ キーに従って指定されたシャードにデータが書き込まれますが、読み取り時にはシリーズ キーを予測できないため、各シャードをクエリする必要があります。読み取りプロセス全体は、データ ノード上のストレージ エンジンを読み取り、ノード内で複数のシャードをマージおよび集約する段階と、プロキシ ノード上の複数のデータ ノードのデータを集約し、その後マージおよび集約して最終結果セットを形成し、クライアントに返す段階の 2 つの段階に分かれています。

QTSDB の既存のクラスタリング機能はまだ不完全であり、今後の使用に向けて継続的に改善される予定です。

[この記事は、51CTOコラムニスト360 Technology、WeChatパブリックアカウント「360 Technology（id: qihoo_tech）」からのオリジナル記事です]

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