Respostas:
O MongoDB é fortemente consistente por padrão - se você fizer uma gravação e depois uma leitura, presumindo que a gravação foi bem-sucedida, você sempre será capaz de ler o resultado da gravação que acabou de ler. Isso ocorre porque o MongoDB é um sistema de mestre único e todas as leituras vão para o primário por padrão. Se você opcionalmente habilitar a leitura dos secundários, o MongoDB se tornará eventualmente consistente, onde é possível ler resultados desatualizados.
O MongoDB também obtém alta disponibilidade por meio de failover automático em conjuntos de réplicas: http://www.mongodb.org/display/DOCS/Replica+Sets
Eu concordo com a postagem de Luccas. Você não pode simplesmente dizer que MongoDB é CP / AP / CA, porque na verdade é uma troca entre C, A e P, dependendo da configuração do banco de dados / driver e do tipo de desastre : aqui está uma recapitulação visual, e abaixo um explicação mais detalhada.
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 systemsO MongoDB é fortemente consistente quando você usa uma única conexão ou o Nível de preocupação de gravação / leitura correto (o que vai custar sua velocidade de execução ). Assim que você não atender a essas condições (especialmente quando estiver lendo de uma réplica secundária), o MongoDB se torna eventualmente consistente.
O MongoDB obtém alta disponibilidade por meio de conjuntos de réplicas . Assim que o primário cair ou ficar indisponível, os secundários determinarão que um novo primário ficará disponível novamente. Há uma desvantagem nisso: cada gravação realizada pelo antigo primário, mas não sincronizada com os secundários, será revertida e salva em um arquivo de rollback, assim que se reconectar ao conjunto (o primário antigo é um secundário agora). Portanto, neste caso, alguma consistência é sacrificada por uma questão de disponibilidade.
Através do uso dos referidos conjuntos de réplicas, o MongoDB também atinge a tolerância de partição: desde que mais da metade dos servidores de um conjunto de réplicas estejam conectados uns aos outros, um novo primário pode ser escolhido . Por quê? Para garantir que duas redes separadas não possam escolher um novo primário. Quando não há secundários suficientes conectados entre si, você ainda pode ler a partir deles (mas a consistência não é garantida), mas não escrever. O conjunto está praticamente indisponível por uma questão de consistência.
Como um novo artigo brilhante apareceu e também alguns experimentos incríveis de Kyle neste campo, você deve ter cuidado ao rotular o MongoDB e outros bancos de dados como C ou A.
É claro que o CAP ajuda a rastrear sem muitas palavras o que o banco de dados prevalece sobre ele, mas as pessoas freqüentemente esquecem que C no CAP significa consistência atômica (linearização), por exemplo. E isso me causou muita dor para entender ao tentar classificar. Então, além do MongoDB dar consistência forte, isso não quer dizer que seja C. Desta forma, se fizermos essas classificações, recomendo também dar mais detalhes de como realmente funciona para não deixar dúvidas.
Sim, é CP ao usar safe=true . Isso significa simplesmente que os dados foram para o disco mestre. Se você quiser ter certeza de que ele também chegou em alguma réplica, observe o parâmetro 'w = N', onde N é o número de réplicas nas quais os dados devem ser salvos.
Não tenho certeza sobre P para Mongo. Imagine a situação:
O problema aqui é que o tamanho do arquivo de despejo é limitado e se você teve uma partição por muito tempo, pode perder seus dados para sempre.
Você pode dizer que é improvável que aconteça - sim, a menos que na nuvem, onde é mais comum do que se possa imaginar.
Este exemplo é porque eu seria muito cuidadoso antes de atribuir qualquer carta a qualquer banco de dados. Existem tantos cenários e implementações que não são perfeitas.
Se alguém souber se esse cenário foi abordado em versões posteriores do Mongo, comente! (Faz algum tempo que não acompanho tudo o que está acontecendo ..)
O Mongodb nunca permite a gravação no secundário. Ele permite leituras opcionais do secundário, mas não gravações. Portanto, se o primário cair, você não poderá escrever até que o secundário se torne primário novamente. É assim que você sacrifica a alta disponibilidade no teorema CAP. Ao manter suas leituras apenas do primário, você pode ter uma consistência forte.
O MongoDB seleciona Consistência em vez de Disponibilidade sempre que houver uma partição. O que significa é que quando há uma partição (P), ela escolhe Consistência (C) em vez de Disponibilidade (A).
Para entender isso, vamos entender como o MongoDB faz o conjunto de réplicas funciona. Um conjunto de réplicas possui um único nó primário. A única maneira "segura" de confirmar os dados é gravar naquele nó e, em seguida, esperar que os dados sejam confirmados para a maioria dos nós do conjunto. (você verá esse sinalizador para w = maioria ao enviar gravações)
A partição pode ocorrer em dois cenários da seguinte forma:
Basicamente, sempre que ocorre uma partição e o MongoDB precisa decidir o que fazer, ele escolherá Consistência em vez de Disponibilidade. Ele parará de aceitar gravações no sistema até acreditar que pode concluir essas gravações com segurança.
O Mongodb fornece consistência e tolerância de partição .
No contexto de bancos de dados distribuídos (NoSQL), isso significa que sempre haverá uma compensação entre consistência e disponibilidade. Isso ocorre porque os sistemas distribuídos são sempre necessariamente tolerantes à partição (ou seja, simplesmente não seria um banco de dados distribuído se não fosse tolerante à partição).
Consistência - O sistema acabará por se tornar consistente. Os dados irão se propagar para todos os lugares que deveriam, mais cedo ou mais tarde, mas o sistema continuará a receber informações e não verificará a consistência de todas as transações antes de passar para a próxima.
Disponibilidade - Por padrão, o Mongo DB Client (driver MongoDB) envia todas as solicitações de leitura / gravação para o nó líder / primário. Isso torna o sistema consistente, mas não disponível devido a - Se um líder se desconectar do cluster, leva alguns segundos para eleger um novo líder. Portanto, tornando-o indisponível para gravações e leituras nessa duração.