すべてのプロダクト
Search
ドキュメントセンター

AnalyticDB for MySQL:データインポートパフォーマンスの最適化

最終更新日:Jun 12, 2024

AnalyticDB for MySQLは、さまざまなシナリオの要件を満たすためにいくつかのデータインポート方法を提供していますが、インポートパフォーマンスはさまざまな要因によって影響を受ける可能性があります。 例えば、不適切なテーブルモデリングは、データスキューをもたらし、データインポートのための不適切な構成は、非効率的なリソース利用をもたらし得る。 このトピックでは、さまざまなシナリオでデータインポートパフォーマンスを最適化する方法について説明します。

外部テーブルを使用してデータをインポートするときのパフォーマンスの最適化

配布キーの確認

配布キーは、シャード単位でテーブルデータを同時にインポートする方法を決定します。 データが不均等に分散されている場合、大量のデータがインポートされたシャードはインポートに時間がかかり、データスキューの問題が発生し、データインポートジョブ全体のパフォーマンスに影響を与える可能性があります。 これらの問題を解決するには、データをインポートするときにデータが均等に分散されるようにします。 配布キーの選択方法については、「」をご参照ください。配布キーの選択"Schemaデザイントピックのセクション。

配布キーが適切かどうかを判断します。

  • データをインポートする前に、配布キーの意味に基づいて配布キーが適切かどうかを判断します。 たとえば、Lineitemテーブルでl_discount列が配布キーとして選択され、l_discount列には11個の個別の値しか存在しないとします。 l_discount列に同じ値を持つデータは同じシャードに分散され、重大なデータスキューの問題が発生し、データインポートパフォーマンスに影響します。 この場合、l_orderkey列はより適切な配布キーです。 順序ID値はすべて一意であるため、データを均等に分散できます。

  • データのインポート後、配布キーの妥当性の診断に基づいて、配布キーが適切かどうかを判断します。 配布キーの診断を表示する方法については、「データモデリング診断」トピックの「配布フィールドスキューに関する診断」を参照してください。

パーティションキーを確認する

INSERT OVERWRITE INTO SELECTを使用してパーティションをAnalyticDB for MySQLに書き込むと、同じ名前を使用する既存のパーティションのデータが上書きされます。 各シャードのデータは、対応するパーティションにインポートされます。 外部ソートやデータインポートパフォーマンスの低下を防ぐため、一度に多数のパーティションをインポートしないことをお勧めします。 パーティションキーの選択方法については、「スキーマ設計」の「パーティションキーの選択」をご参照ください。

パーティションキーが適切かどうかを判断します。

  • データをインポートする前に、ビジネスデータ要件とデータ配布に基づいてパーティションキーが適切かどうかを判断します。 たとえば、l_shipdate列を使用してLineitemテーブルを分割し、テーブルデータが7年に及ぶとします。 データが年でパーティション分割されている場合、テーブルには7つのパーティションが含まれます。 データが日付でパーティション分割されている場合、テーブルには2,000を超えるパーティションが含まれ、各パーティションには約30万行のデータが含まれます。 この場合、月または年でテーブルを分割する方が適切です。

  • データのインポート後、パーティションキーの妥当性に関する診断に基づいて、パーティションキーが適切かどうかを判断します。 パーティションキーの診断を表示する方法の詳細については、「データモデリング診断」トピックの「パーティションフィールドの妥当性に関する診断」を参照してください。

インデックスの確認

デフォルトでは、AnalyticDB for MySQLはテーブルの作成時にすべての列のインデックスを作成し、ワイドテーブルのすべての列のインデックスを作成すると特定のリソースが消費されます。 ワイドテーブルにデータをインポートする場合は、主キーインデックスを使用することを推奨します。 主キーインデックスは重複排除に使用できますが、多数の主キー列を使用するとパフォーマンスが低下します。 主キーインデックスの選択方法については、「スキーマ設計」の「主キーの選択」をご参照ください。

インデックスが適切かどうかを判断します。

  • 通常、バッチ計算中にデータが重複排除されているため、バッチインポートシナリオでは主キーインデックスを指定する必要はありません。

  • AnalyticDB for MySQLコンソールの [モニタリング情報] ページで、[テーブル情報統計] タブをクリックして、テーブルデータ、インデックスデータ、および主キーインデックスデータの量を表示します。 インデクスのデータ量が表のデータ量を超える场合は, 列に长い文字列が存在するかどうかを确认してください。 このような列では、インデックスの作成に時間がかかり、大量のストレージスペースを占有する可能性があります。 そのようなインデックスを削除することを推奨します。 詳細については、「ALTER TABLE」トピックの「ALTER TABLE」セクションをご参照ください。

    説明

    主キーインデックスは削除できません。 プライマリキーインデックスを削除する場合は、別のテーブルを作成する必要があります。

インポートを高速化するヒントを追加する

データインポートステートメントの前にヒント (/direct_batch_load=true) を追加して、インポートジョブを高速化できます。

説明

このヒントは、Cluster Edition V3.1.5のエラスティックモードのAnalyticDB for MySQL Data Warehouse Edition (V3.0) でのみサポートされます。 パフォーマンスが改善されない場合、 チケットを起票してください。

例:

ジョブを送信 /* direct_batch_load=true */INSERT OVERWRITE adb_table
SELECT * からadb_external_table; 

エラスティックインポート機能を使用したインポートの高速化

