3つの主要なクラウドネイティブデータベース: Aurora、PolarDB、Socrates

1. 「クラウドネイティブデータベース」とは何ですか?

クラウドコンピューティングの出現により、企業の情報技術の発展が加速しました。クラウドコンピューティングプロバイダーは、膨大な量のコンピューティング、ストレージ、および通信リソースを「プール」にまとめ、企業または個々のユーザーは、オンデマンドでコンピューティングリソースを購入して、情報システムを迅速かつ低コストで構築します。システムのワークロードが変化すると、必要に応じてコンピュータリソースを拡張または縮小できます。コンピューティングプロバイダーにとっては、すべてのユーザーが使用する膨大なリソースが統一された方法で管理されるため、大幅な規模の経済と低い限界費用が実現します。クラウドコンピューティングのユーザーにとっては、リソースを迅速かつ便利に取得でき、オンデマンド使用は、独自のコンピュータルームを構築し、基本的な設備を構築して運用するよりもコストがかかりません。社会全体の視点から見ると、全体的な資源利用率が高くなり、環境に優しくなります。

データベースは最も一般的に使用される基本ソフトウェアの1つであり、通常は計算するそしてストレージ能力。ストレージは、もちろんデータの基本的な機能です。計算能力は、データベースがユーザーによって発行された複雑な分析や計算要求を完了できること（強力な計算ロジックを SQL を使用して記述できる）という外部的な面と、クエリの最適化、トランザクション処理、インデックスのメンテナンスなどの内部計算という内部的な面の両方に反映されます。

スタンドアロンデータベースは通常のホスト上に展開され、そのストレージとコンピューティング機能はホストのハードウェアによって制限されるため、拡張が困難です。分散データベースでは、マシンを適切に追加することでデータベース容量と計算能力を拡張できますが、クラスターノードの機能は依然としてマシンリソースによって制限されます。何も変更せずに単にクラウドに移行すると、通常のホストがクラウドホストに置き換えられます。

まず、データベースをクラウド上に直接展開すると、ネットワークのボトルネックや深刻な書き込み増幅の問題など、多数の新たな問題が発生する可能性があります。たとえば、単一マシンのデータベースに無限のストレージを接続したとしても、データ量が非常に大きい場合はパフォーマンスが非常に低下します。第二に、クラウドコンピューティングの最大の利点である「柔軟なリソース管理とオンデマンド利用」を十分に活用できず、また、幅広いクラウドストレージ製品を柔軟に利用することもできません。第三に、情報化とデジタル化の急速な発展により、データベースに対する要求がさらに高まりました。より高いパフォーマンス、より低いコスト、より優れた柔軟性などです。これは、スタンドアロンのデータベースをクラウドに移行するだけでは解決できません。

分散データベースも優れたスケーラビリティを備えていますが、「クラウドネイティブ」とは言えません。まず、概念的には、弾力的な拡張の単位は、より細かい「コンピューティングおよびストレージリソース」ではなく、「マシン」です。第二に、設計時にクラウドプラットフォームの特性が考慮されておらず、最適なパフォーマンスとコストを実現するための適切な最適化が行われていませんでした。 3 番目に、分散トランザクションや分散クラスタ管理などのモジュールの導入によっても、システムはより複雑になります。 (ここで批判するつもりはありません。分散データベースには、膨大なデータ、スケーラビリティの必要性、グローバル展開の必要性など、大きな利点もあります。)

「クラウドネイティブデータベース」の核心は、「弾力的なリソース管理」の概念にさらに沿ったデータベースアーキテクチャを設計し、クラウドプラットフォームのプールされたリソースを最大限に活用し、クラウドプラットフォームの既存のインフラストラクチャに適応することです。

クラウドコンピューティングプラットフォームのストレージとコンピューティングリソースは個別に拡張できるため、クラウドネイティブデータベースにはストレージとコンピューティングを分離したアーキテクチャが必要です。

2. オーロラ

2.1 主な問題点

Aurora は AWS が立ち上げた OLTP クラウドデータベースの先駆者であり、MySQL コードに基づいてストレージとコンピューティングの分離アーキテクチャを変革しました。 AWS は、クラウド上にデータベースを構築するとストレージリソースの拡張が容易になると考えていますが、データベースインスタンスとすべてのストレージノード間のやり取りはネットワークを経由する必要があるため、システムのボトルネックはネットワークにあります。したがって、Aurora の中心的なコンセプトは、ネットワーク経由で送信されるデータの量を削減することです。

Aurora の論文では、MySQL をクラウドに直接移行する例が示されています。

