Garantias de isolamento
Leitura nĂŁo confirmada
Dependendo do read concern, os clientes podem ver os resultados das escritas antes que elas sejam durĂĄveis:
Independentemente da write concern, outros clientes que usam a read concern podem ver o resultado de uma operação de gravação antes que a operação de gravação seja reconhecida pelo cliente
"local""available"emissor.Os clientes que usam a read concern
"local"ou"available"podem ler dados que podem ser revertidos posteriormente durante failovers de conjuntos de réplicas.
Para operaçÔes em uma transação de vĂĄrios documentos, quando uma transação Ă© confirmada, todas as alteraçÔes de dados feitas na transação sĂŁo salvas e ficam visĂveis fora da transação. Ou seja, uma transação nĂŁo confirmarĂĄ algumas de suas alteraçÔes enquanto reverte outras.
AtĂ© que uma transação seja confirmada, as alteraçÔes de dados feitas na transação nĂŁo serĂŁo visĂveis fora da transação.
No entanto, quando uma transação Ă© gravada em vĂĄrios fragmentos, nem todas as operaçÔes de leitura externas precisam esperar que o resultado da transação confirmada fique visĂvel nos fragmentos. Por exemplo, se uma transação estiver comprometida e escrever 1 estiver visĂvel no fragmento A, mas escrever 2 ainda nĂŁo estiver visĂvel no fragmento B, uma leitura externa em questĂŁo de leitura "local" poderĂĄ ler os resultados da escrita 1 sem ver a escrita 2.
Leitura nĂŁo confirmada Ă© o nĂvel de isolamento padrĂŁo e se aplica a mongod instĂąncias autĂŽnomo, conjuntos de rĂ©plicas e clusters.
Leitura nĂŁo confirmada e atomicidade de documento Ășnico
As operaçÔes de gravação sĂŁo atĂŽmicas em relação a um Ășnico documento; ou seja, se uma gravação estiver atualizando mĂșltiplos campos no documento, uma operação de leitura nunca verĂĄ o documento com apenas alguns dos campos atualizados. No entanto, embora um cliente possa nĂŁo ver um documento atualizado parcialmente, ler sem compromisso significa que as operaçÔes de leitura simultĂąneas ainda podem ver o documento atualizado antes que as alteraçÔes fiquem durĂĄveis.
Com uma instĂąncia mongod autĂŽnoma, um conjunto de operaçÔes de leitura e gravação em um Ășnico documento Ă© serializĂĄvel. Com um conjunto de rĂ©plicas, um conjunto de operaçÔes de leitura e gravação em um Ășnico documento Ă© serializĂĄvel somente na ausĂȘncia de uma reversĂŁo.
Leitura nĂŁo confirmada e gravação de mĂșltiplos documentos
Quando uma Ășnica operação de gravação (por exemplo, db.collection.updateMany()) modifica vĂĄrios documentos, a modificação de cada documento Ă© atĂŽmica, mas a operação como um todo nĂŁo Ă© atĂŽmica.
Ao realizar operaçÔes de escrita de vĂĄrios documentos, seja por meio de uma Ășnica operação de escrita ou de vĂĄrias operaçÔes de escrita, outras operaçÔes podem ser intercaladas.
Para situaçÔes que exigem atomicidade de leituras e escritos em vĂĄrios documentos (em uma Ășnica coleção ou vĂĄrias coleçÔes), o MongoDB suporta transaçÔes distribuĂdas, incluindo transaçÔes em conjuntos de rĂ©plicas e clusters fragmentados.
Para obter mais informaçÔes, consulte transaçÔes.
Importante
Na maioria dos casos, uma transação distribuĂda incorre em um custo de desempenho maior do que as gravaçÔes de um Ășnico documento, e a disponibilidade de transaçÔes distribuĂdas nĂŁo deve substituir o design eficaz do esquema. Em muitos cenĂĄrios, o modelo de dados desnormalizado (documentos e arrays incorporados) continuarĂĄ a ser ideal para seus dados e casos de uso. Ou seja, para muitos cenĂĄrios, modelar seus dados adequadamente minimizarĂĄ a necessidade de transaçÔes distribuĂdas.
Para consideraçÔes adicionais sobre o uso de transaçÔes (como limite de tempo de execução e limite de tamanho do oplog), consulte também ConsideraçÔes de produção.
Sem isolar as operaçÔes de gravação de mĂșltiplos documentos, o MongoDB exibe o seguinte comportamento:
OperaçÔes de leitura nĂŁo pontuais. Suponha que uma operação de leitura comece no momento t 1 e comece a ler documentos. Em seguida, uma operação de gravação confirma uma atualização em um dos documentos em um momento posterior t 2. O leitor pode ver a versĂŁo atualizada do documento e, portanto, nĂŁo vĂȘ um instantĂąneo pontual dos dados.
OperaçÔes nĂŁo serializĂĄveis. Suponha que uma operação de leitura leia um documento d 1 no tempo t 1 e uma operação de gravação atualize d 1 em algum momento posterior t 3. Isso introduz uma dependĂȘncia de leitura-gravação tal que, se as operaçÔes forem serializadas, a operação de leitura deve preceder a operação de gravação. Mas tambĂ©m suponha que a operação de gravação atualize o documento d 2 no tempo t 2 e a operação de leitura subsequentemente leia d 2 em algum momento posterior t 4. Isso introduz uma dependĂȘncia de leitura-gravação que, em vez disso, exigiria que a operação de leitura viesse apĂłs a operação de gravação em uma agenda serializĂĄvel. HĂĄ um ciclo de dependĂȘncia que torna a serializabilidade impossĂvel.
As leituras podem perder documentos correspondentes que são atualizados durante a operação de leitura.
Snapshot do cursor
Os cursores do MongoDB podem retornar o mesmo documento mais de uma vez em algumas situaçÔes. Ă medida que um cursor retorna documentos, outras operaçÔes podem intercalar-se com a consulta. Se uma dessas operaçÔes alterar o campo indexado no Ăndice usado pela consulta, o cursor poderĂĄ retornar o mesmo documento mais de uma vez.
Consultas que usam Ăndices Ășnicos podem, em alguns casos, retornar valores duplicados. Se um cursor que usa um Ăndice exclusivo se intercalar com uma exclusĂŁo e inserção de documentos que compartilham o mesmo valor exclusivo, o cursor poderĂĄ retornar o mesmo valor exclusivo duas vezes de documentos diferentes.
Use o isolamento de leitura para melhorar a consistĂȘncia. Para saber mais, consulte preocupação de leitura "snapshot".
GravaçÔes monotÎnicas
O MongoDB fornece garantias de gravação monotÎnica, por padrão, para instùncias autÎnomas mongod e conjuntos de réplicas.
Para escritas monotĂŽnicas e clusters fragmentados, consulte ConsistĂȘncia causal.
GravaçÔes que não modificam nenhum documento são chamadas de gravaçÔes noop. GravaçÔes sem operação:
Ocorre se o filtro para gravar não corresponder a nenhum documento ou se os documentos correspondentes permanecerem inalterados após a aplicação da gravação.
NĂŁo aumente o valor de optime.
Retorna
WriteResult.nModifiedigual a0, o que indica que a operação de gravar não modificou nenhum documento.
Para garantir a monotonicidade com gravaçÔes sem operação, use garantias de consistĂȘncia causal. Para todas as outras gravaçÔes, as seçÔes a seguir descrevem as garantias de monotonicidade.
Ordem em tempo real
Para operaçÔes de leitura e escrita no primĂĄrio, a emissĂŁo de "linearizable" preocupação de leitura para leituras e "majority" preocupação de gravação para escritas permite que vĂĄrios threads leiam e escrevam um Ășnico documento como se um Ășnico thread executasse essas operaçÔes em tempo real. O cronograma resultante para essas leituras e escritas Ă© linearizĂĄvel.
ConsistĂȘncia causal
As operaçÔes que dependem logicamente de uma operação anterior tĂȘm uma relacionamento causal. Por exemplo, uma gravar que exclui todos os documentos que correspondem a uma condição especificada e uma leitura subsequente que verifica se a operação de exclusĂŁo tem uma relacionamento causal .
Com sessÔes causalmente consistentes, o MongoDB executa operaçÔes causais em uma ordem que respeita seus relacionamentos causais. Os clientes observam resultados consistentes com esses relacionamentos.
SessĂ”es de clientes e garantias de consistĂȘncia causal
O MongoDB permite consistĂȘncia causal por meio de sessĂ”es de cliente . Uma sessĂŁo com consistĂȘncia causal garante que as operaçÔes de leitura com "majority" preocupação de leitura e as operaçÔes de escrita com "majority" preocupação de gravação tenham um relacionamento causal refletido em sua ordenação. Os aplicativos devem garantir que somente um thread por vez execute essas operaçÔes em uma sessĂŁo do cliente.
Para operaçÔes causalmente relacionadas:
Um cliente inicia uma sessĂŁo de cliente.
Importante
As sessĂ”es de cliente garantem apenas consistĂȘncia causal para:
Leia as operaçÔes com
"majority"preocupação de leitura. Os dados de retorno foram reconhecidos pela maioria dos membros do conjunto de réplicas e são duråveis.Escreva operaçÔes com
"majority"preocupação de gravação. Essas operaçÔes solicitam o reconhecimento de que a gravação foi aplicada à maioria dos membros votantes do conjunto de réplicas.
Para obter mais informaçÔes sobre a consistĂȘncia causal e diferentes read e write concerns, consulte ConsistĂȘncia causal e read e write concerns.
Como o cliente emite operaçÔes de leitura com
"majority"preocupação de leitura e operaçÔes de escrita com"majority"preocupação de gravação, o cliente inclui informaçÔes de sessão com cada operação.Para cada operação de leitura com
"majority"preocupação de leitura e operação de gravação com"majority"preocupação de gravação associada à sessão, o MongoDB retorna o operation time e o cluster time, mesmo se a operação for errada. A sessão do cliente acompanha a operation time e o tempo de cluster.Observação
O MongoDB não retorna o tempo de operação e o tempo de cluster para operaçÔes de gravação não reconhecidas (
w: 0). Escritos não reconhecidos não implicam qualquer relação causal.O MongoDB retorna o operation time e o tempo de cluster para operaçÔes de leitura e operaçÔes de gravação confirmadas em uma sessão do cliente. Somente as operaçÔes de leitura com preocupação de leitura
"majority"e as operaçÔes de escrita com preocupação de gravação"majority"garantem consistĂȘncia causal. Para obter detalhes, consulte ConsistĂȘncia causal e preocupaçÔes com leitura e gravação.A sessĂŁo de cliente associada acompanha esses dois campos de tempo.
Observação
As operaçÔes podem ser causalmente consistentes em diferentes sessÔes. Os drivers e do MongoDB
mongoshfornecem métodos para avançar o tempo de operação e o tempo de cluster para uma sessão de cliente . Um cliente pode adiantar o tempo de cluster e o tempo de operação de uma sessão de cliente para ser consistente com as operaçÔes de outra sessão de cliente .
Garantias de consistĂȘncia causal
A tabela a seguir descreve as garantias de consistĂȘncia causal para sessĂ”es causalmente consistentes que usam "majority" preocupação de leitura para operaçÔes de leitura e "majority" preocupação de gravação para operaçÔes de escrita.
Garantias | Descrição |
|---|---|
Ler suas gravaçÔes | As operaçÔes de leitura refletem os resultados das operaçÔes de gravação que as precedem. |
Leituras monotÎnicas | As operaçÔes de leitura não retornam resultados que correspondam a um estado anterior dos dados em relação a uma operação de leitura precedente. Por exemplo, se em uma sessão:
entĂŁo read 2 nĂŁo pode retornar resultados de write 1. |
Escritas monotÎnicas | As operaçÔes de gravação que devem preceder outras gravaçÔes são executadas antes dessas outras gravaçÔes. Por exemplo, se a gravação 1 precisar preceder a gravação 2 em uma sessão, o estado dos dados no momento da gravação 2 deverå refletir o estado dos dados após a gravação 1. Outras gravaçÔes podem ser intercaladas entre a gravação 1 e a gravação 2, mas a gravação 2 não pode ocorrer antes da gravação 1. |
Escritas que seguem as leituras | As operaçÔes de gravação que devem ocorrer após as operaçÔes de leitura são executadas após essas operaçÔes de leitura. Ou seja, o estado dos dados no momento da gravação deve incorporar o estado dos dados das operaçÔes de leitura anteriores. |
readPreference
Essas garantias sĂŁo vĂĄlidas para todos os membros da implantação do MongoDB . Por exemplo, em uma sessĂŁo causalmente consistente, se vocĂȘ emitir uma gravação com "majority" preocupação de gravação seguida por uma leitura de um secundĂĄrio com preferĂȘncia de leitura secondary e "majority" preocupação de leitura, a operação de leitura refletirĂĄ o estado do banco de dados depois a operação de gravação.
Isolamento
As operaçÔes dentro de uma sessão causalmente consistente não são isoladas de operaçÔes fora da sessão. Se uma operação de gravação simultùnea interceptar entre as operaçÔes de gravaçãoe leitura da sessão, a operação de leitura da sessão poderå retornar resultados que refletem uma operação de gravação que ocorreu após a operação de gravação da sessão.
MongoDB Drivers
Dica
Os aplicativos devem garantir que apenas um thread de cada vez execute essas operaçÔes em uma sessão do cliente.
Os clientes exigem drivers do MongoDB atualizados para o MongoDB 3.6 ou posterior:
Java 3.6+ Python 3,6+ C 1.9+ Go 1.8+ | C# 2.5+ NĂł 3.0+ Ruby 2,5+ Rust 2.1+ Swift 1.2+ | Perl 2.0+ PHPC 1.4+ Scala 2,2+ C++ 3.6.6+ |
Exemplos
Importante
SessĂ”es causalmente consistentes garantem apenas consistĂȘncia causal para leituras com "majority" preocupação de leitura e gravar com "majority" preocupação de gravação.
Considere uma coleção items que mantém dados atuais e históricos de vårios itens. Somente dados históricos possuem uma data end não nula. Se o valor sku de um item for alterado, atualize o documento com o valor sku antigo para adicionar a data end e insira um novo documento com o valor sku atual. Use uma sessão causalmente consistente para garantir que a atualização ocorra antes da inserção.
Use o seletor de idioma para definir o idioma deste exemplo.
Para ler todos os valores de sku atuais de outro cliente, avance o tempo de cluster e o operation time para corresponder à outra sessão. Isso garante que o cliente seja causalmente consistente com a outra sessão e leia após as duas gravaçÔes:
LimitaçÔes
As operaçÔes a seguir criam estruturas in-memory e não são causalmente consistentes:
(operação) | Notas |
|---|---|
| |
Retorna um erro se a operação estiver associada a uma sessão de cliente causalmente consistente. | |
Retorna um erro se a operação estiver associada a uma sessão de cliente causalmente consistente. | |
Retorna um erro se a operação estiver associada a uma sessão de cliente causalmente consistente. | |
Retorna um erro se a operação estiver associada a uma sessão de cliente causalmente consistente. | |