PostgreSQL для трекера: как не утонуть в миллиардах кликов и событий

PostgreSQL для трекера: как не утонуть в миллиардах кликов и событий

Трекер быстро превращает БД в свалку из событий, кликов и конверсий. Если хранить всё в одной таблице без дисциплины, PostgreSQL начинает страдать не от «объема», а от хаоса в схеме. Под капотом всё устроено проще, чем кажется: нагрузку убивают длинные транзакции, плохие индексы и отсутствие партиционирования.

Что работает стабильно:
— партиционирование по дате или кампании, чтобы запросы не сканировали весь архив;
— короткие индексы только под реальные фильтры: campaign_id, created_at, status;
— отдельные таблицы для сырых событий и агрегатов, чтобы отчеты не мешали записи;
— регулярный VACUUM и контроль bloat, иначе таблица раздувается без пользы.

Для горячих таблиц держите fillfactor ниже 100, если идут частые UPDATE. Для логов и кликов чаще выгоднее INSERT-only схема: меньше блокировок, проще репликация, легче архивировать старые партиции. Если отчетам нужны только сутки или неделя, не заставляйте БД читать историю за полгода — это не оптимизация, а саботаж.

В арбитраже контроль над стеком — это контроль над прибылью. Нормальная PostgreSQL-конфигурация экономит не только CPU и диск, но и нервы команды, когда поток событий растет быстрее, чем хочется.