AnalyticDB for MySQLは、さまざまなシナリオの要件を満たすためにいくつかのデータインポート方法を提供していますが、インポートパフォーマンスはさまざまな要因によって影響を受ける可能性があります。 例えば、不適切なテーブルモデリングは、データスキューをもたらし、データインポートのための不適切な構成は、非効率的なリソース利用をもたらし得る。 このトピックでは、さまざまなシナリオでデータインポートパフォーマンスを最適化する方法について説明します。
外部テーブルを使用してデータをインポートするときのパフォーマンスの最適化
配布キーの確認
配布キーは、シャード単位でテーブルデータを同時にインポートする方法を決定します。 データが不均等に分散されている場合、大量のデータを含むシャードはインポートに時間がかかり、データスキューの問題が発生し、データインポートジョブ全体のパフォーマンスに影響を与える可能性があります。 これらの問題を解決するには、データをインポートするときにデータが均等に分散されるようにします。 配布キーの選択方法については、「」をご参照ください。配布キーの選択"Schemaデザイントピックのセクション。
配布キーが適切かどうかを判断します。
データをインポートする前に、配布キーの意味に基づいて配布キーが適切かどうかを判断します。 たとえば、Lineitemテーブルで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」トピックの「インデックスの削除」セクションをご参照ください。
説明主キーインデックスは削除できません。 プライマリキーインデックスを削除する場合は、別のテーブルを作成する必要があります。
インポートを高速化するヒントを追加する
データインポートステートメントの前にヒント (/direct_batch_load=true
) を追加して、インポートジョブを高速化できます。
このヒントは、Cluster Edition V3.1.5のエラスティックモードのAnalyticDB for MySQL Data Warehouse Edition (V3.0) でのみサポートされます。 パフォーマンスが改善されない場合、 チケットを起票してください。
例:
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM 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]*/
submit job insert overwrite 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使用率を確認して、システムリソースが十分かどうかを確認します。