単一マシンの MySQL トランザクションをコミットするには、ログをディスクに書き込む必要があります。同時に、バックグラウンドスレッドはダーティページを非同期的にフラッシュします。ページ区切りを回避するには、ダーティページをフラッシュするときに、データページを二重書き込み領域に書き込む必要があります。下の図に示すように、本番環境でのマスタースレーブレプリケーションの必要性を考慮すると、AZ1 と AZ2 はそれぞれ同期ミラーレプリケーション用の MySQL インスタンスを展開し (これは DRBD ソリューションであるべきでしょうか?)、基盤となるストレージは Elastic Block Store (EBS) を使用し、各 EBS には独自のミラーがあり、ポイントインタイムリカバリをサポートするために、REDO ログと binlog ログをアーカイブするために Simple Storage Service (S3) が展開されます。

上記の書き込み同期では、各ステップで、REDO ログ、バイナリログ、データページ、ダブル書き込み、および frm メタデータの 5 種類のデータを渡す必要があります。ミラーリングに基づく同期レプリケーションであるため、図の手順 1、3、5 は連続しています。このモデルの応答時間は非常に悪いです。必要なネットワーク IO は 4 つあり、そのうち 3 つは同期およびシリアルです。ストレージの観点から見ると、データは EBS 上の 4 つのコピーに保存され、返される前に 4 つのコピーすべてが正常に書き込まれる必要があります。したがって、このアーキテクチャでは、IO ボリュームとシリアル化モデルの両方でパフォーマンスが非常に低下します。

IO 数を削減するために、Aurora はすべてのノード間のデータ転送に redo のみを使用します。これを実現するには、一部のデータベース機能をストレージノードにプッシュダウンする必要があります。もちろん、IO の削減に加えて、Aurora の設計には他にも多くの利点があります。

2.2 コアテクノロジー

2.2.1 ストレージとコンピューティングの分離アーキテクチャ

Aurora によってストレージにプッシュダウンされる主な機能は、主に、ログの再生、障害回復、バックアップと復元など、REDO に関連するものです。テクニカルレイヤーには、クエリ処理、トランザクション処理、キャッシュ管理、ロック管理、アクセス制御などのほとんどの機能が保持されます。

Aurora は、AZ 全体のプライマリインスタンス、複数のレプリカ (最大 15 個)、および複数のストレージノードで構成されます。マスターインスタンスと読み取り専用インスタンス/ストレージノード間では、REDO ログとメタ情報のみが転送されます。マスターインスタンスとレプリカインスタンスは分散ストレージのセットを共有するため、レプリカインスタンスを追加してもストレージコストはゼロになり、Aurora の読み取りスケーラビリティが大幅に向上します。

マスターインスタンスは、REDO ログをレプリカインスタンスに非同期的に送信し、レプリカインスタンスはそれを受信した後、REDO ログの再生を開始します。ログに対応するページがローカルページキャッシュにない場合は、ストレージノードにすべてのページと REDO ログがあり、必要に応じてストレージノードから直接要求できるため、REDO ログを直接破棄できます。

ストレージノードは、REDO ログを受信するとそれを永続化し、ログを再生してデータページの古いバージョンを再利用する作業をバックグラウンドで非同期的に実行できます。ストレージノードは、フォアグラウンド/バックグラウンド作業を実行するためにリソースを柔軟に割り当てることができます。同時に、従来のデータベースと比較して、Aurora はバックグラウンドでチェックポイントを進める必要がありません (このアクションは多くの場合、フォアグラウンドリクエストに影響します)。独立したストレージ層は、データベースインスタンスにまったく影響を与えることなく、チェックポイントを継続的に進めます。さらに、進歩が速いほど、読み取り要求にとって有利になります。

ストレージ層でチェックポイントを継続的に進めることで、障害回復を高速化することもできます。通常、10w TPS の圧力下では、Aurora は 10 秒以内に回復を完了できます。障害回復プロセス中、

詳細には、Aurora の書き込みプロセスは次のようになります。

（1）ストレージノードはプライマリインスタンスからログを受信し、それをメモリキューに追加します。

（２）ストレージノードはログを保存し、マスターインスタンスに応答します。

（３）ログをシャードごとに分類し、欠落しているログがないか確認する。

（4）他のストレージノードと対話して、不足しているログを埋めます。

（５）ログを再生し、データページを生成します。

（6）データとログを定期的にS3にバックアップします。

（７）期限切れのデータページのバージョンを定期的にリサイクルする。

（８）データページを定期的にCRCチェックする。

上記のすべての操作のうち、（1）と（3）のみがシリアル同期であり、要求応答時間に直接影響します。その他は非同期操作です。

