Понимание согласованности MongoDB: Объяснение модели BASE для разработчиков

Согласованность MongoDB вызывает путаницу, потому что люди сводят её к одной фразе: "MongoDB является в конечном счёте согласованной". Это слишком грубо, чтобы быть полезным. Реплика-сет MongoDB может обеспечить строгое поведение для одних операций и устаревшие чтения для других, в зависимости от уровня записи, уровня чтения, предпочтений чтения и того, происходит ли отказоустойчивый переход.

Если вы переходите с PostgreSQL или MySQL, самое большое изменение заключается в том, что согласованность не является одним фиксированным параметром для всего приложения. Вы выбираете гарантию, которая вам нужна для каждого пути. Процесс оформления заказа, лента уведомлений и панель аналитики не требуют одинаковой свежести или долговечности.

ACID против BASE: Два подхода к согласованности

Прежде чем углубляться в модель MongoDB, полезно понять две основные парадигмы согласованности баз данных: ACID и BASE.

Свойства ACID (Традиционные РСУБД)

Традиционные реляционные системы управления базами данных (РСУБД), такие как PostgreSQL или MySQL, обычно придерживаются свойств ACID, обеспечивая надежность данных, особенно в транзакционных нагрузках. ACID расшифровывается как:

• Атомарность: Каждая транзакция рассматривается как единое неделимое целое. Она либо выполняется полностью (фиксируется), либо не происходит вообще (откатывается). Частичных транзакций не бывает.
• Согласованность: Транзакция переводит базу данных из одного допустимого состояния в другое. Она гарантирует, что записываемые данные соответствуют всем определенным правилам и ограничениям.
• Изоляция: Параллельные транзакции выполняются изолированно, как будто они выполняются последовательно. Результат параллельных транзакций такой же, как если бы они выполнялись одна за другой.
• Долговечность: После фиксации транзакции она останется зафиксированной даже в случае сбоя питания, сбоев или других системных ошибок. Изменения сохраняются постоянно.

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

Свойства BASE (NoSQL базы данных, такие как MongoDB)

Напротив, многие базы данных NoSQL, включая MongoDB, отдают приоритет доступности и устойчивости к разделению перед немедленной согласованностью, часто следуя модели BASE. BASE расшифровывается как:

• Basically Available (В основном доступна): Система гарантирует доступность, то есть она будет отвечать на любой запрос, даже если не может гарантировать самую последнюю версию данных.
• Soft State (Мягкое состояние): Состояние системы может меняться со временем, даже без ввода данных. Это связано с моделью конечной согласованности, где данные асинхронно распространяются по системе.
• Eventual Consistency (Конечная согласованность): Если не вносить новые обновления в данный элемент данных, то со временем все обращения к этому элементу вернут последнее обновленное значение. Существует задержка, прежде чем изменения станут видны на всех узлах распределенной системы.

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

Понимание конечной согласованности в MongoDB

MongoDB может проявлять поведение конечной согласованности, когда чтение выполняется с вторичных узлов или когда записи еще не реплицировались повсеместно. Это означает, что когда вы записываете данные в реплика-сет MongoDB, основной узел подтверждает запись, а затем асинхронно реплицирует эту запись на свои вторичные узлы. В то время как основной узел обеспечивает долговечность записи, он не ждет, пока все вторичные узлы догонят, прежде чем подтвердить успех клиенту. Следовательно, последующее чтение с вторичного узла может не сразу отразить последнюю запись, хотя в конечном итоге она станет согласованной.

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

Компромиссы конечной согласованности

• Плюсы: Более высокая доступность, лучшая производительность (меньшая задержка для операций записи) и большая масштабируемость для распределенных систем.
• Минусы: Приложения должны быть спроектированы так, чтобы обрабатывать возможность чтения устаревших данных. Это особенно актуально для операций, где критична немедленная согласованность на всех репликах.

Уровни чтения и записи MongoDB: Настройка согласованности

Хотя MongoDB по умолчанию использует конечную согласованность, она предоставляет мощные механизмы – Уровни чтения и Уровни записи – которые позволяют разработчикам настраивать уровень согласованности для каждой операции. Это позволяет вам балансировать между согласованностью, доступностью и производительностью в соответствии с потребностями вашего приложения.

Уровни записи

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

Ключевые параметры уровня записи:

