リレーショナルデータベースの束縛を打破する: クラウドネイティブデータベースミドルウェアのコア分析

データベース技術の開発と変革が本格化しています。 NewSQL の登場により、必要なさまざまなテクノロジーが単純に組み合わされるようになりました。これらの技術の組み合わせによって実現されるコア機能が、クラウドネイティブデータベースの開発を推進しています。前回の記事『リレーショナルデータベースはまだ生き残れるか？NoSQLとNewSQLのどちらが取って代わるのか？』では、クラウドネイティブデータベースの開発背景をすでに理解したので、この記事では、クラウドネイティブデータベースの関連コンテンツを具体的かつ詳細に解釈します。

3 種類の NewSQL のうち、新しいアーキテクチャとクラウドデータベースには、基盤となるデータベース関連の実装が多すぎます。この記事の範囲が広すぎないようにするために、透過的シャーディングデータベースミドルウェアのコア機能と実装原則に焦点を当てます。他の 2 種類の NewSQL はコア機能は似ていますが、実装の原則は異なります。

1. データシャーディング

単一のデータノードにデータを集中的に保存する従来のソリューションでは、パフォーマンスと可用性の面で、インターネットの膨大なデータシナリオのニーズを満たすことができませんでした。ほとんどのリレーショナルデータベースは B+ ツリーインデックスを使用するため、データ量がしきい値を超えると、インデックスの深さが増すとディスクアクセス IO の数も増加し、クエリパフォーマンスが大幅に低下します。同時に、同時アクセス要求が多いと、集中型データベースがシステムの最大のボトルネックになります。

従来のリレーショナルデータベースではインターネットシナリオのニーズを満たすことができないため、分散コンピューティングをネイティブにサポートする NoSQL にデータを保存しようとする試みが増えています。しかし、NoSQL は SQL と互換性がなく、エコシステムも不完全であるため、リレーショナルデータベースとの競争で致命的な打撃を与えることができず、リレーショナルデータベースの地位は揺るぎないままです。

データシャーディングとは、パフォーマンスのボトルネックと可用性を向上させるために、特定のディメンションに従って単一のデータベースに保存されているデータを複数のデータベースまたはテーブルに分散することを指します。データシャーディングの効果的な手段は、リレーショナルデータベースをサブライブラリまたはサブテーブルに分割することです。データベースとテーブルの両方のシャーディングにより、許容しきい値を超えるデータ量によって発生するクエリのボトルネックを効果的に回避できます。

さらに、データベースシャーディングを使用すると、単一のデータベースポイントへのアクセスを効果的に分散できます。テーブルシャーディングにより、分散トランザクションを可能な限りローカルトランザクションに変換する可能性が提供されます。マルチマスターおよびマルチスレーブのシャーディング方式を使用すると、データの単一ポイントを効果的に回避できるため、データアーキテクチャの可用性が向上します。

1. 垂直シャーディング

垂直シャーディングは垂直分割とも呼ばれます。その中心となる概念は、専用のデータベースを専用の目的に使用することです。分割前、データベースは複数のデータテーブルで構成され、各データテーブルは異なるビジネスに対応します。分割後、テーブルは業務ごとに分類され、異なるデータベースに分散されるため、図に示すように、異なるデータベース間で負荷が分散されます。

2. 水平シャーディング

水平シャーディングは水平分割とも呼ばれます。垂直シャーディングと比較すると、水平シャーディングでは、ビジネスロジックに従ってデータを分類するのではなく、特定のフィールドの特定のルールに従ってデータを複数のライブラリまたはテーブルに分散し、各シャードにはデータの一部のみが含まれます。

例えば、ID の最後の桁のモジュロ 10 に基づいて、最後の桁が 0 の数字はライブラリ (テーブル) 0 に配置され、最後の桁が 1 の数字はライブラリ (テーブル) 1 に配置されます。図に示すように、

リレーショナルデータベースが大量のデータに直面したときに、過剰なデータ量によって引き起こされるパフォーマンスの問題を解決するには、データをシャーディングすることが効果的なソリューションです。

単一のノードに集中しているデータを分割し、複数のデータベースまたはテーブルに保存することをシャーディングと呼びます。データベースシャーディングは、高い同時実行性によって生じるデータベースアクセスの負荷を効果的に分散できます。シャーディングではデータベースの負荷を軽減することはできませんが、シャード間の更新操作ではデータベースのネイティブ ACID トランザクションを引き続き使用できます。ただし、データベース間の更新操作が関係すると、分散トランザクションの問題は非常に複雑になります。

データベースとテーブルをシャーディングしてデータを分割すると、各テーブルのデータ量がしきい値以下に抑えられます。垂直シャーディングでは、アーキテクチャと設計の調整が必要になることが多く、これは通常、インターネットの急速に変化するビジネスニーズに対応するには遅すぎ、単一ポイントのボトルネックを真に解決することはできません。水平シャーディングは、理論的には単一マシンのデータ処理のボトルネックを打破し、比較的自由に拡張できます。これは、データベースとテーブルをシャーディングするための標準ソリューションです。