可用性を確保するために、Aurora 永続性では Quorum プロトコルが使用されます。レプリケーションセットに V ノードが含まれており、読み取り要求には Vr ノードが応答する必要があり、書き込み要求には Vw ノードが応答する必要があると仮定します。読み書きの一貫性を確保するために、クォーラムプロトコルには2つの主な条件があります: (1) Vr + Vw > V; （２）Vw＞V/2。

マスターインスタンスからの各書き込みは、3 つの AZ にある 6 つのストレージノードに送信され、永続化が成功したことを示す 4 つの応答が受信されると、書き込みは成功したと見なされます。したがって、Aurora の Quorum プロトコルでは、V = 6、Vw = 4、Vr = 3 になります。もちろん、実際の読み取り要求では、3 つのストレージノードを実際にクエリする必要はありません。最新のデータを持つストレージノードに対してクエリを実行するだけで済みます。

クォーラムプロトコルにより、AZ レベルの障害とノード障害が同時に発生しない限り、データベースの可用性が保証されます。同時に、Aurora はシャード管理戦略を採用しています。各シャードは 10G で、6 つの 10G コピーが保護グループを形成します。各シャードは障害回復ユニットです。 10G/s ネットワークでは、シャードは 10 秒以内に復元できます。したがって、可用性が影響を受けるのは、10 秒以内に 2 つ以上のシャードが同時に失敗した場合のみであり、これはほぼ不可能です。

sysbench 書き込み専用テストでは、Aurora のスループットはミラーリングされた MySQL の 35 倍であり、各トランザクションのログボリュームはミラーリングされた MySQL の 7.7 分の 1 です。

一般的に、Aurora のストレージとコンピューティングの分離アーキテクチャには、次のような利点があります。(1) クラウドに展開すると、すべてのノード間で REDO データのみが送信されるため、ネットワークの負荷が軽減されます。（２）フロントスレッドとバックスレッドが互いに干渉せず、バックグラウンドタスクを停止することなく非同期に実行できる。（３）ストレージノードはAZ間で高可用性を実現します。（４）リードレプリカとストレージノードは線形に拡張可能（上限あり）（５）障害回復時間が速い。

2.2.2 一貫性の保証

MySQL から Aurora まで、スタンドアロンシステムは分散システムへと進化しており、ストレージノードとデータベースインスタンス間でデータの一貫性を確保する必要があります。 Aurora は、分散一貫性を保証する従来の方法である 2PC プロトコルは複雑であり、耐障害性が非常に低いことを強調しています。 Aurora は、一貫性を確保するために、Quorum + Gossip プロトコルと LSN ベースのアルゴリズムに依存しています。

実のところ、Aurora が論文で 2PC について言及した理由がよくわかりません。 2PC は一貫性の問題を解決できますが、ほとんどの人はこのシナリオでは 2PC を使用しません。まず、データベースの状態を変更する操作であるトランザクションのコミット管理はマスターインスタンスによって制御され、システム全体の一貫性はマスターインスタンスのみによって完全に決定されます。ストレージノードは、マスターインスタンスに永続化の結果を通知するだけで済みます。これはスタンドアロンデータベースと何ら変わりはなく、分散 2 フェーズコミットプロトコルが必要な理由が明確ではありません。第二に、分散トランザクション送信と比較して、Aurora ストレージノードには、REDO 永続性に対する要件が単純です。その他のリソース要件 (ロック、トランザクションコンテキストの作成など) はなく、送信後にリソースを解放する必要もありません。 2PCを使用する必要は全くありません。

率直に言えば、2PC を使用するかどうかは、データベースの状態変更を誰が制御するかによって決まります。ストレージノードは永続的ですが、データベースの状態の変更はトランザクションマネージャーによって完全に制御されます。トランザクションプロセッサが異なるノードに分散されている場合 (これにより書き込みのスケーラビリティが大幅に向上します)、2 フェーズコミットが必要であり、トランザクションをコミットするかロールバックするかを全員がネゴシエートします。

さらに興味深い比較は、ほとんどのシステムが Paxos/Raft などのコンセンサスアルゴリズムを使用し、高可用性を確保するために最下層に強力な一貫性のあるストレージシステムを実装する傾向があるのに対し (PolarDB、Spanner、OB など)、Aurora は単純な Quorum のみを使用し、コンピューティング層とストレージ層を組み合わせて高可用性と強力な一貫性を実現している点です。

上記は私の個人的な考えです。実際、トランザクションロジックがスタンドアロンデータベースとほぼ同じである Aurora のようなデータベースでは、通常の状況では一貫性の保証に違いはありません。主な違いは、データベースインスタンスがクラッシュして再起動すると、どのデータページの未完了トランザクションをコミットまたはロールバックするかを決定するために、クラッシュ前の未完了トランザクションが必要になることです。スタンドアロンデータベースのリカバリは単一のログに基づいており、Aurora は複数のストレージノードから複数のログを取得する必要があるため、Aurora はどのログを再生し、どのログを切り捨てる必要があるかを決定する必要があります。

