PostgreSQL для трекера: что тормозит БД при миллионах событий

PostgreSQL для трекера: что тормозит БД при миллионах событий

Если трекер пишет клики, конверсии и логи в одну таблицу без дисциплины, PostgreSQL быстро превращается в дорогой склад мусора. Основные убийцы: жирные строки, бесконечные UPDATE, плохие индексы и отсутствие партиционирования. Под капотом всё устроено проще, чем кажется.

Рабочая схема для большого потока данных:
— разделяй hot-данные и архив по времени;
— режь таблицы по дням или неделям, если запросы почти всегда фильтруют по периоду;
— держи индексы только под реальные WHERE и JOIN, а не “на всякий случай”;
— для событий пиши INSERT, а не UPDATE, где это возможно.

Для трекеров особенно важны три вещи: fillfactor, autovacuum и размер строки. Не пихай в основную таблицу JSON с лишними полями, user-agent и сырой креатив, если это редко читается. Выноси тяжёлые атрибуты в отдельную таблицу или в холодное хранилище. Иначе VACUUM будет не лечить, а лишь откладывать падение.

Проверяй планы через EXPLAIN ANALYZE, смотри на seq scan там, где должен быть index scan, и не бойся BRIN для больших append-only таблиц. Контроль над стеком — это контроль над прибылью. Владей своим софтом, а не арендуй его.