1,000,000 を超えるレコードを保持する可能性のあるテーブルをクエリする Java アプリケーションを開発しています。できるだけ効率的になるようにできる限りのことを試みましたが、平均でしか達成できません。1 分間に約 5,000 レコード、ある時点で最大 10,000 レコード。データ ローダーのリバース エンジニアリングを試みましたが、私のコードは非常に似ているように見えますが、まだうまくいきません。
ここでスレッド化は実行可能な解決策ですか? 私はこれを試しましたが、非常に最小限の結果しか得られませんでした。
私は読んでいて、可能な限りすべてのもの（リクエスト/レスポンスの圧縮、スレッドなど）を適用しましたが、速度のようなデータローダーを達成できません。
なお、queryMoreメソッドがボトルネックになっているようです。
私を正しい方向に導くために共有できるコードサンプルや経験を持っている人はいますか?
ありがとう
私が過去に使用したアプローチは、必要な ID だけを照会することです (これにより、照会が大幅に高速化されます)。その後、複数のスレッドで retrieves() を並列化できます。
それは次のようになります。
[クエリ スレッド] -> BlockingQueue -> [retrieve() を実行しているスレッド プール] -> BlockingQueue
最初のスレッドは、query() と queryMore() をできるだけ速く実行し、取得したすべての ID を BlockingQueue に書き込みます。私の知る限り、 queryMore() は同時に呼び出す必要がないため、このステップを並列化する方法はありません。すべての ID が BlockingQueue に書き込まれます。ロックの競合が問題になる場合は、それらを数百のバンドルにパッケージ化して、ロックの競合を減らすことをお勧めします。その後、スレッド プールは ID に対して同時 retrieve() 呼び出しを実行して、SObject のすべてのフィールドを取得し、アプリケーションの残りの部分が処理できるようにそれらをキューに入れることができます。
便利な SF API を使用するための Java ライブラリを作成しました。http://blog.teamlazerbeez.com/2011/03/03/a-new-java-salesforce-api-library/
Salesforce API では、バッチ サイズの制限が実際に速度を低下させる可能性があります。query/queryMore メソッドを使用する場合、最大バッチ サイズは 2000 です。ただし、SOAP ヘッダーでバッチ サイズとして 2000 を指定しても、Salesforce は応答としてより小さいバッチを送信する場合があります。バッチ サイズの決定は、サーバー アクティビティと元のクエリの出力に基づいています。
「テキスト」フィールドを含むクエリを送信すると、バッチ サイズが 50 に制限されることに気付きました。
私の提案は、クエリが必要なデータのみをプルしていることを確認することです。多くの Salesforce テーブルには、すべてのインテグレーションで必要とされない可能性のある多くのカスタム フィールドが含まれていることを私は知っています。
このテーマに関するSalesforce ドキュメント
Accounts オブジェクトには約 14000 のレコードがあり、すべてのレコードを取得するにはかなりの時間がかかります。約 1 分かかるクエリを実行しますが、batchsize を 2000 に設定しても、SF は 500 以下のバッチしか返しません。各クエリの操作には 45 秒から 1 分かかります。大量のデータを取得する必要がある場合、この制限は非常にイライラします。
Bulk-api を使用して、Java から任意の数のレコードをクエリします。私はそれを利用しており、数秒で結果が得られても非常に効果的に実行しています. 返される文字列はカンマ区切りです。10k 以下のバッチを維持して、CSV (open csv を使用) または文字列で直接レコードを取得することもできます。
コードのヘルプが必要な場合はお知らせください。
レイテンシーはこのタイプの状況のキラーになります-そして解決策はマルチスレッドまたは非同期操作（NIOを使用）のいずれかです。まず、10個のワーカースレッドを並行して実行し、それがどのような違いをもたらすかを確認します（バックエンドが同時取得をサポートしていると仮定します）。
ここで提供できる具体的なコードや何かはありません。申し訳ありませんが、高遅延ネットワークを介したAPI呼び出しの苦痛な経験だけです。