NoSQL: Что значит для MongoDB или BigTable не всегда быть "доступным"?

Чтение Nathan Hurst Визуальный справочник по NoSQL Systems, он включает треугольник CAP:

C onsistency
A vailibility
P Толерантность к исправлениям

С SQL Server, являющимся системой AC, и MongoDB является системой CP.

Эти определения из профессор Калифорнийского университета Беркли Эрик Брюэр и его беседа на PODC 2000 (Принципы распределенных вычислений):

Доступность

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

Что означает, в контексте MongoDB или BigTable, чтобы система не была "доступна"?

Вы идете подключиться (например, через TCP/IP), а сервер не отвечает? Вы пытаетесь выполнить запрос, но запрос никогда не возвращается - или возвращает ошибку?

Что значит быть недоступным?

Ответ 1

Доступность в этом случае означает, что в случае сетевого раздела сервер, к которому подключается клиент, не может гарантировать уровень согласованности, которого ожидает клиент (или что система настроена для предоставления).

Предполагая, что у вас есть 3 узла, A, B и C, в гипотетической распределенной системе. A, B и C работают на собственной стойке серверов с двумя переключателями между ними:

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]

Теперь предположим, что указанная система настроена так, что ГАРАНТИРОВАНО, что любая запись будет идти как минимум до 2 узлов, прежде чем она будет считаться совершенной. Теперь давайте предположим, что коммутатор №2 отключен, а какой-то клиент подключен к node C:

[Node A] <- Switch #1 -> [Node B]                 [ Node C ] <-- Some client

Этот клиент не сможет выдавать согласованные записи, потому что распределенная система в настоящее время находится в секционированном состоянии (а именно, node C не может связываться со многими другими узлами, чтобы гарантировать согласованность 2 node).

Я бы добавил к этому, что некоторые базы данных NoSQL позволяют очень динамично выбирать атрибуты CAP. Например, Cassandra позволяет клиентам указывать количество серверов, на которые должна идти запись, прежде чем они будут совершены на основе записи. Записывается на один сервер "AP", пишет, что переход на кворум (или все) серверов больше "CA".

EDIT - из комментариев ниже:

В MongoDB вы можете иметь только конфигурацию master/slave в наборе реплик. Это означает, что выбор AP против CP производится клиентом во время запроса. Клиент может указать slaveOk, который будет считываться из произвольно выбранного подчиненного устройства (которое может иметь устаревшие данные): mongodb.org/display/DOCS/.... Если клиент не работает с устаревшими данными, не указывайте slaveOk, и запрос перейдет к мастеру. Если клиент не может связаться с мастером, вы получите сообщение об ошибке. Я точно не знаю, что это за ошибка.

Ответ 2

Теорема CAP применяется к распределенным компьютерным системам. MongoDB поддерживает две различные формы распределенных вычислений: масштабирование для горизонтального масштабирования и наборов реплик для отказоустойчивости/высокой доступности. Эти два могут использоваться вместе или независимо. Я думаю, что теорема CAP несколько отличается от двух форм:

Уровень окантовки. MongoDB хранит данные не более чем на одном авторитетном осколке.

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

Уровень репликации - MongoDB реплицирует данные в пределах осколка, обеспечивая согласованность с помощью одного, авторитетного первичного node.

Сильная согласованность: все чтения/записи обрабатываются основным node.
Сильная толерантность к разделам: если количество узлов становится недоступным, выбирается новый первичный. Процесс выборов гарантирует, что всегда существует не более одного первичного node.
Слабая доступность: Чтение/запись завершится неудачей, если первичный не существует, даже если к данным можно получить доступ через вторичные узлы.

Параметр slaveOK/ReadPreference.SECONDARY жертвует некоторой согласованностью (можно просмотреть устаревшие данные) для повышения производительности и доступности.