AnalyticDB for MySQL は、さまざまなシナリオに対応する複数のデータインポートメソッドを提供します。しかし、さまざまな要因がデータインポートのパフォーマンスに影響を与える可能性があります。たとえば、不適切なテーブルスキーマはロングテールタスクを引き起こし、低いインポート構成は非効率的なリソース使用につながる可能性があります。このトピックでは、さまざまなシナリオでデータインポートのパフォーマンスを最適化する方法について説明します。
外部テーブルからのデータインポートの最適化
分散キーの確認
分散キーは、データインポートのハッシュパーティションを決定します。データは、ハッシュパーティションレベルで各テーブルに同時にインポートされます。データが均等に分散されていない場合、データ量の多いハッシュパーティションがロングテールノードとなり、インポートタスク全体のパフォーマンスが低下します。したがって、インポート中にデータが均等に分散されるようにする必要があります。分散キーの選択方法の詳細については、「分散キーの選択」をご参照ください。
分散キーが適切かどうかを判断するには、次の点を考慮してください。
インポートの前に、ビジネスコンテキストに基づいて、選択した分散キーが適切かどうかを判断します。たとえば、Lineitem テーブルで、l_discount 列を分散キーとして選択した場合、注文割引値のカーディナリティは低く、11 個の個別値しかありません。同じ l_discount 値を持つデータは同じパーティションに分散されます。これにより、深刻なデータスキューが発生し、ロングテールタスクが作成され、パフォーマンスが低下します。l_orderkey 列は、注文 ID が一意であるため、データがより均等に分散されることを保証するため、より良い選択です。
インポート後、データモデリング診断で分散フィールドのデータスキューが示された場合、選択した分散キーが不均等なデータ分布を引き起こしています。分散キー診断の表示方法の詳細については、「ストレージ診断」をご参照ください。
パーティションキーの確認
INSERT OVERWRITE SELECT 文はパーティションを上書きします。これは、インポートされたサブパーティションが、ターゲットテーブル内の同じ名前を持つ既存のサブパーティションを置き換えることを意味します。各ハッシュパーティション内で、データは対応するサブパーティションにインポートされます。一度に多くのサブパーティションをインポートすることは避けてください。複数のサブパーティションを同時にインポートすると、外部ソートプロセスがトリガーされ、インポートパフォーマンスが低下する可能性があります。パーティションキーの選択方法の詳細については、「パーティションキーの選択」をご参照ください。
パーティションキーが適切かどうかを判断するには、次の点を考慮してください。
インポートの前に、要件とデータ分布に基づいてパーティションキーが適切かどうかを判断します。たとえば、Lineitem テーブルを l_shipdate 列でサブパーティション化し、タイムスタンプ範囲が 7 年間にわたる場合、年でパーティション化すると 7 つのサブパーティションが作成されます。日でパーティション化すると 2,000 以上のサブパーティションが作成され、各サブパーティションには約 3,000 万レコードが含まれます。この場合、月または年によるパーティション化がより適切です。
インポート後、データモデリング診断でサブパーティションが不合理であることが示された場合、選択したパーティションキーは不適切です。パーティションキー診断の表示方法の詳細については、「パーティションテーブルの診断」をご参照ください。
インデックスの確認
デフォルトでは、AnalyticDB for MySQL はテーブル作成時にすべての列にインデックスを作成します。ワイドテーブルのすべての列にインデックスを構築すると、大量のリソースが消費されます。ワイドテーブルにデータをインポートする場合は、主キーインデックスのみを使用することを検討してください。主キーインデックスは、重複を削除するために使用されます。主キー列が多すぎると、重複排除のパフォーマンスが低下する可能性があります。プライマリキーの選択方法の詳細については、「プライマリキーの選択」をご参照ください。
インデックスが適切かどうかを判断するには、次の点を考慮してください。
オフラインインポートシナリオでは、データは通常、オフラインコンピューティングによって重複排除されます。主キーインデックスを指定する必要はありません。
タブで、テーブルデータ、インデックスデータ、および主キーインデックスデータの量を確認できます。インデックスデータの量がテーブルデータの量より大きい場合は、長い文字列を持つ列を確認してください。これらの列にインデックスを構築すると、時間がかかり、大量のストレージ領域が消費されます。これらのインデックスは削除できます。詳細については、「ALTER TABLE」をご参照ください。
説明主キーインデックスは削除できません。テーブルを再作成する必要があります。
インポートを高速化するためのヒントの追加
インポートタスクの前にヒント (direct_batch_load=true) を追加して、インポートを高速化できます。
このヒントは、バージョン 3.1.5 を実行する エラスティックモードの Data Warehouse Edition クラスターでのみサポートされます。ヒントを使用してもインポートパフォーマンスが大幅に向上しない場合は、チケットを起票してください。
例：
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;エラスティックインポート機能を使用したインポートの高速化
エラスティックインポート機能は、カーネルバージョン 3.1.10.0 以降を実行するクラスターでのみサポートされます。
エラスティックインポート機能は、Job リソースグループが作成されている Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスターでサポートされます。
エラスティックインポートは、CSV、Parquet、または ORC 形式で保存された MaxCompute データと OSS データのインポートのみをサポートします。
エラスティックインポート機能を使用してインポートを高速化する場合は、Job リソースグループに十分なリソースがあることを確認してください。これにより、長い待機時間、長いタスク期間、リソース不足によるタスクの失敗などの問題を回避できます。
エラスティックインポートは、複数のエラスティックインポートタスクの同時実行をサポートします。また、割り当てられたリソースを増やすことで、単一のエラスティックインポートタスクを高速化することもできます。詳細については、「データインポートメソッド」をご参照ください。
例：
/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;パラメーターの詳細については、「ヒントパラメーター」をご参照ください。
DataWorks からのデータインポートの最適化
タスク構成の最適化
バッチ挿入あたりのレコード数の最適化
このパラメーターは、1 回のインポートのバッチサイズを指定します。デフォルト値は 2048 です。この値を変更することはお勧めしません。
1 つのレコードが大きい場合 (数百 KB から最大 512 KB など)、この設定を 16 に変更できます。この変更により、各バッチインポートが 8 MB を超えないようにし、フロントエンドノードでの高いメモリ使用量を防ぐことができます。
チャネルコントロールの最適化
データ同期のパフォーマンスは、[最大同時実行数] の値に比例します。[最大同時実行数] の値はできるだけ大きくすることができます。
重要最大同時実行数の値を大きくすると、より多くの DataWorks リソースが消費されます。要件に基づいて値を選択してください。
同期パフォーマンスを向上させるために、[分散実行] をオンにすることができます。
よくある質問と解決策
クライアントが十分なインポート負荷を生成しない場合、クラスターの CPU 使用率、ディスク I/O 使用率、および書き込み応答時間は低いままです。データベースサーバーは、クライアントから送信されたデータを迅速に処理できます。ただし、送信されるデータの総量が少ないため、1 秒あたりの書き込みトランザクション (TPS) が期待どおりにならない場合があります。
解決策: [バッチ挿入あたりのレコード数] と [最大同時実行数] の値を増やすことができます。データインポートのパフォーマンスは、インポート負荷に比例して線形に増加します。
インポートのターゲットテーブルにデータスキューがある場合、一部のクラスターノードが過負荷になり、インポートパフォーマンスが低下します。この場合、クラスターの CPU 使用率とディスク I/O 使用率は低いですが、書き込み応答時間は長くなります。また、 ページのスキュー診断テーブルでターゲットテーブルを特定することもできます。
解決策: テーブルスキーマを再設計してから、データを再インポートできます。詳細については、「テーブルスキーマの設計」をご参照ください。
JDBC プログラムからのデータインポートの最適化
クライアント側の最適化
アプリケーション側でのバッチインポートの使用
JDBC プログラムを使用してデータをインポートする場合は、バッチインポートを使用してネットワークとリンクのオーバーヘッドを削減します。特別な要件がない限り、単一レコードのインポートは避けてください。
バッチサイズは 2048 レコードを推奨します。1 つのレコードが大きい場合 (数百 KB など)、バッチサイズを 8 MB 未満に保ちます。1 つのレコードのサイズで 8 MB を割ることで、バッチあたりのレコード数を計算できます。バッチが大きすぎると、フロントエンドノードでメモリを過剰に使用し、インポートパフォーマンスが低下する可能性があります。
アプリケーション側での同時実行の構成
アプリケーションからデータをインポートする場合は、複数の同時実行スレッドを使用してデータをインポートします。単一のプロセスでは、システムリソースを完全には利用できません。また、クライアントは通常、データを処理してバッチを作成する必要があり、これはデータベースのインポート速度よりも遅くなる可能性があります。複数の同時実行スレッドを使用すると、インポートを高速化できます。
インポートの同時実行数は、バッチ処理、データソース、およびクライアントマシンの負荷の影響を受けます。単一の最適な値は存在しません。テストを実行して最適な同時実行レベルを見つけることをお勧めします。インポートパフォーマンスが期待どおりでない場合は、同時実行数を 2 倍にします。インポート速度が低下した場合は、同時実行数を徐々に減らして最適な数を見つけます。
よくある質問と解決策
プログラムから AnalyticDB for MySQL にデータをインポートする際にパフォーマンスが低い場合は、まずクライアントのパフォーマンスボトルネックを確認する必要があります。
データソースが十分な速度でデータを生成できることを確認してください。データが他のシステムやファイルから取得される場合は、クライアントの出力ボトルネックを確認してください。
データ処理速度が高いことを確認してください。データの生成と消費が同期しているかどうかを確認します。AnalyticDB for MySQL にインポートする準備ができている十分なデータがあることを確認してください。
クライアントマシンの負荷を確認してください。CPU 使用率やディスク I/O 使用率などのシステムリソースが十分であることを確認してください。