AnalyticDB:ホットデータとコールドデータの階層ストレージ

ホットデータとコールドデータの階層ストレージを使用する前に、次の要件が満たされていることを確認してください。

• elastic mode for cluster EditionのAnalyticDB for MySQLクラスターが作成されます。

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

  説明

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

  • AnalyticDB for MySQLクラスターのマイナーバージョンを更新するには、

    チケットを起票し、更新の時間枠を指定します。 マイナーバージョンの更新が完了するまでに約20分かかる場合があります。 更新中、クラスターは期待どおりに実行できますが、一時的な接続が数回発生する可能性があります。 オフピーク時にクラスターのマイナーバージョンを更新し、アプリケーションがクラスターに自動的に再接続するように設定されていることを確認することをお勧めします。

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

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

  説明

  AnalyticDB for MySQLは、ローカル冗長ストレージ (LRS) モードでコールドデータをOSSに保存します。

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

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

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

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

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

次の例では、新しいパーティション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_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テーブルに含まれるフィールドを示します。