Требования к хранилищу

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

Сначала опиши нагрузку на данные

Перед выбором базы данных нужно понять, что именно система будет хранить и как с этим будут работать. Одинаковый объём данных может требовать совершенно разных решений, если в одном случае почти всё читают, а в другом постоянно записывают и обновляют.

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

Объём и рост

Нужно оценивать не только размер данных сегодня, но и скорость их появления. Если система создаёт 50 ГБ в день, то за год это уже десятки терабайт без учёта реплик, индексов и резервных копий.

daily growth = 50 GB
one year    ≈ 18 TB

Для некоторых данных важен срок хранения. Сырые события можно держать несколько месяцев, а профиль пользователя — годами. Политика retention напрямую влияет на итоговый объём.

Чтения и записи

Система должна понимать не только RPS в целом, но и распределение операций. Например, каталог товаров может иметь много чтений и относительно мало изменений, а телеметрия устройств — огромное число последовательных записей.

Также важна форма доступа: чтение по идентификатору, диапазону времени, нескольким полям, сложный join или большой аналитический scan. Именно паттерн доступа часто определяет подходящую модель хранения.

Latency, availability и consistency

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

Нужно отдельно определить требования к доступности: может ли операция подождать восстановления, или сервис должен продолжать отвечать даже при отказе части инфраструктуры.

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

Данные тоже имеют форму

Структура данных влияет на выбор не меньше нагрузки. Если сущности сильно связаны и правила целостности важны, это один профиль задачи. Если объект обычно читается целиком и имеет гибкий набор полей — другой.

После такой характеристики уже имеет смысл сравнивать конкретные классы хранилищ. Без неё выбор превращается в спор о технологиях без привязки к задаче.