AnalyticDB for MySQL V3.1.3.3以降のエラスティックモードfor Cluster Editionでは、テーブルまたはパーティションレベルでホットデータとコールドデータの階層ストレージをサポートします。
前提条件
ホットデータとコールドデータの階層ストレージを使用する前に、次の要件が満たされていることを確認してください。
elastic mode for cluster EditionのAnalyticDB for MySQLクラスターが作成されます。
クラスターのマイナーバージョンは3.1.3.3以降です。
説明AnalyticDB For MySQLクラスターのマイナーバージョンを表示する方法については、クラスターのマイナーバージョンを表示するにはどうすればよいですか。
AnalyticDB for MySQLクラスターのマイナーバージョンを更新するには、 チケットを起票し、更新の時間枠を指定します。 マイナーバージョンの更新が完了するまでに約20分かかる場合があります。 更新中、クラスターは期待どおりに実行できますが、一時的な接続が数回発生する可能性があります。 オフピーク時にクラスターのマイナーバージョンを更新し、アプリケーションがクラスターに自動的に再接続するように設定されていることを確認することをお勧めします。
課金ルール
クラスターを使用すると、従量課金に基づいてホットデータとコールドデータのストレージに対して課金されます。 詳細については、「Data Warehouse Editionの課金項目」および「Data Warehouse Editionの料金」をご参照ください。
包年包月集群可以购买存储资源包来抵扣热数据存储空间和冷数据存储空间。超出存储资源包的部分按量付费。详情请参见存储资源包。
ストレージポリシー
AnalyticDB for MySQLには、コールドストレージ、ホットストレージ、混合ストレージの3つのポリシーが用意されています。
コールドストレージは、費用対効果の高いストレージポリシーです。 このストレージポリシーを使用すると、すべてのデータがObject storage Service (OSS) に保存されます。
ホットストレージは、高いアクセスパフォーマンス要件を満たすことができるストレージポリシーです。 このストレージポリシーを使用すると、すべてのデータがSSDに保存されます。
混合ストレージは、特定のパーティションをSSDに保存し、他のパーティションをOSSに保存できるようにするストレージポリシーです。
ホットデータとコールドデータのストレージポリシーを指定する
CREATE TABLE文を実行してテーブルを作成するときに、storage_policy
パラメーターを使用して、テーブルのホットデータとコールドデータのストレージポリシーを指定できます。
既存のテーブルのホットデータとコールドデータのストレージポリシーを変更するには、ALTER table table_name storage_policy;
ステートメントを実行します。 詳細については、「ALTER TABLE」トピックの「ストレージポリシー」セクションをご参照ください。
混合ストレージの原理
混合ストレージポリシーを使用する場合、hot_partition_count
パラメーターを使用してホットパーティションの数を指定する必要があります。 hot_partition_count
パラメーターの詳細については、「CREATE TABLE」をご参照ください。
パーティションは、パーティションキー値によって降順にソートされます。 hot_partition_countパラメーターがNに設定されている場合、SSDに保存されている最初のN個のパーティションはホットパーティションであり、OSSに保存されている他のパーティションはコールドパーティションです。
たとえば、ホットパーティションの数が4に設定され、パーティションが、20201110、20201109、20201108、20201107、20201106、20201105、20201104の降順でパーティションキー値によってソートされていると仮定します。 この場合、最初の4つのパーティションはホットパーティションとして指定され、他のパーティションはコールドパーティションです。
ホットパーティションとコールドパーティションの分布は、次のシナリオで変更される可能性があります。
データが追加、変更、または削除されます。 詳細については、このトピックの「ホットパーティションとコールドパーティションの分散に対するデータ変更の影響」を参照してください。
ホットパーティションの数が変更されます。 詳細については、このトピックの「ホットパーティション数の変更がホットパーティションとコールドパーティションの分布に与える影響」を参照してください。
ホットパーティションとコールドパーティションの分布に対するデータ変更の影響
新しいパーティションが挿入されると、すべてのパーティションが再びソートされ、N個のホットパーティションのみが存在するようになります。
次の例では、新しいパーティション20201110がテーブルに挿入されます。 このパーティションは、テーブルのすべてのパーティションの中で最大のパーティションキー値を持ちます。 その結果、最小のパーティションキー値を有するパーティション20201105内のデータがホットパーティションからコールドパーティションに移行され、パーティション20201110内のデータがホットパーティションに移行される。
ホットパーティションとコールドパーティションの分布に対するホットパーティション量の変化の影響
ホットパーティションの数がNであり、ホットパーティションの数をMに変更するとします。
MがNより大きい場合、M − N個のパーティションのデータは、コールドパーティションからホットパーティションに移行される。
次の例では、ホットパーティションの数を5から6に変更します。 その結果、最大のパーティションキー値を有するパーティション20201104内のデータが、コールドパーティションからホットパーティションに移行される。
MがNより小さい場合、N − Mパーティションのデータは、ホットパーティションからコールドパーティションに移行される。
例えば、ホットパーティションの数が5から4に変更される。 その結果、最小のパーティションキー値を持つパーティション内のデータは、ホットパーティションからコールドパーティションに移行されます。
ホットとコールドのデータストレージの分布を照会する
table_usage
テーブルを使用して、ホットおよびコールドデータストレージの分布を照会できます。 例:
すべてのテーブルのホットおよびコールドデータストレージの分布を照会します。
select * from information_schema.table_usage;
特定のテーブルのホットおよびコールドデータストレージの分布を照会します。
select * from information_schema.table_usage where table_schema='<schema_name>' and table_name='<table_name>';
次の表に、table_usageテーブルに含まれるフィールドを示します。
項目 | 説明 |
table_schema | データベースの名前。 |
table_name | テーブルの名前。 |
storage_policy | ストレージポリシー。 有効な値:
|
hot_partition_count | ホットパーティションの数。 |
cold_partition_count | 冷たいパーティションの数。 |
rt_total_size | リアルタイムデータの総量。rt_data_sizeフィールドとrt_index_sizeフィールドの合計です。 単位:バイト |
rt_data_size | リアルタイムデータの量。 単位:バイト |
rt_index_size | リアルタイムデータでの主キーとインデックスデータの量。 単位:バイト |
hot_total_size | ホットパーティション内のデータの総量。hot_data_sizeフィールドとhot_index_sizeフィールドの合計です。 単位:バイト |
hot_data_size | ホットパーティション内のデータ量。 単位:バイト |
hot_index_size | ホットパーティション内の主キーとインデックスデータの量。 単位:バイト |
cold_total_size | コールドパーティション内のデータの総量。cold_data_sizeフィールドとcold_index_sizeフィールドの合計です。 単位:バイト |
cold_data_size | コールドパーティションのデータ量。 単位:バイト |
cold_index_size | コールドパーティション内の主キーとインデックスデータの量。 単位:バイト |
注:
table_usageテーブルはリアルタイムで更新されます。 rt_total_size、rt_data_size、rt_index_size、hot_total_size、hot_data_size、hot_index_size、cold_total_size、cold_data_size、およびcold_index_sizeフィールドの値は、INSERT、UPDATE、DELETE、およびBUILDステートメントの実行によって異なります。
データがロードされた後、hot_total_sizeフィールドとcold_total_sizeフィールドの値が両方とも0の場合、データはリアルタイムエンジンに保存されたままであり、rt_total_sizeフィールドの値はリアルタイムデータの量を示します。 次のBUILDステートメントを実行して、リアルタイムデータをパーティション分割されたデータに変換し、hot_total_sizeおよびcold_total_sizeフィールドの値を照会できます。
build table <table_name>;
ユーザー定義のhot_partition_countフィールドは、リストパーティション分割後の単一のシャード内のホットパーティションの数を示します。一方、table_usageテーブルから照会されたhot_partition_countフィールドは、シャードが結合された後のホットパーティションの数を示します。 データパーティションがシャード間で異なる方法で分散されている場合、table_usageテーブルから照会されるhot_partition_countフィールドの値は、ユーザー定義のhot_partition_countフィールドの値よりも大きくなる可能性があります。
たとえば、テーブルAがShard1およびShard2を含み、hot_partition_countが2に設定されると仮定する。 次の図は、表Aのデータパーティションの分布を示しています。
シャード1: P4とP5はホットパーティションです。 P1、P2、およびP3は低温区画である。
シャード2: P3とP4はホットパーティションです。 P1およびP2は低温区画である。
ホットパーティションの実際の数は、以下の式を使用することによって計算される。ユニオン (P3, P4) = (P3, P4, P5) 。 したがって、hot_partition_countの実際の値は3です。
ストレージポリシーの変更の進行状況を照会する
ALTER TABLE
文を実行して、テーブルのストレージポリシーを変更できます。 詳細については、「ALTER TABLE」をご参照ください。 storage_policy_modify_progress
テーブルを使用して、ストレージポリシーの変更の進行状況を照会できます。
現在のクラスターに含まれるすべてのテーブルのストレージポリシーの変更の進行状況を照会します。
select * from information_schema.storage_policy_modify_progress;
特定のテーブルのストレージポリシーの変更の進行状況を照会します。
select * from information_schema.storage_policy_modify_progress where table_schema='<schema_name>' and table_name='<table_name>';
次の表に、storage_policy_modify_progress
テーブルに含まれるフィールドを示します。
項目 | 説明 |
table_schema | データベースの名前。 |
table_name | テーブルの名前。 |
task_id | ストレージポリシー変更ジョブのID。 |
source_storage_policy | 元のストレージポリシー。 有効な値:
|
source_hot_partition_count | 元のホットパーティションの数。 |
dest_storage_policy | 新しいストレージポリシー。 有効な値:
|
dest_hot_partition_count | 新しいホットパーティションの数。 |
hot_to_cold_partition_count | ホットストレージからコールドストレージに変更されるパーティションの数。 |
cold_to_hot_partition_count | コールドストレージからホットストレージに変更されるパーティションの数。 |
hot_to_cold_data_size | ホットストレージからコールドストレージに変更されるデータの量。 単位:バイト |
cold_to_hot_data_size | コールドストレージからホットストレージに変更されるデータの量。 単位:バイト |
hot_data_size_before_change | ストレージポリシーが変更される前のホットデータの量。 単位:バイト |
cold_data_size_before_change | ストレージポリシーが変更される前のコールドデータの量。 単位:バイト |
hot_data_size_after_change | ストレージポリシーが変更された后のホットデータの量。 単位:バイト |
cold_data_size_after_change | ストレージポリシーが変更された後のコールドデータの量。 単位:バイト |
start_time | ストレージポリシーが変更される時間範囲の開始。 |
update_time | ストレージポリシーが変更される時間範囲の終了。 |
progress | ストレージポリシーの変更の進行状況。 単位: % 。 |
status | ストレージポリシーの変更ステータス。 有効な値:
|