Теорема CAP кажется логичной для меня. Я понимаю, что:Как Marklogic может иметь согласованность и доступность?
Если у меня есть согласованность в распределенной системе, я должен дождаться всех транзакций . Стоимость ACID - это время для дублирования данных по всей сети .
Но как Marklogic может иметь оба. ACID и распределенная система без запаздывания?
Возможно ли иметь свойства BASE и ACID в одной базе данных?
Неправильная теорема CAP?
Доступность в CAP Теорема о хозяевах, которые находятся по обе стороны раздела, а не о системе в целом.
В теореме CAP вы «доступны», если все хосты по обе стороны сетевого раздела могут продолжать принимать операции чтения и обновления. Большинство наших клиентов все равно, если все хосты остаются доступными перед сетевым разделом. Имейте в виду, что база данных в целом остаются доступными во время сетевого раздела. Поэтому, если кластер реплицировал или делил данные, чтобы на обеих сторонах раздела было достаточно данных, чтобы продолжать обслуживать запросы, и достаточно умен, чтобы знать, какая часть раздела должна оставаться доступной и которая должна изящно раскланяться, тогда база данных может оставаться доступной перед сетевым разделом, даже если все хосты этого не делают. Это то, что делает MarkLogic внутри кластера.
Между кластерами у MarkLogic есть много вариантов того, насколько близко вы абсолютно согласны. Мы используем асинхронную репликацию для перемещения данных между кластерами, поэтому там, где есть сетевой раздел между кластерами, данные могут быть несовместимыми между этими кластерами. Вы можете контролировать, как долго этот лаг-предел будет таким, чтобы вы могли его настроить, и если вам нужна абсолютная согласованность между кластерами, у нас есть способы его достижения.
Суть в том, что:
Надеюсь, что это поможет.
Теорема CAP не ошибается, она просто устарела. Вот обновление от автора: CAP Twelve Years Later: How the "Rules" Have Changed.
MarkLogic поддерживает свойства ACID через MVCC. Если хотите, вы можете настроить его для работы с свойствами BASE. Ключ, насколько я понимаю, заключается в разработке и оптимизации ваших производственных требований. У MarkLogic есть множество доступных функций репликации, и мы постоянно добавляем к этому портфолио, так как наши клиенты решают проблемы реального мира, развертывая глобально распределенные кластеры.
Ты прочитал (а) Inside MarkLogic Server? Этот технический документ прекрасно справляется с тем, как MarkLogic решает многие из этих проблем.
Итак, если я хорошо понимаю, по умолчанию Marcklogic является ACID на уровне кластера, но не полным уровнем сети базы данных (из-за согласованности)? И если мне нужна абсолютная согласованность между кластером, система всегда разделяет толерантность? – jeremieca
База данных находится в кластере, поэтому для данной базы данных MarkLogic является ACID. База данных может быть реплицирована во второй кластер для аварийного восстановления. Мы делаем это через лог-доставку. Внутри этого второго кластера эта база данных также является ACID. Однако, поскольку репликация является асинхронной, база данных реплик всегда отстает от основной базы данных на несколько секунд. Этот предел задержки настраивается. Вы также можете настроить два кластера MarkLogic, чтобы оставаться всегда синхронными, но штраф, который вы платите, заключается в том, что ваши транзакции будут занимать больше времени из-за высокой задержки между кластерами. Имеют смысл? –
Хорошо, это имеет смысл. Итак, еще два вопроса, которые я точно понимаю. Второй кластер предназначен для аварийного восстановления, поэтому вы не можете запрашивать его из производственного приложения, не так ли? Обычно ваш кластер централизуется в одном центре данных или, по крайней мере, на одном континенте, чтобы ограничить задержку между узлом кластера, не так ли? Спасибо за время, чтобы ответить, я очень ценю :). – jeremieca