Масштабирование баз данных
База данных — главное узкое место highload-системы. Её сложнее всего масштабировать. В отличие от приложения, которое можно просто размножить на десятки серверов, база данных хранит состояние. Данные должны быть согласованы, транзакции — целостными, а производительность — стабильной под нагрузкой.
Существует несколько стратегий масштабирования БД: вертикальное (мощнее сервер), репликация (read replicas), партиционирование (разбиение больших таблиц), шардирование (разбиение данных на части). Каждая решает свою задачу и применяется на своём этапе. В этой статье — разбор стратегий масштабирования баз данных для highload-проектов. Если нужно масштабировать БД для высоконагруженного проекта — поможем.
Почему БД — узкое место
Приложение можно масштабировать горизонтально: добавили серверов — выросла пропускная способность. С базой данных так не работает. Данные должны быть в одном месте, иначе возникают проблемы с согласованностью.
Состояние
В отличие от приложения, БД хранит состояние. Его нельзя просто «размножить» на несколько серверов без синхронизации.
ACID
Транзакции должны быть атомарными, согласованными, изолированными. В распределённой среде это сложно обеспечить.
Связность
Данные связаны между таблицами. При разбиении на части JOIN между ними становится дорогим или невозможным.
Нагрузка
База данных обрабатывает все запросы приложения. При росте трафика нагрузка на неё растёт быстрее всего.
Вертикальное масштабирование
Вертикальное масштабирование — первый шаг при росте нагрузки на БД. Увеличение CPU, RAM, быстрые диски.
Плюсы
- Простота: ничего не нужно менять в архитектуре;
- Совместимость: код приложения не меняется;
- Эффективность: больше RAM — больше данных в кеше БД;
- Целостность: все данные в одном месте.
Минусы
- Ограничения: у сервера есть предел. Дальше — только распределение;
- Дорого: мощные серверы стоят экспоненциально дороже;
- Единая точка отказа: если сервер упадёт — БД упадёт;
- Простой при апгрейде: нужно остановить сервер.
Вертикальное масштабирование — первый шаг. Но рано или поздно вы упрётесь в предел. Тогда придётся переходить к репликации или шардированию.
Репликация для чтения
Репликация (read replicas) — создание копий базы данных для обработки запросов на чтение. Мастер принимает запись, реплики — чтение.
Как работает
- Мастер: принимает INSERT, UPDATE, DELETE;
- Реплики: получают изменения через асинхронную репликацию;
- Чтение: распределяется между репликами;
- Запись: идёт только на мастер.
Плюсы
- Разгрузка мастера: чтение уходит на реплики;
- Масштабирование чтения: можно добавить несколько реплик;
- Отказоустойчивость: если мастер упадёт — реплика станет мастером;
- Геораспределение: реплики в разных регионах.
Минусы
- Задержка репликации: реплика может отставать на миллисекунды или секунды;
- Не решает запись: если узкое место — запись, реплики не помогут;
- Сложность: приложение должно маршрутизировать запросы;
- Консистентность: чтение с реплики может вернуть устаревшие данные.
💡 Важно
Репликация — это не бэкап. Если на мастере ошибка удалит данные, она попадёт на реплику. Нужны отдельные бэкапы.
Партиционирование
Партиционирование — разбиение одной большой таблицы на части (партиции) внутри одной базы данных. Партиции на одном сервере, в отличие от шардов.
Как работает
- По диапазону: партиции по дате, ID;
- По списку: партиции по региону, категории;
- По хешу: равномерное распределение;
- Прозрачность: приложение работает с таблицей как с единым целым.
Плюсы
- Производительность: запросы читают только нужную партицию (partition pruning);
- Обслуживание: можно удалять старые партиции, а не строки;
- Прозрачность: приложение не меняется;
- Проще шардирования: всё в одной БД.
Когда использовать
- Большие таблицы с естественным делением (логи, заказы, события);
- Нужно быстро удалять старые данные;
- Запросы часто фильтруют по ключу партиционирования;
- Как подготовка к шардированию.
Citus для PostgreSQL
Citus — расширение PostgreSQL для горизонтального масштабирования. Позволяет масштабировать БД без отказа от SQL и ACID.
Как работает
- Координатор: принимает запросы, маршрутизирует их;
- Воркеры: хранят данные и выполняют запросы;
- Шардирование: данные распределяются по ключу;
- Прозрачность: приложение работает с Citus как с обычным PostgreSQL.
Плюсы
- Полный SQL: не нужно отказываться от JOIN, транзакций, индексов;
- Масштабирование: до 100+ узлов, петабайты данных;
- Совместимость: работает с существующими инструментами PostgreSQL;
- Мультитенантность: идеально для SaaS.
Когда использовать
- Мультитенантные SaaS-приложения;
- Real-time аналитика на больших данных;
- Микросервисы с распределённым состоянием;
- Когда одна PostgreSQL больше не справляется.
Порядок действий
Масштабирование БД — это лестница. Каждый шаг добавляет сложность, но даёт больше возможностей.
| Шаг | Действие | Эффект |
|---|---|---|
| 1 | Индексы и оптимизация запросов | Базовый |
| 2 | Кеширование (Redis, Memcached) | Высокий |
| 3 | Пул соединений (PgBouncer) | Средний |
| 4 | Вертикальное масштабирование | Средний |
| 5 | Репликация для чтения | Высокий |
| 6 | Партиционирование | Средний |
| 7 | Шардирование | Максимальный |
💡 Важно
Большинство «нам нужно масштабирование БД» решаются одним индексом, одним кешем или одним пулом. Не начинайте с дорогих решений, пока не исчерпали дешёвые.
Ошибки
Начать с шардирования
Самое сложное решение — первым. Начинайте с оптимизации и кеша.
Репликация вместо бэкапа
Репликация защищает от сбоя сервера, но не от ошибок в данных. Нужны бэкапы.
Нет индексов
Масштабировать без оптимизации запросов. Проблема остаётся, только дороже.
Игнорирование кеша
Кеш даёт больше эффекта, чем добавление реплик. Начинать нужно с него.
Плохой ключ шардирования
Данные распределяются неравномерно. Один шард перегружен, другие простаивают.
Нет мониторинга
Не знать, где узкое место. Масштабировать «наугад».
Наши рекомендации
📌 Что вы получаете, заказывая масштабирование БД у нас
- Аудит — где узкие места
- Оптимизацию — индексы, запросы, схемы
- Кеширование — Redis, Memcached
- Репликацию — read replicas, отказоустойчивость
- Партиционирование — большие таблицы
- Шардирование — если нужно
📌 Итоговый вывод
Масштабирование БД — это лестница, по которой нужно идти по порядку.
Что нужно знать:
- Вертикальное — мощнее сервер. Просто, но ограничено
- Репликация — read replicas. Разгружает мастер
- Партиционирование — большие таблицы. Проще шардирования
- Шардирование — последний шаг. Мощно, но сложно
- Citus — расширение PostgreSQL для шардирования
- Порядок — оптимизация → кеш → пул → вертикальное → реплики → партиции → шарды
- Ошибки — начать с шардирования, нет индексов, нет кеша
Хотите масштабируемую БД? Закажите консультацию в Lead Hub.
Также рекомендуем: что такое highload, архитектура highload, масштабирование, кеширование, ошибки, высоконагруженные проекты.