• w: Указывает количество экземпляров mongod, которые должны подтвердить запись.
  • w: 0: Нет подтверждения. Клиент не ждет никакого ответа от базы данных. Это обеспечивает самую высокую пропускную способность, но несет риск потери данных, если основной узел выйдет из строя сразу после записи.
  • w: 1 (По умолчанию): Подтверждение только от основного узла. Основной узел подтверждает, что получил и обработал запись. Это быстро, но не гарантирует, что запись была реплицирована на какие-либо вторичные узлы.
  • w: "majority": Подтверждение от большинства членов реплика-сета (включая основной узел). Это обеспечивает более строгие гарантии долговечности, так как запись фиксируется на большинстве узлов. Если основной узел выходит из строя, данные гарантированно существуют на большинстве других узлов.
• j: Указывает, должен ли экземпляр mongod записывать в журнал на диске перед подтверждением записи. Включение журналирования (j: true) обеспечивает долговечность даже в случае сбоя процесса mongod.
• wtimeout: Лимит времени для выполнения уровня записи. Если уровень записи не выполнен за это время, операция записи возвращает ошибку.

Пример уровня записи (с использованием w: "majority" и журналирования):

db.products.insertOne(
  { item: "laptop", qty: 50 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
);

Совет: Для критических данных, которые должны быть долговечными и высокодоступными, рекомендуется w: "majority" с j: true. Для менее критических данных или высокопроизводительного логирования может быть приемлемо w: 1 или даже w: 0.

Уровни чтения

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

Ключевые параметры уровня чтения:

• local: Возвращает данные с экземпляра (основного или вторичного), к которому подключен клиент. Это значение по умолчанию для автономных экземпляров и вторичных узлов. Для реплика-сетов это обеспечивает наименьшую задержку, но может возвращать устаревшие данные.
• available: Возвращает данные с экземпляра без гарантии, что данные были записаны на большинство членов реплика-сета. Аналогично local, отдает приоритет доступности и низкой задержке.
• majority: Возвращает данные, которые были подтверждены большинством членов реплика-сета. Это гарантирует, что данные долговечны и не будут откатаны. Обеспечивает более строгую согласованность, чем local или available, ценой потенциально более высокой задержки.
• linearizable: Гарантирует, что возвращаемые данные отражают самую последнюю подтвержденную запись глобально. Это самый строгий уровень чтения, гарантирующий, что чтение видит все записи, которые были подтверждены уровнем записи majority. Это может привести к значительному снижению производительности и доступно только для чтения с основного узла.
• snapshot (для многодокументных транзакций): Гарантирует, что запрос возвращает данные на определенный момент времени, позволяя чтению быть согласованным для нескольких документов в рамках транзакции.

Пример уровня чтения (с использованием majority):

db.products.find(
  { item: "laptop" },
  { readConcern: { level: "majority" } }
);

Предупреждение: Хотя linearizable обеспечивает строгую согласованность, это сопряжено с последствиями для производительности. Используйте его разумно для сценариев, где критичны строгий порядок и глобальная видимость записей.

Почему BASE и конечная согласованность важны для масштабирования

Модель BASE и конечная согласованность являются ключевыми факторами, обеспечивающими масштабируемость и высокую доступность MongoDB:

1. Горизонтальное масштабирование (Шардирование): Ослабляя немедленную согласованность, MongoDB может распределять данные по нескольким шардам (кластерам реплика-сетов). Каждый шард работает относительно независимо, позволяя базе данных масштабироваться горизонтально для обработки огромных наборов данных и высокой пропускной способности, не требуя, чтобы каждый узел во всей распределенной системе был идеально синхронизирован в любой момент времени.
2. Высокая доступность и отказоустойчивость: В реплика-сете, если основной узел становится недоступным, из вторичных узлов может быть выбран новый основной. Конечная согласованность означает, что даже во время отказов вторичные узлы могут продолжать обслуживать чтение (в зависимости от уровня чтения), и система остается доступной. Если бы основному узлу приходилось ждать все вторичные узлы для каждой записи, один отстающий вторичный узел мог бы стать узким местом для всей системы.
3. Производительность: Менее строгие требования к согласованности означают меньшую задержку для операций записи и более высокую общую пропускную способность, так как системе не нужно блокироваться и ждать подтверждений от всех узлов перед продолжением.

Предоставляя настраиваемую согласованность через уровни чтения и записи, MongoDB дает разработчикам возможность принимать обоснованные решения. Приложения, которые отдают приоритет высокой доступности и пропускной способности (например, сбор данных IoT, аналитика в реальном времени), могут выбирать более слабую согласованность. И наоборот, приложения, требующие более строгой целостности данных (например, финансовые транзакции, обновления инвентаря), могут выбирать более строгие уровни согласованности, принимая связанные компромиссы в производительности.

Практические соображения и лучшие практики

• Определите критические данные: Определите, какие данные абсолютно требуют строгой согласованности (например, балансы счетов) по сравнению с данными, которые могут терпеть конечную согласованность (например, обновления профилей пользователей, данные сессий).
• Проектируйте для идемпотентности: При использовании более слабых уровней записи возможно, что запись будет успешной на основном узле, но не сможет реплицироваться на вторичные, что приведет к последующему откату и клиент будет считать, что запись не удалась. Если клиент повторит операцию, это может привести к дубликатам. Проектируйте свои операции так, чтобы они были идемпотентными, где это возможно.
• Чтение собственных записей на стороне клиента: Если пользователь выполняет запись и затем немедленно пытается прочитать её, он может увидеть устаревшие данные, если чтение выполняется с вторичного узла со слабым уровнем чтения. Чтобы гарантировать, что пользователь всегда читает свои собственные недавние записи, рассмотрите возможность направления таких чтений на основной узел или использования уровня чтения majority, возможно, в сочетании с уровнем записи majority для этих конкретных операций.
• Мониторинг: Следите за отставанием реплика-сета с помощью rs.printReplicationInfo() или метрик MongoDB Atlas. Высокое отставание репликации может усугубить проблемы конечной согласованности.

Более полезный способ думать о согласованности MongoDB

MongoDB не является просто "конечно согласованной" в каждой ситуации, и отношение к ней таким образом приводит к небрежным проектам. Чтение с основного узла после подтвержденной записи может вести себя совершенно иначе, чем чтение, направленное на вторичный узел, который отстает на несколько секунд. Запись, подтвержденная с w: 1, имеет другой профиль риска, чем запись, подтвержденная с w: "majority". История согласованности зависит от вашего предпочтения чтения, уровня чтения, уровня записи, топологии и того, происходит ли отказоустойчивый переход в неподходящее время.

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

Практический шаблон заключается в использовании более строгих настроек для путей подтверждения, ориентированных на пользователя, и более слабых настроек для фоновых или аналитических путей. Например, запись заказа может использовать w: "majority", а немедленное чтение подтверждения может идти на основной узел. Панель мониторинга, которая агрегирует активность за вчерашний день, может читать с вторичных узлов, так как небольшая задержка обычно приемлема. Конвейер приема логов может принимать более слабое подтверждение, чем бухгалтерская книга, но он все равно должен честно сообщать о том, что может быть потеряно во время сбоя или отказоустойчивого перехода.

Будьте осторожны со словом "доступный". Распределенная база данных может продолжать обслуживать некоторые запросы во время сбоев, но это не означает, что каждый запрос может быть выполнен с теми же гарантиями. Выборы основного узла приостанавливают запись на короткий период. Вторичный узел может обслуживать чтение только в том случае, если ваше предпочтение чтения это позволяет. Сетевое разделение может заставить MongoDB выбирать безопасность вместо принятия записей на узле, который больше не принадлежит к большинству. Это не недостатки; это компромиссы, которые предотвращают разделение реплицированных данных на две конфликтующие истории.

Вот решение, которое я бы записал в заметку по проектированию приложения:

Критические изменения учетных записей, заказов и инвентаря:
- writeConcern: majority
- читать обратно с основного узла при подтверждении собственного действия пользователя
- использовать повторяемые записи, где драйвер их поддерживает
- делать операции записи идемпотентными с помощью идентификаторов запросов или уникальных ключей

Страницы поиска, ленты, аналитика и некритическое отображение профилей:
- чтение с вторичных узлов может быть приемлемо
- терпеть устаревшие результаты в пользовательском интерфейсе
- показывать временные метки, когда свежесть важна

Такого рода заметка более полезна, чем сказать "MongoDB — это BASE" и двигаться дальше. Она сообщает будущим инженерам, где устаревшие чтения приемлемы, а где нет.