Xエンジンの概要 - ApsaraDB RDS - Alibaba Cloud ドキュメントセンター

X-Engineは、Alibaba Cloudのデータベース製品ビジネスユニットによって開発されたオンライントランザクション処理 (OLTP) データベース指向のストレージエンジンです。 X-Engineは、コストを削減するためにAlibaba Group内の多くのビジネスシステムで広く使用されています。これらのシステムは、トランザクション履歴データベースおよびDingTalkチャット履歴データベースを含む。さらに、X-Engineは、Alibaba Groupが中国で開催されるショッピングフェスティバルDouble 11の期間中、平均の数百倍にも急増する可能性のあるトラフィックのバーストに耐えることを可能にする重要なデータベーステクノロジーです。

背景情報

X-Engineは、Alibaba Groupが内部ワークロードを実行できるように設計されています。 Alibaba Groupは、2010年からMySQLデータベースを大規模にデプロイしています。ただし、年々指数関数的に増加する大量のデータは、これらのデータベースに次の課題を課し続けています。

同時並行性の高いトランザクションを処理します。
大量のデータを保存します。

処理能力とストレージ容量を増やすために、より多くのデータベースを作成できるサーバーを追加できます。しかし、この方法は非効率的である。 Alibaba Cloudは、技術的手段を使用して最小限のリソースでパフォーマンスを最大化することを目指しています。

従来のデータベースアーキテクチャの性能は、注意深く研究される。データベース分野のリーダーであり、Turing Awardの受賞者であるMichaelStonebreakerは、このトピックについてOLTP Through the Looking GlassとWhat We Found Thereというタイトルの論文を書きました。論文の中で、彼は、従来の汎用リレーショナルデータベースが実際にデータを処理するのに10% 未満の時間しか費やさないことを指摘しています。残りの90% は、ロックされたリソースの解放待ち、バッファの管理、ログの同期など、他の作業に浪費されます。

これは、近年依存しているハードウェアシステムの大幅な変更が原因です。これらには、マルチコアおよび多コアCPU、キャッシュ専用メモリアーキテクチャ (COMA) および非均一メモリアクセス (NUMA) などの新しいプロセッサアーキテクチャ、GPUおよびフィールドプログラマブルゲートアレイ (FPGA) などのさまざまな異種コンピューティングデバイスが含まれます。しかし、これらのハードウェアシステム上に構築されたデータベースソフトウェアはあまり変わっていません。このようなソフトウェアは、Bツリー索引付けに基づいてページサイズを固定するメカニズム、トランザクションを処理し、セマンティクス (ARIES) アルゴリズムを利用する回復および分離を使用することによってデータを復元するメカニズム、および独立したロックマネージャに基づいた同時実行制御メカニズムを含む。これらのソフトウェアメカニズムは低速ディスクに基づいて設計されているため、前述のハードウェアシステムの潜在的なパフォーマンスを実現できません。

Alibaba Cloudは、現在使用されているハードウェアシステムの要件をサポートするX-Engineを開発しました。

アーキテクチャ

MySQLのプラガブルストレージエンジンを使用すると、X-engineをMySQLとシームレスに統合し、階層ストレージアーキテクチャを使用できます。

X-Engineは、大量のデータを保存し、同時トランザクションの処理能力を高め、ストレージコストを削減するように設計されています。大量のデータがあるほとんどのシナリオでは、データは均等にアクセスされません。ホットデータと呼ばれる頻繁にアクセスされるデータは、ごく一部しか占めていません。 X-Engineは、アクセス頻度に基づいてデータを複数のレベルに分割します。さらに、X-Engineはストレージ構造を決定し、各レベルのデータのアクセス特性に基づいて適切なストレージデバイスにデータを書き込みます。

X-Engineは、階層ストレージ用に再設計されたログ構造化マージツリー (LSMツリー) アーキテクチャを使用します。

