Решение: шардинг или репликация (масштабирование)?
Решение о масштабировании БД зависит от того, где узкое место — в чтении или записи, и помещаются ли данные на один узел. Неверная стратегия означает лишнюю сложность или нерешённое узкое место. Это дерево сначала напоминает о самых дешёвых и простых вариантах (вертикальное масштабирование, кэширование), а затем помогает правильно выбрать между репликами для чтения и шардингом.
Вы сначала попробовали самый простой путь: вертикальное масштабирование и оптимизацию запросов?
Прежде чем переходить к распределённой архитектуре, возьмите самый дешёвый выигрыш: наращивание оборудования (CPU/RAM/IOPS), добавление недостающих индексов и исправление дорогих запросов решают большинство узких мест. Добавляйте сложность, только когда эти возможности исчерпаны.
- Нет / я ещё не упёрся в предел
- Да, вертикального масштабирования и оптимизации недостаточно
Узкое место — чтение или запись/объём данных?
Определите источник проблемы масштабирования: множество запросов на чтение перегружает один узел (нагрузка с преобладанием чтения), или скорость записи либо общий объём данных превышают возможности одного узла (преобладание записи/объёма)? Это различие — фундаментальная разница между репликами и шардингом.
- Преобладает трафик чтения, запись помещается на один узел
- Скорость записи или объём данных превышают один узел
Чтения повторяющиеся/кэшируемые или свежие и разнообразные?
Разберите узкое место чтения ещё на шаг: одни и те же результаты читаются снова и снова (кэш очень эффективен) или чтения запрашивают разнообразные, широкие и актуальные данные (нужна дополнительная мощность чтения)? Это определяет выбор между уровнем кэша и репликами для чтения.
- Одни и те же данные читаются многократно, небольшое устаревание допустимо
- Разнообразные/свежие чтения, нужна чистая мощность чтения
Рекомендация: сначала вертикальное масштабирование + оптимизация запросов
Первый и самый дешёвый путь перед переходом к распределённой архитектуре. Наращивание оборудования и исправление запросов/индексов решают большинство проблем масштабирования без добавления операционной сложности.
Рекомендация: реплики для чтения (масштабирование чтения)
Запись остаётся на одном узле (первичном), а трафик чтения распределяется по одной или нескольким репликам. Это стандартный способ увеличить мощность чтения и устойчивость для нагрузок с преобладанием чтения.
Рекомендация: уровень кэша
Хранение часто перечитываемых результатов в быстром слое в памяти резко снижает нагрузку на базу данных. При правильном паттерне он отвечает, не обращаясь к базе данных, снижая и задержку, и нагрузку.
Рекомендация: шардинг (масштабирование записи/данных)
Данные делятся по ключу шардинга и распределяются по нескольким независимым узлам; каждый узел владеет частью данных и их записью. Это способ масштабировать скорость записи и общий объём данных, но он существенно добавляет сложности.