Где mongodb стоит в теореме CAP?

Всюду, где я смотрю, я вижу, что MongoDB - CP. Но когда я копаю, я вижу, что это в конечном итоге непротиворечиво. Это CP, когда вы используете safe = true? Если это так, значит ли это, что когда я пишу с безопасным = true, все реплики будут обновлены до получения результата?

Ответ 1

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

MongoDB также получает высокую доступность благодаря автоматическому отказоустойчивости в наборах реплик: http://www.mongodb.org/display/DOCS/Replica+Sets

Ответ 2

Это должно помочь ответить на вопрос, наряду с другими системами NoSQL и другими постоянными системами хранения.

Ответ 3

Как появилась блестящая новая статья, а также некоторые удивительные эксперименты Кайл в этой области, вы должны быть осторожны при маркировке MongoDB и других баз данных, таких как C или A.

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

Ответ 4

Я согласен с сообщением Лукки. Вы не можете просто сказать, что MongoDB - это CP/AP/CA, потому что это фактически компромисс между C, A и P:

Последовательность:

MongoDB сильно согласован, если вы используете одно соединение или правильно Write/Прочитайте уровень Концерна (Который будет стоить вам скорость исполнения). Как только вы не встретите эти условия (особенно когда вы читаете из вторичной реплики), MongoDB становится окончательно согласованным.

Доступность:

MongoDB получает высокую доступность через Replica-Sets. Как только первичный снижается или становится недоступным, то вторичные будут определять новый первичный, который станет доступен снова. Недостаток заключается в следующем: каждая запись, выполняемая старыми первичными, но не синхронизированными с вторичными, будет откат и сохранена на rollback-file, как только он снова подключится к набору (старый первичный - вторичный). Поэтому в этом случае некоторая согласованность приносится в жертву ради доступности.

Толерантность раздела:

Благодаря использованию упомянутых наборов Replica-MongoDB также достигается допуск разделов: до тех пор, пока более половины серверов Replica-Set связаны друг с другом, можно выбрать новый первичный вариант. Зачем? Чтобы обе отдельные сети не могли выбрать новый первичный. Когда не хватает второстепенных подключений друг к другу, вы все еще можете их читать (но последовательность не гарантируется), но не записывается. Набор практически недоступен для согласованности.

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

Ответ 5

Да, это CP при использовании safe=true. Это просто означает, что данные попали на диск мастера. Если вы хотите убедиться, что он также появился на какой-либо реплике, загляните в параметр "w = N", где N - количество реплик, данные должны быть сохранены.

см. этот и этот для получения дополнительной информации.

Ответ 6

Я не уверен в P для Монго. Представьте себе ситуацию:

Ваша реплика разделяется на два раздела.
Писания продолжаются с обеих сторон по мере избрания новых мастеров.
Разделение разрешено - все серверы снова подключены.
Что происходит, так это то, что выбирается новый мастер - тот, который имеет самый высокий oplog, но данные от другого мастера возвращаются к общему состоянию перед разделом и сбрасываются в файл для ручного восстановления.
все второстепенные пользователи догоняют нового мастера

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

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

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

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