X-Engineは、トランザクションの実行を促進するために多数のメモリデータベーステクノロジーを使用して、ホットデータと更新されたデータをメモリに保存します。これらの技術には、ロックフリーのインデックス構造と追加専用のデータ構造が含まれます。
X-Engineは、トランザクション処理パイプラインメカニズムを使用して、複数のトランザクション処理ステージを並列に実行します。これにより、スループットが大幅に向上します。
コールドデータと呼ばれるアクセス頻度の低いデータは、徐々に削除または永続的なストレージレベルにマージされ、NVM、SSD、HDDなどの階層ストレージデバイスに格納されます。
性能に重大な影響を与える圧縮に対して多くの改良がなされている。
- データ記憶の粒度は、データ更新ホットスポットの集中に基づいて改良される。これにより、コンパクションプロセスで可能な限りデータが再利用されます。
- LSMツリーの階層は、I/Oおよびコンピューティングコストを削減し、コンパクションによって消費されるストレージを最小限に抑えるために洗練されています。
よりきめ細かいアクセス制御とキャッシュメカニズムを使用して、読み取りパフォーマンスを最適化します。

その他の特長

FPGAハードウェアは、コンパクションを高速化し、データベースシステムのパフォーマンスをさらに最大化するために使用されます。これは、ハードウェアアクセラレーションがOLTPデータベースのストレージエンジンに適用されるのは初めてのことです。この成果は、FPGA-Accelerated Compactions for LSMベースのキーバリューストアというタイトルの論文にまとめられています。この論文は、2020年の第18回USENIX Conference on File and Storage Technologies (FAST'20) に承認されました。
データ再利用技術は、コンパクションのコストを削減し、キャッシュからのデータ削除によって引き起こされるパフォーマンスのジッターを軽減するために使用されます。
キューイングされたマルチトランザクション処理とパイプライン処理を使用して、スレッドコンテキスト切り替えのオーバーヘッドを削減し、各ステージでタスク比率を計算します。これにより、パイプライン全体が合理化され、RocksDBなどの他の同様のストレージエンジンと比較してトランザクション処理パフォーマンスが10倍以上向上します。
コピーオンライト技術は、データページが読み出されるときにデータページが更新されるのを防止するために使用される。これにより、読み取り専用データページを符号化および圧縮することができる。これはまた、InnoDBなどの従来のストレージエンジンと比較して、ストレージ使用量を50% 90% 削減します。
ブルームフィルタは、要求されたデータが存在するかどうかを迅速に判断するために使用され、簡潔なレンジフィルタ (SuRF) は、レンジデータが存在するかどうかを判断するために使用され、行キャッシュは、ホットデータ行をキャッシュして読み取り操作を加速するために使用される。

LSMの基本ロジック

すべてのLSMベースの書き込み操作は、データをメモリに追加することによってデータを書き込みます。書き込まれたデータの量が特定の量に達すると、データはレベルとしてフリーズされ、永続的ストレージにフラッシュされます。データが書き込まれるすべての行は、データがメモリに格納されているか永続ストレージに格納されているかにかかわらず、プライマリキーに基づいてソートされます。メモリにおいて、データは、スキップリストまたはBツリーなどのソートされたメモリ内データ構造で記憶される。永続ストレージでは、データは読み取り専用の完全にソートされた永続ストレージ構造に格納されます。

共通のストレージエンジンが共通のストレージシステムでトランザクション処理をサポートできるようにするには、一時的な要素を追加する必要があります。これに基づいて、トランザクションごとに独立したビューを構築できます。これらのビューは、同時トランザクションの場合には影響を受けません。例えば、ストレージエンジンは、トランザクションをソートし、単調かつグローバルに増加するシーケンス番号 (SN) をトランザクションに割り当て、各トランザクションのSNを記録する。このように、ストレージエンジンは、独立したトランザクション間の可視性を判定し、トランザクションを分離できる。

データがLSMストレージ構造に継続的に書き込まれ、他の操作が実行されない場合、LSMストレージ構造は最終的に次の図に示す構造になります。

この構造は、書き込み動作を容易にする。書き込み操作は、データが最新のメモリテーブルに追加された後に完了したと見なされます。クラッシュリカバリのために、データはredoログに記録されるだけでよい。新しいデータは古いデータを上書きしないため、追加されたレコードは自然なマルチSN構造を形成します。

ただし、より多くの永続性レベルのデータが蓄積および凍結されると、クエリのパフォーマンスが低下します。異なるトランザクションコミットに対して生成されるが、同じ主キーを有するマルチSNレコードは、異なるキーを有するレコードと同様に、異なるレベルにわたって分散される。この場合、読み出し動作は、すべてのレベルのデータを検索し、見つかったデータをマージして最終結果を取得する必要があります。

この問題を解決するために、圧縮がLSMに導入されます。 LSMの圧縮には2つの目的があります。

LSMの階層を制御する
ほとんどの場合、LSMレベルの低下に比例してデータ量が増加し、読み取りパフォーマンスが向上します。
ストレージシステム内のデータアクセスはローカライズされており、アクセストラフィックの大部分はデータの小さな部分に集中しています。これは、キャッシュシステムにおける効率的な運用の基本的な前提条件です。 LSMストレージ構造では、NVMやDRAMなどの高速ストレージデバイスにホットデータを高いLSMレベルで格納し、低コストで提供される低速ストレージデバイスにコールドデータを低いレベルで格納できます。これは、X-Engineのホットデータとコールドデータの分離の基礎です。
データのマージMerge data
コンパクションは、隣接するLSMレベルでデータを連続的にマージし、マージされたデータをより低いLSMレベルに書き込む。コンパクションプロセス中に、システムは2つ以上の隣接するレベルからマージするデータを読み取り、キーに基づいてデータをソートします。同じキーを有する複数のレコードが異なるSNを有する場合、システムは、最新のSNを有するレコードのみを保持し、以前のSNを有するレコードを破棄し、最新のSNを有するレコードを新しいレベルに書き込む。最新のSNは、実行されている現在のトランザクションの最も早いSNよりも大きい。このプロセスは、多数のリソースを消費する。
ホットデータとコールドデータの分離に加えて、データ更新頻度などの要因も圧縮中に考慮する必要があります。多数のマルチSNレコードのクエリは、より多くのI/OおよびCPUリソースを浪費します。したがって、同じキーを有するが異なるSNを有するレコードは、好ましくは、SNの数を減らすためにマージされなければならない。 Alibaba Cloudは、X-Engine向けの独自のコンパクションスケジューリングメカニズムを設計しています。

高度に最適化されたLSM

X-Engineでは、メモリテーブルでロックフリーのスキップリストを使用して、同時並行性の高い読み取りおよび書き込みクエリを高速化します。永続性レベルでのデータの効率的な編成を保証するために、各LSMレベルでデータ構造を計画する必要があります。

データ構造化
X-Engineでは、各レベルは固定サイズのエクステントに分割されます。エクステントは、レベルで連続したキー範囲を持つデータを格納します。各レベルのエクステントに対してメタデータインデックスのセットが作成されます。これらのインデックスのすべては、アクティブおよびインミュータブルメモリテーブルのすべてとともに、メタデータツリーを形成する。メタデータツリーは、Bツリーの構造と同様の構造を有し、メタデータツリーのルートノードは、メタデータスナップショットである。メタデータツリーは、エクステントをすばやく見つけるのに役立ちます。
データが書き込まれているアクティブなメモリテーブルを除いて、X-Engineのすべての構造は読み取り専用であり、変更することはできません。ログシーケンス番号 (LSN) が1000されている場合など、時点が指定されている場合、前の図のメタデータスナップショット1で参照されている構造体には、LSNが1000するまでログに記録されているすべてのデータが含まれます。これが、この構造がスナップショットと呼ばれる理由でもあります。
メタデータ構造自体は、生成された後も変化しません。すべての読み取り操作は、このスナップショット構造から開始します。これは、X-Engineがスナップショットレベルの分離を実装するための基礎です。コピーオンライト技術は、コンパクションやメモリテーブルのフリーズなどのすべての操作を実行するために使用されます。各修正の結果は新しいエクステントに書き込まれます。次に、新しいメタデータインデックス構造が生成される。最後に、新しいメタデータスナップショットが生成される。
たとえば、次の図に示すように、圧縮ごとに新しいメタデータスナップショットが生成されます。
この例では、メタデータスナップショット2は、メタデータスナップショット1とわずかに異なる。変更されたリーフノードとインデックスノードのみが変更されます。
説明このデータ構造化技術は、Bツリー、シャドウイング、およびクローンというタイトルの論文に提示されている技術に類似している。このプロセスをよりよく理解するために論文を読むことができます。
トランザクション処理
軽量の書き込み機構では、LSMは書き込み動作の処理において大きな利点を有する。ただし、トランザクション処理は、更新されたデータをシステムに書き込むほど単純ではなく、アトミック性、一貫性、分離、および耐久性 (ACID) を保証するために複雑な処理フェーズを必要とします。 X-Engineは、トランザクション処理プロセスを2つのフェーズに分けます。
1. 読み取りおよび書き込みフェーズ
  読み取りと書き込みのフェーズで、X-Engineは書き込みと書き込みの競合と読み取りと書き込みの競合をチェックし、トランザクションを実行、ロールバック、またはロックできるかどうかを判断します。競合が検出されない場合、すべての変更されたデータがトランザクションバッファに書き込まれます。
2. コミットフェーズ
  コミットフェーズには、データを先書き (WAL) ファイルに書き込み、データをメモリテーブルに書き込み、データをコミットし、結果をユーザーに返すプロセス全体が含まれます。このプロセスは、I/O動作およびCPU動作を含む。 I/O操作は、操作を記録し、結果を返すために実行される。 CPU動作は、ログをコピーし、メモリテーブルにデータを書き込むために実行される。
トランザクション処理中のスループットを高めるために、システムは多数のトランザクションを同時に処理する。単一のI/O動作は、高いコストを必要とする。したがって、ほとんどのストレージエンジンは、好ましくは、「グループコミット」と呼ばれる、一度にいくつかのトランザクションをコミットする。これにより、I/O操作を組み合わせることができます。しかし、一度にコミットされるべきトランザクションは、依然として長い期間待つ必要がある。たとえば、ログがディスクに書き込まれている場合、データがディスクにフラッシュされるのを待つ以外には何も行われません。
トランザクション処理中のスループットをさらに向上させるために、X-Engineは、コミットフェーズを4つの独立したよりきめ細かいステージに分割するパイプラインテクノロジーを採用しています。
1. ログバッファへのログのコピー
2. ログをディスクにフラッシュする
3. メモリテーブルへのデータの書き込み
4. データのコミットCommitting data
トランザクションコミットスレッドがコミットフェーズに入ると、データを処理するパイプラインの任意のステージを自由に選択できます。このようにして、スレッドは異なる段階でデータを同時に処理できます。各ステージのタスクがサイズに基づいて適切に分割されている場合、パイプラインのすべてのステージをほぼ完全にロードできます。さらに、バックグラウンドスレッドではなくトランザクション処理スレッドがコミットフェーズで使用されます。各フェーズは、ステージでタスクを実行するか、要求を処理します。このプロセスは、待機または切り替えを伴わず、したがって、各スレッドの能力が完全に利用される。
読み取り操作
LSMでは、同じキーを持つ複数のレコードが異なるSNを持つ場合、より遅いSNを持つレコードは、最も早いSNを持つレコードに追加されます。同じキーを有するが異なるSNを有するレコードは、異なるレベルに格納され得る。システムは、トランザクション分離レベルに基づいて定義された可視性ルールに従って、要求された各レコードの適切なSNを識別する必要があります。ほとんどの場合、システムは、最高レベルから最低レベルまでの最新のSNを有するレコードを検索する。
単一レコードクエリの場合、クエリプロセスは、単一レコードが見つかった後に終了します。レコードが高レベル、たとえばメモリテーブルにある場合、レコードはすぐに返されます。レコードが低レベル、例えばランダム読み取りに使用されるレベルに位置する場合、システムはレベルごとに下方にサーチしなければならない。この場合、ブルームフィルタを使用していくつかのレベルをスキップし、クエリを促進することができます。しかし、これはより多くのI/O動作を含む。 X-Engineでは、行キャッシュを使用して単一行クエリを処理します。行キャッシュは、すべての永続データレベルを超えるデータを格納します。単一行クエリがメモリテーブル内の要求されたデータをヒットしない場合、単一行クエリは、行キャッシュ内の要求されたデータをヒットすることができる。行キャッシュは、すべての永続性レベルで最新のSNを持つ各レコードを格納する必要があります。ただし、行キャッシュ内のレコードは変更される場合があります。たとえば、読み取り専用メモリテーブルが永続性レベルにフラッシュされた後、それに応じて行キャッシュ内のレコードを更新する必要があります。この操作は微妙で、慎重な設計が必要です。
レンジスキャンの場合、特定のキーレンジに関連付けられたデータが格納されるレベルを決定することはできません。この場合、最終結果は、すべてのレベルがデータについてスキャンされ、データがマージされた後にのみ返すことができます。 X-Engineは、この問題に対処するさまざまな方法を提供します。たとえば、2018 SIGMOD Conferenceのベストペーパーで提示されたSuRFは、スキャンするレベルの数を減らすためのレンジスキャンフィルタを提供します。この問題に対処するために、非同期I/Oおよびプリフェッチ機構も提供される。
圧縮
圧縮は重要です。システムは、重複したキー範囲に関連するデータを隣接するレベルから読み出し、データをマージし、マージされたデータを新しいレベルに書き込む必要がある。これは、単純な書き込み操作のコストです。 X-Engineのストレージアーキテクチャは、圧縮を最適化するように再設計されています。
前述のように、Xエンジンは、各レベルのデータを固定サイズのエクステントに分割します。エクステントは、小さいながらも完全なソート文字列テーブル (SSTable) と同等であり、レベルで連続したキー範囲を持つデータを格納します。キー範囲は、データブロックと呼ばれるより小さな連続セグメントにさらに分割される。データブロックは、データブロックが読み取り専用であり、その長さが固定されていないことを除いて、従来のデータベースのページと同等である。
メタデータスナップショット1とメタデータスナップショット2を比較すると、エクステント設計の意図を理解するのに役立ちます。各変更の間に変更される必要があるのは、オーバーラップされたデータのごく一部およびメタデータインデックスノードのみである。メタデータスナップショット1およびメタデータスナップショット2の構造は、多数のデータ構造を共有する。これはデータ再利用と呼ばれ、エクステントサイズはデータ再利用率を決定する重要な要素です。完全に再利用可能な物理構造として、重複データの量を減らすためにエクステントサイズが最小化される。ただし、範囲のサイズは適切でなければなりません。エクステントサイズが異常に小さい場合、多数のインデックスが必要になり、管理コストが増加します。
X-Engineでは、データの再利用率はコンパクションで高くなります。たとえば、レベル1とレベル2の重複したキー範囲を含むエクステントをマージします。この場合、マージアルゴリズムは、行ごとにデータをスキャンする。他のレベルのデータと重複しない、データブロックおよびエクステントを含むすべての物理構造を再利用することができる。エクステントの再使用とデータブロックの再使用との違いは、エクステントのメタデータインデックスを変更することができ、データブロックをコピーすることしかできないことである。データブロックは推奨されませんが、CPU使用率を大幅に削減できます。
次の図は、コンパクションでの一般的なデータ再利用プロセスを示しています。
行ごとの反復は、データ再利用プロセスを完了するために使用される。しかしながら、このきめ細かいデータ再利用は、データ断片化を引き起こす。
データの再利用は、コンパクション自体に利益をもたらし、コンパクション中のI/OおよびCPU消費を低減し、システムの全体的なパフォーマンスを改善する。例えば、コンパクション処理では、データを完全に書き換える必要がないため、書き込まれたデータが占有するストレージが大幅に削減されます。さらに、ほとんどのデータは変更されず、したがって、キャッシュされたデータは、データ更新後も有効なままである。これにより、コンパクション中にキャッシュされたデータが期限切れになることによって引き起こされる読み取りパフォーマンスのジッターが軽減されます。
実際、コンパクションへの最適化は、X-Engineが行うことの一部にすぎません。 X-Engineは、コンパクションスケジューリングポリシーを最適化し、エクステントのタイプを指定し、コンパクションの粒度と指定されたコンパクションの実行優先度を定義します。これらは全て、システムの性能に影響を及ぼす。完全なポリシーは存在しませんが、X-Engineは貴重な経験を蓄積し、適切なコンパクションスケジューリングポリシーを定義するためのいくつかのルールを定義しました。

シナリオ

詳細については、「X-Engineのベストプラクティス」をご参照ください。

X-Engineを使い始める

詳細については、「使用状況のメモ」をご参照ください。

フォローアップ开発

MySQLのストレージエンジンとして、X-engineはMySQLシステムとの互換性に関して継続的に改善する必要があります。最も緊急のニーズに基づいて、外部キーなどの一部の機能が徐々に強化され、より多くのデータ構造とインデックスタイプがサポートされます。

X-Engineの中核的価値は費用対効果にあります。低コストでのパフォーマンスの継続的な改善は、長期的な基本的な目標です。 Alibaba Cloudは、コンパクションスケジューリング、キャッシュ管理と最適化、データ圧縮、トランザクション処理など、X-Engineの運用効率を向上させる新しいアプローチを模索し続けています。