Подписка на RSS

Распределенная согласованность — Часть 1 — Введение

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

CAP

CAP теорема гласит, что в системе одновременно можно выбрать только две вещи з трех: корректность, доступность, устойчивость к разделению сети. В распределенных системах недоступность некоторых узлов неизбежна и система должна быть устойчивой к этому, поэтому CAP означает, что мы не можем одновременно поддерживать корректность и 100% доступности.

Я бы сказал, что теорема CAP означает, что если сеть разорвана, ваша база данных не будет работать.

Однако, мы должны подобрать определение фразе «не будет работать». Это может означать падение (недоступность) или некорректность (старые данные).

Если быть более точными, что мы имеем ввиду под «корректностью»? Академические работы в этой области ссылаются на «упорядочиваемость в одну копию» или «линеаризуемость». Если выполнена серия операций или транзакций, они применены в корректном порядке. Менее формальный способ понимания компромисса: «Могу я читать и управлять старыми/плохими данными? Могу ли я всегда производить запись?»

Объединение

У нас есть два класса архитектур: класс C (строгая корректность) и класс A (более высокая доступность, менее согласованная). Давайте рассмотрим некоторые распределенные системы из реального мира, и к какому классу они отнесены.

Amazon Dynamo — распределенное хранилище данных, которое реализует согласованное хэширование и оно входит в группу A. Оно предоставляет конечную согласованность. Возможна ситуация чтения старых данных.

CouchDB обычно используется с синхронными мастер-мастер репликациями и она тоже в группе A. Она предоставляет конечную согласованность.

Кластер MongoDB с автоматическим шардингом и репликацией в каждый момент времени для каждого шарда обладает мастер сервером. Она в группе C. Традиционные реляционные СУБД системы также строго корректны (при обычном использовании) — например, синхронный кластер реляционной СУБД.

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

Главный вопрос — доступность на запись, а не доступность на чтение

На сегодняшний день легко иметь неограниченное число асинхронных слэйв репликаций, распределенных по миру. В случае разрыва сети мы все равно будем иметь доступ к локальным слэйв данным. Так как репликация асинхронна, эти данные конечно согласованы, поэтому результат не будет сюрпризом — мы не в группе A. Однако практически все архитектуры, даже из класса C, могут легко добавить асинхронную способность чтения. Таким образом, все важнейшие архитектурные решения касаются способности записи.

Компромиссы:

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

Мы обсудим эти плюсы и минусы более детально в последующих статьях.

Автор статьи: Блог MongoDB
Дата: 26 марта 2010
Оригинал статьи

Leave a Reply

Your email address will not be published. Required fields are marked *