トラフィックを迂回させるためのデータベースシャーディングと読み取り/書き込み分離は、高トラフィックに対処するための一般的な方法です。シャーディングは大量のデータによって生じるパフォーマンスの問題を解決できますが、同じデータベースにアクセスするリクエストが多すぎるために生じる応答が遅くなるという問題は解決できません。したがって、水平シャーディングは通常、データベースシャーディングの形をとり、膨大なデータ量とアクセス量の問題を同時に解決します。読み取りと書き込みの分離はトラフィックを迂回させるもう 1 つの方法ですが、データの読み取りと書き込みの間の遅延は、アーキテクチャ設計時に考慮する必要がある問題です。

データベースシャーディングは上記の問題を解決できますが、分散アーキテクチャは利点を得る一方で新たな問題ももたらします。このように別々のライブラリやテーブルにデータが散在している場合、重要な課題の 1 つは、アプリケーション開発者や運用保守担当者にとってデータベース操作が非常に困難になることです。どの特定のデータベーステーブルからどのようなデータを取得する必要があるかを知る必要があります。

NewSQL の新しいアーキテクチャとデータシャーディングミドルウェアは、この機能を異なる方法で処理します。

NewSQL の新しいアーキテクチャでは、データベースストレージエンジンが再設計され、分散ファイルシステム内の同じテーブルにデータが保存されるようになります。
データシャーディングミドルウェアは、データベースとテーブルのシャーディングの影響を可能な限り透過的にし、ユーザーが水平にシャーディングされたデータベースを単一のデータベースのように使用できるようにします。

データベース間のトランザクションは、分散データベースが対処しなければならない難しい問題です。シャーディングを合理的に使用すると、単一テーブル内のデータ量を削減し、ローカルトランザクションを最大限に活用できます。同じデータベース内の異なるテーブルをうまく使用することで、分散トランザクションによって発生する問題を効果的に回避できます。データベース間のトランザクションを回避できないシナリオでも、一部のビジネスではトランザクションの一貫性を維持する必要があります。しかし、XA ベースの分散トランザクションはパフォーマンスが低いため、インターネット企業では採用できません。それらのほとんどは、分散トランザクションの代わりに、最終的に一貫性のある柔軟なトランザクションを使用します。

3. 読み取りと書き込みの分離

システムアクセスの増加に伴い、データベースのスループットが大きなボトルネックになっています。同時読み取り操作が多数あり、同時に書き込み操作が少ないアプリケーションシステムの場合、単一のデータベースをマスターデータベースとスレーブデータベースに分割し、マスターデータベースでトランザクションの追加、削除、変更操作を処理し、スレーブデータベースでクエリ操作を処理すると、データ更新によって発生する行ロックを効果的に回避でき、システム全体のクエリパフォーマンスが大幅に向上します。

1 つのマスターと複数のスレーブの構成により、クエリ要求を複数のデータコピーに均等に分散できるため、システムの処理能力がさらに向上します。

マルチマスターおよびマルチスレーブのアプローチを使用すると、システムのスループットが向上するだけでなく、システムの可用性も向上するため、データベースがクラッシュしたり、ディスクが物理的に損傷したりしても、システムの正常な動作に影響はありません。

読み取りと書き込みの分離は、本質的にはデータシャーディングの一種です。シャードキーに基づいて各データノードにデータを分散する水平シャーディングとは異なり、読み取り/書き込み分離では、SQL セマンティクスの分析に基づいて、読み取り要求と書き込み要求がそれぞれマスターデータベースとスレーブデータベースにルーティングされます。読み取り/書き込み分離されたデータノード内のデータは一貫していますが、水平シャーディング内の各データノードのデータの内容は異なります。水平シャーディングと読み取り/書き込み分離を組み合わせると、システムパフォーマンスをより効果的に向上できますが、システムのメンテナンスも複雑になります。

読み取りと書き込みの分離によりシステムのスループットと可用性が向上しますが、複数のマスターデータベース間のデータ一貫性や、マスターデータベースとスレーブデータベース間のデータ一貫性など、データの不整合の問題も発生します。さらに、読み取りと書き込みの分離によってもデータシャーディングと同じ問題が発生し、アプリケーション開発者や運用保守担当者にとってデータベースの運用と保守がより複雑になります。

読み取り/書き込み分離の主な機能は、読み取り/書き込み分離の影響を透明化し、ユーザーがマスター/スレーブデータベースを 1 つのデータベースであるかのように使用できるようにすることです。

4. コアプロセス

データシャーディングの中核は、SQL 解析、SQL ルーティング、SQL 書き換え、SQL 実行、結果のマージのプロセスで構成されます。元のアプリケーションプログラムを低いアクセスコストで維持するためには、データベースへのアクセスとの互換性を保つ必要があるため、データベースプロトコルを適応させる必要があります。

プロトコル適応

NewSQL は従来のリレーショナルデータベースと互換性があります。 SQL に加えて、互換性のあるデータベースプロトコルにより、ユーザーのアクセスコストを削減できます。オープンソースのリレーショナルデータベースは、プロトコル標準を実装することで、製品をネイティブのリレーショナルデータベースとして偽装できます。

MySQL と PostgreSQL の人気が高いため、多くの NewSQL 製品でそれらの転送プロトコルが実装されており、MySQL と PostgreSQL のユーザーはビジネスコードを変更することなく NewSQL 製品に自動的にアクセスできます。

MySQL プロトコル

MySQL は現在最も人気のあるオープンソースデータベースです。プロトコルを理解するには、MySQL の基本的なデータ型、プロトコルパケット構造、接続フェーズ、コマンドフェーズから始めることができます。