Aurora トランザクションはすべてマスターインスタンスによって開始されるため、マスターインスタンスは各 REDO ログにログシーケンス番号 (LSN) を時系列順に割り当てることができます。一貫性を確保するために、Aurora は次の主要なログポイントを定義します。

ボリューム完了 LSN (VCL) は、ストレージ層に VCL より前のすべての完全なログがあることを意味します。障害回復中は、VCL より大きい LSN を持つすべてのログを破棄する必要があります。

一貫性ポイント LSN (CPL)、MySQL (InnoDB) トランザクションは複数の内部ミニトランザクションで構成され、各ミニトランザクションはアトミック操作の最小単位です。たとえば、B+ ツリーの分割では複数のページを変更する必要があり、これはアトミックである必要があり、アトミック REDO ログのセットによって表される必要があります。 CPL は、ミニトランザクションの最後のログの LSN です。ログを再生する場合、単位として CPL が必要です。トランザクションは通常、複数の CPL で構成されます。

ボリューム永続 LSN (VDL) は、すべての CPL 間で永続化された最大 LSN であり、データベースが一貫した状態にある最新の場所を表します。 VDL は VCL 以下である必要があります。ミニトランザクションのアトミック性を保証するために、VDL より大きいログもすべて破棄する必要があります。障害回復フェーズでは、データベースインスタンスはクォーラム読み取りを通じて最新の VDL を計算できます。

たとえば、VCL=1007 かつ CPLs={900, 1000, 1100} の場合、1000 以降のすべてのログは切り捨てられます。

3. ポラDB

PolarDB は、Alibaba Cloud が立ち上げたクラウドネイティブデータベースです。どちらもコンピューティングとストレージが分離されたアーキテクチャを備えていますが、設計コンセプトは Aurora とは大きく異なります。

3.1 主な問題点

PolarDB は、クラウドに移行する際には従来のデータベースアーキテクチャに多くの問題があることを、多くの公開共有や記事で強調してきました。以下に典型的なものをいくつか示します。

スケーラビリティ関連:

物理マシンのディスク制限とバックアップ戦略により、データベースのデータサイズは大きくなりすぎることはできません。インスタンスが大きすぎると、運用と保守に支障をきたします。
アクティビティがオンラインになると、突然圧力が増加しましたが、データベースにはアップグレードする時間がありませんでした。
ビジネスは急速に発展しており、データベースを分割したり、データベースとテーブルを分割したりする時間がありません。

パフォーマンス関連:

従来のバックアップ技術では、データをコピーして安価なストレージにアップロードするため、その速度はネットワークの影響も受けます。完全なデータバックアップには時間がかかり、テーブルのロックなどが必要になります。
読み取り/書き込みインスタンスと読み取り専用インスタンスには、それぞれデータの独立したコピーがあります。新しい読み取り専用インスタンスを作成するには、データを再コピーする必要がありますが、現在のネットワークの制限を考慮すると、それほど高速ではありません。
MySQL データベースの初期バージョンでは、初期のシステム/ハードウェア向けに多くの最適化が行われていましたが、現代の主流のシステム/ハードウェアの優れた機能は考慮されていませんでした。同時実行性の高い環境では、パフォーマンスを向上させる余地がまだたくさんあります。
互換性のために、MySQL は 2 つのログ (トランザクションログとレプリケーションログ) を書き込む必要があり、他の商用データベースと比較するとパフォーマンスが比較的劣ります。
読み取り/書き込みインスタンスと読み取り専用インスタンスは、増分論理データを通じて同期されます。読み取り/書き込みインスタンス上のすべての SQL ステートメントは、読み取り専用インスタンスで再実行する必要があります (SQL 解析や SQL 最適化などの無効な手順を含む)。同時に、レプリケーションの最高の同時読み取りはテーブルディメンションに基づいているため、マスターとスレーブ間の遅延が非常に一般的になり、さまざまな切り替えタスクに影響を及ぼします。
アプリケーションが拡張された後、数百の ECS が 1 つのデータベースに接続されたため、同時実行性が高い場合のパフォーマンスが非常に低下しました。

コスト関連:

読み取り/書き込みインスタンスと読み取り専用インスタンスには、それぞれデータの独立したコピーがあります。ユーザーが読み取り専用インスタンスを購入する場合、コンピューティングコストだけでなく、ストレージリソースコストも支払う必要があります。

....

