Database стек для affiliate-сайта с миллионом страниц: где чаще всего ломают скорость

Database стек для affiliate-сайта с миллионом страниц: где чаще всего ломают скорость

Для сетки с 1M страниц база умирает не от объёма, а от плохих запросов. Если у вас WordPress или кастомный каталог, сначала разделяйте: metadata в MySQL/PostgreSQL, тяжёлые выборки и фильтры — в кеш, поиск — в отдельный движок. Иначе каждый фильтр по GEO, офферу и языку превращается в полный скан таблицы.

Рабочая схема выглядит так:
— primary DB держит записи, статусы, связи
— Redis кеширует сессии, меню, часто читаемые карточки
— отдельный search индекс обслуживает поиск и фасеты
— фоновые задачи пишут пачками, а не по одной строке

Критичные правила:
— индексы под реальные WHERE и ORDER BY, а не «на всякий случай»
— никаких JOIN по нескольким большим таблицам в публичных страницах
— пагинация только keyset, не OFFSET на сотни тысяч строк
— для аналитики и логов — отдельная база или хранилище

Самая частая ошибка — пытаться сделать из одной базы и CMS, и поиск, и аналитику, и очередь задач. Так вы получаете рост TTFB, lock’и и деградацию админки. Для affiliate-сайта база должна отвечать быстро на простые запросы, а всё тяжёлое выносится наружу.

Если нужна стабильность, проектируйте стек так, будто трафик и контент будут расти в 10 раз: короткие запросы, минимум записей на фронте, кеш перед БД.