PostgreSQL, будучи одной из самых популярных реляционных баз данных с открытым исходным кодом, традиционно воспринимается как инструмент для классовых сценариев хранения и обработки данных. Однако современные технологические компании все чаще сталкиваются с необходимостью обрабатывать огромные объёмы событий в реальном времени, что приводит к поиску эффективных и устойчивых решений для организации систем очередей. Благодаря проекту RudderStack, который успешно масштабировал систему очередей на PostgreSQL до 100 тысяч событий в секунду, появилась уникальная возможность изучить передовые практики и важные уроки, которые помогли достичь такого впечатляющего результата. В этом материале мы подробно рассмотрим особенности архитектуры очередей на Postgres, оптимизации, с которыми пришлось столкнуться, и стратегии повышения производительности при масштабировании таких систем. История выбора PostgreSQL как основного механизма стриминга и организации очередей связана с его гибкостью, надежностью транзакций и удобством в отладке, что поначалу делало специализированные решения вроде Apache Kafka менее предпочтительными.
Основной вызов заключался в создании структуры, способной обеспечить быструю обработку множества задач без типичных проблем масштабируемости: разрастания таблиц, ухудшения производительности запросов, узких мест в индексах и скачков из-за повторных попыток обработки. В центре структуры очередей находится набор данных, обычно размером около ста тысяч заданий. Каждая очередь разбита на несколько таких наборов — датасетов, что позволяет поддерживать более быстрые и эффективные индексные сканирования, минимизируя негативные эффекты роста таблиц. Основной схематический элемент — это две связанные таблицы: таблица задач, где хранится полезная нагрузка и метаданные для каждой задачи, и таблица статусов, служащая логику жизненного цикла задачи, отражая ее текущее состояние через запись в режиме добавления. Индексация оказалась краеугольным камнем производительности.
На этапе роста нагрузок простые первичные ключи перестали справляться с нагрузкой из-за увеличения задержек при извлечении задач. Анализ SQL-запросов с помощью EXPLAIN ANALYZE выявил узлы, имеющие наибольшее время выполнения, и позволил разработать комплексные составные индексы, учитывающие поля, часто используемые в условиях WHERE и ORDER BY, что значительно ускорило выборку данных для конкретных конвейеров обработки. Однако следует соблюдать баланс, так как чрезмерное количество индексов может вызвать торможение вставок и возрастание использования дискового пространства, что на практике приводит к росту блоата, ухудшению производительности и дополнительным накладным расходам. Другая важнейшая внутренняя оптимизация — использование Index-Only Scans (IOS), которые позволяют PostgreSQL выполнять покупки данных исключительно из индексных структур без обращения к главным таблицам. Несмотря на высокую эффективность такого подхода, успешность применения IOS зависит от состояния visibility map, которая отслеживает доступность данных для текущих транзакций.
В системах с интенсивной нагрузкой на запись, подобных очередям, постоянное обновление visibility map становится проблемой, затрудняя достижения устойчивых IOS и требуя регулярного обслуживания, например, операций VACUUM. Особый интерес вызывают методы обхода ограничений отсутствия поддержки в PostgreSQL «loose index scan», которые в других СУБД позволяют ускоренно получать уникальные ключи из индексов. В RudderStack вместо стандартного SELECT DISTINCT применяются рекурсивные CTE, которые значительно улучшают производительность при выборе уникальных идентификаторов конвейеров, обходя множество повторяющихся значений, что критично для своевременного определения активных задач и распределения нагрузки по воркерам. Одной из острых проблем при масштабах 100 тысяч событий в секунду является рост таблицы статусных обновлений, особенно в сценариях массовых повторных попыток обработки — так называемых retry storms, когда множество задач многократно пытаются пройти обработку из-за временных ошибок. Это приводит к миллионам записей за малый промежуток времени, что сильно раздувает таблицы и замедляет критичные запросы.
Компактирование статусов, при котором сохраняется только последний статус задачи, а старые записи удаляются, стало ключевой тактикой для борьбы с блоатом таблиц. Это требует регулярных операций VACUUM ANALYZE для освобождения места и обновления статистики, благодаря чему планировщик запросов выбирает быстрые и эффективные планы выполнения. Высокая скорость вставки данных достигается благодаря активному использованию команды COPY для пакетной загрузки, которая значительно превосходит по производительности обычные «INSERT» выражения, снижая нагрузку на логирование и упрощая контроль транзакций. При развитии системы подход к компактированию данных тоже эволюционировал. Сначала компактизация запускалась по фиксированному порогу процента обработанных задач, но из-за накладных расходов и необходимости приостанавливать операции на время копирования был найден новый баланс.
Быстрая очистка полностью обработанных датасетов путем их полного удаления и более избирательная компактизация активных наборов без значительного простоя обеспечили стабильность и высокая доступность очередей. В условиях большого количества датасетов естественно возникла проблема излишних проверок во время поиска задач конкретных конвейеров. Для борьбы с задержками был разработан так называемый «No Jobs Cache», позволяющий на уровне приложения игнорировать датасеты, где для заданного конвейера нет активных задач, сокращая число обращений к базе. Параллельно применяется кэш активных конвейеров с маленьким TTL, заметно уменьшающий нагрузку на базу при частом опросе изменений. Интересным техническим наблюдением стала аномалия с типами данных в Go.
Было замечено, что передача байтовых срезов существенно увеличивает объем сетевого трафика из-за того, что драйвер PostgreSQL кодирует их в hex, удваивая размер передаваемых данных по сравнению с строками, которые напрямую отправляются как UTF-8. Переключение на представление payload в виде строк существенно снизило сетевые издержки и оптимизировало общую производительность. Мониторинг дисковой подсистемы выявил стойкий эффект write amplification — фактический объем записи на диск в итоге примерно в три раза превышал логические данные. Этот фактор связан с особенностями Write-Ahead Logging, характером записи страниц размера 8Кб, необходимостью обслуживания индексных структур и специфическими механизмами хранения больших значений (TOAST). Понимание этого было важно для правильного прогнозирования производительности и выбора подходящей инфраструктуры.
Важный сдвиг в производительности происходит при переходе из режима, когда весь рабочий набор помещается в оперативную память, к условиям, когда операции активно обращаются к диску. Быстрая память обеспечивает практически мгновенный доступ к данным, но когда объем обрабатываемых данных превышает возможности кеша, производительность зависит от того, как эффективно организованы запросы и как оптимизирован доступ к накопителям. Для этого в RudderStack активно прогнозируют и тестируют нагрузки с учётом ограничения памяти, чтобы принять своевременные решения о масштабировании и оптимизации. Важным аспектом, влияющим на характеристики базы, являются настроечные параметры PostgreSQL, которые подбирались специально под высокие нагрузки с интенсивными операциями записи. Увеличение размера WAL буферов и общей емкости WAL позволило снизить частоту контрольных точек, сгладить нагрузку записи, а более частые, но короткие контрольные точки повысили устойчивость к сбоям.
Параметры, связанные с памятью для сортировок и хеш-операций, изменялись для достижения баланса между эффективностью и потреблением ОЗУ. Снижение параметра random_page_cost адаптировало планировщик запросов под SSD диски, более агрессивная работа autovacuum способствовала своевременной очистке мертвых строк и улучшению статистики. Полученный опыт демонстрирует, что PostgreSQL при грамотной адаптации и постоянном мониторинге способен эффективно выполнять роль надежной системы очередей для сверхнагруженных потоков событий. Добиться производительности в 100 тысяч событий в секунду оказалась задачей комплексной, требующей баланса между архитектурными решениями, оптимизацией запросов, управлением данными и системными настройками. Такой путь наверняка будет полезен всем, кто стремится построить масштабируемую, отзывчивую и устойчивую систему, управляемую средствами с открытым исходным кодом, исключая необходимость использования исключительно специализированных решений.
Продолжение роста данных, изменения моделей доступа и уровень конкуренции в современных приложениях требуют постоянного совершенствования и гибкого подхода к инфраструктуре, делая PostgreSQL ценным инструментом в арсенале инженера данных.