基本的なデータ型

MySQL プロトコルパッケージ内のすべてのコンテンツは、MySQL によって定義された基本データ型で構成されています。具体的なデータ型については、次の表を参照してください。

MySQL 基本データ型

バイナリデータを MySQL が理解できるデータに変換する必要がある場合、MySQL プロトコルパケットは、データ型によって事前に定義されたビット数に従って読み取られ、対応する数値または文字列に変換されます。逆に、MySQL は仕様で指定された長さに従って各フィールドをプロトコルパケットに書き込みます。

プロトコルパケット構造

MySQL プロトコルは、1 つ以上の MySQL プロトコルパケットで構成されます。タイプに関係なく、ペイロード長、シーケンス ID、ペイロードの 3 つの部分で構成されます。

メッセージの長さは int<3> 型です。後続のメッセージ本文が占めるバイトの合計数を示します。メッセージの長さには、シーケンスの主キーのプレースホルダーは含まれないことに注意してください。
シーケンスの主キーは int<1> 型です。これは、リクエスト後に返される複数の MySQL プロトコルパケット内の各プロトコルパケットのシーケンス番号を示します。 1 バイトのシーケンスキーの最大値は 0xff で、10 進数では 255 になります。ただし、これは各リクエストに最大 255 個の MySQL プロトコルパケットを含めることができるという意味ではありません。 255 を超えるシーケンスキーは、再び 0 からカウントを開始します。たとえば、クエリによって数十万件のレコードが返される場合があります。この場合、MySQL プロトコルパッケージでは、シーケンスの主キーが連続していることを確認し、255 より大きいシーケンスの主キーを 0 にリセットして、カウントを再開するだけで済みます。
メッセージ本文の長さは、メッセージ長で宣言されたバイト数です。これは、MySQL プロトコルパッケージ内の実際のビジネスデータです。メッセージ本文の内容は、プロトコルパッケージの種類によって異なります。

接続フェーズ

接続フェーズは、MySQL クライアントとサーバー間の通信チャネルを作成するために使用されます。このフェーズでは、主に、MySQL クライアントとサーバーのバージョン機能記述の交換と照合 (Capability Negotiation)、SSL 通信チャネルの作成、および認証の検証という 3 つのタスクが実行されます。次の図は、MySQL サーバーの観点から見た接続作成のフローチャートを示しています。

MySQL 接続フェーズのフローチャート

この図には、MySQL サーバーとクライアント間のやり取りは含まれていません。実際、MySQL 接続の作成はクライアントによって開始されます。

MySQL サーバーは、クライアントからの接続要求を受信すると、まずサーバーとクライアントのバージョン間で機能情報を交換して一致させ (Capability Negotiation)、次に両端のネゴシエーション結果に基づいて異なる形式の初期化ハンドシェイクプロトコルパケットを生成し、変更されたプロトコルパケットをクライアントに書き込みます。プロトコルパッケージには、MySQL サーバーによって割り当てられた接続主キー、サーバーの現在のバージョンの機能、および認証と承認用に生成された暗号テキストが含まれます。

サーバーから送信されたハンドシェイクプロトコルパケットを受信した後、MySQL クライアントはハンドシェイクプロトコル応答パケットを送信します。このプロトコルパッケージに含まれる主な情報は、データベースアクセスに使用されるユーザー名と暗号化されたパスワードの暗号テキストです。

ハンドシェイクプロトコル応答パケットを受信すると、MySQL サーバーは認証チェックを実行し、チェック結果をクライアントに返します。

コマンドフェーズ

接続フェーズが成功すると、コマンド実行の対話型フェーズが始まります。 MySQL には合計 32 個のコマンドプロトコルパケットがあります。具体的なタイプについては、下の図を参照してください。

MySQL コマンドパッケージ

MySQL のコマンドプロトコルパッケージは、テキストプロトコル、バイナリプロトコル、ストアドプロシージャ、データレプリケーションプロトコルの 4 つのカテゴリに分かれています。

プロトコルパケットメッセージ本体の最初のビットは、コマンドタイプを識別するために使用されます。プロトコルパッケージの名前はわかりやすいので、具体的な用途を 1 つずつ説明する必要はありません。以下では、いくつかの主要な MySQL コマンドプロトコルパッケージを分析します。

COM_クエリ

COM_QUERY は、プレーンテキスト形式でクエリを実行するために MySQL が使用する重要なコマンドです。 JDBC の java.sql.Statement に相当します。 COM_QUERY コマンド自体は比較的単純で、識別子と SQL で構成されています。

1 [03] COM_クエリ

文字列[EOF] サーバーが実行するクエリ

COM_QUERY の応答プロトコルパケットは、次の図に示すように、より複雑です。

MySQL クエリコマンドフローチャート

COM_QUERY は、シナリオに応じて、クエリ結果、更新結果、ファイル実行結果、エラー結果の 4 種類の結果を返す場合があります。

実行中にネットワーク切断や不正な SQL 構文などのエラーが発生した場合、MySQL プロトコルでは、プロトコルパケットの最初のビットを 0xff に設定し、エラー情報を ErrPacket プロトコルパケットにカプセル化して返す必要があります。

ファイル経由で COM_QUERY を実行することは一般的ではないため、ここでは詳細に説明しません。

