ストレージ診断 - AnalyticDB - Alibaba Cloud ドキュメントセンター

データスキュー、不当なパーティションフィールド、過剰なインデックスなどのテーブルの問題が発生した場合、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 スキューテーブル
このセクションでは、合計データサイズに基づいて降順にソートされたスキューテーブルを表示します。テーブルを見つけて、[操作] 列の チルト詳細の表示 をクリックすると、各シャードのテーブルの行数を表示して、テーブルのスキューの程度を判断できます。

最適化方法

次のいずれかの方法を使用して問題を解決できます。

ストレージ容量を増やします。
- AnalyticDB For MySQL Data Lakehouse Editionクラスターの場合、予約済みストレージリソースをスケールアップおよびアウトします。詳細については、「データLakehouse Editionクラスターのスケール」トピックの「クラスターのスケールアップ」セクションをご参照ください。
- エラスティックモードのAnalyticDB For MySQL Data Warehouse Editionクラスターの場合、エラスティックI/Oリソースをスケールアウトします。詳細については、「データウェアハウスエディションクラスターのスケール」トピックの「エラスティックモードでクラスターをスケールする」をご参照ください。
- 予約モードのAnalyticDB For MySQL Data Warehouse Editionクラスターの場合、ノードグループをスケールアップおよびアウトします。詳細については、「データウェアハウスエディションクラスターのスケール」トピックの「予約モードでクラスターをスケールする」をご参照ください。
アイドルインデックスまたはパーティションを削除して、ストレージ使用量を減らします。詳細については、このトピックの「インデックス診断」セクションをご参照ください。
テーブルを作成し、データをテーブルに移行します。詳細については、「CREATE TABLE」をご参照ください。

ホットテーブルとコールドテーブルの最適化

AnalyticDB for MySQLは、テーブルのアクセス回数を分析し、アクセス頻度の低いテーブルの最適化の提案を提供します。最適化の提案に基づいて、テーブルのホットデータとコールドデータのストレージポリシーを変更できます。詳細については、「ホットとコールドのデータストレージの分離」をご参照ください。

診断基準

AnalyticDB for MySQLは、過去15日以内にアクセスされず、アクセス率が1% 未満のホットテーブルに関する最適化の提案を提供します。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
テーブル診断 タブをクリックし、 ホットテーブルとコールドテーブルの最適化 タブをクリックします。
利用可能な最適化提案 セクションで、[有効化] をオンにして、ホットテーブルとコールドテーブルの最適化機能を有効にします。クラスターでホットテーブルとコールドテーブルの最適化機能がすでに有効になっている場合は、この手順をスキップできます。

利用可能な最適化提案 および 推奨事項の採用 セクションで、利用可能な最適化の提案を表示します。

パラメーター	説明
提案ID	最適化の提案のID。
SQL	変更するテーブルの詳細情報を指定するSQL文。
最適化タイプ	最適化のタイプ。このパラメーターは、ホットおよびコールドデータ最適化に設定されます。
最適化の提案	最適化タイプに対して与えられる特定の最適化提案。
期待される最適化の利点	最適化提案の後に得られる期待される利益が適用される。説明期待される最適化の利点は、履歴データに基づいて参照のみのために測定された推定値です。
操作	[適用] をクリックすると、テーブルに最適化の提案を適用できます。説明 [Apply] をクリックすると、AnalyticDB for MySQLがテーブルのストレージポリシーをCOLDに変更します。ストレージポリシーをMIXEDまたはHOTに変更する場合は、ALTERステートメントを実行して、ストレージポリシーを手動で変更します。詳細については、ALTER TABLEトピックの「ストレージポリシー」セクションをご参照ください。最適化の提案を採用することに同意した場合は、[適用] をクリックします。テーブルに対して [Apply] をクリックすると、ALTERステートメントがクラスターで実行され、提案が [Applied Optimization Suggestions] タブに表示されます。 Apply操作は、クライアントでALTERステートメントを実行するのと同じ効果があります。この操作は取り消すことができません。作業は慎重に行ってください。 SQLステートメントの実行を伴う最適化提案の適用は、テーブル上で自動的にトリガされるBUILD操作が完了した後にのみ完了することができる。 BUILD操作がトリガーされる前は、提案は実行中状態です。 BUILD操作がトリガーされた後、提案のステータスは完了に変わります。

レプリケートされたテーブル診断

