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

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

95
cap-theorem database mongodb nosql

6 ответов

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

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

81

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

enter image description here

103

Я согласен с Luccas post. Вы не можете просто сказать, что MongoDB - это CP/AP / CA, потому что на самом деле это компромисс между C, A и P, в зависимости от конфигурации базы данных/драйвера и типа катастрофы: вот визуальное резюме, а ниже более подробное объяснение.

    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

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

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

в наличии:

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

Раздел Терпимости:

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

21

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

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

16

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

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

10

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

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

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

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

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

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

5