更新要求の場合、MySQL プロトコルでは、プロトコルパケットの最初のビットを 0x00 に設定し、OkPacket プロトコルパケットを返す必要があります。 OkPacket プロトコルパッケージには、この更新操作によって影響を受ける行レコードの数と、最後に挿入された主キー値の情報が含まれている必要があります。

クエリ要求は最も複雑です。結果セットフィールドの数を取得するには、int<lenenc> を読み取り、返す独立した FIELD_COUNT プロトコルパケットを作成する必要があります。次に、返されたフィールド詳細の各列が順番に独立した COLUMN_DEFINITION プロトコルパケットに変換され、クエリフィールドのメタデータ情報は EofPacket で終了します。その後、データプロトコルパケットの Text Protocol Resultset Row を行ごとに生成できます。データの特定のタイプには注意を払わず、string<lenenc> 形式に変換します。データプロトコルパケットは依然として EofPacket で終わります。

JDBC の java.sql.PreparedStatement に対応する操作は、MySQL プロトコルパッケージ内のバイナリプロトコルで構成されており、COM_STMT_PREPARE、COM_STMT_EXECUTE、COM_STMT_CLOSE、COM_STMT_RESET、および COM_STMT_SEND_LONG_DATA の 5 つのプロトコルパッケージで構成されています。最も重要なのは COM_STMT_PREPARE と COM_STMT_EXECUTE で、それぞれ JDBC の connection.prepareStatement メソッドと connection.execute&connection.executeQuery&connection.executeUpdate メソッドに対応します。

COM_STMT_PREPARE

COM_STMT_PREPARE プロトコルパケットは COM_QUERY プロトコルパケットに似ており、コマンド識別子と SQL で構成されます。

1 [16] COM_STMT_PREPARE

string[EOF] 準備するクエリ

COM_STMT_PREPARE プロトコルパケットの戻り値はクエリ結果ではなく、statement_id、列数、パラメータ数などの情報で構成される応答プロトコルパケットです。 statement_id は、MySQL によってプリコンパイルされた SQL に割り当てられる一意の識別子です。対応する SQL は、statement_id を通じて MySQL から取得できます。

COM_STMT_PREPARE コマンドによって登録された SQL の場合、SQL 自体を再度渡すことなく、COM_STMT_EXECUTE コマンドに statement_id を渡すだけで済むため、不要なネットワーク帯域幅の消費を節約できます。

さらに、MySQL は COM_STMT_PREPARE によって渡された SQL を抽象構文ツリーに事前コンパイルして再利用できるため、SQL の実行効率が向上します。 COM_QUERY を使用して SQL を実行する場合は、各 SQL を再コンパイルする必要があります。これが、 PreparedStatement が Statement よりも効率的である理由です。

COM_STMT_EXECUTE

COM_STMT_EXECUTE プロトコルパケットは、主に SQL とペアになったステートメント ID とパラメーターで構成されます。パラメータ内の空の値を識別するために、-bitmap と呼ばれるデータ構造を使用します。

COM_STMT_EXECUTE コマンドの応答プロトコルパケットは、COM_QUERY コマンドの応答プロトコルパケットに似ています。どちらもフィールドメタデータとクエリ結果セットの形式で返され、途中で EofPacket 間隔が引き続き使用されます。

違いは、COM_STMT_EXECUTE コマンドの応答プロトコルパケットが、テキストプロトコル結果セット行ではなくバイナリプロトコル結果セット行を使用することです。データ型に関係なく、データを文字列に変換しません。代わりに、返されたデータのタイプに応じて対応する MySQL 基本データ型を書き込み、ネットワーク伝送帯域幅をさらに節約します。

その他のプロトコル

MySQL プロトコルに加えて、PostgreSQL プロトコルと SQL Server プロトコルも完全にオープンソースであり、同じ方法で実装できます。よく使用される別のデータベース Oracle プロトコルはオープンソースではないため、この方法で実装することはできません。

SQL 解析

他のプログラミング言語と比較すると、SQL は比較的シンプルです。ただし、SQL は完全なプログラミング言語であるため、SQL 構文の解析と他のプログラミング言語 (Java、C、Go など) の解析の間に本質的な違いはありません。

解析プロセスは、語彙解析と文法解析に分けられます。まず、語彙解析によって SQL を分割できない単語に分割します。次に、構文パーサーを使用して SQL を抽象構文ツリーに変換します。最後に、抽象構文木にアクセスして、解析コンテキストを抽出します。

解析コンテキストには、テーブル、選択項目、並べ替え項目、グループ化項目、集計関数、ページング情報、クエリ条件が含まれます。シャーディングミドルウェアタイプが NewSQL の場合は、変更される可能性のあるプレースホルダータグも記録する必要があります。

SQL「select username, ismale from userinfo where age > 20 and level > 5 and 1 = 1」を抽象構文ツリーに解析します。

抽象構文木

抽象構文木を生成するためのサードパーティ製ツールは多数ありますが、ANTLR は良い選択肢です。開発者が定義したルールに従って抽象構文木の Java コードを生成し、ビジターインターフェイスを提供できます。コード生成と比較すると、手書きの抽象構文木は実行効率が高くなりますが、作業負荷も大きくなります。パフォーマンス要件が高いシナリオでは、抽象構文ツリーのカスタマイズを検討できます。

リクエストルーティング