AnalyticDB for MySQLでは、DISTRIBUTED BY BROADCAST句を指定して、レプリケートされたテーブルを作成できます。複製されたテーブルデータのコピーが各シャードに格納されます。大きなテーブルと小さなテーブルを結合する多数の同時クエリを実行する場合は、小さなテーブルのデータを格納するレプリケートされたテーブルを作成できます。これにより、クラスター内の小さなテーブルのデータ転送が減り、同時実行パフォーマンスが向上します。ただし、レプリケートされたテーブルは書き込みパフォーマンスが低くなり、大量のストレージスペースを占有するため、AnalyticDB for MySQLの全体的な書き込みパフォーマンスに影響します。

診断基準

レプリケートされたテーブルに20,000を超えるレコードが含まれている場合、テーブルは不合理と見なされます。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
テーブル診断 タブをクリックし、 レプリケーションテーブル診断 タブをクリックします。

最適化方法

標準テーブルを作成し、テーブルにデータを移行できます。詳細については、「CREATE TABLE」をご参照ください。

パーティション診断

パーティション化されたテーブル診断

不当なパーティションフィールドを含むパーティションテーブルを作成すると、次の問題が発生します。

パーティションが大量のデータを含み、BUILDジョブがパーティション上で実行される場合、ジョブは、完了し、ストレージノードの実質的なCPUおよびディスクI/Oリソースを消費するのに長時間を必要とする可能性がある。たとえば、テーブルは年ごとに分割され、各パーティションには大量のデータが含まれています。この場合、クラスターの安定性が影響を受けます。
パーティションが少量のデータを含む場合、クラスタは多くのパーティションの情報をキャッシュし、かなりのメモリリソースを消費する可能性があります。たとえば、テーブルは時間ごとに分割され、各パーティションには少量のデータが含まれます。この場合、多くのパーティションがスキャンされ、クエリのパフォーマンスが影響を受けます。

合理的なパーティションサイズの基準

パーティションサイズは、テーブル¹のパーティション内の行数を指し、²するシャードの数に比例します。 N個のシャードを持つテーブルの場合、パーティション内の行数が1,000,000 × Nから5,000,000 × Nの範囲内にある場合、パーティションサイズは妥当であると見なされます。

たとえば、テーブル内のシャードの数が64で、パーティション内の行数が6400万から320万の範囲内の場合、パーティションサイズは妥当です。

説明

¹: テーブルのパーティションの行数を照会するには、次のステートメントを実行します。SELECT partition_id, row_count FROM information_schema.kepler_partitions WHERE schema_name = '$DB' AND table_name ='$TABLE' AND partition_id > 0;
²: テーブルのシャード数を照会するには、SELECT COUNT(1) FROM information_schema.kepler_meta_shards; を実行します。

パーティションフィールドの合理性診断

診断基準

テーブル内の10% 以上のパーティションのサイズが不合理な場合、テーブルのパーティションフィールドは不合理と見なされます。

たとえば、テーブルに100個のパーティションがあり、10個以上のパーティションのサイズが不合理な場合、テーブルのパーティションフィールドは不合理です。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
パーティション診断 タブをクリックして、不当なパーティションを含むテーブルと不当なパーティションに関する情報を パーティションテーブルの診断 タブに表示します。

パーティションサイズを適切な範囲に調整します

パーティションテーブル診断で不合理なパーティションが検出された場合は、次の方法を使用してパーティション設定を調整します。

テーブルのパーティションの行数が妥当な範囲の下限に達していない場合、パーティションサイズは小さすぎると見なされます。パーティションの粒度を上げることを推奨します。たとえば、シャードの数が64の場合、パーティション行の妥当な範囲は64百万から320百万です。パーティションの行数が6400万未満の場合、パーティションサイズは小さすぎます。日ごとに粒度を変更することを推奨します。
テーブルのパーティション内の行数が妥当な範囲の上限を超える場合、パーティションサイズは過度に大きいと見なされます。パーティションの粒度を下げることを推奨します。たとえば、シャードの数が64の場合、パーティション行の妥当な範囲は64百万から320百万です。パーティションの行数が320万を超えると、パーティションサイズが大きくなりすぎます。月ごとに粒度を変更することを推奨します。
パーティションの粒度を変更する方法については、「ALTER table」トピックの「テーブルのパーティション関数の形式の変更」をご参照ください。
パーティションテーブルの行の総数が妥当な範囲の下限に達していない場合は、非パーティションテーブルを作成し、パーティションテーブルから非パーティションテーブルにデータを移行できます。

非パーティションテーブル診断

