AnalyticDB for MySQL:ホットとコールドのデータストレージの分離

AnalyticDB for MySQLクラスターは、次の要件を満たす必要があります。

• クラスターは [クラスターエディション] になっています。

• クラスターのマイナーエンジンバージョンは3.1.3.3以降です。

  説明

  • AnalyticDB For MySQLクラスターのバージョンを表示する方法については、AnalyticDB for MySQLクラスターのバージョンを表示するにはどうすればよいですか?

  • AnalyticDB for MySQLクラスターのバージョンを更新するには、 チケットを起票し、更新の時間枠を指定します。 エンジンバージョンの更新が完了するまでに約20分かかる場合があります。 更新中、クラスターは正常に実行できますが、数回中断されることがあります。 オフピーク時にクラスターのエンジンバージョンを更新し、アプリケーションをデータベースシステムに自動的に再接続できるようにすることをお勧めします。

AnalyticDB for MySQLには、コールドストレージ、ホットストレージ、混合ストレージの3つのポリシーが用意されています。

• コールドストレージは、費用対効果の高いストレージポリシーです。 このストレージポリシーを使用すると、すべてのデータがObject storage Service (OSS) に保存されます。

• ホットストレージは、高いアクセスパフォーマンス要件を満たすことができるストレージポリシーです。 このストレージポリシーを使用すると、すべてのデータがSSDに保存されます。

• 混合ストレージは、指定されたパーティションをSSDに保存し、他のパーティションをOSSに保存できるようにするストレージポリシーです。

ホットパーティションとコールドパーティションの分布は、次のシナリオで変更される可能性があります。

• データが追加、変更、または削除されます。 詳細については、このトピックの「ホットパーティションとコールドパーティションの分散に対するデータ変更の影響」を参照してください。

• ホットパーティションの数が変更されます。 詳細については、このトピックの「ホットパーティション数の変更がホットパーティションとコールドパーティションの分布に与える影響」を参照してください。

次の例では、新しいパーティション20201110がテーブルに挿入されます。 このパーティションは、テーブルのすべてのパーティションの中で最大のパーティションキー値を持ちます。 その結果、最小のパーティションキー値を有するパーティション20201105のデータがホットパーティションからコールドパーティションに移動され、パーティション20201110のデータがホットパーティションに移動される。

ホットパーティションの数がNであり、ホットパーティションの数をMに変更するとします。

• MがNより大きい場合、M-Nパーティションのデータは、コールドパーティションからホットパーティションに移行される。

  次の例では、ホットパーティションの数を5から6に変更します。 その結果、最大のパーティションキー値を有するパーティション20201104のデータが、コールドパーティションからホットパーティションに移行される。

• MがN未満の場合、N-Mパーティションのデータはホットパーティションからコールドパーティションに移行されます。

  例えば、ホットパーティションの数が5から4に変更される。 その結果、最小のパーティションキー値を有するパーティションのデータは、ホットパーティションからコールドパーティションに移行される。

table_usageテーブルを使用して、ホットおよびコールドデータストレージの分布を照会できます。 例：

• すべてのテーブルのホットおよびコールドデータストレージの分布を照会します。

  information_schema.table_usageから * を選択します。

• 特定のテーブルのホットおよびコールドデータストレージの分布を照会します。

  select * from information_schema.table_usage where table_schema='<schema_name>' およびtable_name='<table_name>';

次の表に、table_usageテーブルに含まれるフィールドを示します。

注：

• 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の値を照会できます。

  ビルドテーブル <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テーブルに含まれるフィールドを示します。