解析コンテキストに応じてデータシャーディング戦略を一致させ、ルーティングパスを生成します。シャーディングキーを伝送する SQL ルートの場合、シャーディングキーの違いに応じて、単一シャードルート (シャーディング演算子は等号)、マルチシャードルート (シャーディング演算子は IN)、範囲ルート (シャーディング演算子は BETWEEN) に分類できます。シャーディングキーを持たない SQL ステートメントはブロードキャストルーティングを使用します。

シャーディング戦略は通常、データベースに組み込まれているか、ユーザーが構成できます。データベースの組み込みソリューションは比較的シンプルです。組み込みのシャーディング戦略は、大まかにモジュール、ハッシュ、範囲、ラベル、時間などに分類できます。ユーザーが構成するシャーディング戦略はより柔軟になり、ユーザーのニーズに応じて複合シャーディング戦略をカスタマイズできます。

SQL 書き換え

新しいアーキテクチャの NewSQL では、SQL の書き換えは必要ありません。この部分は主にシャーディングミドルウェアタイプの NewSQL 用です。これは、SQL を実際のデータベースで正しく実行できるステートメントに書き換えるために使用されます。これには、論理テーブル名を実際のテーブル名に置き換え、ページング情報の開始値と終了値を書き換え、並べ替え、グループ化、自動増分主キー用の補助列を追加し、AVG を SUM/COUNT に書き換えることが含まれます。

結果をマージする

複数の実行結果セットをマージし、統一された方法でアプリケーション側に出力します。結果のマージには、ストリーミングマージとメモリマージが含まれます。

ストリーミングマージは、単純なクエリ、並べ替えクエリ、グループ化クエリ、並べ替え項目とグループ化項目がまったく同じである並べ替えとグループ化のシナリオに使用されます。ストリーミングマージ結果セットは、追加のメモリを占有することなく、毎回 next メソッドを呼び出すことによって走査されます。
メモリ内マージでは、処理のために結果セット内のすべてのデータをメモリに読み込む必要があります。結果セットにデータが多すぎると、大量のメモリが占有されます。

2. 分散トランザクション

前述したように、データベーストランザクションは次の 4 つの特性を満たす必要があります: ACID (原子性、一貫性、独立性、永続性)。

アトミック性とは、トランザクションが全体として実行されるか、すべて実行されるか、まったく実行されないかのいずれかを意味します。
一貫性とは、トランザクションによって、データが 1 つの一貫した状態から別の一貫した状態に変換されることを保証することを意味します。
分離とは、複数のトランザクションが同時に実行される場合、1 つのトランザクションの実行が他のトランザクションの実行に影響を与えないことを意味します。
永続性とは、コミットされたトランザクションによって変更されたデータが永続化されることを意味します。

単一のデータノードでは、トランザクションは単一のデータベースリソースのアクセス制御に制限され、ローカルトランザクションと呼ばれます。しかし、SOA に基づく分散アプリケーション環境では、複数のデータベースリソースや複数のサービスへのアクセスを同じトランザクションに含める必要があるアプリケーションが増え、分散トランザクションが生まれます。

リレーショナルデータベースは、ローカルトランザクションに対して完全な ACID ネイティブサポートを提供します。しかし、分散シナリオでは、システムパフォーマンスの足かせになります。分散シナリオでデータベースを ACID 特性に適合させる方法、または対応する代替手段を見つける方法は、分散トランザクションの重要なタスクです。

1. XAプロトコル

最も初期の分散トランザクションモデルは、X/Open International Alliance によって提案された X/Open 分散トランザクション処理 (DTP) モデルであり、XA プロトコルと呼ばれています。

DTP モデルでは、グローバルトランザクションマネージャーが複数のリソースマネージャーと対話します。グローバルトランザクションマネージャーは、グローバルトランザクションの状態とトランザクションに関係するリソースを管理する役割を担い、リソースマネージャーは特定のリソース操作を担当します。 DTP モデルとアプリケーションの関係を次の図に示します。

DTPモデル

XA プロトコルは、分散トランザクションの原子性を保証するために 2 フェーズコミットを使用します。提出プロセスは準備フェーズと提出フェーズに分かれています。

準備フェーズでは、グローバルトランザクションマネージャーは各リソースマネージャーに準備メッセージを送信し、ローカルトランザクション操作の成功を確認します。
コミットフェーズ中に、グローバルトランザクションマネージャーがすべてのリソースマネージャーから成功メッセージを受信すると、各リソースマネージャーにコミットメッセージを送信し、それ以外の場合はロールバックメッセージを送信します。リソースマネージャーは、受信したメッセージに基づいてローカルトランザクションをコミットまたはロールバックします。

次の図は、XA プロトコルのトランザクションフローを示しています。

XAトランザクションプロセス

2 フェーズコミットは、XA プロトコルの標準実装です。分散トランザクションの送信を準備とコミット/ロールバックの 2 つの段階に分割します。

XA グローバルトランザクションが有効になると、すべてのサブトランザクションはローカルのデフォルトの分離レベルに従ってリソースをロックし、UNDO ログと REDO ログを記録します。次に、TM は準備投票を開始し、すべてのサブトランザクションがコミット可能かどうかを尋ねます。すべてのサブトランザクションのフィードバック結果が「はい」の場合、TM はコミットを開始します。いずれかのサブトランザクションのフィードバック結果が「いいえ」の場合、TM はロールバックを開始します。準備フェーズでのフィードバック結果が「はい」で、コミット処理中にクラッシュなどの例外が発生した場合、ノードサービスの再起動後、XA リカバリに従ってコミット補正を再度実行し、データの一貫性を確保できます。