これらの問題は、本質的にはスタンドアロンデータベースが直面する問題です。もちろん、データベースをクラウドに移行することは、これらの問題を解決する方法の 1 つです。ただし、スタンドアロンデータベースをクラウド上に単純に展開する場合には、これらの問題は依然として存在します。 PolarDB は、この一連の問題を解決するために開発されました。

もちろん、Aurora でも上記の問題のほとんどを解決できると思いますが、PolarDB が選択した技術的なルートは Aurora とはまったく異なります。

3.2 コアテクノロジー

3.2.1 ストレージとコンピューティングの分離アーキテクチャ

PolarDB はストレージとコンピューティングを分離するアーキテクチャも使用します。コンピューティングノードは、SQL 解析、トランザクション処理などの保存を担当する MySQL インスタンスです。ストレージノードは、信頼性の高いデータストレージを担当する PolarDB のコアコンポーネントである PolarStore です。同じクラスター内の複数のコンピューティングノード (1 つの読み取り/書き込みインスタンスと複数の読み取り専用インスタンス) がデータのコピーを共有します。このため、読み取り専用インスタンスの拡張速度とコストは非常に低くなります。フェイルオーバーが発生した場合に、読み取り専用インスタンスを読み取り/書き込みインスタンスに迅速に変換することで、データベースインスタンスの高可用性が確保されます。データの高可用性と一貫性は、PolarStore 内に実装された Parallel-Raft (アウトオブオーダーコミットをサポートし、raft よりも優れたパフォーマンスを発揮) によって保証されます。

コンピューティングノードとストレージノードは高速ネットワークを使用して相互接続され、データは RDMA プロトコルを介して送信されるため、ネットワークがボトルネックになることはなくなります。

PolarDB の設計の焦点は、複数のデータベースインスタンス (同時マウントをサポート) に高性能で信頼性の高いデータアクセスサービスを提供できる高性能分散ファイルシステム PolarFS です。

3.2.2 ポラFS

PolarFS は、多数の新しいハードウェアを活用した、極めて低いレイテンシと高い信頼性を備えた分散ファイルシステムです。外部インターフェースは libpfs であり、データベースはこのレイヤーを通じて PolarFS と対話します。

PolarFS ストレージは、ボリューム、チャンク、ブロックの 3 つのレベルに分けられます。ユーザーが PolarDB データベースインスタンスを作成すると、システムはそのインスタンスのボリュームを作成します。ボリュームのサイズは 10G から 100T の範囲になります。各ボリュームは複数のチャンクで構成されます。チャンクは、データの移動/高可用性/分散の最小単位であり、SSD ディスクに保存する必要があります。各チャンクのサイズは 10 GB で、他の分散ファイルシステム (GFS は 64 MB) よりもはるかに大きくなります。これにより、ボリュームからチャンクへのマッピングのメタデータのサイズが削減され、管理とキャッシュが容易になります。欠点は、ホットスポットが分散しにくいことです。各チャンクには 3 つのコピーがあり、ParallelRaft プロトコルによって高可用性が保証されます。チャンクはさらに 163,840 個のブロックに分割され、各ブロックのサイズは 64 KB です。事前に割り当てられたスペースの最小単位です。

PolarFS の主なコンポーネントは次のとおりです。

libpfs: ユーザースペースファイルシステムライブラリは、コンピューティングノードが基盤となるストレージにアクセスするための API インターフェイスです。

ポラスイッチ : コンピューティングノードにデプロイされたデーモン。IO 要求を特定の ChunkServer リーダーへのアクセスに変換する役割を担います。

チャンクサーバー : チャンクを管理し、ブロック IO 要求を処理するために使用されます。ストレージノードは複数の ChunkServer を展開できます。各 ChunkServer は CPU コアにバインドされ、独立した NVMe SSD ディスクを管理します。 ChunkServer 間でリソースの競合は発生しません。アトミック性と耐久性を確保するために、チャンクの変更は最初に WAL に書き込まれます。 ChunkServer は、3D XPoint SSD と通常の NVMe SSD のハイブリッド WAL バッファを使用します。ログは、より高速な 3D XPoint SSD に優先的に保存されます。

極性Ctrl ：システムのコントロールプレーンは、PolarFS クラスターの制御コアであり、ChunkServer の監視とバランス調整、さまざまなメタデータの維持、PolarSwitch メタデータキャッシュの更新などを担当します。

PolarFS の書き込み操作プロセスは次のとおりです。

