NewSQL + MySQL 分散データベースを構築するにはどうすればいいですか?

分散データベースに興味のある友人は、Google の F1 と Spanner が NewSQL テクノロジの開発を促進し、多くの企業が NewSQL の開発を開始したため、MySQL に基づく分散データベースは時代遅れであると多くの人が信じていることを知っています。

実際、MySQL は時代遅れではありません。この記事の主役である RadonDB は、NewSQL 分野でより普及している分散一貫性アルゴリズムを MySQL と組み合わせて、スケーラビリティ、高可用性、強力な一貫性、および容易な展開という特性も実現する新世代の分散データベース MyNewSQL を形成します。

では、NewSQL 分野のより一般的なテクノロジーを MySQL と組み合わせて、新しい分散データベースを作成するにはどうすればよいでしょうか。

1. RadonDB アーキテクチャ

まず、RadonDB のアーキテクチャを見てみましょう。上図に示すように、上部が分散 SQL 層、下部がストレージ層です。 F1 と Spanner を抽象化すると、これらもこの 2 つのレイヤーであることがわかります。

SQL レイヤーの主な役割は、ユーザー SQL を解析し、分散実行プランとエグゼキュータを生成し、これらのエグゼキュータを特定のストレージ ノードに送信して実行することです。

アーキテクチャは一貫しているように見えますが、RadonDB の特別な点は、下のストレージ層に複数のストレージ ノードがあることです。図中の各円はストレージ ノードです。各ストレージ ノードには 3 つのコピーがあります。 3 つのコピー間でデータを同期するために、Raft プロトコルが使用されます。各コピーは MySQL です。その他の NewSQL は KV またはその他のストレージです。

2. RadonDBアーキテクチャ層の分析

以下では、アーキテクチャにおけるさまざまな技術的なポイントについて詳しく説明します。

SQL ノード

まず、SQL ノードを見てみましょう。

ユーザー要求が SQL ノードに到達すると、データ分散ルールに基づいて分散実行プランが生成され、ユーザーの SQL をどのストレージ ノードに分散するかが指示されます。次に、分散実行プランに基づいて、どのストレージ ノードをリンクし、実行し、返すかを指定する分散エグゼキュータが生成されます。

実行後、SQL ノードは二次操作を実行します。なぜ二次手術と呼ばれるのでしょうか?基盤となるデータベースは MySQL であるため、SQL ノードは計算を MySQL にプッシュし、その後 SQL ノードは limit/groupby/aggregation/join などの二次操作を実行します。

したがって、SQL ノードは分散化され、ステートレスであり、強力なスケーラビリティを備えています。

3.ストレージ層

ストレージ層は複数のノードで構成され、各ノードは 1 つのマスターと 2 つのスレーブを持つ MySQL です。ただし、MySQL には高可用性ソリューションがないため、この MySQL は特別です。おそらく誰もが MHA を使用したり、運用と保守のためにマスター/スレーブ切り替えスクリプトを作成したりしているでしょう。

しかし、RadonDB は分散化された Raft プロトコルを導入しました。マスター データベースに障害が発生すると、Raft プロトコルを通じて新しいマスターが選択され、MySQL GTID メカニズムに基づいてデータが同期されます。

MySQL ベースであることの利点は、ストレージ容量だけでなくコンピューティング容量も備えていることです。レプリカが KV のみの場合、その計算能力は比較的制限されます。 SQL レイヤーはデータをストレージ レイヤーにプッシュし、その後、SQL ノードに戻ってさらに計算を行います。このようにして、ストレージ層と SQL 層の間の相互作用が増えます。

MySQL とデータは一緒に保存され、ネットワーク転送は行われず、データのフィルタリングには少数の I/O のみが必要なため、コンピューティング能力をストレージ層に押し下げ、MySQL にそれを完了させようとしています。

4. データ配信

先ほど、SQL レイヤーとストレージ レイヤーについて説明しました。それでは、データがどのように配布されるかを見てみましょう。

T1 テーブルを作成し、パーティション分割方法を HASH として指定します。 RadonDB では、テーブル全体のデフォルトのスロット数は 4096 で、各小さなテーブルのデフォルトのスロット数は 128 です。実際には、大きなテーブルは 32 個の小さなテーブルに分割されます。たとえば、ストレージ ノードが 2 つある場合、T1 テーブルの最初の 16 個の小さなテーブルは最初のストレージ ノードにあり、最後の 16 個の小さなテーブルは 2 番目のノードにあり、均等に分散されます。

MySQL ベースの容量拡張は問題があると考える人も多いかもしれませんが、前述のように、RadonDB はテーブル分割後、小さなテーブル単位でデータ移行を行うため、容量拡張は非常に便利です。新しいノードが追加されると、RadonDB はいくつかの動的な小さなテーブルを新しいノードに移行します。 MySQL をベースとしているため、最初にボリューム全体を実行し、次に場所を記録し、ボリューム全体が完了した後に増分を追跡します。この移行プロセスは基本的にビジネスに影響を与えません。

したがって、各小さなテーブルは複数のストレージ ノード上で動的にドリフトする可能性があります。これらの移行ルールはカスタマイズすることもできます。たとえば、大きなテーブルや人気の高いテーブルを最初に移行するなどして、全体的なリソース割り当てをできるだけ早く最適化することができます。

