PolarDB:ストレージプール

制限事項

• インスタンスのエンジンバージョンは5.4.18-17066805以降である必要があります。

• 論理データベースはAUTOモードでパーティション分割する必要があります。

背景情報

顧客関係管理 (CMR) 、ウェアハウス、eコマースプラットフォームの注文システムなどのプラットフォームベースのアプリケーションとシステムは、複数のユーザーによって使用されます。 これらのプラットフォームのサービスモデルとビジネスデータベースは、ユーザーに基づいて設計および分割されています。 この場合、ユーザは、売り手、ブランド、または倉庫であり得る。

これらのプラットフォームのビジネスが発展するにつれて、多数のサービス要求を有するユーザは、より高いサービス品質を必要とする主要ユーザまたはVIPユーザになる。 このような要件に適応するには、ビジネスアプリケーション層も変更する必要があります。 さらに、ビジネスデータベースは、サービスレベルを定義し、異なるテナントからのデータのストレージと計算のためのリソースを分離する機能を提供する必要があります。

データベースの分割に使用される方法に基づいて、次のテナントソリューションが提供されます。

• スキーマレベルのSaaSマルチテナント: 複数のテナントのデータは、異なるデータベースに分散されます。 各テナントは独立してスキーマを実行する必要があります。

• パーティションレベルのSaaSマルチテナント: 複数のテナントのデータは、論理テーブルの異なるパーティションに分散されます。 テナントはスキーマを共有する必要があります。

パーティションレベルのSaaSマルチテナントと比較して、スキーマレベルのSaaSマルチテナントは、より高いレベルの分離を提供します。 ただし、スキーマレベルのSaaSマルチテナントでは、より多くのスキーマを維持する必要があるため、O&Mおよびクエリのコストも高くなります。 パーティションレベルのSaaSマルチテナントの動作は、ミドルウェアのデータベースシャーディングおよびテーブルシャーディング機能、または分散データベースのパーティション機能に依存します。 この場合、リソースの分離はスタンドアロンデータベースでは実装できません。 スキーマレベルのSaaSマルチテナントの操作ははるかに簡単です。 複数のスタンドアロンApsaraDB RDSインスタンスを使用してアプリケーションを構築できます。

従来のSaaSマルチテナントソリューションには、次の問題点があります。

• マシン間の分散トランザクション: ほとんどの分散ミドルウェアは、分散トランザクション機能に強力な一貫性を提供できません。 したがって、アプリケーションに対して変換を実行する必要があります。

• データ管理: ミドルウェアソリューションに基づいて、スキーマレベルまたはパーティションレベルのSaaSマルチテナントを使用するかどうかに関係なく、列またはインデックスの追加または削除、テーブルの作成と削除などのデータ管理を手動で実行する必要があります。

• リソース変更管理: 複数のテナントのリソースレベルの定義を変更すると、高いO&Mコストが発生します。 たとえば、リソースを1つのテナントに割り当てる場合は、外部同期ツールを使用してデータを移行する必要があります。

PolarDBは、パーティション定義やパーティション変更などの包括的なパーティション管理機能を提供します。 PolarDBは、分散トランザクションおよび分散データ定義言語 (DDL) 機能も提供します。 前述の基本機能に基づいて、PolarDBはネイティブストレージプール機能をエンジンに統合し、SaaSユーザーにリソースのグループ化、リソースの再構築、データベースオブジェクトリソースのバインド、およびデータベースオブジェクトリソースの再定義機能を提供します。 これらの機能は、従来のSaaSマルチテナントソリューションの問題点を解決するのに役立ちます。

基本デザイン

ストレージプール機能を使用して、ストレージノードを複数のストレージプールに分割し、データベース、テーブル、パーティションなどのデータベースオブジェクトを異なるストレージプールに関連付けて、ストレージの分離を実装できます。

• ストレージ分割のためのグローバルかつ包括的なメソッドと、既存の分割メソッドに基づくデータベースオブジェクトの完全なバインディングセマンティクスを提供します。

• インスタンスの変更時にカスタム分割方法に従って、変更プロセスを最適化し、負荷分散機能を提供します。

複数のテナントのサービス分離を実装するには、仕様、ゾーン、データセンターの場所に基づいてPolarDBインスタンスの分散ストレージノード (以下、DNと呼びます) を手動で分割し、データベースオブジェクトを異なるストレージプールに関連付けることができます。

ストレージプール機能には、次の利点があります。

• インスタンスのストレージノードを個別のストレージプールに分割できます。

