PolarDB-X and X-DB, PolarDB

PolarDB-X、X-DB、PolarDB は Alibaba のデータベース製品です。これらにはどのような関係があるのでしょうか。

この問いに答えるには、まず X-DB が何かを理解する必要があります。

X-DB とは

簡単に言えば、X-DB は MySQL と X Engine をベースに構築された分散型クロス AZ 高可用性データベースを指します。

X-DB のコア機能の一つは、Paxos プロトコルに基づく AZ 間の RPO = 0 です。当初、Alibaba が使用していた MySQL は従来のマスター/スレーブアーキテクチャでした。各 MySQL インスタンスは 2 つのノードで構成されます。

このアーキテクチャには重要な欠陥があります。アクティブ/スタンバイ切り替えが発生すると、レプリカデータに不整合が生じる可能性があるのです。アクティブ/スタンバイアーキテクチャの問題を解決するため、Alibaba は当初、以下のような多くの運用・保守の手法を採用していました。

ADHA というシステムが MySQL のサービス有効化やアクティブ/スタンバイ切り替えなどを担当します。

アクティブ/スタンバイ切り替えの前に、複雑なデータ検証を実行して、切り替え前にアクティブ/スタンバイ間のデータ整合性を確保します（では、不整合がある場合はどうやって切り替えるのでしょうか）。

クロスリージョンシナリオでは、独自開発のデータ同期サービスを使用して、MySQL の組み込み同期メカニズムを置き換えます。

ビジネスデータのロールバックと補充には、非常に複雑なデータ修正プログラムを使用します（ビジネスに依存しており、ビジネステーブル構造に一定の要件があります）。

このアーキテクチャは機能しますが、エレガントではありません。複雑さと運用コストが非常に高く、ビジネスの成長についていくことが困難です。

2016 年、Alibaba は社内で X-DB の開発を開始しました。X-DB はまずレプリカデータの整合性問題を解決することを目的としています。X-DB チームは Paxos プロトコルを開発し、MySQL の組み込みアクティブ/スタンバイ同期ロジックを置き換えることを選択しました。Paxos に関する記事は数多くありますので、ここでは詳しく説明しません。興味のある方はご自身でお探しください。

Paxos プロトコルを採用した MySQL の 2 つのコア利点を紹介します。1. マスター切り替えをいつでも実行でき、データ整合性の問題は一切発生しません。RPO = 0 です。2. リーダー選出や探索などは X-DB カーネル（MySQL プロセス）内で完全に処理され、外部システムに依存しません。

Alibaba での数年間の開発を経て、X-DB の Paxos プロトコルライブラリは MySQL と組み合わさり、従来のアクティブ/スタンバイ MySQL クラスターを高い信頼性で完全に置き換えました。

PolarDB-X と X-DB

上記からわかるように、X-DB はディザスタリカバリや障害復旧などの問題を解決しましたが、PolarDB-X の強みはサービスシナリオへの適応性と水平スケーリングにあります。

PolarDB-X 2.0 のデータノード（DN）は、X-DB のクラスターディザスタリカバリ技術を統合し、水平スケーリング機能を提供します。

実際、X-DB と PolarDB-X の関係は Paxos プロトコルだけにとどまりません。分散トランザクション、スケーラビリティ、コンピューティングパワーのプッシュダウン、HTAP など、多くの開発作業が行われています。今後の記事にご注目ください。

PolarDB-X と PolarDB

PolarDB（ここでは PolarDB for MySQL）は、共有ストレージ技術に基づくクラウドネイティブデータベースです。PolarDB はストレージスペースで高い柔軟性を実現できますが、一般的な使用ではコンピューティング性能と書き込み性能に依然としてシングルマシンの上限があります。

PolarDB-X 2.0 のシェアードナッシングアーキテクチャでは、コンピューティング、書き込み、読み取り、ストレージを含むすべてのリソースを水平方向にスケールアウトでき、シングルマシンのボトルネックの制約がありません。

ただし、シェアードナッシングアーキテクチャは、単純なデータ容量の点では PolarDB の共有ストレージアーキテクチャほど柔軟ではありません。

たとえば、PolarDB-X 2.0 や TiDB のようなどのようなシェアードナッシングデータベースでも、10 台のマシンに 10 TB のデータがあり、マシンを追加してストレージスペースを拡張したい場合、データの約半分は必ず新しいマシンに移動する必要があり、データ量に比例した時間がかかります（たとえば、一般的に数十テラバイトのデータを移動するには少なくとも数時間かかります）。

PolarDB の場合、上記のシナリオは数分で拡張できます。

では、シェアードナッシングの利点と共有ストレージ/シェアードエブリシングの利点を組み合わせることは可能でしょうか。

答えは「はい」です。

現在、次世代の分散データベースでは、DN に RDMA ハードウェアと共有ストレージアーキテクチャに基づく PolarDB のコア技術を導入し、すべてのリソースを水平方向にスケールアウトできるようにするとともに、容量の弾力性コストを大幅に削減します。

PolarDB-X のローカルディスク版と共有ストレージ版は、今後長期間にわたり共存し、どちらが完全に置き換わるということはありません。ローカルディスク版は特殊なハードウェアに依存しないため、主にプライベートクラウドの軽量な導入に適しており、ユーザーの 3 台のマシンで PolarDB-X の導入を完了することが目標です。共有ストレージ版は容量の弾力性が高いですが、この弾力性はある程度の規模を持つパブリッククラウドでのみ十分に発揮されます（パブリッククラウド上にのみ、ビジネスの弾力性を支える十分な規模のマシングルが存在します）。