5.高可用性を確保するにはどうすればよいでしょうか?

1 つのストレージ ノードに 3 つのレプリカを作成して高可用性を確保するにはどうすればよいですか?分散コンセンサスアルゴリズム Raft と MySQL 独自の GTID を組み合わせます。

Raft は主に 2 つのことを行います。1 つはリーダー選出、もう 1 つはデータ同期です。 MySQL 5.7 GTID は、Raft のログ インデックスに似ています。データ同期は GTID を通じて行われ、マスターは Raft を通じて選出されます。 MySQL の状態をリアルタイムで監視するための Raft フレームワークを開発しました。マスターが異常な場合は、マスターの再選出を開始します。

選出後、新しいマスターのデータを他の 2 つのスレーブ ライブラリと同期するにはどうすればよいでしょうか。 2 つのスレーブは、独自の GTID に基づいてマスターからデータを取得し、データを同期します。 MySQL 5.7 は並列レプリケーションが可能で、プロセスが非常に高速です。マスターとスレーブの間には基本的に遅延はなく、高圧下でも遅延は非常に小さくなります。さらに、より強力な準同期により、トランザクションが失われないことが保証されます。

ストレージ ノード内の Raft と GTID は集中化されておらず、コンピューター ルーム全体に展開できるため、非常に柔軟です。

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

分散トランザクションを見てみましょう。分散データベースに分散トランザクションが必要なのはなぜですか?

データはストレージ ノードに分散して保存されるため、たとえば、テーブルはノード 1、2、3 に保存されます。次に、操作が実行され、ノード 1 では成功し、ノード 2 では失敗し、ノード 3 では成功します。この時点で分散トランザクションがない場合、テーブルは実際には不良です。

分散トランザクションの保証がなければ、データはいつでも利用できなくなり、重要でない業務を保存するためだけにしか使用できなくなります。

したがって、RadonDB は分散トランザクションを提供します。たとえば、前のケースでは、2 つのストレージ ノードに障害が発生すると、1 番目と 3 番目のストレージ ノードが自動的にロールバックされます。これは分散トランザクションの保証です。

RadonDB の分散トランザクションも MySQL に基づいて実装されており、MySQL では 2 フェーズでコミットされます。

まず、xa start を実行し、次に SQL を実行し、xa end を実行し、最後に xa prepare を実行します。これが最初の段階で、トランザクションがレプリカからコピーされます。 2 番目のステージは xa コミットです。

したがって、RadonDB は SQL レイヤーでトランザクション管理を実行し、MySQL の 5 つのステップを 3 つに抽象化します。1 つ目は Begin、2 つ目は Execute、3 つ目は Commit です。準備が失敗した場合は、ロールバックを実行できます。

分散トランザクションに関しては、「このトランザクションの分離レベルは何ですか?」と疑問に思うかもしれません。

RadonDB は、スナップショット分離レベルであるスナップショット分離を実装します。このコンセプトは何ですか?一部のパーティションがコミットされていない場合、そのトランザクションは他のトランザクションからは見えません。これを部分的なコミットの不可視性と呼びます。なお、提出しないと表示されません。つまり、準備はしても実行しなければ、それは目に見えません。

7. SI分離レベル

上の図の右側にある 2 つの SQL ステートメントを見てみましょう。 2 つのクライアントが接続されています。 1 つのクライアントがテーブルをスキャンし、2 番目の SQL ステートメントがテーブルを継続的に更新します。

SI 分離レベルには、XeLabs/go-jepsen、1 つの更新スレッド、16 のテーブル スキャン スレッドを使用し、100 億回を超える操作と監視を通じて問題は見つかりませんでした。また、ストレージ ノードのプライマリ コピーをランダムに KILL することもできます。これらすべては、MySQL XA がすでに非常に強力であることを証明しています。

RadonDB は HTAP ハイブリッド モードもサポートしています。従来のソリューションでは、通常、2 つのシステム、つまり 2 つのポートが存在します。トランザクションと分析が必要な場合は、それぞれ 2 つのポートで処理され、その間の ETL チャネルを介してデータ同期が行われます。

ただし、RadonDB にはポートが 1 つしかありません。 OLAP 操作の場合は、自動的にコンピューティング ノードにルーティングされます。さらに、OLTP と OLAP のコンピューティング リソースは分離されており、相互に影響を与えません。

8.パフォーマンス

***RadonDB のパフォーマンスをご覧ください。上の図は、単一マシンの MySQL と 4 つのストレージ ノードを持つ RadonDB の比較です。

16 個のテーブルと 512 個のスレッドを持つ sysbench を使用して、5,000 万個のデータをランダムに書き込みました。テスト結果によると、RadonDB は基本的に 26,589 TBS を達成でき、単一のマシンでは 9,346 TBS を達成できます。 TBS レベルでは、RadonDB のパフォーマンスは単一マシンのほぼ 3 倍ですが、レイテンシはその 3 分の 1 しかないことがわかります。

これが分散データベースの威力であり、ノードの追加に応じてパフォーマンスと容量が直線的に増加します。

著者について

[[231783]]

Zhang Yanfei は、QingCloud データベースの上級技術専門家です。 TokuDB カーネルの貢献者およびメンテナー、TokuDB エンタープライズ レベルのホット スタンバイ ツールの作者。