Data Storage & Consistency
Выбор хранилища начинается с владения данными, access patterns и требуемых гарантий. «SQL против NoSQL» не является идеологическим выбором: каждый вариант по-разному сочетает гибкость запросов, транзакции, consistency, масштабирование, операционную сложность и стоимость.
Source of truth и access patterns
Выберите основной source of truth до добавления реплик, индексов и кэшей. Определите, какой компонент принимает авторитетные записи, какие данные нужно надёжно сохранить до возврата успеха и какие чтения могут обращаться к копии.
Реляционное хранилище часто подходит, когда:
- важны связи и структурированные запросы;
- нужны транзакции над несколькими записями;
- ограничения должны защищать инварианты;
- схема и модель запросов выигрывают от SQL.
Документное, key-value или wide-column хранилище может подойти, когда:
- access patterns просты и заранее известны;
- горизонтальное partitioning является ключевым требованием;
- полезна гибкая схема;
- компромиссы оправданы специализированной нагрузкой или очень большим масштабом.
Реляционные базы умеют масштабироваться, а нереляционные всё равно имеют ограничения consistency и эксплуатации. Оценивайте конкретный движок и нагрузку, а не лозунги о категориях.
Индексы, replication и partitioning
Индекс ускоряет выбранные чтения с помощью дополнительной структуры. Он занимает место и удорожает запись, поэтому набор индексов должен соответствовать реальным запросам.
Replication создаёт копии для redundancy, локальности или увеличения capacity чтения. Read replica снижает нагрузку на primary, но из-за replication lag может не сразу показать запись. Partitioning, или sharding, делит данные между узлами, обычно по ключу. Неудачный ключ создаёт hot partitions, неравномерное хранение и дорогие межсекционные запросы. Rebalancing и маршрутизация становятся частью дизайна.
Эволюция схемы должна учитывать данные старых версий и код разных версий во время rolling deployment. По возможности используйте обратно совместимые переходы: добавить поле, перенести данные, переключить чтение, затем удалить устаревшее поле.
Транзакции, consistency и durability
Транзакция объединяет операции с заданными гарантиями атомарности и изоляции. Она защищает инварианты, которые должны меняться вместе, но широкие распределённые транзакции могут снижать availability и throughput.
Strong consistency в неформальном обсуждении system design служит общим термином: обычно он означает, что клиенты не видят произвольно устаревшее состояние. Когда точная гарантия важна, её следует назвать явно, например linearizable reads, read-after-write consistency или session-level guarantees. Eventual consistency допускает временное расхождение реплик, которые сходятся после прекращения обновлений, успешной доставки и разрешения конфликтов по заданному правилу. Это не случайные данные: допустимые наблюдения и правила сходимости всё равно требуют контракта.
Read-after-write consistency часто является пользовательским требованием. После обновления профиля пользователь обычно ожидает сразу увидеть новое значение. Счётчики аналитики могут допускать задержку. Разные операции одной системы могут выбирать разные гарантии.
Durability отвечает на вопрос, переживут ли подтверждённые данные отказ процесса, узла или региона. Ответ зависит от момента сброса журнала, числа подтвердивших запись реплик и набора покрываемых отказов.
CAP theorem в контексте
CAP означает Consistency, Availability, Partition tolerance. Здесь consistency означает линейризуемое представление общих данных, а availability - что каждый запрос к исправному узлу в итоге получает ответ, который не обязан подтверждать запись. Формула «нужно выбрать любые два свойства» вводит в заблуждение. Когда network partition мешает узлам обмениваться данными, система должна решить для затронутой операции: отклонить или задержать работу ради сохранения consistency либо продолжить обслуживание с риском расхождения состояния ради availability.
Partition не является обычной настройкой, а consistency не сводится к одному переключателю. Для баланса счёта, просмотра профиля и счётчика аналитики могут требоваться разные решения. Лучше описывать сценарий отказа и гарантию конкретной операции, чем маркировать всю систему только как «CP» или «AP».