XA プロトコルに基づいて実装された分散トランザクションは、ビジネスにほとんど影響を与えません。その最大の利点は、ユーザーにとって透明性があることです。ユーザーは、ローカルトランザクションを使用する場合と同じように、XA プロトコルに基づく分散トランザクションを使用できます。 XA プロトコルは、トランザクションの ACID 特性を厳密に保証できます。

しかし、トランザクションの ACID プロパティを厳密に保証することは、諸刃の剣です。

トランザクション実行プロセス中は、必要なすべてのリソースをロックする必要があります。一定の実行時間を持つ短いトランザクションに適しています。長いトランザクションの場合、トランザクション全体にわたってデータを排他的に使用すると、ホットデータに依存するビジネスシステムの同時パフォーマンスが大幅に低下します。したがって、同時実行性が高く、パフォーマンスを優先するシナリオでは、XA プロトコルに基づく分散トランザクションは最適な選択ではありません。

2. 柔軟な取引

ACID トランザクション要素を実装するトランザクションを固定トランザクションと呼ぶのに対し、BASE トランザクション要素に基づくトランザクションは柔軟なトランザクションと呼びます。 BASE は、Basically Available、Soft State、Eventually Consistent の 3 つの要素の略語です。

基本的な可用性は、分散トランザクションの参加者が必ずしも同時にオンラインになるわけではないことを保証します。
柔軟な状態では、システム状態の更新に一定の遅延が発生しますが、顧客にはそれが気付かれない可能性があります。
最終的な一貫性は通常、メッセージが到達可能であることを保証することによって実現されます。

ACID トランザクションでは分離要件が非常に高く、トランザクション実行中はすべてのリソースをロックする必要があります。柔軟なトランザクションの考え方は、ビジネスロジックを通じて、ミューテックス操作をリソースレベルからビジネスレベルに移動するということです。強力な一貫性の要件を緩和することで、システムのスループットを向上させることができます。

分散システムではタイムアウトの再試行が発生する可能性があるため、柔軟なトランザクションでの操作はべき等性を持つ必要があり、複数のリクエストによって発生する問題を回避するためにべき等性が必要です。柔軟なトランザクションを実装するための主なソリューションは、ベストエフォート配信、Saga、TCC です。

ベストエフォート配信

これは最も単純なタイプの柔軟なトランザクションであり、データベース操作が最終的に成功するシナリオに適しています。 NewSQL は実行に失敗した SQL ステートメントを自動的に記録し、成功するまで何度も試行します。ベストエフォート配信を使用する柔軟なトランザクションにはロールバック機能はありません。

このタイプの柔軟なトランザクションは実装が最も簡単ですが、シナリオに対して非常に厳しい要件があります。この戦略の利点は、リソースのロック時間がなく、パフォーマンスの低下がほとんどないことです。欠点は、コミットの試行が複数回失敗すると、トランザクションをロールバックできないことです。これは、トランザクションが最終的に成功する必要があるビジネスシナリオにのみ適しています。したがって、パフォーマンスの向上と引き換えに、トランザクションロールバック機能が損なわれます。

佐賀

Saga は、1987 年に Hector Garcaa-Molrna と Kenneth Salem が発表した論文から生まれました。

参照リンク: www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

Saga トランザクションは、長いトランザクションが使用されるシナリオに適しています。これは複数のローカルトランザクションで構成され、各トランザクションには対応する実行モジュールと補正モジュールがあります。ローカルトランザクションが失敗した場合、関連する補足メソッドを呼び出すことによって、トランザクションの最終的な一貫性を実現できます。

Saga モデルは、分散トランザクションを複数のローカルトランザクションに分割します。各トランザクションには、対応する実行モジュール (トランザクション) と補正モジュール (補正) があります。 Saga トランザクション内のいずれかのローカルトランザクションが失敗した場合、関連する補正メソッドを呼び出して前のトランザクションを復元し、トランザクションの最終的な一貫性を実現できます。

各 Saga サブトランザクション T1、T2、...、Tn に対応する補償定義 C1、C2、...、Cn-1 がある場合、Saga システムは次のことを保証できます。

サブトランザクションシーケンス T1、T2、…、Tn が完了します。これは、ロールバックが不要なトランザクションの最良のシナリオです。
または、シーケンス T1、T2、…、Tx、Cx、…、C2、C1、（x は n 未満）が完了します。これにより、ロールバックが発生したときに、補正操作がフォワード操作の逆の順序で実行されることが保証されます。

Saga モデルは、順方向回復と逆方向回復の両方をサポートします。フォワードリカバリとは、現在失敗しているトランザクションを再試行することを指し、その実装の前提は、各サブトランザクションが最終的に正常に実行されることです。後方回復については上で説明しましたが、いずれかのサブトランザクションが失敗した場合、完了したすべてのトランザクションが補償されます。

明らかに、フォワードリカバリのための補償トランザクションを提供する必要はありません。事業のサブトランスショナルが常に最終的に成功する場合、フォワードリカバリーはSAGAモデルの使用の複雑さを減らすことができます。さらに、取引を補償するのが難しい場合、前進回復も良い選択肢です。