POLARDB は、リングバッファーを介して libpfs を通じて書き込み要求を PolarSwitch に送信します。
PolarSwitch は、ローカルキャッシュメタデータに基づいて、対応するチャンクのチャンクサーバーリーダーノードに書き込み要求を送信します。
リクエストが ChunkServer に到着すると、ノードの RDMA NIC はリクエストをリクエストキューに追加します。 IO ポーリングスレッドは、要求キューを継続的にポーリングし、新しい要求が見つかると処理を開始します。
IO 処理スレッドは、チャンクに対応する WAL ブロックにリクエストを非同期的に書き込み (SPDK 経由)、フォロワーノードにリクエストを非同期的に送信します。
書き込み要求がフォロワーに到達すると、RDMA NIC を介して要求キューにも配置されます。
フォロワーノード上の IO ポーリングスレッドも非同期的にトリガーされ、書き込まれます。
フォロワーノードの書き込み要求が成功し、RDMA 経由でリーダーに応答を送信します。
リーダーノードがいずれかのフォロワーノードから正常な応答を受信すると、多数決が形成され、書き込み要求が SPDK を介して対応するデータブロックに書き込まれます。
リーダーは、RDMA NIC を介して要求処理結果を PolarSwitch に返します。
PolarSwitch は要求を成功としてマークし、POLARDB データベースインスタンスに通知します。

PolarFS は、ポーリングを通じてハードウェアデバイスの IO 完了イベントを監視する OS カーネル IO プロトコルスタックではなく、SPDK を使用して読み取りと書き込みを行い、DMA を介して SSD を直接操作します。 IO スレッドは CPU コアにバインドされており、データ構造を共有しないため、スレッド間で競合は発生しません。 OS IO プロトコルスタックをバイパスするこの方法により、高速デバイスの IO 処理パフォーマンスが大幅に向上します。同時に、RDMA ネットワークを通じてネットワーク IO パフォーマンスが大幅に向上します。これは基本的に、HDFS や Ceph などの分散ファイルシステムにおけるパフォーマンスの低下とレイテンシの増加の問題を解決します。

3.2.3 物理的な複製

PolarDB の読み取り/書き込みインスタンスと読み取り専用インスタンスはデータのコピーを共有するため、一貫性を確保する必要があります。たとえば、読み取り/書き込みインスタンスに新しく書き込まれたページは、ダーティでなくても読み取り専用インスタンスに表示される必要があります。したがって、インスタンス間には特定の同期メカニズムが必要です (プライマリとバックアップ間の一貫性を確保するため)。

MySQL には、Binlog と InnoDB の Redo ログという 2 つの主要なログがあります。 Binlog はタプルレベルのデータ変更ログであり、MySQL の使いやすいストレージエンジンとダウンストリームの消費間のデータ同期を容易にします。 REDO ログはファイルの物理ページの変更を記録し、トランザクションの ACID 特性をサポートするために InnoDB によって使用されます。

Binlog はタプルレベルであり、読み取り専用インスタンスの再生効率が低すぎます。再生プロセス中に、読み取り専用インスタンスはまったく必要のないページを要求しなければならない場合があります。プライマリサーバーとバックアップサーバー間のデータ同期には、明らかに Redo ログの方が適しています。さらに、Binlog レプリケーションは現在、テーブルレベルでの並列レプリケーションしか実行できませんが、物理レプリケーションはデータページレベルでの同時レプリケーションを実行でき、より細かい粒度と高い並列効率を実現し、プライマリサーバーとスタンバイサーバー間の遅延をミリ秒レベルで維持できます。同時に、Binlog が不要な場合は、Binlog をオフにすることでもパフォーマンスが向上します。

すべてのノードは完全なデータと Redo ログのコピーを共有します。読み取り専用ノードを追加するのは非常に簡単で、プライマリノードとスタンバイノード間の同期にはメタデータのみが必要です。これにより、プライマリノードに障害が発生してフェイルオーバーしたときに、読み取り専用ノードに切り替える際の障害回復時間を 30 秒未満に短縮できます。

物理レプリケーションは、プライマリノードとスタンバイノード間の一貫性を確保するために使用されます。実際、矛盾が発生する可能性のあるさまざまなケースを解決するための非常に複雑なアルゴリズムと戦略が存在します。ここでは詳細には触れません。この記事を読む http:// mysql.taobao.org/monthl 2017/09/01/ より

4. ソクラテス

4.1 主な問題点

Socrates は、SQL Server をベースに Azure によって開発されたクラウドネイティブデータベースです。コンピューティングとストレージを分離したアーキテクチャが依然として使用されています。 Aurora と比較すると、分離がより徹底されています。永続性と高可用性を分離するために、ページとログのストレージはストレージ層で分離されています。

Azure では、クラウド上のログマスタースレーブ同期に基づく SQL DB (RDS) には、次のような大きな問題があると考えています。

データ容量は、単一のマシンのストレージ容量によって制限されます。
非常に大きなトランザクションはローカルディスクを爆発的に増大させる可能性があります。
バックアップ/復元や新しいノードの追加などの操作のコストは、データの量に比例します。
各ノードは全量のデータを保存するため、弾力性が低下します。

