Базы данных, которые не тормозят и не теряют данные

Проектируем схему, настраиваем индексы, репликацию и шардирование. PostgreSQL, MongoDB, Redis, ClickHouse — под ваши задачи и нагрузки.

Когда база данных становится узким местом

База тормозит — тормозит всё приложение

Медленные запросы

Страница грузится 5 секунд, потому что SELECT без индекса сканирует миллион строк.

Данные растут, запросы тормозят всё сильнее

То, что работало мгновенно год назад, сейчас — 10 секунд. База не масштабируется.

Потеря данных при сбое

Упал сервер с единственной БД — всё. Резервные копии не настроены или устарели.

Нагрузка на запись убивает чтение

Клиенты жалуются, что сайт тормозит. А у вас просто отчёты считаются и блокируют таблицы.

Миграции ломают прод

Добавили колонку — всё упало. Потому что миграции тестировали непонятно где.

Нет понимания, что происходит

Кто делает тяжёлые запросы? Какие таблицы раздулись? Почему кэш не помогает? Без мониторинга — гадание.

Какие базы данных мы используем и зачем

Нет «лучшей БД». Есть подходящая под задачу

PostgreSQL — надёжность и ACID

Классические реляционные данные. Транзакции, внешние ключи, сложные JOIN. Банки, ERP, CRM, интернет-магазины.

PostgreSQL — расширяемость

JSONB, полнотекстовый поиск, географические запросы (PostGIS). Одна БД вместо нескольких.

MongoDB — гибкая схема

Документная БД. Меняете структуру данных без миграций. Прототипы, каталоги, логи, контент.

MongoDB — горизонтальное масштабирование

Шардирование из коробки. Данные не помещаются на один сервер? MongoDB размажет их по кластеру.

Redis — скорость

Данные в оперативной памяти. Кэш, сессии, очереди, счётчики, лидерборды. Микросекундные ответы.

ClickHouse — аналитика

Колоночная БД для OLAP. Миллиарды строк. Группировки, агрегации, дашборды. Ответы за секунды, а не минуты.

Этапы работы с базой данных

Как мы проектируем и сопровождаем базы данных

Анализ требований

2–4 дня

Собираем информацию о данных: структура, объёмы, типы

Оцениваем нагрузку: сколько запросов в секунду, чтение или запись преобладает

Выясняем требования к транзакциям (ACID), консистентности, доступности

Узнаём, нужны ли сложные выборки, полнотекстовый поиск, геоданные

Результат:

Документ с требованиями: объёмы данных, профиль нагрузки (OLTP / OLAP), требования к ACID и доступности

Ответственные:

Аналитик , Архитектор БД.

Выбор типа БД

1–2 дня

На основе требований выбираем тип БД:

PostgreSQL — транзакции, сложные запросы, надёжность

MongoDB — гибкая схема, быстрые прототипы, горизонтальное масштабирование

ClickHouse — аналитика, миллиарды строк, агрегации

Redis — скорость, кэш, сессии, очереди

При необходимости комбинируем несколько БД в одном проекте

Результат:

Выбран и утверждён тип (или типы) базы данных под конкретные задачи проекта

Ответственные:

Архитектор БД, Технический лид.

Проектирование схемы

3–7 дней

Проектируем таблицы / коллекции, колонки, типы данных

Определяем связи (один-ко-многим, многие-ко-многим)

Закладываем первичные, внешние и составные ключи

Добавляем индексы под частые запросы

Настраиваем ограничения (NOT NULL, UNIQUE, CHECK)

Результат:

ER-диаграмма (схема данных) и SQL/NoSQL скрипты для создания схемы

Ответственные:

Архитектор БД, Backend-разработчик.

Настройка инфраструктуры

2–5 дней

Разворачиваем сервер БД (on-premise или облако)

Настраиваем репликацию (master-slave / master-master)

Настраиваем автоматические резервные копии (полные + инкрементальные)

Настраиваем мониторинг (Prometheus + Grafana, slow query log)

Конфигурируем connection pool (минимум / максимум соединений)

Тюним параметры БД под нагрузку (shared_buffers, work_mem и т.д.)

Результат:

Рабочий кластер БД с репликацией, бэкапами, мониторингом и оптимальными параметрами

Ответственные:

DevOps инженер, Администратор БД.

Оптимизация запросов

Включаем slow query log, находим самые тяжёлые запросы

Анализируем план выполнения через EXPLAIN

Добавляем недостающие индексы

Переписываем неоптимальные SELECT (убираем SELECT *, добавляем JOIN вместо подзапросов)

Денормализуем там, где это оправдано

Сопровождение и масштабирование

постоянно

Мониторим производительность ежедневно

Периодически обновляем версии СУБД (с тестированием)

Регулярно проверяем восстановление из бэкапов

При росте данных — добавляем реплики на чтение

Когда данных слишком много для одного сервера — внедряем шардирование

При изменении нагрузки — пересматриваем параметры и индексы

Результат:

База данных работает стабильно годами. Данные не теряются. Нагрузка не убивает производительность

Ответственные:

Администратор БД, DevOps инженер.

Почему базы данных часто становятся проблемой

Как делают «для галочки»

Как делаем мы

Индексы на все колонки подряд. INSERT тормозит, SELECT не ускорился

Анализируем реальные запросы. Ставим индексы только там, где они действительно нужны

Миграции — вручную на проде. «Ой, что-то пошло не так»

Миграции кодом, через CI/CD. Откат за минуту. Тестируем на копии прода

Нет мониторинга. Узнаём о проблеме от клиента

Slow query log + Prometheus + Grafana. Увидели проблему до того, как клиент заметил

Один мастер на всё. Нагрузка на чтение убивает запись

Master-replica. Чтение — на реплики. Запись — на мастер. Нагрузка распределена

Бэкап раз в сутки. Последний час данных потеряли

Автоматические бэкапы каждые 15 минут + WAL архивация. Point-in-time recovery

Данные растут, запросы тормозят. Никто не знает, что делать

Анализируем, предлагаем решение: шардирование, партиционирование, смена типа БД

Connection pool не настроен. 1000 подключений — БД легла

Настроили pool: min=10, max=50. БД дышит свободно

Расскажите о данных — предложим архитектуру БД

Пришлите описание: какая БД сейчас, сколько данных, какие запросы самые тяжёлые, какие проблемы беспокоят.
Мы проанализируем и предложим: индексы, оптимизацию, репликацию, шардирование или полную смену типа БД.