このトピックでは、PolarDB-X における透過的な分散とは何か、またその仕組みについて説明します。
背景情報
従来のスタンドアロン MySQL データベースで実行されるアプリケーションがリソースやパフォーマンスのボトルネックに直面した場合、ユーザーはビジネス要件を満たすための実証済みの効果的なソリューションとして、データベースを分散データベースにアップグレードします。
しかし、アップグレード後、ユーザーは分散データベースを使用する上で、次のような問題に直面する傾向があります。
データはデータベース全体にどのように分散されているのか?
どのテーブルを水平分割する必要があるのか? テーブルをどのようにパーティショニングし、どのパーティションキーを使用すべきか? テーブルの適切なパーティション数はいくつか?
自分のデータはどのデータノードに格納されているのか? リソースの不均衡にはどのように対処すればよいのか?
これらの問題を解決するには、ユーザーは分散データベースの仕組みと、利用できるシナリオを理解する必要があります。分散データベースを適切に活用することは容易ではありません。
分散データベースをより使いやすくし、スタンドアロンデータベースからのアップグレードを容易にするために、Alibaba Cloud は PolarDB-X 2.0 でカーネル内透過分散機能を提供します。
この機能は、AUTO モードのデータベースのみをサポートしています。
透過的な分散とは
PolarDB-X 2.0 の透過的分散機能は、デフォルトのパーティショニングポリシーとデフォルトのデータ分散ポリシーを提供するため、ユーザーはアプリケーションを変更することなく分散データベースに接続してパフォーマンスを向上させることができます。
透過的な分散の中核となる機能は、ユーザーがテーブルのパーティション方式と、テーブルデータの PolarDB-X データノード (DN) への分散を決定するのを支援することです。
従来のスタンドアロン MySQL データベースから分散型 PolarDB-X データベースに切り替えるユーザーにとって、業務テーブルを作成するための SQL ステートメントは 2 つのカテゴリに分類されます。
カテゴリ 1：SQL ステートメントが MySQL パーティショニング構文を明示的に使用していない場合。これらの SQL ステートメントを使用して作成されたテーブルは、非パーティション MySQL テーブルと呼ぶことができます。
カテゴリ 2：SQL ステートメントが MySQL パーティショニング構文を明示的に使用している場合 (例:
Partition By Hashs(id)を含む SQL ステートメント) 。これらの SQL ステートメントを使用して作成されたテーブルは、パーティション MySQL テーブルと呼ぶことができます。
ユーザーがカテゴリ 2 のステートメントを使用してテーブルを作成した場合、ビジネス要件に合わせたパーティショニング方式を選択したと見なされます。その理由は、ステートメントが MySQL のパーティショニング構文を明示的に使用しているためです。これらのテーブルは、PolarDB-X によっても手動パーティションテーブルと見なされます。これらのテーブルのパーティションは、負荷分散のために DN に均等に分散されます。
カテゴリ 1 のステートメントから大量に生成されるテーブルは、ユーザーがパーティショニングスキームとデータ分散スキームを選択するのを支援することを目的とした、PolarDB-X の透過的な分散の焦点となります。
PolarDB-X の透過的な分散機能は、カテゴリ 1 のステートメントから作成されたテーブル用に、3 つのパーティショニングおよびデータ分散スキームを提供します:
非パーティションテーブル: この方式では、PolarDB-X はテーブルをパーティション化せずに、固定の DN を割り当てます。これにより、ユーザーは従来のスタンドアロン MySQL テーブルと同じようにテーブルを使用できます。
シャードテーブル: この方式では、PolarDB-X 内で MySQL テーブルはパーティション化されません。ただし、テーブルは自動的にシャーディングされ、DNs に分散されます。
パーティションテーブル：この方式では、パーティション化されていない MySQL テーブルが PolarDB-X によって自動的にパーティション化されます。
プライマリテーブルは、主キーに基づいて HASH で水平パーティショニングされます。
デフォルトでグローバルインデックスが使用され、インデックス列に基づいて水平パーティショニングが実行されます。
したがって、透過的な分散機能は、テーブルのパーティショニングおよびデータ分散スキーマに基づいて、3 つのモードで動作します。
テーブルシャーディング
自動パーティショニング
手動パーティショニング (デフォルト)
透過的な分散の動作モード
アプリケーションを分散データベースに接続する際、特に初めて接続する場合には、希望するパーティショニングまたはデータ分散スキーマに基づいて、ビジネス要件に適した動作モードを選択できます。
次の表では、各動作モードのメリットとデメリットについて説明します。
動作モード | 説明 | メリットとデメリット |
論理データベース内のすべてのテーブルについて：
| メリット：
デメリット：
| |
論理データベース内のテーブルが MySQL パーティショニング構文を明示的に使用していない場合：
| メリット：
デメリット：
| |
手動パーティショニング (デフォルト) | 論理データベース内のすべてのテーブルについて：
| メリット：
デメリット：
|
3 つの動作モードは組み合わせて使用できます。たとえば、複数の要件を満たすために、手動パーティショニングをテーブルシャーディングまたは自動パーティショニングと組み合わせて使用できます。
モードの適したシナリオの詳細については、「ベストプラクティス」をご参照ください。