これらの問題を解決するために、Microsoft は新しいタイプのクラウドネイティブデータベースを設計しました。コンピューティングとストレージ分離アーキテクチャをベースに、さらにストレージ層を分離し、ログをストレージ層から分離し、高性能なログサービスを別途設計しました。より高いレベルでは、耐久性（ログによって実装）と高可用性（ストレージ層によって実装）の分離を実現します。ほとんどのデータベースのこれら 2 つの機能は、ストレージ層によって提供されます。

ソクラテスはこれら2つの概念を分離する考えを持っています。（１）不完全な永続性には高価な記憶装置が必要（詳細は5.2.2を参照）。（２）高可用性には複数のコピーが必ずしも必要ではない（例えば、従来の3部のコピーについては、5.2.3を参照してください）。

これら 2 つの概念の要件を分離すると、Socrates では (1) より安価な高速ストレージとコンピューティングリソース、および (2) より少ないデータコピーが必要になります。それで、彼は具体的にどのようにそれを実行したのでしょうか?

4.2 コアテクノロジー

Socrates は、データベースのさまざまなコンポーネントを独立したサービスに分割し、さまざまな機能を提供します。また、非同期通信を使用して応答時間を短縮し、処理を高速化します。ソクラテスは一般的に4つの要素から構成される

4.2.1 計算ノード

上記の 2 つのクラウドネイティブデータベースと同様に、Socrates コンピューティングレイヤーには、読み取り/書き込みインスタンスと複数の読み取り専用インスタンスが含まれています。読み取り/書き込みインスタンスに障害が発生した場合、読み取り専用インスタンスが新しい読み取り/書き込みインスタンスとして選択されます。

上記のアーキテクチャ図に示されているように、データベースインスタンスがキャッシュされていないページを読み取る必要がある場合、GetPage@LSN (実際には GetPage(PageID, LSN)) RPC を介して応答ページサーバーからページを取得する必要があります。 PageID はページの一意の識別子であり、LSN は、この LSN が適用または更新されるページを返す必要があることをページサーバーに通知します。

簡単な例:

読み取り/書き込みインスタンスは、ローカルキャッシュ内のページ X を更新します。
何らかの理由で、ローカルバッファープールのページ X が削除されます (その変更が XLOG にフラッシュされていることを確認する必要があります)。
読み取り/書き込みインスタンスはページ X を再度読み取ります。

Page X の最新バージョンを確実に読み取れるようにするには、特定の LSN が必要です。読み取り/書き込みインスタンスは、GetPage(X, X_LSN) 要求をページサーバーに送信します。ページサーバーは、X_LSN より小さいすべてのログが適用されるまで待機してから、ページ X を返します。読み取り/書き込みノードは、PageID -> Page LSN のマッピングを維持します。

読み取り/書き込みインスタンスと読み取り専用インスタンスの間には直接の相互作用はありません。読み取り専用ノードが受信したすべてのログは、XLOG によってブロードキャストされます。読み取り専用ノードは、受信後に再生する必要があります。再生プロセス中に対応するページがバッファプールにない場合は、直接破棄されます。ただし、ページサーバーからページを取得して再生するという別の戦略も提供されます。これにより、プライマリサーバーとバックアップサーバー間のキャッシュがほぼ一貫していることが保証され、フェイルオーバーが発生したときに安定性が向上します。

4.2.2 ログ

XLOG は Socrates ログサービスレイヤーです。上の図は、XLOG サービスの内部実装を示しています。

まず、読み取り/書き込みノードは、書き込みのレイテンシを削減するために、高速な永続ストレージサービスである Landing Zone (LZ) にログを直接書き込みます。これは、Azure Advanced Storage Service (XIO) によって実装されます。信頼性を確保するため、データは 3 つのコピーで保存されます。

同時に、読み取り/書き込みノードは XLOG プロセスに非同期的にログを書き込み、XLOG プロセスはログをページサーバーおよび読み取り専用ノードに送信します。 LZ の目的は可用性ではなく永続性です。可用性は、ページサーバーおよびコンピューティングノードによって保証されます。

読み取りノードと書き込みノードは、LZ プロセスと XLOG プロセスにログを並列に書き込みます。そのため、ログは LZ 永続化の前に読み取り専用ノードに到達する可能性があり、障害発生時にデータの不整合が発生する可能性があります。このため、XLOG プロセスは LZ に永続化されたログのみをブロードキャストします。読み取り/書き込みノードは、まず XLOG プロセスの保留ブロックにログを書き込みます。ログが正常に保存されると、XLOG プロセスはそれを保留ブロックから LogBroker に移動し、ブロードキャスト配信します。

