PostgreSQL в трекере: как не убить БД на объёмах трафика

PostgreSQL в трекере: как не убить БД на объёмах трафика

Если трекер пишет клики, конверсии и постбэки без остановки, PostgreSQL быстро превращается в склад мусора. База начинает тормозить не из-за “плохого железа”, а из-за кривой модели записи: слишком много мелких INSERT, тяжёлые индексы и запросы, которые читают лишнее.

Рабочая схема простая:
— разносите hot-таблицы и архив по времени или партициям;
— оставляйте только те индексы, которые реально ускоряют выборку;
— для событийных таблиц используйте fillfactor и не душите autovacuum ручными костылями;
— тяжёлую аналитику выносите в отдельную реплику или витрину, а не в боевую запись.

Для трекеров особенно важны bulk-insert и батчи. Один INSERT на событие — это способ красиво сжечь IOPS. Гораздо лучше копить события в буфер, писать пачками и держать транзакции короткими. Если таблица разрастается, партиционирование по дате или кампании упрощает удаление старого мусора без долгих DELETE и VACUUM-адов.

Не забывайте про планы запросов: EXPLAIN должен стать привычкой, а не ритуалом для галочки. Часто узкое место не в PostgreSQL, а в запросе с JOIN по полям, которые никто не индексировал, или в попытке считать отчёт по сырой таблице за всё время. Контроль над стеком — это контроль над прибылью. Владей своим софтом, а не арендуй его.