Batching: амортизируй фиксированную цену каждой операции

Команда две недели гоняется за медленным ingest-пайплайном. CPU простаивает, сеть простаивает, диск простаивает — а 1000 строк вставляются 9 секунд. Ничто не «занято». Профайлер наконец указывает на очевидное: 1000 отдельных INSERT, 1000 отдельных round-trip к Postgres, и каждый ждёт ACK перед следующим. Заменили цикл на один COPY. То же железо, те же строки: 14 миллисекунд. Они ничего не ускорили — просто перестали платить пошлину тысячу раз.

Модель фиксированной vs переменной цены

У каждой операции две цены. Переменная масштабируется с данными: сериализовать 4 КБ дороже, чем 40 байт. Фиксированная платится за вызов независимо от размера — и обычно это дорогая половина. Syscall платит переход user→kernel и обратно. Сетевой вызов платит полный round-trip плюс ACK. Запись в БД платит планирование запроса, commit транзакции и WAL flush. Строка лога платит fsync.

Запишем общую цену N операций как total = N * (F + V), где F — фиксированная, V — переменная на элемент. Когда F доминирует над V, а N велик, почти всё, что ты платишь — это F, повторённый N раз, и сами данные — погрешность округления. Batching меняет форму на total = F + N * V: ты платишь F один раз и V на элемент. Фиксированная цена амортизирована по всему батчу. Это единственное алгебраическое движение — вынести F за пределы цикла — и есть вся идея.

Вот почему медленный пайплайн был медленным. CPU, диск и сеть выглядели простаивающими, потому что узкое место — это latency, а не utilization: каждая операция жила в ожидании завершения предыдущего round-trip. Фиксированная цена никогда не была временем CPU, видимым во flame graph — это было мёртвое время на проводе и в ядре.

Фиксированная цена живёт на каждом слое

Причина, по которой batching встречается всюду — TCP Nagle, Kafka linger.ms, Postgres COPY, Redis pipelining, io_uring submission queues, syslog buffering — в том, что у каждого слоя стека своя пошлина за операцию. Знание, какую именно фикс. цену ты амортизируешь, говорит, насколько большим будет выигрыш.

Случай Redis — самая чистая иллюстрация модели. Через линию с 250 мс RTT сервер, способный обслуживать 100k запросов/сек, ограничен 4 запросами/сек, если клиент ждёт каждый ответ — потому что узкое место это RTT, платимый на каждую команду. Запайплайнь команды — и платишь один RTT за весь батч: throughput прыгает обратно к реальному потолку сервера. Железо не менялось; фиксированная цена просто перестала повторяться.

Окно: размер и max-wait

Батч не собирается бесплатно — элементы должны накопиться перед отправкой. Это накопление управляется окном с двумя ручками, и что сработает первым — закрывает батч:

• Размер — лимит по числу или байтам. batch.size Kafka по умолчанию 16 КБ; заполнил — батч сбрасывается немедленно.
• Max-wait — лимит по времени. linger.ms Kafka (по умолчанию 5 мс в современных версиях) — это максимум, сколько producer держит недозаполненный батч в надежде, что придёт ещё.

Под высокой нагрузкой батчи заполняются раньше таймера, так что ты едешь на лимите размера и получаешь почти максимальную амортизацию бесплатно. Под лёгкой нагрузкой батч закрывает таймер — и вот тут прячется цена. Элемент, пришедший в пустое окно, платит полный linger.ms мёртвого времени, хотя система простаивает. Бо́льшие окна покупают больше throughput на единицу фикс. цены, но списывают это с tail-latency: элементы в начале окна ждут дольше всех. Поздние уроки уйдут глубоко в тюнинг этого; пока держи форму — окно это диал между throughput и tail-latency, и сеньорный вопрос никогда не «батчить или нет», а «какое окно держит p99 под SLO?».

Где НЕ батчить

Batching не бесплатен, и сеньор знает случаи, где это чистый убыток:

1. Редкие операции. Нет queue depth — нет элементов для амортизации, ты просто добавляешь linger.ms чистой latency к одному вызову. Батч из одного медленнее, чем без батча.
2. Жёсткий sub-миллисекундный SLO. Если контракт p99 < 1ms, любое окно ожидания его ломает. Математика амортизации выигрывает по throughput, но latency тебе тратить нечем.
3. Causal зависимость между операциями. Если вход операции N+1 зависит от подтверждённого результата операции N, ты не можешь запустить их группой — они последовательны по определению.
4. Нельзя терпеть partial-batch loss. Батч часто подтверждается или теряется как единица. Если падение одной записи не должно откатывать её 999 соседей, или крах в середине батча не должен терять забуференные-но-неподтверждённые элементы — твоя failure model дерётся с границей батча.