理論的には、取引を補償することは決して失敗しません。ただし、分散型の世界では、サーバーがダウンし、ネットワークが失敗する可能性があり、データセンターでさえ停電を経験する可能性があります。したがって、手動介入などの障害回復後のロールバックのメカニズムを提供する必要があります。

SAGAモデルにはXAプロトコルの準備フェーズがないため、トランザクションは分離を達成しません。 2つのSAGAトランザクションが同じリソースで同時に動作する場合、更新損失やダーティデータの読み取りなどの問題が発生します。これには、SAGAトランザクションを使用するアプリケーションがアプリケーションレベルにリソースロックロジックを追加する必要がある必要があります。

TCC

TCC（try-confirm-cancel）分散トランザクションモデルは、ビジネスロジックを分解することにより分散トランザクションを実装します。名前が示すように、TCCトランザクションモデルでは、ビジネスシステムが次の3つのビジネスロジックを提供する必要があります。

試す。事業に必要な完全なビジネス検査と予約リソース。 TRY操作はTCC全体の本質であり、ビジネスリソースロックの粒度を柔軟に選択できるようになります。
確認する。ビジネスロジックを実行し、ビジネスチェックを再度実行することなく、トライフェーズで予約されたビジネスリソースを直接使用します。
キャンセル。 TRYフェーズで予約されたビジネスリソースをリリースします。

TCCモデルは、分散トランザクションの原子性を確保するための2相アトミックコミットプロトコルのみを提供します。トランザクション分離は、ビジネスロジックによって実装されます。 TCCモデルの分離概念は、ビジネス変革を通じてロックをデータベースリソースレベルからビジネスレベルに移動させ、それにより基礎となるデータベースロックリソースをリリースし、分散トランザクションロックプロトコルを緩和し、システムの同時性を改善することです。

TCCトランザクションモデルは柔軟なトランザクションで最も強力な機能を備えていますが、アプリケーションは、トランザクションマネージャーが呼び出すために操作を試し、確認し、キャンセルする3つのインターフェイスを提供する責任があります。したがって、ビジネス側の変革のコストは比較的高いです。

例として、RMB 100を説明することを考慮してBを説明します。次の図は、TCCがビジネスをどのように変換するかを示しています。

送金サービスとコレクションサービスは、それぞれTry-Confirm-Cancelインターフェイスを実装し、ビジネス初期化フェーズ中にTCCトランザクションマネージャーに注入する必要があります。

送金サービス

試す

アカウントAの有効性を確認します。つまり、アカウントAのステータスが「転送」または「フローズン」であるかどうかを確認します。
アカウントAのバランスが十分かどうかを確認してください。
アカウントAから100元を差し引き、ステータスを「転送」に設定します。
控除のためのリソースを予約し、メッセージまたはログでアカウントAからアカウントBに100元を転送するイベントを保存します。

確認する

何もしないでください。

キャンセル

アカウントAは100元増加します。
ログまたはメッセージから控除リソースをリリースします。

回収サービス

試す

アカウントBが有効かどうかを確認してください。

確認する

ログまたはメッセージを読んだ後、アカウントBのバランスは100元増加します。
ログまたはメッセージから控除リソースをリリースします。

これから、TCCモデルがビジネスに強い侵入をしており、変革が困難であることがわかります。

メッセージ駆動型

メッセージ一貫性ソリューションは、メッセージミドルウェアを通じて上流および下流のアプリケーションデータ操作の一貫性を保証します。基本的なアイデアは、ローカル操作とメッセージをローカルトランザクションに送信することです。ダウンストリームアプリケーションはメッセージシステムを購読し、メッセージを受信した後に対応する操作を実行します。基本的に、最終的な一貫性を実現するために、メッセージ再試行メカニズムに依存しています。次の図は、メッセージ駆動型トランザクションモデルです。

メッセージ駆動型の欠点は次のとおりです。高いカップリング、メッセージミドルウェアをビジネスシステムに導入する必要性があり、システムの複雑さが向上します。

一般に、酸ベースの強力な一貫性トランザクションと基本ベースの最終的な一貫性トランザクションは銀の弾丸ではなく、その最大の強みは、最も適切なシナリオでのみ機能します。開発者がテクノロジーの選択をするのを助けるために、それらの違いを詳細に比較しましょう。メッセージ駆動型システムはビジネスシステムと高度に結合されているため、比較表には含まれていません。

盲目的に強い一貫性を追求することは、最も合理的な解決策ではないかもしれません。分散システムの場合、「柔らかい外側と強い内部」デザインアプローチを使用することをお勧めします。外部の柔軟性とは、最適なパフォーマンスと引き換えに最終的なデータの一貫性を確保するために、データシャード間の柔軟なトランザクションの使用を指します。内部剛性とは、同じデータシャード内のローカルトランザクションの使用を指し、酸性効果を達成します。

3.データベースガバナンス

1。基本ガバナンス

前の記事で説明されているサービスガバナンスは、データベースの基本管理でほとんど一般的です。主に、構成センター、登録センター、現在の制限、回路の破壊、フェールオーバー、コールリンク追跡などが含まれます。

