ストレージ診断機能を使用すると、AnalyticDB for MySQL クラスター内のデータスキュー、非効率なパーティションキー、過剰なインデックス、その他のテーブル構成上の問題を特定できます。ストレージ診断 ページでは、パーティションキー、分散キー、およびレプリケートされたテーブルの適切性を評価できます。また、コールド・ホットデータ分離の機会を特定し、インデックス最適化の提案を受け取ることも可能です。これらの提案を適用することで、データベーススキーマを最適化し、クラスターのコストを削減して効率を向上させることができます。
重要な注意事項
コールド・ホットテーブル最適化およびインデックス診断は、Milvus バージョン 3.1.4 以降を実行しているクラスターでのみサポートされています。
コールド・ホットテーブル最適化およびインデックス診断に関する最適化の提案は、過去のデータとクエリパターンの分析に基づいて生成されます。これらの提案は、データおよびクエリパターンが安定している限り有効です。これらのパターンが大きく変化した場合、提案の有効性は低下します。この機能を使用する前に、現在のビジネスワークロードに基づいて提案を適用するかどうかを評価してください。
テーブル診断
データスキュー診断
テーブルを作成する際、DISTRIBUTED BY HASH を使用して分散キーを指定します。分散キーを定義すると、AnalyticDB for MySQL は分散キーの値のハッシュを計算し、行を異なる シャード に分散します。ストレージノード間でデータ分布が不均等になると、ディスク領域の偏りが発生し、ディスクが早期に満杯になり、データ書き込みがブロックされる可能性があります。
診断基準
AnalyticDB for MySQL は、10,000 行を超えるテーブルに対してデータスキューを診断します。計算方法は以下のとおりです。
最大のシャードを除外し、平均シャードサイズを算出します。
いずれかのシャードが
平均シャードサイズ × しきい値より大きいか、または平均シャードサイズ / しきい値より小さい場合、そのテーブルはスキューしているとみなされます。デフォルトのしきい値は 3 であり、有効範囲は [0, 10000000000] です。次のコマンドを実行して、しきい値を調整できます：SET ADB_CONFIG RC_DATA_SKEW_THRESHOLD=Value;。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[テーブル診断] タブをクリックし、[テーブルスキュー診断] セクションの詳細を表示します。
ストレージノードディスク使用率
チャートを使用して、ストレージノード間のディスク使用率を確認し、ディスク領域の偏りを特定します。偏りが存在する場合は、[Top10 スキューテーブル] にリストされているスキューしているテーブルを最適化してください。ディスク領域がバランスよく見える場合でも、[Top10 スキューテーブル] にスキューしているテーブルが表示されている場合は、クラスターのクエリパフォーマンスが低下しないようにそれらを最適化してください。
Top10 スキューテーブル
このセクションには、データスキューが発生しているテーブルが、合計データ量の降順でリストされます。各シャードごとの行数を確認し、スキューの深刻度を評価するには、[操作] 列の [チルト詳細の表示] をクリックします。
最適化方法
この問題は、以下のいずれかの方法で解決できます。
ストレージ容量をスケールアウトします。
Enterprise Edition クラスターでは、予約済みリソースのスケーリングが必要です。詳細については、「Enterprise Edition クラスターのスケーリング」をご参照ください。
Basic Edition クラスターでは、計算リソースのスケーリングが必要です。詳細については、「Basic Edition クラスターのスケーリング」をご参照ください。
Data Lakehouse Edition クラスターでは、予約済みストレージリソースのスケーリングが必要です。詳細については、「Data Lakehouse Edition クラスターのスケーリング」をご参照ください。
Data Warehouse Edition (elastic mode) クラスターでは、エラスティック I/O ユニットのスケーリングが必要です。詳細については、「Data Warehouse Edition (elastic mode) クラスターのスケーリング」をご参照ください。
Data Warehouse Edition (reserved mode) クラスターでは、ノードグループのスケーリングが必要です。詳細については、「Data Warehouse Edition (reserved mode) クラスターのスケーリング」をご参照ください。
アイドル状態のインデックスやパーティションを削除して、ストレージ使用量を削減します。詳細については、「インデックス診断」をご参照ください。
テーブルを再作成し、データを移行します。詳細については、「CREATE TABLE」をご参照ください。
コールド・ホットテーブル最適化
AnalyticDB for MySQL はテーブルのアクセス頻度を分析し、アクセス頻度が低いテーブルを特定して最適化の提案を行います。これらの提案を適用することで、テーブルのコールド・ホットデータ分離ポリシーを調整できます。コールド・ホットデータ分離の詳細については、「コールド・ホットデータ分離」をご参照ください。
診断基準
AnalyticDB for MySQL は、直近 15 日間アクセスされておらず、かつアクセス率が 1 % 未満のテーブルに対して最適化の提案を行います。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[テーブル診断] タブで、[ホットテーブルとコールドテーブルの最適化] をクリックします。
[利用可能な最適化提案] タブで、[閉じる] をクリックして、コールド・ホットテーブル最適化機能を有効にします。現在のクラスターでこの機能がすでに有効になっている場合は、このステップをスキップできます。
[利用可能な最適化提案] および [推奨事項の採用] タブをクリックして、利用可能および適用済みの提案を表示します。
パラメーター
説明
提案id
最適化の提案の ID です。
Sql
提案に必要なテーブルおよび定義の変更内容です。
最適化タイプ
コールド・ホットテーブル最適化
特定の最適化の提案
最適化タイプに関する詳細な推奨事項です。
期待最適化利点
提案を適用した後の期待されるメリットです。
説明期待されるメリットは、過去の統計情報に基づく推定値であり、リアルタイムの正確な値ではありません。参考情報としてご利用ください。
特定の運用ガイドライン
現在の提案は、ワンクリックアプリケーション を使用して適用できます。
説明[ワンクリックアプリケーション] をクリックすると、AnalyticDB for MySQL はテーブルのストレージポリシーを COLD に変更します。これを MIXED または HOT に変更するには、手動で ALTER 文を実行する必要があります。詳細については、「ストレージポリシー」をご参照ください。
[ワンクリックアプリケーション] をクリックして、最適化の提案を採用します。[ワンクリックアプリケーション] をクリックすると、対応するクラスターが SQL 変更を実行し、この提案は [推奨事項の採用] タブに表示されます。
[ワンクリックアプリケーション] は、クライアントで SQL を実行するのと同じ効果があります。この操作は取り消せません。慎重に実行してください。
SQL が発行された後、変更を有効にするにはテーブルが Build 操作を完了する必要があります。データベースシステムは内部ルールに基づいて自動的に Build をトリガーします。トリガーされるまでは、提案のステータスは「実行中」のままです。トリガーされると、「完了済み」に変更されます。
レプリケートされたテーブル診断
AnalyticDB for MySQL でテーブルを作成する際、DISTRIBUTED BY BROADCAST を使用してブロードキャストディストリビューションを指定できます。これにより、テーブルはレプリケートされたテーブルとして作成され、各シャードにデータの同一コピーが格納されます。クエリワークロードで大規模なファクトテーブルと小規模なディメンションテーブルを結合するなど、大規模テーブルと小規模テーブルの高同時実行結合が発生する場合、小規模なテーブルをレプリケートされたテーブルとして作成できます。これにより、クラスターの内部ネットワーク経由でのデータ転送を削減し、クエリの同時実行数を向上させることができます。ただし、レプリケートされたテーブルは書き込み性能が低く、大量のストレージ領域を消費するため、AnalyticDB for MySQL クラスター全体の書き込み性能に悪影響を及ぼす可能性があります。
診断基準
レプリケートされたテーブルが 20,000 行を超える場合、非効率であるとみなされます。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[テーブル診断] タブで、[レプリケーションテーブル診断] をクリックします。
最適化方法
標準テーブルを作成し、データを移行します。詳細については、「CREATE TABLE」をご参照ください。
パーティション診断
パーティションテーブル診断
パーティションテーブルを作成する際にパーティションフィールドを正しく設定しないと、以下の問題が発生する可能性があります。
パーティションが大きすぎる場合（例：年単位のパーティションで、各年のデータが 1 つのパーティションに格納される）は、パーティション数が少なく、各パーティションのデータ量が非常に大きくなります。このようなパーティションで Build タスクが実行されると、ストレージノードの CPU やディスク I/O などのリソースを過剰に消費し、クラスターの安定性に影響を及ぼします。
パーティションが小さすぎる場合（例：時間単位のパーティションで、各時間のデータが 1 つのパーティションに格納される）は、パーティション数が多くなり、各パーティションに含まれるデータが最小限になります。クラスターは大量のパーティションメタデータをキャッシュする必要があり、大量のメモリを消費します。また、クエリ時に多数のパーティションをスキャンする必要があるため、クエリパフォーマンスが低下します。
適切なパーティションサイズとは
パーティションサイズは行数1で測定され、シャード数2に比例してスケーリングされます。クラスターに N 個のシャードがある場合、適切なパーティションサイズは [100 万 × N] ～ [500 万 × N] 行の範囲です。
たとえば、クラスターに 64 個のシャードがある場合、適切なパーティションの行数は 6,400 万 ～ 3.2 億 の範囲です。
1パーティションの行数をクエリするには、次のコマンドを実行します：
SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;2シャード数をクエリするには、次のコマンドを実行します：
SELECT COUNT(1) FROM information_schema.kepler_meta_shards;
パーティションフィールドが適切かどうかを診断する方法
診断基準
テーブル内の 10 % 以上のパーティションが適切でないサイズの場合、そのパーティションフィールドは不適切であるとみなされます。
たとえば、テーブルに 100 個のパーティションがあり、そのうち 10 個以上が適切でないサイズの場合、そのパーティションフィールドは不適切とフラグ付けされます。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[パーティション診断] タブをクリックし、[パーティションテーブルの診断] セクションで、不適切なパーティションテーブルおよびその具体的なパーティション名を表示します。
パーティションサイズを適切な範囲に調整する方法
パーティション診断ツールが不適切なパーティションを特定した場合、以下の方法で調整できます。
パーティションの行数が適切な範囲の下限を下回っている場合、そのパーティションは小さすぎます。この場合、パーティションの粒度を粗くできます。たとえば、クラスターに 64 個のシャードがある場合、適切な範囲は 6,400 万 ～ 3.2 億 行です。パーティションの行数が 6,400 万未満の場合、パーティションを日単位から月単位に変更できます。
パーティションの行数が推奨上限を超えている場合、そのパーティションは大きすぎるとみなされ、粒度を細かくする必要があります。たとえば、64 個のシャードがある場合、パーティションあたりの推奨行数は 6,400 万 ～ 3.2 億 の範囲です。パーティションの行数が 3.2 億を超える場合、パーティションを月単位から日単位に変更することを推奨します。
パーティションの粒度を変更する方法の詳細については、「パーティション関数のフォーマット変更」をご参照ください。
テーブルの合計行数が適切な範囲の下限を下回っており、今後その範囲内に到達する見込みがない場合、非パーティション化テーブルを作成し、パーティションテーブルからデータを移行できます。
非パーティション化テーブル診断
テーブル作成時に PARTITION BY 句を省略すると、そのテーブルは非パーティション化テーブルとして作成されます。非パーティション化テーブルに対する INSERT、UPDATE、DELETE などの DML 操作は、多くの場合、フルテーブルの Build タスクをトリガーします。テーブルに大量のデータが含まれている場合、これらの Build タスクは大量の一時ディスク領域を消費し、ノードのディスク使用率を増加させてディスクをロックさせる可能性があります。大規模なテーブルでの Build タスクは、ディスク I/O や CPU リソースを大量に消費し、クラスター全体のパフォーマンスを低下させます。
診断基準
非パーティション化テーブルが 10 億行を超える場合、非効率であるとみなされます。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[パーティション診断] タブをクリックし、[非パーティションテーブル診断] 情報を表示します。
最適化方法
パーティションテーブルを作成し、非パーティション化テーブルからデータを移行します。詳細については、「CREATE TABLE」をご参照ください。
インデックス診断
AnalyticDB for MySQL はインデックスの使用状況を分析し、長期間使用されていないインデックスに対して自動的に最適化の提案を行います。これらの提案を適用することで、アイドル状態のインデックスを削除し、ストレージコストを削減できます。
アイドルインデックス診断
診断基準
直近 15 日間使用されておらず、かつ使用率が 1 % 未満のインデックスは、アイドル状態であるとみなされます。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[インデックス診断] タブをクリックし、[インデックスの削除提案] の詳細を表示します。
[利用可能な最適化提案] タブで、[オープン] をクリックしてインデックス診断を有効にします。この機能がすでに有効になっている場合は、このステップをスキップできます。
[利用可能な最適化提案] および [推奨事項の採用] タブをクリックして、利用可能および適用済みの提案を表示します。
パラメーター
説明
提案id
最適化の提案の ID です。
Sql
提案に必要なテーブルおよび定義の変更内容です。
最適化タイプ
インデックス最適化
特定の最適化の提案
最適化タイプに関する詳細な推奨事項です。
期待最適化利点
提案を適用した後の期待されるメリットです。
説明期待されるメリットは、過去の統計情報に基づく推定値であり、リアルタイムの正確な値ではありません。参考情報としてご利用ください。
特定の運用ガイドライン
現在の提案は、ワンクリックアプリケーション を使用して適用できます。
説明インデックスを削除した後、そのカラムでフィルターをかけるクエリの実行時間が長くなります。
[ワンクリックアプリケーション] は、この最適化の提案を採用することに同意することを示します。[ワンクリックアプリケーション] をクリックすると、対応するクラスターが SQL 変更を実行し、この提案は [推奨事項の採用] タブに表示されます。
[ワンクリックアプリケーション] は、クライアントで SQL を実行するのと同じ効果があります。この操作は取り消せません。慎重に実行してください。
SQL が発行された後、変更を有効にするにはテーブルが Build 操作を完了する必要があります。データベースシステムは内部ルールに基づいて自動的に Build をトリガーします。トリガーされるまでは、提案のステータスは「実行中」のままです。トリガーされると、「完了済み」に変更されます。
新規インデックス診断
診断基準
この診断では、直近 15 日間にクエリでフィルターとして使用されたが、インデックスフィールドとして定義されていないフィールドを特定します。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[インデックス診断] タブをクリックし、[インデックス作成の提案] の詳細を表示します。
[利用可能な最適化提案] タブで、[オープン] をクリックしてインデックス診断を有効にします。この機能がすでに有効になっている場合は、このステップをスキップできます。
[利用可能な最適化提案] および [推奨事項の採用] タブをクリックして、利用可能および適用済みの提案を表示します。
パラメーター
説明
提案id
最適化の提案の ID です。
インデックスフィールド
インデックスとして追加するフィールドです。
Sql
インデックスを作成する SQL ステートメントです。
最適化タイプ
インデックス作成の提案
特定の最適化の提案
フィールドが最近どのくらいの頻度で使用されたかを記述し、インデックスフィールドとしての可能性を示します。
現在の提案を [インデックスを一括作成] を使用して適用できます。
説明[インデックス作成の提案] の後、変更を有効にするにはテーブルが Build 操作を完了する必要があります。データベースシステムは内部ルールに基づいて自動的に Build をトリガーします。トリガーされるまでは、提案のステータスは「実行中」のままです。トリガーされると、「完了済み」に変更されます。
プライマリキーインデックス診断
診断基準
テーブルに 3 つを超えるプライマリキーフィールドがあり、かつこれらのフィールドがテーブルの全フィールドの半分以上を占める場合、そのテーブルはプライマリキーが過剰であるとみなされます。
操作手順
AnalyticDB for MySQL コンソール にログインします。コンソールの左上隅でリージョンを選択し、左側のナビゲーションウィンドウで クラスターリスト をクリックします。管理対象のクラスターを見つけ、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
[インデックス診断] タブをクリックし、[プライマリキー過剰の診断] の詳細を表示します。
[利用可能な最適化提案] タブで、[オープン] をクリックしてインデックス診断を有効にします。この機能がすでに有効になっている場合は、このステップをスキップできます。
プライマリキーが過剰なテーブルを表示します。テーブルには、[データベース]、[テーブル名]、[テーブルフィールド数]、および [プライマリキーフィールド数] の列が表示されます。
よくある質問
コールド・ホットテーブル最適化の提案に対して [今すぐ適用] をクリックしても、最適化タスクのステータスが「実行中」のままになるのはなぜですか？
原因：[ワンクリックアプリケーション] をクリックすると、AnalyticDB for MySQL はテーブルのストレージポリシーを COLD に変更します。この変更を有効にするには Build 操作が必要です。コールド・ホット最適化機能は、Build タスクを即座にトリガーしません。システムは後ほど自動的にこのタスクをトリガーします。
解決策：システムが自動的に Build タスクをトリガーするのを待つか、コンソールから Build タスクをトリガーする SQL 文をコピーして手動で実行できます。Build タスクが実行された後、次のコマンドを実行してそのステータスを確認できます：SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK ORDER BY create_time DESC LIMIT 10;。
関連 API
API | 説明 |
Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスターでプライマリキーが過剰なテーブルを表示します。 | |
Data Warehouse Edition クラスターのパーティション診断を表示します。 |