テーブルを作成するときにPARTITION BY句を指定しない場合、テーブルはパーティション分割されていないテーブルになります。パーティション分割されていないテーブルに対してINSERT、UPDATE、DELETEなどのDML操作を実行すると、テーブル全体でBUILDジョブがトリガーされることがあります。分割されていないテーブルが大量のデータを含む場合、BUILDジョブは一時的に大量のストレージスペースを占有する可能性があります。その結果、ディスク使用量が増加し、ディスクがロックされます。さらに、大きなテーブル上のBUILDジョブは、かなりのCPUおよびディスクI/Oリソースを消費し、クラスタ全体のパフォーマンスを低下させます。

診断基準

パーティション分割されていないテーブルに10億行を超えるデータが含まれている場合、テーブルは不合理と見なされます。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
パーティション診断 タブをクリックし、 非パーティションテーブル診断 タブをクリックします。

最適化方法

パーティションテーブルを作成し、不合理な非パーティションテーブルからパーティションテーブルにデータを移行できます。詳細については、「CREATE TABLE」をご参照ください。

インデックス診断

AnalyticDB for MySQLは、データインデックスの使用状況を分析し、長期間使用されないデータインデックスの最適化の提案を提供します。最適化の提案に基づいてアイドルインデックスを削除し、データインデックスのストレージコストを削減できます。

アイドルインデックス診断

診断基準

過去15日以内に使用されず、使用率が1% 未満のデータインデックスは、アイドルインデックスと見なされます。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
インデックス診断 タブをクリックすると、 アイドルインデックスの最適化 タブの情報が表示されます。
利用可能な最適化提案 セクションで、[有効化] をオンにして、インデックス診断機能を有効にします。クラスターでインデックス診断機能がすでに有効になっている場合は、この手順をスキップできます。

利用可能な最適化提案 および 推奨事項の採用 セクションで、利用可能な最適化の提案を表示します。

パラメーター	説明
提案ID	最適化の提案のID。
SQL	変更するテーブルの詳細情報を指定するSQL文。
最適化タイプ	最適化のタイプ。このパラメーターは、Index Optimizationに設定されます。
最適化の提案	最適化タイプに対して与えられる特定の最適化提案。
期待される最適化の利点	最適化提案の後に得られる期待される利益が適用される。説明期待される最適化の利点は、履歴データに基づいて参照のみのために測定された推定値です。
操作	[適用] をクリックすると、テーブルに最適化の提案を適用できます。説明データインデックスが削除された後、インデックスで参照されているデータを使用してテーブルをフィルタリングするのに時間がかかります。最適化の提案を採用することに同意した場合は、[適用] をクリックします。テーブルに対して [Apply] をクリックすると、ALTERステートメントがクラスターで実行され、提案が [Applied Optimization Suggestions] タブに表示されます。 Apply操作は、クライアントでALTERステートメントを実行するのと同じ効果があります。この操作は取り消すことができません。作業は慎重に行ってください。 SQLステートメントの実行を伴う最適化提案の適用は、テーブル上で自動的にトリガされるBUILD操作が完了した後にのみ完了することができる。 BUILD操作がトリガーされる前は、提案は実行中状態です。 BUILD操作がトリガーされた後、提案のステータスは完了に変わります。

主キー診断

診断基準

テーブルに3つ以上の主キーフィールドがあり、主キーフィールドの数がテーブルのフィールド数の半分に達した場合、テーブルの主キーは過剰であると見なされます。

手順

AnalyticDB for MySQL コンソールにログインします。ホームページの左上でリージョンを選択します。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。 クラスターリスト ページで、タブをクリックしてエディションを選択します。管理するクラスターを確認し、クラスター ID をクリックします。
左側のナビゲーションウィンドウで、スペースの分析 > スペース診断 を選択します。
インデックス診断 タブをクリックし、 プライマリキー過剰の診断 タブをクリックします。

操作	説明
DescribeTablePartitionDiagnose	AnalyticDB for MySQLのパーティション診断に関する情報の照会 Data Warehouse Editionクラスター。
DescribeExcessivePrimaryKeys	AnalyticDB for MySQLで過剰な主キーフィールドを持つテーブルに関する情報を照会します。 Data Lakehouse Editionクラスター。

AnalyticDB:ストレージ診断

使用上の注意

テーブル診断

テーブルスキュー診断

診断基準

手順

最適化方法

ホットテーブルとコールドテーブルの最適化

診断基準

手順

レプリケートされたテーブル診断

診断基準

手順

最適化方法

パーティション診断

パーティション化されたテーブル診断

合理的なパーティションサイズの基準

パーティションフィールドの合理性診断

診断基準

手順

パーティションサイズを適切な範囲に調整します

非パーティションテーブル診断

診断基準

手順

最適化方法

インデックス診断

アイドルインデックス診断

診断基準

手順

主キー診断

診断基準

手順

関連する API 操作