PolarDB:PolarDB-X 2.0 インスタンスと PolarDB-X 1.0 インスタンスの機能比較

機能

PolarDB-X 1.0 インスタンス

PolarDB-X 2.0 インスタンス

インスタンスの購入

PolarDB-X 1.0 インスタンスには ApsaraDB RDS for MySQL リソースは含まれていません。ApsaraDB RDS for MySQL インスタンスを別途購入し、PolarDB-X 1.0 コンソールで PolarDB-X 1.0 インスタンスに統合する必要があります。

データベースサービス全体を提供します。PolarDB-X インスタンスを作成するだけで済みます。

データベースの作成

PolarDB-X 1.0 インスタンスでは、PolarDB-X 1.0 コンソールでデータベースを作成する必要があります。データベースを作成する際には、既存の ApsaraDB RDS for MySQL インスタンスを選択するか、ApsaraDB RDS for MySQL インスタンスを購入する必要があります。

データベースを作成するには、次の 2 つの方法があります。

1. 使い慣れたツールまたは [データ管理 (DMS)] を使用してデータベースサービスにログインし、CREATE DATABASE 文を実行してデータベースを作成します。

2. コンソールでデータベースを作成します。

スケールアウト

各 ApsaraDB RDS for MySQL インスタンスのストレージ容量を評価し、一部のデータベースシャードを新しい ApsaraDB RDS for MySQL インスタンスのストレージに移行する必要があります。

ノードを追加するだけで済みます。データは各ストレージノードに自動的かつ均等に分散されます。

ストレージレイヤー

PolarDB-X 1.0 インスタンスは、汎用 ApsaraDB RDS for MySQL インスタンスに接続します。ほとんどの場合、PolarDB-X 1.0 インスタンスのノードはプライマリ/セカンダリモードでデプロイされます。

PolarDB-X は、金融データのセキュリティを確保できる 3 ノードストレージモードを使用します。PolarDB-X は Paxos プロトコルを使用して、目標復旧時点 (RPO) ゼロを実現します。

高可用性のためのフェールオーバー

ApsaraDB RDS for MySQL のプライマリインスタンスとセカンダリインスタンスがデプロイされている高可用性システムの障害検出メカニズムに基づいて、ダウンタイム時にストレージレイヤーでフェールオーバーが実行されます。サービスレベル契約 (SLA) により、フェールオーバーは数分で完了することが保証されます。

Paxos プロトコルに基づいて、ダウンタイム時にストレージレイヤーでフェールオーバーが実行されます。 SLA により、フェールオーバーは 30 秒以内に完了することが保証されます。

コンピューティングレイヤーは、ストレージレイヤーで実行されるフェールオーバーを認識し、ApsaraDB RDS for MySQL インスタンスへの接続のアクティブクローズに基づいてフェールオーバーを実行します。 SLA により、フェールオーバーは数分で完了することが保証されます。

コンピューティングレイヤーは、ストレージレイヤーで実行されるフェールオーバーを認識し、Paxos のメタデータ情報に基づいてフェールオーバーを実行します。 SLA により、フェールオーバーは数秒で完了することが保証されます。

データ同期

PolarDB-X 1.0 インスタンスからダウンストリームにデータを同期する場合、Data Transmission Service (DTS) を使用して各 ApsaraDB RDS for MySQL インスタンスをサブスクライブし、同じ論理テーブルの異なるテーブルシャード間の違い (テーブル名の違いなど) を慎重に処理する必要があります。 DDL 操作はデータ同期リンクではサポートされていません。

統一バイナリログサービスを提供します。DTS を使用してスタンドアロン ApsaraDB RDS for MySQL インスタンスをサブスクライブするのと同じ方法で、DTS を使用してバイナリログサービスをサブスクライブできます。

読み取り/書き込み分割

読み取り専用 ApsaraDB RDS for MySQL インスタンスを追加し、PolarDB-X 1.0 インスタンスにバインドする必要があります。

読み取り専用の PolarDB-X インスタンスのみを追加できます。

O&M

1. 負荷のバランスが取れていない場合は、いずれかのノードのスペックを個別にアップグレードする必要があります。

2. いずれかのストレージノードを他のビジネスに割り当てることができます。

3. ApsaraDB RDS 5.6、5.7、または 8.0 を使用できます。