• データベースオブジェクトを構成するときにプールを指定できます。 プールを指定した後、宛先トポロジは指定されたプールの要件を満たす必要があります。

• テーブルグループまたはパーティショングループが関連付けられているプールを変更できます。 このような変更が実行されると、パーティションの移行が自動的にトリガーされます。

• プールが関連付けられているノードセットを変更できます。 変更を実行すると、パーティションの移行が自動的にトリガーされます。

セマンティクスとAPI操作

mysql > select * from information_schema.storage_pool_info;
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+
| ID   | NAME     | DN_ID_LIST                                          | IDLE_DN_ID_LIST | UNDELETABLE_DN_ID         | EXTRAS | GMT_CREATED         | GMT_MODIFIED        |
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+
|    1 | _default | dn0,dn1,dn2,dn3,dn4,dn5,dn6,dn7,dn8,dn9             |                 | dn0                       | NULL   | 2024-04-15 19:46:05 | 2024-04-15 19:46:05 |
|    2 | _recycle |                                                     |                 |                           | NULL   | 2024-04-15 19:46:05 | 2024-04-15 19:46:05 |
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+

mysql > alter storage pool _default drain node 'dn1,dn2,dn3,dn4,dn5,dn6,dn7,dn8,dn9';
Query OK, 0 rows affected (1.52 sec)

mysql > select * from information_schema.storage_pool_info;
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+
| ID   | NAME     | DN_ID_LIST                                          | IDLE_DN_ID_LIST | UNDELETABLE_DN_ID         | EXTRAS | GMT_CREATED         | GMT_MODIFIED        |
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+
|    1 | _default | dn0,                                                |                 | dn0                       | NULL   | 2024-04-15 19:46:05 | 2024-04-15 19:46:05 |
|    2 | _recycle | dn1,dn2,dn3,dn4,dn5,dn6,dn7,dn8,dn9                 |                 |                           | NULL   | 2024-04-15 19:46:05 | 2024-04-15 19:46:05 |
+------+----------+-----------------------------------------------------+-----------------+---------------------------+--------+---------------------+---------------------+

create storage pool pool1 dn_list = "dn1,dn2,dn3" undeletable_dn="dn1";
create storage pool pool2 dn_list = "dn4,dn5,dn6" undeletable_dn="dn5";
create storage pool pool3 dn_list = "dn7,dn8,dn9" undeletable_dn="dn7";

LOCALITY = 'storage_pools=pool1,pool2,...;primary_storage_pool=pool1'

create database d1 locality = "storage_pools=pool1";
use d1;
-- valid operation!
create table t1(a int) single locality = "storage_pools=pool1";

-- invalid operation, because t2 locality storage_pools not in d1 storage_pools
create table t2(a int) single locality = "storage_pools=pool3"; 


create database d2 locality = "storage_pools=pool1,pool2,pool3;primary_storage_pool=pool1,pool2";
use d2;
-- valid operation!
create table t1(a int) locality = "storage_pools=pool1"; 
create table t2(a int) locality = "storage_pools=pool3";
create table t3(a int) locality = "storage_pools=pool2";
create table t4(a int) locality = "storage_pools=pool2";
-- all the logical table locate on storage pool pool1,pool2 defaultly;
-- while broadcast table locate on all the storage pool

-- valid operation
alter storage pool pool1 remove node "dn3";
-- invalid operation, because dn1 is the undeletable storage pool for pool1.
alter storage pool pool1 remove node "dn1";


-- valid operation, because dn4 is in _recycle storage pool
-- and no physical db locate on dn4.
alter storage pool pool2 append node "dn3";
-- invalid operation, because dn3 is hold by pool1.
alter storage pool pool2 append node "dn2";

alter database d1 set locality = "storage_pools=sp1;primary_storage_pool=sp1";


alter database d2 set locality = "storage_pools=sp1,sp2;primary_storage_pool=sp1"


use d1;

alter table t1 single locality = "storage_pools=sp1";

サンプルシナリオ

シナリオ1: データベースレベルのテナントソリューション

エンタープライズXという名前のeコマースプラットフォームは、多数の注文を有するいくつかの大きな売り手と多くの小さな売り手を含む、複数の売り手からの注文を維持する必要がある。 次の項目では、Enterprise Xがさまざまな販売者にリソースを割り当てる方法について説明します。

• 個別のストレージリソースを使用して安定したオンライントラフィックを確保し、大手セラー向けに個別のバッチプロセスとデータ分析機能を提供します。

• すべての小規模セラーにストレージリソースのセットを使用し、リソースが小規模セラー間で可能な限り均等に分散されていることを確認します。

