Как стать автором
Обновить

Комментарии 6

Не могли бы вы поправить примеры кода в статье и добавить try с ресурсами?
Я боюсь, что кто-нибудь скопирует это к себе as-is и начнёт использовать.
Поправил.
Батч от 10 до 50? Вообще я реально использовал в проме размеры батчей до 1000 примерно, и производительность вставки все еще росла (нагрузка на СУБД впрочем росла тоже). Так что я бы посоветовал самому померять, и прикинуть, что вам важнее — в зависимости от того, какое у вас железо, и сколько запросов вы хотите пропихнуть за единицу времени.
В статье, я не старался заострять внимание конкретно на размере пакета, так как здесь нужно учитывать много факторов: железо, нагрузка на БД, пропускная способность сети и т.д. Эта тема не простая и возможно заслуживает отдельного поста. Да, всё это нужно замерять и в итоге выбрать оптимальное значение размера пакета. Также нужно учитывать такой момент, что в разное время суток и даже в разные дни нагрузка на БД может меняться, если конечно с БД работает не только один сервис загружающий пакетами данные. Если взять какие-либо высоконагруженные онлайн сервисы использующие БД к примеру интернет магазин, интернет-банкинг, сервисы доставки и т.д., то там нагрузка может меняться во времени и это нужно тоже учитывать. Цель же была рассказать о самой пакетной обработке в целом с примерами, вариантами реализации и осветить некоторые важные моменты на которые стоит обратить внимание.
Так я примерно об этом же — что числовые параметры нужно просто мерять, и выбирать под себя.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации