Высоконагруженные сайты (от 10 000 RPS) упираются не в код приложения, а в базу данных. Правильная оптимизация СУБД — это разница между стабильной работой и полным коллапсом системы. Рассмотрим три фундаментальных инструмента: индексы, кэширование и репликацию.
Индексы: основа производительности запросов
Типы индексов и их применение
B-деревья — стандарт для большинства запросов (диапазоны, равенства)
Хеш-индексы — только для точных совпадений (=), не работают для диапазонов
Составные индексы — правильный порядок колонок критичен (A,B,C ≠ C,B,A)
Антипаттерны индексирования
- Индексы по всем колонкам — замедляют INSERT/UPDATE
- Слишком много индексов (более 5-7 на таблицу) — убивают производительность записи
- Индексы по низкокардинальным полям (пол/статус с 2-3 значениями) — бесполезны
Практическое правило
Индекс должен покрывать 80% запросов, а не 100% таблицы. Анализируйте slow query log ежедневно.
Кэширование: искусство забывания правильно
Уровни кэширования
Уровень 1: Кэш запросов в СУБД
- MySQL query cache (устарел, в 8.0 удалён)
- PostgreSQL pgpool-II для балансировки + кэша
- Важно: инвалидация при изменении данных
Уровень 2: Кэш результатов приложения (Redis/Memcached)
Типичная стратегия:
1. Проверить кэш по ключу
2. Если нет — запросить БД
3. Сохранить в кэш с TTL
4. Вернуть данные
Уровь 3: Read-Through кэширование
- Приложение всегда читает из кэша
- Кэш сам подгружает данные из БД при промахе
- Сложнее, но эффективнее для read-heavy нагрузки
Критические ошибки кэширования
- Кэширование без TTL — устаревшие данные на дни
- «Тёплый» кэш при рестарте — лавина запросов к БД
- Кэширование личных данных — проблемы с безопасностью
Репликация: распределение нагрузки
Мастер-слейв архитектура
Мастер (Master) → Запись
├→ Слейв 1 (Slave) → Чтение (30% нагрузки)
├→ Слейв 2 (Slave) → Чтение (30% нагрузки)
└→ Слейв 3 (Slave) → Чтение + бэкапы (40% нагрузки)
Современные подходы
PostgreSQL: Streaming replication + логическая репликация
MySQL: GTID-based репликация (глобальные идентификаторы транзакций)
MongoDB: Replica Sets с автоматическим фейловером
Задержка репликации (Replication Lag) — главный враг
- Пользователь добавил комментарий → не видит его 2 секунды
- Решение: sticky sessions или чтение своих записей с мастера
Комбинированная стратегия для 100 000 RPS
Пример архитектуры для e-commerce
Клиент → Load Balancer
├→ Веб-сервер 1 → Redis Cluster (сессии, кэш)
├→ Веб-сервер 2 → PostgreSQL Master (запись)
└→ Веб-сервер N → PostgreSQL Replica 1-3 (чтение)
Реальные метрики оптимизации
До оптимизации:
- Время отклика БД: 1200 мс
- Максимальная нагрузка: 5 000 RPS
- CPU БД: 95%
После внедрения:
- Индексы: -60% времени запросов
- Кэш Redis: hit rate 85%, -40% нагрузки на БД
- Репликация 1→3: -75% нагрузки на мастер
- Итог: 25 000 RPS при 40% CPU
Мониторинг и поддержка
Обязательные метрики
- Database Load: Запросов в секунду, активные соединения
- Cache Efficiency: Hit/Miss ratio, размер кэша
- Replication Health: Lag в секундах, статус реплик
- Query Performance: 95-й процентиль времени выполнения
Инструменты
Для PostgreSQL: pg_stat_statements, pgBadger
Для MySQL: Performance Schema, pt-query-digest
Универсальные: Prometheus + Grafana, Datadog APM
Паттерны для конкретных сценариев
Социальная сеть (read-heavy)
- Агрессивное кэширование ленты новостей (5 минут TTL)
- Шардинг по user_id для таблицы постов
- Асинхронная запись лайков/просмотров через очередь
Финансовый сервис (write-heavy)
- Оптимизация индексов только для критичных запросов
- Batch INSERT вместо одиночных записей
- TimescaleDB для временных рядов вместо обычных таблиц
E-commerce (смешанная нагрузка)
- Materialized Views для отчётов
- Кэширование каталога с инвалидацией при изменении цены
- Connection pooling PgBouncer для управления соединениями
Типичные ошибки при масштабировании
- Премьерная оптимизация без профилирования — индексы по догадкам
- Кэш как костыль для плохих запросов — сначала оптимизируйте запросы
- Бесконечные реплики — каждая реплика тоже требует ресурсов
- Игнорирование мониторинга — проблемы обнаруживаются пользователями
Заключение: принцип 80/20 для оптимизации БД
80% результата дают:
- Правильные индексы на самые частые запросы
- Стратегический кэш для данных, которые редко меняются
- Балансировка чтения на реплики
Остальные 20% — тонкая настройка, которая зависит от конкретной нагрузки, данных и бизнес-логики.
Ключевое правило: Оптимизируйте на основе данных, а не предположений. Каждый день анализируйте slow queries, мониторьте hit rate кэша и следите за lag репликации. Высоконагруженная БД — это не статичная система, а живой организм, требующий постоянного внимания.
Канал в телеграмм — https://t.me/+-BsUnghNcJ81OGYy
Наш канал на Youtube — https://youtube.com/@traff058
Telegram Паблик — https://t.me/+R2NG4GVGqS4yOTky
Паблик в VK — https://vk.com/traff_agency
Инстаграм TRAFF — https://www.instagram.com/traff_agency
Блог на vc.ru — https://vc.ru/u/2452449-studiya-razrabotki-saitov-traff
Сервисы, которыми пользуемся мы: хостинг Beget — https://beget.com/p1898855
