Запрос более 1 000 000 записей с использованием Salesforce Java API и поиск наилучшего подхода
Я занимаюсь разработкой Java-приложения, которое будет запрашивать таблицы, которые могут содержать более 1000 000 записей. Я перепробовал все, что мог, чтобы быть максимально эффективным, но я могу достичь только на среднем уровне. около 5000 записей в минуту и максимум 10000 в одной точке. Я попытался выполнить обратный инжиниринг загрузчика данных, и мой код, похоже, очень похож, но все же не повезло.
Является ли многопоточность жизнеспособным решением здесь? Я пробовал это, но с очень минимальными результатами.
Я читал и применил все, что только возможно (сжатие запросов / ответов, потоки и т. Д.), Но я не могу достичь загрузчика данных, как скорости.
Отметим, что кажется, что метод queryMore является узким местом.
У кого-нибудь есть примеры кода или опыт, которыми они могут поделиться, чтобы направить меня в правильном направлении?
Спасибо
5 ответов
Подход, который я использовал в прошлом, состоит в том, чтобы запрашивать только те идентификаторы, которые вы хотите (что делает запросы значительно быстрее). Затем вы можете распараллелить retrieves() в нескольких потоках.
Это выглядит примерно так:
[запрос потока] -> BlockingQueue -> [пул потоков, выполняющий функцию retrieve()] -> BlockingQueue
Первый поток выполняет query() и queryMore() настолько быстро, насколько это возможно, записывая все идентификаторы, которые он получает, в BlockingQueue. Насколько мне известно, queryMore() - это не то, что вы должны вызывать одновременно, поэтому нет никакого способа распараллелить этот шаг. Все идентификаторы записываются в BlockingQueue. Возможно, вы захотите упаковать их в пакеты по несколько сотен, чтобы уменьшить конфликт блокировок, если это станет проблемой. Пул потоков может затем выполнять параллельные вызовы retrieve () для идентификаторов, чтобы получить все поля для объектов SObject и поместить их в очередь, чтобы остальная часть вашего приложения имела дело с ними.
Я написал библиотеку Java для использования SF API, которая может быть полезной. http://blog.teamlazerbeez.com/2011/03/03/a-new-java-salesforce-api-library/
При использовании Salesforce API ограничение размера пакета действительно замедляет работу. Когда вы используете методы query/queryMore, максимальный размер пакета равен 2000. Однако даже если вы можете указать 2000 в качестве размера пакета в заголовке SOAP, Salesforce может отправлять меньшие пакеты в ответ. Их решение о размере пакета зависит от активности сервера, а также от результатов вашего исходного запроса.
Я заметил, что если я отправляю запрос, который содержит какие-либо текстовые поля, размер пакета ограничен 50.
Я бы хотел убедиться, что ваши запросы запрашивают только те данные, которые вам нужны. Я знаю, что многие таблицы Salesforce заканчиваются множеством настраиваемых полей, которые могут не понадобиться для каждой интеграции.
Документация Salesforce по этому вопросу
Используйте Bulk-api для запроса любого количества записей из Java. Я использую его и очень эффективно работаю даже в считанные секунды, когда вы получаете результат. Возвращаемая строка разделяется запятой. Даже вы можете поддерживать пакеты, меньшие или равные 10 КБ, чтобы получать записи либо в CSV (используя open csv), либо непосредственно в String.
Дайте мне знать, если вам нужна помощь кода.
У нас есть около 14000 записей в нашем объекте Accounts, и на получение всех записей уходит довольно много времени. Я выполняю запрос, который занимает около минуты, но SF возвращает пакеты не более 500, хотя я установил размер пакета равным 2000. Каждая дополнительная операция запроса также занимает от 45 секунд до минуты. Это ограничение довольно неприятно, когда вам нужно получить объемные данные.
Задержка станет убийцей для ситуаций такого типа - и решение будет или многопоточными, или асинхронными операциями (с использованием NIO). Я хотел бы начать с параллельного запуска 10 рабочих потоков и посмотреть, в чем разница (при условии, что сервер поддерживает одновременное получение).
У меня нет никакого конкретного кода или чего-либо, что я могу предоставить здесь, извините - просто болезненный опыт с вызовами API, проходящими через сети с высокой задержкой.