Bulk API 2.0 および Bulk API 開発者ガイド
jデータ読み込みに関する一般的なガイドライン
データ読み込みを計画するときは、処理時間を最適化するために、次のヒントを検討してください。データ読み込みを行う場合は、事前に必ず Sandbox 組織でテストを実行します。本番組織では、処理時間が異なる場合があります。
- できる限り並列同時実行モードを使用する
- Salesforce Bulk API の同時実行モードによって、同時に処理できるデータのバッチ数と、バッチの処理方法が決定されます。Bulk API ジョブのバッチはすべて、並列同時実行モードまたは逐次同時実行モードで処理されます。
- デフォルトモードの並列モードの場合、バッチの処理は、同じジョブの他のバッチや他の並列モードジョブのバッチと並列に実行されます。データをより高速に読み込むには、並列モードでバッチを処理します。ただし、並列処理の場合、レコードのロック競合が発生する可能性があります。失敗したレコードは再送信する必要があります。
- 逐次モードの場合、バッチは同じジョブの他のバッチや他の逐次モードジョブのバッチと連続的に処理されます。各バッチは、次のバッチの処理が開始される前に必ず完了されます。バッチは 1 つずつ処理されるため、ロック競合の可能性を最小限に抑えることができます。逐次モードを使用した場合のデメリットは、処理時間が増加することです。
- 逐次バッチは、並列モードで送信されたジョブのバッチと並行して同時に処理されます。このため、レコードのロックが発生する可能性が多少あります。
- JobInfo リソースを使用して、ジョブレベルで concurrencyMode の値を設定します。
- 結論として、選択する同時実行モードは、特定の使用事例の要求に応じて異なります。逐次モードでデータを処理するのは、並列モードでロックのタイムアウトが発生し、ロックを回避するためにバッチを再編成できないことが分かっている場合のみにし、それ以外は避けてください。失敗したレコードは再送信する必要があります。
- ロック競合を回避できるようにバッチを再構成する
- たとえば、AccountTeamMember レコードの作成や更新を行う場合、このレコードが参照する取引先レコードは、トランザクションが完了するまでロックされます。AccountTeamMember レコードのバッチを複数読み込む場合に、これらのレコードに同一の取引先への参照が含まれていると、すべてのバッチで同じ取引先をロックしようとするため、ロックタイムアウトが発生することが予想されます。このような場合、バッチへのデータの振り分けを見直すことで、ロックタイムアウトを回避できる可能性があります。たとえば、AccountId 別に AccountTeamMember レコードを分類して、同じ取引先を参照するすべてのレコードを 1 つのバッチにまとめると、複数のバッチによるロック競合のリスクを減らすことができます。
- Bulk API では、ロックが発生するとただちにエラーが返されるわけではありません。ロックが解除されるのを数秒間待ち、解除されない場合はレコードを Failed としてマークします。1 つのバッチ内で、100 を超えるレコードに対してロックが確認された場合、そのバッチの未処理のリクエストはいったんキューに戻されます。後で再度同じバッチが処理されるとき、Failed としてマークされたレコードは再試行されません。これらのレコードを処理するには、別のバッチにまとめて再送信する必要があります。
- 再度の処理も正常に完了しなかった場合、バッチは再びキューに戻され、最大 10 回まで処理が試行されます。それでも完了できない場合は、バッチ処理が完全に失敗したとみなされます。バッチの状態が Failed であっても、一部のレコードは正常に処理されている可能性があります。エラーが回避されない場合は、別のジョブを作成し、データを逐次モードで処理します。逐次モードでは、バッチが 1 つずつ順番に処理されます。
- ロック競合を引き起こしやすい処理に注意する
- 次に示すのは、ロック競合を引き起こしやすい処理です。これらの処理では必要に応じて逐次モードを使用します。
- ユーザの作成
- 非公開で共有されているレコードの所有者の更新
- ユーザロールの更新
- テリトリー階層の更新
- これらの処理に関連するエラーが発生した場合は、別のジョブを作成し、逐次同時実行モードでデータを処理してください。JobInfo リソースを使用して、ジョブレベルで concurrencyMode を設定します。
- 項目の数を最小限に抑える
- 各レコードの読み込む項目数が少ないほど、処理時間は短くなります。外部キー項目、参照関係項目、積み上げ集計項目が含まれると、処理時間が長くなる傾向にあります。項目の数を減らすことが難しい場合もあるかと思いますが、可能であれば実行してください。これにより、読み込み時間を短縮できます。
- ワークフローアクションの数を最小限に抑える
- ワークフローアクションの数が増えると処理時間が長くなります。
- トリガの数を最小限に抑える
- トリガが関連付けられたオブジェクトでは、それらのトリガが他の並列トランザクションに悪影響を及ぼさないようであれば、並列モードを使用してもかまいません。ただし、Salesforce では、複雑なトリガが関連付けられたオブジェクトを含む、サイズの大きなバッチを読み込むことは推奨していません。代わりに、すべてのデータが読み込まれた後に実行される一括処理 Apex ジョブとして、トリガのロジックを記述し直してください。
- バッチサイズを最適化する
- Salesforce では、すべての顧客組織間で処理リソースが共有されます。各組織のバッチ処理の待機時間が長くなりすぎないようにするため、処理に 10 分以上かかるバッチはいったんキューに戻され、後で処理されます。そのため、処理時間を短縮する最善の方法は、10 分以内に処理が完了するバッチを送信することです。一括処理のタイミングの監視についての詳細は、「バッチの監視」を参照してください。
- 処理時間に基づいてバッチサイズを調整します。まず 5,000 件のレコードを含むバッチで処理を試行し、処理時間に応じてサイズを調整します。1 つのバッチの処理に 5 分以上かかるようなら、バッチサイズを小さくしたほうがよいでしょう。数秒で完了するようであれば、バッチサイズを大きくします。バッチの処理時にタイムアウトエラーが発生する場合は、バッチをより小さなサイズに分割して再試行します。詳細は、「制限」を参照してください。
- 非同期キュー内の一括処理数を最小限に抑える
- Salesforce では、キューベースのフレームワークを使用して、Apex の future ジョブや一括処理、Bulk API 一括処理などの供給元からの非同期プロセスを処理します。このキューは、組織間で要求ワークロードを調整するために使用します。キュー内で 1 つの組織の未処理要求が 2,000 を上回ると、その組織からの以降の要求は遅延し、その間に他の組織からの要求が処理されます。一括処理がキュー内で遅延しないようにするには、一度に送信できる一括処理の数を最小限に抑えます。