4. ApsaraDB RDS for MySQL インスタンスのバイナリログをサブスクライブできます。

いずれかのデータベースシャードを削除すると、PolarDB-X 1.0 インスタンスは削除されたデータベースシャードに格納されているデータにアクセスできなくなることに注意してください。

PolarDB-X は、ユーザーをストレージノードからシールドします。ユーザーはストレージノードに直接アクセスできません。 PolarDB-X は、データベースを全体的な視点からユーザーに提示します。

PolarDB-X は、自動負荷分散、論理バイナリログ、混合負荷用のハイブリッドトランザクション/分析処理 (HTAP) などの機能を使用して、ストレージノードへの直接アクセス要求を削減します。 PolarDB-X インスタンスの計算ノードは MySQL 5.7 に基づいています。

Database Autonomy Service (DAS)

[Log Service] に基づいて SQL 監査と分析を提供し、低速 SQL クエリに関する詳細を表示できます。

[SQL エクスプローラー] と、セキュリティ監査、SQL エクスプローラー、インテリジェントストレステスト、パフォーマンストレンド、インスタンスセッション、スロークエリログ、ストレージ容量分析、リアルタイムパフォーマンス、ストレージ容量評価などの分析機能を提供します。

アーキテクチャの違い

PolarDB-X 1.0 のアーキテクチャでは、多数の機能が周辺管理システムに基づいて実装されています。例：

1. スケールアウト操作は、内部データレプリケーションシステムを使用して実行されます。

2. リージョンにデプロイされたインスタンスは、メタデータを格納するために Diamond を共有します。

3. プライマリインスタンスとセカンダリインスタンスの障害検出メカニズムとフェールオーバーは、Alibaba Database High Availability (ADHA) コンポーネントに基づいて実装されます。

PolarDB-X のアーキテクチャでは、すべてのコア機能がカーネルに統合されています。

1. X-DB がデータノードとして使用されます。

2. [Global Meta Service (GMS)] ノードは、次の機能をサポートしています。

   1. 分散トランザクションで使用されるグローバル自動増分タイムスタンプを提供します。負荷に基づいてノード間でデータを均等に分散します。

   2. INFORMATION_SCHEMA などの統一メタデータを提供します。

   3. フェールオーバー、ノードのオンライン化、ノードのオフライン化など、計算ノードとデータノードを管理します。

3. PolarDB-X インスタンスのスケールアウト操作は、分散トランザクションに基づいてカーネルを使用して完了します。

トランザクションモデル

オープンソース MySQL によって提供される XA トランザクションを使用します。 XA トランザクションは、書き込み操作の原子性を保証します。

グローバルマルチバージョン同時実行制御 (MVCC) をサポートする独自開発のトランザクションを使用します。 2 フェーズコミット (2PC) プロトコルに加えて、トランザクションではスナップショットタイムスタンプ (snapshot_ts) とコミットタイムスタンプ (commit_ts) がサポートされています。

パフォーマンスの向上

PolarDB-X 1.0 インスタンスは、標準リンクを使用して ApsaraDB RDS for MySQL インスタンスに接続されます。 [Server Load Balancer (SLB)] 経由の転送が必要です。これにより、1 ホップのネットワークレイテンシが増加します。

1. PolarDB-X インスタンスの計算ノードとデータノードは、同じ物理ネットワークにデプロイされます。 SLB または Linux Virtual Server (LVS) 経由の転送なしで、直接ポイントツーポイント接続がサポートされています。これにより、低ネットワークレイテンシが実現します。

2. プライベートリモートプロシージャコール (RPC) プロトコルをサポートします。

   1. SQL 文ではなく、実行計画を転送します。これにより、MySQL が SQL 文を繰り返し解析および最適化することを防ぎます。

   2. 非同期モデルを使用します。接続はスレッドに 1 つずつバインドされていません。接続はセッションに 1 つずつバインドされていません。いくつかの接続を使用して要件を満たすことができます。

   3. 応答ヘッダーなど、通信で不要になった情報を削除します。

   4. 計算ノードの計算中に使用される形式と同じ形式でデータを送信します。これにより、データの二次変換が防止されます。

パフォーマンスデータの詳細については、「Sysbench テスト手順」をご参照ください。

パフォーマンスデータの詳細については、「Sysbench テスト」をご参照ください。