説明
  • elastic importは、V3.1.10.0以降のAnalyticDB for MySQLクラスターにのみ使用できます。

  • ジョブリソースグループを持つAnalyticDB for MySQL Data Lakehouse Edition (V3.0) クラスターにelastic importを使用できます。

  • エラスティックインポートを使用して、MaxComputeデータと、Object Storage Service (OSS) に保存されているCSV、Parquet、およびORCデータのみをインポートできます。

  • エラスティックインポートを使用する場合は、ジョブの長い待機時間、長い実行時間、およびジョブの失敗を防ぐために、ジョブリソースグループに十分なリソースがあることを確認してください。

AnalyticDB for MySQLを使用すると、複数のエラスティックインポートジョブを同時に実行し、エラスティックインポートジョブのリソースの最大量を増やしてジョブを高速化できます。 詳細については、「データインポート方法」をご参照ください。

例:

/* elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]* /
ジョブ挿入上書きadb_table select * from adb_external_table; 

詳細については、「外部テーブルを使用してdata Lakehouse Editionにデータをインポートする」トピックの「ヒントパラメーター」セクションを参照してください。

DataWorksを使用してデータをインポートするときのパフォーマンスの最適化

ジョブ設定の最適化

  • 書き込みごとのデータレコードの値を最適化する

    このパラメーターは、バッチごとにインポートされるデータレコードの数を指定します。 デフォルト値は2048です。 ほとんどの場合、デフォルト値を使用することを推奨します。

    ただし、1つのデータレコードのサイズが数百KBに達する場合は、このパラメーターの値を変更することをお勧めします。 たとえば、1つのデータレコードのサイズが512 KBの場合、パラメーターを16に設定できます。 これにより、バッチごとにインポートされるデータの量が8 MBを超えないようにし、フロントエンドノードの高メモリ使用を防ぎます。

  • チャネル制御の設定を最適化する

    • データインポートジョブのデータ同期パフォーマンスは、Expected Maximum Concurrencyの値に比例します。 このパラメーターの値を増やすことを推奨します。

      重要

      Expected Maximum Concurrencyの値が大きいほど、占有されるDataWorksリソースが多くなります。 このパラメーターを適切な値に増やします。

    • 同期パフォーマンスを向上させるために、分散実行をオンにすることを推奨します。

一般的な問題と解決策

  • クライアントから少量のデータがインポートされると、データはデータベースサーバーによってタイムリーに処理されますが、CPUおよびディスクI/Oリソースは十分に活用されていません。 その結果、1秒あたりの書き込み応答時間と書き込みトランザクション (TPS) が期待に合わない場合があります。

    解決方法: [書き込みごとのデータレコード] および [期待される最大同時実行] の値を増やして、インポートされるデータの量を増やします。 データインポートパフォーマンスは、インポートされるデータの量が増加するにつれて直線的に増加します。

  • インポートされたテーブルにデータスキューの問題がある場合、特定のクラスターノードが過負荷になり、インポートパフォーマンスが低下します。 この場合、CPUおよびディスクI/Oリソースが十分に利用されず、書き込み応答時間が長くなる。 [診断と最適化] ページの [データモデリング診断] タブに、インポートしたテーブルのデータスキュー診断結果が表示されます。

    解決策: テーブルスキーマを再設計し、データを再度インポートします。 詳細については、「スキーマデザイン」をご参照ください。

プログラムとJDBCを使用してデータをインポートするときのパフォーマンスの最適化

クライアントを最適化する

  • クライアントからのバッチデータのインポート

    • プログラムとJava Database Connectivity (JDBC) を使用してデータをインポートする場合、ネットワークと接続のオーバーヘッドを減らすためにデータを一括インポートすることをお勧めします。 特別な要件が適用されない限り、単一のデータレコードをインポートしないでください。

    • バッチごとに2,048のデータレコードをインポートすることを推奨します。 1つのデータレコードのサイズが数百KBに達する場合、1バッチあたり8 MB以下のデータをインポートすることを推奨します。 8 MBを1つのデータレコードのサイズで割ることで、バッチあたりの最適なデータレコード数を計算できます。 バッチごとに大量のデータをインポートすると、フロントエンドノードのメモリ使用量が多くなり、インポートのパフォーマンスが低下する可能性があります。

  • クライアントの同時実行設定

    • クライアントからデータをインポートする場合、単一のプロセスではシステムリソースを十分に活用できず、クライアントでのバッチ操作によってインポート速度が低下するため、同時にデータをインポートすることをお勧めします。 同時実行ポリシーを使用して、データのインポートを高速化できます。

    • 同時実行機能は、クライアントが配置されているホストのバッチ、データソース、およびワークロードの数によって決まります。 テストによって適切な同時実行機能を見つけることを推奨します。 たとえば、インポートのパフォーマンスが要件を満たせない場合は、同時プロセスの数を2倍にすることができます。 インポート速度が低下した場合は、並行プロセスの数を徐々に減らすことができます。

一般的な問題と解決策

プログラムとJDBCを使用してデータをAnalyticDB for MySQLにインポートするときに、パフォーマンスが要件を満たしていない場合は、まずクライアントのパフォーマンスのボトルネックを確認します。

  • データソースが高速にデータを生成できることを確認してください。 データが他のシステムまたはファイルからのものである場合は、クライアントの出力ボトルネックを確認します。

  • データを高速に処理できることを確認してください。 データを同期的に生成および消費できるかどうかを確認し、十分な量のデータがAnalyticDB for MySQLにインポートされるのを待っていることを確認します。

  • クライアントが配置されているホストで適切なワークロードを確保しながら、CPU使用率またはディスクI/O使用率を確認して、システムリソースが十分かどうかを確認します。