構成センターは、構成集中化、動的構成の更新、通知分布に使用されます。
登録センターは、サービスの発見に使用されます。ここでのサービスとは、データベースの中間層インスタンス自体を指し、ステータスの監視と自動通知を達成できるため、データベースのミドルウェアが非常に利用可能で自己治癒します。
現在の制限は、トラフィックの過負荷保護に使用されます。これは、データベースミドルウェア自体のトラフィックオーバーロード保護とデータベースのトラフィックオーバーロード保護に分割されます。
回路ブレーカーは、トラフィックの過負荷の保護尺度でもあります。その違いは、データベース全体のデータベースへのアクセス全体が、データベースが通常のトラフィックを持つ他のシステムにサービスを提供し続けるのを防ぐために、データベースへのアクセスを破ることです。自動回路ブレーカーメカニズムは、上記の回路ブレーカーモードを介して実装できます。
フェールオーバーは、複数のデータコピーの場合に使用されます。完全に一貫したデータを持つ複数のデータノードの中で、1つのノードが利用できない場合、フェールオーバーメカニズムを使用して、データベースミドルウェアが別の有効なデータノードにアクセスしてデータを操作できるようにします。
コールリンクトレースコールリンク、パフォーマンス、トポロジ関係、およびデータベースアクセスのその他の指標が視覚的に表示されます。

2。弾性スケーリング

データベースガバナンスとサービスガバナンスの重要な違いは、データベースがステートフルであり、各データノードに独自の永続的なデータがあるため、サービス指向のような弾性スケーリングを実現することは困難です。

システムアクセスボリュームとデータボリュームが以前の評価の期待を超えると、多くの場合、データベースの再シェードが含まれます。デートシャーディングなどの戦略を使用すると、レガシーデータを移行せずに容量を直接拡張することができますが、ほとんどのシナリオでは、データベースのレガシーデータを新しいシャード戦略に直接マッピングすることはできません。シャード戦略の変更には、データ移行が必要です。

従来のシステムでは、データを移行するためのサービスを停止し、移行後にサービスを再起動することが効果的なソリューションです。ただし、このソリューションにより、ビジネス側のデータ移行コストが非常に高くなり、ビジネスエンジニアがデータボリュームを正確に評価する必要があります。

インターネットシナリオでは、システムの可用性要件は非常に高く、爆発的なビジネスの成長の可能性は、従来の業界よりも一般的です。クラウドネイティブサービスアーキテクチャモデルでは、弾性スケーリングは一般的な要件であり、比較的簡単に実装できます。したがって、サービスに相当するデータ弾性スケーリングは、クラウドネイティブデータベースの重要な機能です。

システムのプレシェードに加えて、弾性スケーリングのもう1つのソリューションは、オンラインデータ移行です。オンラインデータの移行は、多くの場合、「飛行中に飛行機のエンジンを変更する」ことに例えられています。最大の課題は、移行プロセスがサービスに影響を与えないようにする方法です。オンラインデータ移行は、データベースシェルディング戦略を変更した後に実行できます（たとえば、プライマリキー％16に基づいてプライマリキー％4〜16データベースに基づいて4つのデータベースからシャード法を変更します）。一連の体系的な操作を通じて、データベースに依存するサービスを完全に認識しないようにしながら、データが新しいデータノードに正しく移行されるようにすることができます。次の4つのステップに分けることができます。

同期オンラインダブルライティング。つまり、データは、シャーディング戦略が変更される前に元のデータノードに書き込まれ、シャード戦略が同時に変更された後に新しいデータノードが変更されます。ダブルライティングの一貫性は、上記で紹介したPaxosやRaftアルゴリズムなどの一貫性アルゴリズムによって確保できます。
履歴データの移行。オフラインでは、新しいデータノードに移行する必要がある履歴ストックデータは、元のデータノードから移行されます。 SQLまたはBinlogなどのバイナリメソッドを介して処理できます。
データソースの切り替え。新しいデータソースに読み取りと書き込み要求を切り替えて、元のデータノードに二重書き込みを停止します。
冗長データをクリーンアップします。古いデータノードでは、新しいデータノードに移行された関連データをクリーンアップします。

オンラインデータ移行は、データ拡張を実行するだけでなく、同じ方法でオンラインでDDL操作を実行することもできます。データベースのネイティブDDL操作はトランザクションをサポートしておらず、DDLが多数のデータテーブルに使用されるとテーブルの長期ロックを引き起こすため、オンラインDDL操作はオンラインデータ移行を通じてサポートできます。オンラインDDL操作は、データ移行の手順と一致しています。移行前にDDLによって変更された新しい空のテーブルを作成し、上記の4つのステップに従う必要があります。

著者について

Zhang Liang、 JD Digital Technologyのデータ研究開発責任者。オープンソースが大好きで、現在、2つのオープンソースプロジェクトElastic-JobとSharding-Sphere（Sharding-JDBC）をリードしています。彼は、KubernetesとMesosに基づいたJavaおよびCloudプラットフォームに基づいた分散アーキテクチャが得意であり、エレガントなコードを提唱しており、表現型コードの作成方法について多くの研究を行っています。彼は2018年初頭にJD Digitalに入社し、現在データ研究開発の責任者です。現在、それは主に、シャーディング球を業界クラスの金融グレードデータソリューションに構築することに専念しています。

<<: LVSが提供する3つのIP負荷分散技術

>>: 仮想化テクノロジーをいくつご存知ですか?