• ビジネスが変化すると、小さな売り手は大きな売り手になり、大きな売り手は自分のビジネスを他のプラットフォームとの間で移行する可能性があります。

テナントの定義

既存のストレージノードを複数のストレージプールに分割して、大規模な販売者ごとに個別のストレージスペースを作成し、_defaultストレージプールを小規模な販売者の共有ストレージスペースとして使用できます。

CREATE STORAGE POOL sp1 dn_list="dn4,dn5,dn6" undeletable_dn="dn4";

CREATE STORAGE POOL sp2 dn_list="dn7,dn8,dn9" undeletable_dn="dn7";

CREATE DATABASE orders_comm MODE = "auto"
      LOCALITY= "storage_pools='_default'"; /* Small sellers share the _default storage pool (dn1, dn2, dn3). */

CREATE DATABASE orders_seller1 MODE = "auto"
      LOCALITY= "storage_pools='sp1'"; /* Big Seller 1 uses the sp1 storage pool (dn4, dn5, dn6). */
CREATE DATABASE orders_seller2 MODE = "auto"
      LOCALITY= "storage_pools='sp2'"; /* Big Seller 2 uses the sp2 storage pool (dn7, dn8, dn9). */
...

上記のステートメントを実行すると、次の結果が得られます。

• 大きな売り手と小さな売り手のストレージリソースは完全に分離されています。

• スモールセラーは、_defaultストレージプールでdn1、dn2、およびdn3を共有します。

• 大きな売り手と小さな売り手のテーブル作成ステートメントは独立しています。 各販売者は、スキーマとストレージスペースを個別に設定できます。

リソースのバランス

地域の原則に基づいてパーティション分割されていないテーブルを作成するか、小規模な売り手に使用されるデータベースにパーティション分割されたテーブルを作成できます。 データ配布の違いにより小規模な販売者間でリソースのバランスを取る必要がある場合は、ストレージプール内のリソースのバランスを取るために使用されるステートメントのみを実行する必要があります。

REBALANCE TENANT "_default" POLICY="data_balance";

REBALANCEステートメントを実行すると、ストレージプール内のオブジェクトの定義に基づいて、パーティション分割されていないテーブルとパーティションのバランスが自動的に調整されます。 インスタンスのスケーリングと同様に、この操作は自動的にリソース制限を満たし、パーティション分割されていないすべてのテーブルとパーティションをdn1、dn2、およびdn3に均等に分散します。

テナントの移行

大規模な販売者がエンタープライズXにビジネスを移行する場合、ストレージノードをインスタンスに追加し、そのノードを使用してストレージプールを作成し、大規模な販売者が作成したストレージプールを排他的に使用するためのデータベースを作成できます。 デフォルトでは、新しいストレージノードは_recycleストレージプールに関連付けられています。

CREATE STORAGE POOL spn dn_list = "dn10,dn11,dn12" undeletable_dn="dn10";
/* Create a storage pool named spn (dn10, dn11, and dn12). */

CREATE DATABASE orders_sellern MODE = "auto"
      LOCALITY="storage_pools='spn'";
/* Big Seller N uses the spn storage pool. */

大規模な売り手がビジネスを別のプラットフォームに移行する場合、対応するデータベースを削除して、対応するリソースをリリースできます。

DROP DATABASE orders_sellern; 

DELETE STORAGE POOL spn;/* Remove the storage pool. After you remove the pool, nodes in the pool are automatically moved to the _recycle storage pool. */

ALTER STORAGE POOL _recycle DRAIN NODE "dn7, dn8, dn9"; /* Release resources from the corresponding nodes in the cluster. */

上記のストレージプールとデータベースを追加または削除しても、既存のビジネスは影響を受けず、アプリケーションはほとんど中断されません。

シナリオ2: パーティションレベルのテナントソリューション

パーティションに基づいてリソースを分離し、シナリオ1のEnterprise Xの要件を実装することもできます。 データベースレベルのテナントソリューションと比較して、パーティションレベルのテナントソリューションは各テナントに同じ分離機能を提供し、次の利点があります。

• すべてのパーティションは論理テーブルの定義を共有します。 列およびインデックスの追加および削除、ブロードキャストテーブルのプッシュダウンなどのデータO&M操作は、データベースによって自動的に管理されます。

• パーティション分割やパーティションマージなどのパーティション管理機能を使用すると、このソリューションでは、より柔軟な方法でリソースを変更できます。 たとえば、一部のテナントのサービスレベルをVIPにアップグレードし、一部のテナントのリソースをマージできます。

テナントの定義

