データスキュー、不合理なパーティションフィールド、過剰なインデックスなどのテーブルの問題が発生した場合、AnalyticDB for MySQL コンソールの [ストレージ診断] ページで、パーティションフィールドの合理性、分散フィールドの合理性、レプリケートされたテーブルの合理性に関する診断を実行できます。また、ホットデータとコールドデータの最適化の提案やインデックスの最適化の提案を使用してスキーマの最適化を実行し、コストを削減して効率を向上させることもできます。
使用上の注意
V3.1.4 以降の AnalyticDB for MySQL クラスターのみが、インデックス診断とホットデータおよびコールドデータの最適化機能をサポートします。
ホットデータとコールドデータの最適化の提案、およびインデックスの最適化の提案は、既存データとクエリ特性の分析から得られます。データとクエリ特性が安定している場合、関連する提案は有効なままです。データとクエリ特性が大幅に変化した場合、提案の参考としての価値が低くなる可能性があります。ビジネス特性に基づいて提案を採用するかどうかを判断することをお勧めします。
テーブル診断
テーブルスキュー診断
テーブルを作成する際に、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 文を実行して手動でストレージポリシーを変更します。詳細については、「ストレージポリシー」をご参照ください。
最適化の提案を採用することに同意する場合は、[適用] をクリックします。テーブルに対して [適用] をクリックすると、クラスターで ALTER 文が実行され、提案が [適用済みの最適化の提案] タブに表示されます。
[適用] 操作は、クライアントで ALTER 文を実行するのと同じ効果があります。この操作は元に戻せません。注意して実行してください。
SQL 文の実行による最適化の提案の適用は、テーブルで自動的にトリガーされる BUILD 操作が完了した後にのみ完了します。BUILD 操作がトリガーされる前は、提案は実行中状態です。BUILD 操作がトリガーされると、提案のステータスが完了に変わります。
レプリケートされたテーブルの診断
AnalyticDB for MySQL では、DISTRIBUTED BY BROADCAST 句を使用してレプリケートされたテーブルを作成できます。レプリケートされたテーブルは、各シャードにデータの同一コピーを格納します。クエリワークロードに、大きいテーブルと小さいテーブル (たとえば、大きいテーブル A と小さいテーブル B の結合) との間の頻繁で高同時実行の結合が含まれる場合、小さいテーブルをレプリケートされたテーブルにすることができます。これにより、内部クラスターネットワークを介した小さいテーブルのデータ転送が削減され、同時実行パフォーマンスが向上します。ただし、レプリケートされたテーブルは書き込みパフォーマンスが低く、大量のストレージ領域を消費するため、AnalyticDB for MySQL クラスターの全体的な書き込みパフォーマンスに影響を与える可能性があります。
診断基準
レプリケートされたテーブルに 20,000 レコードを超えるレコードが含まれている場合、そのテーブルは不合理であると見なされます。
手順
AnalyticDB for MySQL コンソールにログインします。コンソールの左上隅で、リージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。管理するクラスターを見つけて、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 をクリックします。
テーブル診断 タブで、 レプリケーションテーブル診断 をクリックします。
最適化メソッド
標準テーブルを作成し、データを移行する必要があります。詳細については、「CREATE TABLE」をご参照ください。
パーティション診断
パーティションテーブルの診断
不合理なパーティションフィールドを含むパーティションテーブルを作成すると、次の問題が発生します:
パーティションに大量のデータが含まれ、そのパーティションで BUILD ジョブが実行される場合、ジョブの完了までに長時間を要し、ストレージノードのかなりの CPU およびディスク I/O リソースを消費する可能性があります。たとえば、テーブルが年ごとにパーティション分割され、各パーティションに大量のデータが含まれている場合、クラスターの安定性に影響します。
パーティションに少量のデータしか含まれていない場合、クラスターは多くのパーティションの情報をキャッシュし、かなりのメモリリソースを消費する可能性があります。たとえば、テーブルが時間ごとにパーティション分割され、各パーティションに少量のデータしか含まれていない場合、多くのパーティションがスキャンされ、クエリパフォーマンスに影響します。
合理的なパーティションサイズの基準
パーティションサイズとは、テーブルのパーティション内の行数 1 を指し、これはシャードの数 2 に比例します。N 個のシャードを持つテーブルの場合、パーティション内の行数が 1,000,000 × N から 5,000,000 × N の範囲内であれば、パーティションサイズは合理的であると見なされます。
たとえば、テーブル内のシャード数が 64 の場合、パーティション内の行数が 6,400 万から 3 億 2,000 万の範囲内であれば、パーティションサイズは合理的です。
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,000 万です。パーティション行数が 6,400 万未満の場合、パーティションサイズは過度に小さいです。粒度を日から月に変更することをお勧めします。
テーブルのパーティション内の行数が合理的な範囲の上限を超えている場合、パーティションサイズは過度に大きいと見なされます。パーティションの粒度を下げることをお勧めします。たとえば、シャード数が 64 の場合、パーティション行の合理的な範囲は 6,400 万から 3 億 2,000 万です。パーティション行数が 3 億 2,000 万を超える場合、パーティションサイズは過度に大きいです。粒度を月から日に変更することをお勧めします。
パーティションの粒度を変更する方法の詳細については、「パーティション関数フォーマットの変更」をご参照ください。
パーティションテーブル内の総行数が合理的な範囲の下限に達しておらず、達する見込みもない場合は、非パーティションテーブルを作成し、パーティションテーブルから非パーティションテーブルにデータを移行できます。
非パーティションテーブルの診断
テーブルを作成する際に PARTITION BY 句を指定しない場合、そのテーブルは非パーティションテーブルになります。非パーティションテーブルに対して DML 操作 (INSERT、UPDATE、DELETE) を実行すると、全テーブルの 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
最適化の提案に従って変更する必要があるテーブルと対応する定義。
最適化タイプ
インデックスの最適化。
最適化の提案
最適化タイプに対して与えられた具体的な最適化の提案。
期待される最適化のメリット
最適化の提案が適用された後に得られる期待されるメリット。
説明期待される最適化のメリットは、既存データに基づいて測定された推定値であり、参考用です。
アクション
[適用] をクリックして、テーブルの最適化の提案を適用できます。
説明データインデックスを削除すると、インデックスで参照されているデータを使用してテーブルをフィルタリングするのに時間がかかります。
最適化の提案を採用することに同意する場合は、[適用] をクリックします。テーブルに対して [適用] をクリックすると、クラスターで ALTER 文が実行され、提案が [適用済みの最適化の提案] タブに表示されます。
[適用] 操作は、クライアントで ALTER 文を実行するのと同じ効果があります。この操作は元に戻せません。注意して実行してください。
SQL 文の実行による最適化の提案の適用は、テーブルで自動的にトリガーされる BUILD 操作が完了した後にのみ完了します。BUILD 操作がトリガーされる前は、提案は実行中状態です。BUILD 操作がトリガーされると、提案のステータスが完了に変わります。
プライマリキー診断
診断基準
テーブルに 3 つ以上のプライマリキーフィールドがあり、プライマリキーフィールドの数がテーブル内のフィールド数の半分に達する場合、テーブルのプライマリキーは過剰であると見なされます。
手順
AnalyticDB for MySQL コンソールにログインします。コンソールの左上隅で、リージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。管理するクラスターを見つけて、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、 をクリックします。
インデックス診断 タブをクリックし、 プライマリキー過剰の診断 の詳細を表示します。
利用可能な最適化提案 タブで、右上隅にある [有効化] をクリックして、インデックス診断機能を有効にします。現在のクラスターでこの機能がすでに有効になっている場合は、このステップをスキップできます。
利用可能な最適化提案 タブと 推奨事項の採用 タブをクリックして、それぞれの提案を表示します。
パラメーター
説明
提案 ID
最適化の提案の ID。
SQL
最適化の提案に従って変更する必要があるテーブルと対応する定義。
最適化タイプ
インデックスの最適化。
最適化の提案
最適化タイプに対して与えられた具体的な最適化の提案。
期待される最適化のメリット
最適化の提案が適用された後に得られる期待されるメリット。
説明期待される最適化のメリットは、既存データに基づいて測定された推定値であり、参考用です。
アクション
[適用] をクリックして、テーブルの最適化の提案を適用できます。
説明データインデックスを削除すると、インデックスで参照されているデータを使用してテーブルをフィルタリングするのに時間がかかります。
最適化の提案を採用することに同意する場合は、[適用] をクリックします。テーブルに対して [適用] をクリックすると、クラスターで ALTER 文が実行され、提案が [適用済みの最適化の提案] タブに表示されます。
[適用] 操作は、クライアントで ALTER 文を実行するのと同じ効果があります。この操作は元に戻せません。注意して実行してください。
SQL 文の実行による最適化の提案の適用は、テーブルで自動的にトリガーされる BUILD 操作が完了した後にのみ完了します。BUILD 操作がトリガーされる前は、提案は実行中状態です。BUILD 操作がトリガーされると、提案のステータスが完了に変わります。
よくある質問
関連する操作
API | 説明 |
AnalyticDB for MySQL Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスターで、過剰なプライマリキーフィールドを持つテーブルに関する情報をクエリします。 | |
AnalyticDB for MySQL Data Warehouse Edition クラスターのパーティション診断に関する情報をクエリします。 |