AnalyticDB for MySQL は、さまざまなシナリオ向けに複数のデータインポート方法を提供します。ただし、インポートパフォーマンスは、データスキューを引き起こす不適切なテーブルモデリングや、最適でないインポート構成による非効率的なリソース利用などの要因によって影響を受ける場合があります。このトピックでは、さまざまなシナリオにおけるデータインポートパフォーマンスの最適化方法について説明します。
外部テーブルからのデータインポートを最適化する
このセクションでは、外部テーブルから TPC-H の lineitem データ（約 1 TB、60 億レコード）をインポートするという具体例を用いて、インポートジョブのパフォーマンスを最適化する方法を説明します。データインポートの詳細については、「INSERT OVERWRITE SELECT」をご参照ください。
分散キー
分散キーは、インポート時にデータをシャードに分割する方法を決定します。テーブルは、そのシャードに分割された状態で並列的にインポートされます。データの分散が不均等な場合、最も多くのデータを保持するシャードがボトルネックとなり、データスキューが発生し、全体のインポートジョブのパフォーマンスが低下します。このような問題を防ぐためには、インポート時にデータが均等に分散されるよう配慮してください。分散キーの選択方法については、「分散キーの選択」をご参照ください。
分散キーが適切かどうかを判断するには、以下の手順を実施します。
データインポート前に、選択した分散キーのビジネスロジックを評価します。たとえば、lineitem テーブルにおいて
l_discountカラムを分散キーとして選択した場合、注文割引値のカーディナリティは非常に低く、異なる値はわずか 11 種類のみです。l_discountの値が同じデータはすべて同一のシャードに配置されるため、深刻なデータスキューが発生し、インポートパフォーマンスが低下します。一方、注文 ID は一意であるため、l_orderkeyカラムを選択すると、より均等なデータ分布が実現できます。データインポート後に、「データモデリング診断」を確認してデータスキューの有無を確認します。スキューが検出された場合は、選択した分散キーによるデータの分散が不均等であることを示します。分散キー診断の確認方法については、「ストレージ領域診断」をご参照ください。
パーティションキー
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 (V3.0) のエラスティッククラスターでのみサポートされています。このヒントワードを使用してもインポートパフォーマンスが大幅に向上しない場合は、チケットを起票してください。
例：
SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;エラスティックインポートによる高速化
エラスティックインポートは、カーネルバージョン 3.1.10.0 以降を実行するクラスターでのみサポートされます。
エラスティックインポートは、ジョブリソースグループが作成済みの Enterprise Edition、Basic Edition、および Data Lakehouse Edition (V3.0) クラスターでサポートされます。
エラスティックインポートでは、MaxCompute および CSV、Parquet、ORC 形式で OSS に保存されたデータのみがサポートされます。
エラスティックインポートを使用する際は、ジョブリソースグループに十分なリソースが確保されていることを確認してください。リソース不足により、待機時間が長くなる、実行時間が延長される、またはジョブが失敗する可能性があります。
エラスティックインポートでは、複数のインポートジョブを同時に実行できます。また、単一のインポートジョブに対してより多くのリソースを割り当てることで、そのジョブの実行速度を向上させることも可能です。詳細については、「データインポート方法」をご参照ください。
例：
/*+ 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 回の書き込みあたりのデータレコード数 を最適化する
このパラメーターは、1 回の書き込み操作におけるバッチサイズを指定します。デフォルト値のまま使用することを推奨します。
ただし、1 レコードのサイズが大きい場合（例：512 KB）、このパラメーターを 16 に設定することを推奨します。これにより、各バッチのサイズが 8 MB を超えることがなく、フロントエンドノードのメモリ使用量が過度に増加することを防げます。
チャネル制御 を最適化する
データ同期パフォーマンスは、予期される最大同時実行数 の値に直接関係します。ワークロードが許容する限り、この値をできるだけ大きく設定することを推奨します。
重要予期される最大同時実行数の値を大きくすると、DataWorks のリソース消費量も増加します。ワークロードに適した値を選択してください。
同期パフォーマンスを向上させるため、分散実行 を有効化します。
よくある問題と解決方法
クライアント側の書き込み圧力が不足している：クライアントがデータを十分な速度で送信できない場合、CPU 使用率やディスク I/O 使用率などのクラスターリソースの利用率は低いままであり、データベースサーバーは受信したデータを迅速に処理できますが、総データ量が少ないため、全体の書き込み TPS が期待通りに達成されません。
解決方法：1 回の書き込みあたりのデータレコード数 および 予期される最大同時実行数 の値を増加させます。クライアント側の書き込み圧力を高めることで、データインポートパフォーマンスが向上します。
ターゲットテーブルにおけるデータスキュー：ターゲットテーブルにデータスキューが発生している場合、一部のクラスターノードが過負荷になり、インポートパフォーマンスが低下します。この場合、CPU 使用率およびディスク I/O 使用率は低いものの、書き込み応答時間が長くなります。「」ページでも、スキューが発生しているテーブルを特定できます。
解決方法：テーブルスキーマを再設計し、データを再インポートします。詳細については、「テーブルスキーマの設計」をご参照ください。
JDBC を使用したデータインポートを最適化する
クライアント側の最適化
バルク挿入のためにクライアントでデータをバッチ処理する
JDBC を使用してプログラムからデータをインポートする場合、ネットワークおよび接続のオーバーヘッドを軽減するため、レコードをバッチ処理することを推奨します。必要でない限り、単一レコードの挿入は避けてください。
バッチサイズは 2,048 レコードを推奨します。1 レコードのサイズが数百 KB のように大きい場合は、バッチ全体のサイズを 8 MB 未満に保つことを推奨します。1 バッチあたりのレコード数は、8 MB を 1 レコードのサイズで割ることで算出できます。過大なバッチサイズはフロントエンドノードのメモリを過度に消費し、インポートパフォーマンスを低下させる可能性があります。
クライアント側の同時実行数の構成
クライアントアプリケーションからデータをインポートする場合、複数の並行スレッドを使用することを推奨します。単一プロセスではシステムリソースを十分に活用できず、クライアント側でのデータ処理およびバッチ処理のため、データベースへの取り込み速度に追いつかないことが多くあります。複数の並行スレッドを使用することで、インポート速度を大幅に向上させることができます。
最適な並行スレッド数は、バッチ処理、データソース、クライアントマシンの負荷など、さまざまな要因によって異なります。最適な値は一概には定まりません。テストを通じて最適な同時実行レベルを特定することを推奨します。インポート速度が満足できない場合は、並行スレッド数を 2 倍にして試行してください。その後、速度が低下した場合は、徐々に同時実行数を減らして、最適な数を見つけてください。
よくある問題と解決方法
プログラムから AnalyticDB for MySQL へデータをインポートする際にパフォーマンスが劣る場合は、まずクライアント側のボトルネックを確認してください。
データソースが高速でデータを生成できることを確認します。データソースが他のシステムまたは一連のファイルである場合、クライアント側の出力ボトルネックがないか確認してください。
データ処理速度が十分に高いことを確認します。データの生成と消費が同期しているか確認し、AnalyticDB for MySQL へインポート可能なデータが十分に準備されていることを確認してください。
クライアントマシンの負荷を確認します。CPU 使用率やディスク I/O 使用率などのシステムリソースが十分にあることを確認してください。