ストレージノードをストレージプールに分割し、すべてのプールを使用してパブリックデータベースを作成します。

CREATE DATABASE orders_db MODE = "auto" 
       LOCALITY = "storage_pools='_default,sp1,sp2,...',primary_storage_pool='_default'"

USE orders_db;

CREATE TABLE commodity(
  commodity_id int,
  commodity_name varchar(64)
) BROADCAST;
/* The system creates table shards in all storage pools based on the commodity broadcast table. In this case, you can push down join operations to a partition in the orders_sellers table. */

CREATE TABLE orders_sellers(
 order_id int AUTO_INCREMENT primary key,
 customer_id int,
 commodity_id int,
 country varchar(64),
 seller_id int,
 order_time datetime not null)
partition BY list(seller_id)
(
  partition p1 VALUES IN (1, 2, 3, 4),
  partition p2 VALUES IN (5, 6, 7, 8),
  /* By default, the p1 and p2 partitions of the orders_seller table store data on the nodes of the _default storage pool and share resources in the pool. */
  ...
  partition pn VALUES IN (k) LOCALITY = "storage_pools='sp1'",
  partition pn+1 VALUES IN (k+1, k+2) LOCALITY = "storage_pools='sp2'",
  /* The pn and pn+1 partitions of the orders_seller table store data on the nodes of the sp1 and sp2 storage pools respectively and use the resources on the corresponding nodes. */
  ...
) LOCALITY = "storage_pools='_default,sp1,sp2,...'";

• データベースの定義には、すべてのストレージプールが含まれています。 さらに、primary_storage_poolと_defaultストレージプールが定義されています。 したがって、orders_sellersテーブルのパーティションは、_defaultストレージプールのノードをストレージノードとして自動的に使用し、ブロードキャストテーブルはすべてのストレージプールのノードに自動的に分散されます。

• 各パーティションの定義には、異なるテナントのセットが含まれます。 パーティションごとにカスタムストレージリソースを指定できます。

テナントの移行

小規模な売り手が企業Xにビジネスを移行する場合、新しいパーティションを追加できます。 この場合、パーティションのみが生成されます。

ALTER TABLE orders_sellers ADD PARTITION 
(PARTITION p3 values in (32, 33));

大規模な販売者が企業Xにビジネスを移行する場合、既存のストレージノードにノードを追加し、追加したノードのデータをルーティングしてパーティションを作成し、ノードのストレージプールを指定できます。

CREATE STORAGE POOL spn dn_list = "dn10,dn11,dn12" undeletable_dn="dn10";
/* Create a storage pool named spn in the instance.*/

ALTER DATABASE orders_db SET LOCALITY = 
  "storage_pools='_default,sp1,sp2,...,spn',primary_storage_pool='_default'"
/* Add the spn storage pool to the storage pools of the orders_db database. After you perform this operation, the broadcast table is automatically moved to a node in the created storage pool. */

