Запрос более 1 000 000 записей с использованием Salesforce Java API и поиск лучшего подхода

Question

Я занимаюсь разработкой Java-приложения, которое будет запрашивать таблицы, которые могут содержать более 1 000 000 записей. Я перепробовал все, что мог, чтобы быть максимально эффективным, но я могу достичь только на среднем уровне. около 5000 записей в минуту и ​​максимум 10000 в одной точке. Я попытался выполнить обратный инжиниринг загрузчика данных, и мой код кажется очень похожим, но все равно не повезло.

Является ли многопоточность жизнеспособным решением здесь? Я пробовал это, но с очень минимальными результатами.

Я читал и применил все, что только возможно (сжатие запросов / ответов, потоки и т. Д.), Но я не могу достичь загрузчика данных, как скорости

Следует отметить, что метод queryMore, похоже, является узким местом.

У кого-нибудь есть примеры кода или опыт, которыми они могут поделиться, чтобы направить меня в правильном направлении?

Спасибо

Answer 1

Подход, который я использовал в прошлом, состоит в том, чтобы запрашивать только те идентификаторы, которые вы хотите (что делает запросы значительно быстрее). Затем вы можете распараллелить retrieves () в нескольких потоках.

Это выглядит примерно так:

[цепочка запросов] -> BlockingQueue -> [пул потоков, выполняющих получение ()] -> BlockingQueue

Первый поток выполняет query () и queryMore () настолько быстро, насколько это возможно, записывая все идентификаторы, которые он получает, в BlockingQueue. Насколько мне известно, queryMore () - это не то, что вы должны вызывать одновременно, поэтому нет никакого способа распараллелить этот шаг. Все идентификаторы записываются в BlockingQueue. Возможно, вы захотите упаковать их в пакеты по несколько сотен, чтобы уменьшить конфликт блокировок, если это станет проблемой. Пул потоков может затем выполнять параллельные вызовы retrieve () для идентификаторов, чтобы получить все поля для объектов SObject и поместить их в очередь, чтобы остальная часть вашего приложения имела дело с ними.

Я написал библиотеку Java для использования SF API, которая может быть полезной. http://blog.teamlazerbeez.com/2011/03/03/a-new-java-salesforce-api-library/

Answer 2

С помощью Salesforce API ограничение размера пакета действительно замедляет работу. Когда вы используете методы query / queryMore, максимальный размер пакета равен 2000. Однако даже если вы можете указать 2000 в качестве размера пакета в заголовке SOAP, Salesforce может отправлять меньшие пакеты в ответ. Их решение о размере пакета зависит от активности сервера, а также от результатов вашего исходного запроса.

Я заметил, что если я отправляю запрос, который включает в себя какие-либо "текстовые" поля, размер пакета ограничен 50.

Я бы хотел убедиться, что ваши запросы запрашивают только те данные, которые вам нужны. Я знаю, что многие таблицы Salesforce заканчиваются множеством настраиваемых полей, которые могут не понадобиться для каждой интеграции.

Документация Salesforce по этому вопросу

Answer 3

Используйте Bulk-api для запроса любого количества записей из Java. Я использую его и очень эффективно работаю даже в считанные секунды, когда вы получаете результат. Возвращаемая строка разделяется запятой. Даже вы можете поддерживать пакеты, меньшие или равные 10 КБ, чтобы получать записи либо в CSV (используя open csv), либо непосредственно в String.

Дайте мне знать, если вам нужна помощь кода.

Answer 4

У нас около 14000 записей в нашем объекте Accounts, и на получение всех записей уходит довольно много времени. Я выполняю запрос, который занимает около минуты, но SF возвращает пакеты не более 500, хотя я установил размер пакета равным 2000. Каждая дополнительная операция запроса также занимает от 45 секунд до минуты. Это ограничение очень неприятно, когда вам нужно получить объемные данные.

Answer 5

Задержка станет убийцей для ситуаций такого типа - и решением будут многопоточные или асинхронные операции (с использованием NIO). Я хотел бы начать с параллельного запуска 10 рабочих потоков и посмотреть, в чем разница (при условии, что сервер поддерживает одновременное получение).

У меня нет никакого конкретного кода или чего-либо, что я могу предоставить здесь, извините - просто болезненный опыт с вызовами API, проходящими через сети с высокой задержкой.