PostgreSQL для трекера: как не убить БД на объёмах

PostgreSQL для трекера: как не убить БД на объёмах

Трекер с кликами, конверсиями и постбэками почти всегда страдает не от «плохой БД», а от кривой схемы и запросов. Главные враги: широкие таблицы, бессмысленные индексы и запись всего подряд в одну горячую таблицу.

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

На объёмах важнее не магия тюнинга, а предсказуемость. Следи, чтобы autovacuum успевал чистить dead tuples, иначе таблица раздувается, а запросы начинают жить своей жизнью. Для тяжёлых отчётов делай предагрегацию: дешево считать раз в минуту, а не каждый раз по миллионам строк. Контроль над стеком — это контроль над прибылью.

Если трекер начал тормозить, смотри сначала на план запроса, количество индексов и размер hot table, а уже потом лезь в shared_buffers и прочую шаманщину. Под капотом всё устроено проще, чем кажется: меньше хаоса в записи, меньше боли в чтении.