ALTER TABLE orders_sellers ADD PARTITION 
(PARTITION p4 values in (34) LOCALITY="storage_pools='spn');
/* Add a partition in the orders_sellers table and distribute the partition to the spn storage pool. */

売り手がビジネスを別のプラットフォームに移行する場合、対応するパーティションを削除し、リソースプール内のリソースを解放できます。

ALTER TABLE orders_sellers DROP PARTITION p4;

売り手が小さな売り手の場合、対応するパーティションの定義を変更し、パーティション内の売り手を削除できます。

ALTER TABLE orders_sellers MODIFY PARTITION p1 DROP VALUES (4, 5);

パーティションレベルのテナントの場合、すべてのパーティションが論理テーブルの定義を共有します。 この場合、データベースの設定を変更して、データモードを変更できます。 上記のすべての変更ステートメントはオンラインで実行され、関連するパーティションのみに影響します。

テナントのサービスレベルを変更する

小規模な販売者がサービスレベルをVIPにアップグレードしたい場合は、対応するパーティションの定義を変更し、パーティションを別のストレージプールに関連付けることができます。

ALTER TABLE orders_sellers SPLIT PARTITION p2 INTO 
(PARTITION p2 VALUES in (6, 7, 8) ,
PARTITION `pn+2` VALUES in (5) LOCALITY = "storage_pools='spn+3'");

大きな売り手のサービスレベルをダウングレードすることもできます。

ALTER TABLE orders_sellers MERGE PARTITION p1, pn TO p1 LOCALITY="";

上記の操作を実行すると、p1パーティションとpnパーティションがマージされます。 ただし、マージされたパーティションは引き続き_defaultストレージプールを使用します。

データベースレベルのテナントソリューションのリソース分離能力に基づいて、パーティションベースのテナントソリューションは、柔軟なリソース変更および管理のためのより包括的なパーティション管理操作を提供します。

リソースのバランス

テナントに対応するパーティションのワークロードが異なる場合は、ストレージプールで使用されるREBALANCEステートメントを実行して負荷のバランスを取ることもできます。

REBALANCE TENANT "_default" POLICY="data_balance";

シナリオ3: スタンドアロンデータベースから分散データベースへのデータ移行

次の例では、データはスタンドアロンのリレーショナルデータベースから分散リレーショナルデータベースに移行されます。 移行の初期段階では、スタンドアロンリレーショナルデータベースの既存のモードと分散リレーショナルデータベースのスケールアウト機能を使用して、スムーズな変換を実現します。 ビジネスの発展に伴い、既存のビジネスのデータベーステーブルモデルやリソース使用量に影響を与えずに、多数のワークロードを持つ特定のテーブルを分散テーブルに変換する必要があります。

ストレージプール機能を使用して、異なるテーブルのストレージリソースを定義し、パーティション分割されていないテーブルと分散テーブルの統合ハイブリッド展開を実装できます。 これにより、分散データベースへのデータのスムーズな移行が保証されます。

データベースとテーブルの作成

ブロードキャストテーブルのセマンティクスを持つ特定のテーブルを除き、テーブルシャーディング機能を使用して、PolarDB-Xのスタンドアロンデータベースでテーブルを作成するために使用されるセマンティクスを再利用できます。 これにより、数回クリックするだけで既存のビジネスを移行および変革できます。

CREATE DATABASE orders_db MODE = "auto" DEFAULT_SINGLE=on 
    LOCALITY = "storage_pools='_default',primary_storage_pool='_default'";

use orders_db;

CREATE TABLE orders_region1(
 order_id int AUTO_INCREMENT primary key,
 customer_id int,
 country varchar(64),
 city int,
 order_time datetime not null);
CREATE TABLE orders_region2(
 order_id int AUTO_INCREMENT primary key,
 customer_id int,
 country varchar(64),
 city int,
 order_time datetime not null);
CREATE TABLE orders_region3(
 order_id int AUTO_INCREMENT primary key,
 customer_id int,
 country varchar(64),
 city int,
 order_time datetime not null);
CREATE TABLE commodity(
  commodity_id int,
  commodity_name varchar(64)
) BROADCAST;

データベースとテーブルの作成に使用される上記のステートメントでは、次の結果が得られます。

• ステートメントを使用して作成されたパーティション分割されていないすべてのテーブルは、データボリュームとテーブル数に基づいて_defaultストレージプールで自動的にバランスが取られます。

• ブロードキャストテーブルのテーブルシャードは、_defaultストレージプールのすべてのノードに作成されます。

パーティション分割されていないテーブルを分離する

パーティション分割されていないテーブルのデータ量と訪問数が多い場合は、ストレージノードをインスタンスに追加し、新しいストレージノードのテーブルを分離できます。

ALTER DATABASE orders_db set LOCALITY = "storage_pools='_default,sp1',primary_storage_pool='_default'";
/* If a change operation is performed on the database, the system automatically handles the table shard expansion of the broadcast table.  */

ALTER TABLE orders_region_single1 single LOCALITY = "storage_pools='sp1'";
/* Isolate non-partitioned tables that have excessive workloads on the nodes of the sp1 storage pool. */

テーブルを分散テーブルに変換する

ビジネスの発展に伴い、ワークロードがデータベースのワークロード制限を超えるテーブルを分散テーブルに変換し、テーブルが使用するストレージノードを指定できます。

ALTER DATABASE orders_db set LOCALITY = "storage_pools='_default,sp1,sp2,sp3',primary_storage_pool='_default'";


ALTER TABLE orders_region_single2 partition by hash(order_id) partitions 16
  LOCALITY = "storage_pools='sp2'";
/* The orders_region_single2 table uses the sp2 storage pool. */

ALTER TABLE orders_region_single3 partition by hash(order_id) partitions 16
  LOCALITY = "storage_pools='sp3'";
/* The orders_region_single3 table uses the sp3 storage pool. */

シャーディングタスクを使用すると、カスタムパーティション分割方法とストレージリソースをオンラインで指定できます。 これにより、テーブルレベルのビジネスモデルを変換し、パーティション分割されていないテーブルを分散テーブルに簡単に変換できます。

手順

カスタムストレージプールを作成し、ストレージプール内のノードを管理する方法については、「データノードの管理」をご参照ください。