この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

データ読み込みに関する一般的なガイドライン

最小限の処理時間でデータ読み込みが実行されるように計画を立てるためのヒントを紹介します。データ読み込みを行う場合は、事前に必ず Sandbox 組織でテストを実行します。ただし、Sandbox 組織と本番組織とでは、処理時間が異なる可能性があります。
できる限り並列モードを使用する
バッチを並列モードで処理することにより、Bulk API のメリットを最大限に引き出すことができます。並列モードはデフォルトで選択されており、より迅速なデータ読み込みを可能にします。ただし、並列モードを使用すると、レコードに対するロック競合が発生することがあります。これを回避するには、逐次モードを使用して処理を実行します。ただし、並列モードだとロックタイムアウトが発生し、バッチを再構成してもロックを回避できないとわかっている場合以外は、逐次モードでデータ処理を実行しないでください。
処理モードはジョブレベルで設定します。1 つのジョブに含まれるすべてのバッチが並列モード、逐次モードのいずれかで処理されます。
ロック競合を回避できるようにバッチを再構成する
たとえば、AccountTeamMember レコードの作成や更新を行う場合、このレコードが参照する取引先レコードは、トランザクションが完了するまでロックされます。AccountTeamMember レコードのバッチを複数読み込む場合に、これらのレコードに同一の取引先への参照が含まれていると、すべてのバッチで同じ取引先をロックしようとするため、ロックタイムアウトが発生することが予想されます。このような場合、バッチへのデータの振り分けを見直すことで、ロックタイムアウトを回避できる可能性があります。たとえば、AccountId 別に AccountTeamMember レコードを分類して、同じ取引先を参照するすべてのレコードを 1 つのバッチにまとめると、複数のバッチによるロック競合のリスクを減らすことができます。
Bulk API では、ロックが発生するとただちにエラーが返されるわけではありません。ロックが解除されるのを数秒間待ち、解除されない場合はレコードを Failed としてマークします。1 つのバッチ内で、100 を超えるレコードに対してロックが確認された場合、そのバッチの未処理のリクエストはいったんキューに戻されます。後で再度同じバッチが処理されるとき、Failed としてマークされたレコードは再試行されません。これらのレコードを処理するには、別のバッチにまとめて再送信する必要があります。
再度の処理も正常に完了しなかった場合、バッチは再びキューに戻され、最大 10 回まで処理が試行されます。それでも完了できない場合は、バッチ処理が完全に失敗したとみなされます。バッチの状態が Failed であっても、一部のレコードは正常に処理されている可能性があります。バッチ結果を取得して、個々のレコードの処理状況を確認する方法については、「バッチ結果の取得」を参照してください。エラーが回避されない場合は、別のジョブを作成し、データを逐次モードで処理します。逐次モードでは、バッチが 1 つずつ順番に処理されます。
ロック競合を引き起こしやすい処理に注意する
次に示すのは、ロック競合を引き起こしやすい処理です。これらの処理では必要に応じて逐次モードを使用します。
  • 新規ユーザの作成
  • 非公開で共有されているレコードの所有者の更新
  • ユーザロールの更新
  • テリトリー階層の更新
これらの処理に関連するエラーが発生した場合は、別のジョブを作成し、逐次モードでデータを処理してください。

データモデルは組織ごとに異なるため、ロック競合が発生する条件は、上記で説明したものと一致しない場合があります。

メモ

項目の数を最小限に抑える
各レコードの読み込む項目数が少ないほど、処理時間は短くなります。外部キー項目、参照関係項目、積み上げ集計項目が含まれると、処理時間が長くなる傾向にあります。項目の数を減らすことが難しい場合もあるかと思いますが、可能であれば実行してください。これにより、読み込み時間を短縮できます。
ワークフローアクションの数を最小限に抑える
ワークフローアクションの数が増えると処理時間が長くなります。
トリガの数を最小限に抑える
トリガが関連付けられたオブジェクトでは、それらのトリガが他の並列トランザクションに悪影響を及ぼさないようであれば、並列モードを使用してもかまいません。ただし、Salesforce では、複雑なトリガが関連付けられたオブジェクトを含む、サイズの大きなバッチを読み込むことは推奨していません。代わりに、すべてのデータが読み込まれた後に実行される一括処理 Apex ジョブとして、トリガのロジックを記述し直すことをお勧めします。
バッチサイズを最適化する
Salesforce では、すべての顧客組織間で処理リソースが共有されます。各組織がバッチの処理を長時間待たなくても済むように、処理に 10 分以上かかるバッチはいったんキューに戻され、後で処理されます。そのため、処理時間を短縮する最善の方法は、10 分以内に処理が完了するバッチを送信することです。一括処理のタイミングの監視についての詳細は、「バッチの監視」を参照してください。
バッチサイズは処理時間に基づいて調整する必要があります。まず 5,000 件のレコードを含むバッチで処理を試行し、処理時間に応じてサイズを調整します。1 つのバッチの処理に 5 分以上かかるようなら、バッチサイズを小さくしたほうがよいでしょう。数秒で完了するようであれば、バッチサイズを大きくします。バッチの処理時にタイムアウトエラーが発生する場合は、バッチをより小さなサイズに分割して再試行します。 詳細は、「Bulk API の制限」を参照してください。

一括クエリの場合、バッチサイズはクエリ結果セットと取得データサイズのどちらにも適用されません。一括クエリの処理に時間がかかりすぎる場合、クエリステートメントを絞り込んで、返されるデータ量を減らす必要があります。

メモ

非同期キュー内の一括処理数を最小限に抑える
Salesforce では、キューベースのフレームワークを使用して、Apex の future ジョブや一括処理、Bulk API 一括処理などの供給元からの非同期プロセスを処理します。このキューは、組織間で要求ワークロードを調整するために使用します。キュー内で 1 つの組織の未処理要求が 2,000 を上回ると、その組織からの以降の要求は遅延し、その間に他の組織からの要求が処理されます。一括処理がキュー内で遅延しないようにするには、一度に送信できる一括処理の数を最小限に抑えます。