また、バックグラウンドでは、高速アクセスのために永続ログをローカル SSD キャッシュに移動するデステージングスレッドも実行されます。同時に、長期アーカイブ (LT) のために XStore に移動されます。 XStore は安価なストレージを使用するため、コストは低いですが速度は遅くなります。 LZ と LT はすべてのログを保存し、共同で永続性の目標を達成します。 Socrates は、ポイントインタイムリカバリと災害復旧のために、デフォルトで 30 日間ログレコードを保持します。明らかに、LZ に 30 日間のログを保存するのは非常にコストがかかりますが、XStore はこのタスクを完全に引き継ぐことができます。

LZは高速ですが高価であり、これは迅速なトランザクションの提出に適していますが、Xstoreは安価ですが、コスト削減に適しています。

4.2.3ページサーバー

ページサーバーは、主に3つのことを担当します

ログを再生してデータベースパーティションを管理します
計算ノードのgetPageリクエストに応答します
Xstoreへのチェックポイントとバックアップ

各ページサーバーは、保存するページに関連するログに注意する必要があります。ログに十分な注釈情報がログに追加され、ログレコードを適用する必要があるパーティションを示します。 XLOG Processはこの情報を使用して、ログのターゲットページを見つけます。

コンピューティングノードのようなページサーブは、RBPEX（Resilient Buffer Pool Extention）も使用します。ただし、コンピューティングノードキャッシングは、従来のデータベースキャッシング方法です。最高のパフォーマンスを実現するために、最もホットなページをキャッシュすることです。ページサーバーは、このパーティションのすべてのページをキャッシュします。これは、GetPageリクエストのパフォーマンスに非常に優しいものであり、一定の期間XSTOREダウンタイムを許容できます。

また、新しいページサーバーを起動することも非常に便利です。 RBPEXキャッシュは非同期に確立され、ページサーバーはリクエストとアプリケーションログを同時に受け入れることができます。各ページサーバーによって管理されるデータは大きくないため、回復は非常に高速です。データの1つのコピーとデータの1つのコピーの安価なストレージを通じて、高可用性が達成されます。

4.2.4 Xstore

データベース内のすべてのデータはXstoreに保存され、ページサーバーはキャッシュに相当します。 Xstoreは、AZS全体で低コストの高度に複製されたストレージシステムであり、データをほとんど失うことはありません。 Xstoreは従来のデータベースのハードディスクに相当し、コンピューティングノードとページサーバーのメモリとSSDキャッシュ（RBPEX）は、従来のデータベースのメモリに相当します。

一般に、Xlog + Xstoreは永続性を達成し、コンピューティングノード +ページサーバーは高可用性を達成します。

5。コントラスト

対照的に、オーロラはクラウドネイティブのデータベースの先駆者です。データベースのストレージおよびコンピューティング機能を分割し、データベースの機能の一部をストレージノード（主にREDO）に移動する最初のことであり、送信されるデータの量を大幅に減らしてパフォーマンスと効率を向上させます。ソクラテスはさらに一歩進んで、データベースコンポーネントをより詳細なコンポーネントに分解し、複数のサービスレイヤーを形成します。このアーキテクチャはより柔軟性があり、可用性とコストを制御するためのより細かい粒度があり、パフォーマンスと可用性を確保しながらシステムが大幅にコストを制御するのに役立ちます。（これは、ソクラテスがオーロラよりも進歩していることを意味するものではありません。オーロラは近年、マルチマスター、Serveless、その他の分野の特定のブレークスルーを備えており、クラウドデータベースの分野の主要な位置にあります。）

Polardbにはストレージとコンピューティングの分離アーキテクチャもあり、複数のノードがデータのコピーを共有していますが、その側面はオーロラ/ソクラテスとは異なります。ストレージレイヤーは、さまざまな新しいハードウェア機能を使用して、非常に信頼性の高い高性能分散ファイルシステムを確保し、複数のノードがマウントされます。 Polardbは、高速ネットワークとさまざまな新しいハードウェアの開発は、ネットワークがもはや主要なボトルネックではないことを意味するが、ボトルネックはソフトウェア自体にあることを意味すると考えています。したがって、新しいハードウェアに適応し、OSバイパスとゼロコピーテクノロジーを使用してCPU利用効率を向上させるために、多くの作業が行われました。 PolardBのようなアーキテクチャは、実際にはオープンソースコミュニティの新しいバージョンに従うのが簡単です。これは、コンピューティング層の機能的な変化が特に大きくなく、主に新しいストレージと物理的な複製に適応するためです。

これらの2つの方法のどれが優れているかについては、個人的な意見に依存します。

>>: エッジクラウドと 5G のセキュリティ確保: 方法と重要性