Выбор хранилища

Базовый System Design
≈ 2 мин чтения

Начинай с операций, а не с названия базы

К этому моменту у нас есть несколько моделей хранения, и каждая сильна в своём профиле нагрузки. Чтобы выбрать хранилище, полезно пройти один и тот же путь: описать данные, паттерны доступа, требуемые гарантии и масштаб, а уже потом сравнивать варианты.

Сопоставь задачу с моделью

  • Реляционная база — когда важны связи, ограничения, транзакции и гибкие запросы по структурированным данным.
  • Key-Value Store — когда основной доступ идёт по известному ключу и нужна простая быстрая операция чтения или записи.
  • Document Database — когда данные естественно живут агрегатами с вложенной и развивающейся структурой.
  • Column-oriented Database — когда доминируют большие аналитические сканы и агрегации по части колонок.
  • Object Storage — когда нужно дёшево и надёжно хранить большие бинарные объекты.

Это не строгая таблица истинности. Конкретные продукты пересекаются по возможностям, поэтому финальное решение нужно проверять на реальной нагрузке и операционных требованиях.

Проверяй худший важный сценарий

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

Если решение выдерживает только нормальный режим, но не соответствует требованиям при отказе, это часть архитектурного риска, а не «редкий случай».

Считай стоимость эксплуатации

Дополнительная база означает отдельные резервные копии, мониторинг, обновления, права доступа, экспертизу команды и процедуры восстановления. Иногда менее специализированное, но уже знакомое хранилище оказывается лучшим решением для текущего масштаба.

Не вводи новое хранилище ради небольшого локального выигрыша. Оно должно давать преимущество, которое оправдывает дополнительную сложность системы и команды.

Разные данные могут требовать разных решений

Если одна модель действительно не закрывает разные профили нагрузки, систему можно разделить по ответственности. Например, транзакционные данные оставить в реляционной базе, файлы вынести в object storage, а быстрые lookup-данные — в key-value систему.

orders  -> relational database
sessions -> key-value store
media    -> object storage

Главное — чтобы у каждого набора данных был понятный источник истины и ясные правила синхронизации между хранилищами.