Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Operações CRUD

Preocupação de leitura

Nesta página

  • Níveis de preocupação de leitura
  • readConcern Suporte
  • Considerações

A opção readConcern permite controlar as propriedades de consistência e isolamento dos dados lidos de conjuntos de réplicas e clusters fragmentados.

Por meio do uso efetivo de write concerns e read concerns, você pode ajustar o nível de garantias de consistência e disponibilidade conforme apropriado, como esperar por garantias de consistência mais fortes ou afrouxar os requisitos de consistência para fornecer maior disponibilidade.

Os conjuntos de réplicas e clusters fragmentados são compatíveis com a configuração de uma referência de leitura padrão global. As operações que não especificam uma referência de leitura explícita herdam as configurações globais padrão da referência de leitura. Consulte setDefaultRWConcern para obter mais informações.

Níveis de preocupação de leitura

Os seguintes níveis de read concern estão disponíveis:

level
Descrição

"local"

A query retorna dados da instância sem nenhuma garantia de que os dados foram escritos na maioria dos membros do conjunto de réplicas (ou seja, podem ser revertidos).

Padrão para leituras em relação ao primário e aos secundários.

Disponibilidade: Read concern "local" está disponível para uso com ou sem sessões e transações causalmente consistentes.

Para mais informações, consulte a página de referência do "local".

"available"

A query retorna dados da instância sem nenhuma garantia de que os dados foram escritos na maioria dos membros do conjunto de réplicas (ou seja, podem ser revertidos).

Disponibilidade: A read concern "available" está indisponívelpara uso com sessões e transações causalmente consistentes.

Para clusters fragmentados, um read concern "available" fornece a menor latência de leitura possível entre as várias read concerns. No entanto, isso vem às custas da consistência, já que "available" read concern pode retornar documentos órfãos ao ler de uma coleção fragmentada. Para evitar o risco de retornar documentos órfãos ao ler de coleções fragmentadas, use uma read concern diferente, como a read concern "local".

Para mais informações, consulte a página de referência do "available".

"majority"

A query retorna os dados que foram confirmados por uma maioria dos membros do conjunto de réplicas. Os documentos retornados pela operação de leitura são duráveis, mesmo em caso de falha.

Para executar a read concern "maioria", o membro do conjunto de réplicas retorna dados de sua exibição na memória dos dados no ponto de confirmação de maioria. Como tal, a read concern é comparável em custo de desempenho a outras read "majority" concerns.

Disponibilidade:

Read concern "majority" está disponível para uso com ou sem sessões e transações causalmente consistentes.

Requisitos: Para usar o nível de read concern de"majority", os conjuntos de réplicas devem usar o mecanismo de armazenamento WiredTiger.

Para operações em multi-document transactions, a read concern "majority" fornece suas garantias somente se a transação for confirmada com a write concern "maioria". Caso contrário, a read concern "majority" não oferece garantias sobre os dados lidos nas transações.

Para mais informações, consulte a página de referência do "majority".

"linearizable"

A query retorna dados que refletem todas as escritas bem-sucedidas confirmadas pela maioria que foram concluídas antes do início da operação de leitura. A query pode esperar que as escritas de execução simultânea se propaguem para a maioria dos membros do conjunto de réplicas antes de retornar os resultados.

Se a maioria dos membros do seu conjunto de réplica falhar e reiniciar após a operação de leitura, os documentos retornados pela operação de leitura serão duráveis se o writeConcernMajorityJournalDefault estiver configurado para o estado padrão de true.

Com writeConcernMajorityJournalDefault definido como false, o MongoDB não espera que w: "majority" gravações sejam gravadas no registro em disco antes de reconhecer as gravações. Dessa forma, as operações de gravações "majority" poderiam ser revertidas no caso de uma perda transitória (por exemplo. falha e reinicialização) da maioria dos nós em determinado conjunto de réplicas.

Disponibilidade:

  • A read concern "linearizable" não está disponível para uso com sessões e transações causalmente consistentes.

  • Você pode especificar a read concern linearizável para operações de leitura somente no primary.

Não é possível usar o stage $out ou $merge em conjunto com a read concern "linearizable". Ou seja, se você especificar "linearizable" read concern para db.collection.aggregate(), não poderá incluir nenhum dos estágios no pipeline.

Requisitos:

As garantias de leitura linearizável só se aplicam se operações de leitura especificarem um filtro de queries que exclusivamente identifique um único documento. Além disso, se nenhum dos critérios a seguir for atendido, a preocupação de leitura linearizável poderá não ler de um snapshot consistente, fazendo com que um documento correspondente ao filtro não seja retornado:

  • A query usa um campo imutável como chave de pesquisa da query. Por exemplo, pesquisando no campo _id ou usando $natural.

  • Nenhuma atualização simultânea altera a chave de pesquisa da query.

  • A chave de pesquisa tem um índice único e a query usa esse índice.

Se algum dos critérios anteriores for atendido, a query lerá a partir de um snapshot consistente para retornar o único documento correspondente .

Sempre use maxTimeMS com read concern linearizável caso a maioria dos membros portadores de dados não esteja disponível. maxTimeMS garante que a operação não bloqueie indefinidamente e, em vez disso, garante que a operação retorne um erro se a read concern não puder ser executada.

Para mais informações, consulte a página de referência do "linearizable".

"snapshot"

Uma query com read concern "snapshot" retorna dados comprometidos pela maioria como aparece nos fragmentos a partir de um único ponto específico no passado recente. A Read concern "snapshot" fornece suas garantias somente se a transação se ligar com a write concern "majority".

If a transaction is not part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data.
If a transaction is part of a causally consistent session, upon transaction commit with write concern "majority", the transaction operations are guaranteed to have read from a snapshot of majority-committed data that provides causal consistency with the operation immediately preceding the transaction start.

Disponibilidade:

A read concern "snapshot" está disponível para

  • Todas as operações de leitura dentro de transações multidocumento com o conjunto de read concern no nível de transação.

  • Os seguintes métodos fora de transações multidocumento:

    Todas as outras operações de leitura proíbem "snapshot".

Independentemente do nível de read concern, os dados mais recentes em um nó podem não refletir a versão mais recente dos dados no sistema.

Para obter mais informações sobre cada nível de read concern, consulte:

readConcern Suporte

Opção de preocupação de leitura

Para operações que não estejam em transações de vários documentos, você pode especificar um readConcern nível read concern como uma opção para comandos e métodos que suportam a read concern:

readConcern: { level: <level> }

Para especificar o nível de preocupação de leitura para o método mongosh db.collection.find(), utilize o método cursor.readConcern():

db.collection.find().readConcern(<level>)

Transações e preocupações de leitura disponíveis

Para transações com vários documentos, você define a questão de leitura no nível da transação, não no nível de operação individual. As operações na transação usarão a read concern no nível da transação. Qualquer read concern definido no nível da coleção e do banco de dados é ignorado dentro da transação. Se o problema de leitura no nível da transação for explicitamente especificado, o problema de leitura no nível do cliente também será ignorado dentro da transação.

Importante

Não defina explicitamente a read concern para as operações individuais. Para definir a read concern para transações, consulte Read Concern/Write Concern/Read Preference.

Você pode definir o read concern no início da transação:

Se não especificado no início da transação, as transações usam a read concern no nível de sessão ou, se isso não estiver definido, a read concern no nível de cliente.

Para obter mais informações, consulte Transação Read Concern.

Sessões causalmente consistentes e read concerns disponíveis

Para operações em uma sessão causalmente consistente, os níveis "local", "majority" e "snapshot" estão disponíveis. No entanto, para garantir a consistência causal, você deve usar "majority". Para obter detalhes, consulte Consistência causal.

Operações que apoiam a read concern

As seguintes operações suportam a read concern:

Importante

Para definir a read concern para operações em uma transação, defina a read concern no nível de transação, não no nível de operação individual. Não defina explicitamente a read concern para as operações individuais em uma transação. Para obter mais informações, consulte Transações and Read Concern.

Comando/Método
"local"
"available"
"majority"
"snapshot" [3]
"linearizable"

count

✓
✓
✓
✓

distinct

✓
✓
✓

✓ [2]

✓

find

✓
✓
✓
✓
✓

db.collection.find() via cursor.readConcern()

✓
✓
✓
✓
✓

getMore

✓
✓

aggregate db.collection.aggregate()

✓
✓
✓
✓

✓ [3]

Session.startTransaction()

✓
✓
✓
[1] Não é possível usar o stage $out ou $merge em conjunto com a read concern "linearizable". Ou seja, se você especificar "linearizable" read concern para db.collection.aggregate(), não poderá incluir nenhum dos estágios no pipeline.
[2] Read concern "snapshot" está disponível apenas para determinadas operações de leitura e para transações de vários documentos. Em uma transação, você não pode usar o comando distinct ou seus ajudantes em uma coleta fragmentada.

As seguintes operações de escrita também podem aceitar uma read concern se fizerem parte de uma transação multidocumento:

Importante

Para definir a read concern para operações em uma transação, defina a read concern no nível de transação, não no nível de operação individual.

Comando
"local"
"available"
"majority"
"snapshot" [3]
"linearizable"
delete
db.collection.deleteOne()
db.collection.deleteMany()
db.collection.remove()
✓
✓
findAndModify
db.collection.findAndModify()
db.collection.findOneAndDelete()
db.collection.findOneAndReplace()
db.collection.findOneAndUpdate()
✓
✓
insert
db.collection.insertOne()
db.collection.insertMany()
✓
✓
update
db.collection.updateOne()
db.collection.updateMany()
db.collection.replaceOne()
✓
✓
create
db.createCollection()
(Requires FCV 4.4 or greater)
✓
createIndexes
db.collection.createIndex()
db.collection.createIndexes()
(Requires FCV 4.4 or greater)
✓
[3](1, 2) A área de leitura "snapshot" está disponível somente para determinadas operações de leitura e transações com vários documentos. Para transações, você define a read concern no nível de transação. As operações de transação que suportam "snapshot" correspondem às operações CRUD disponíveis nas transações. Para obter mais informações, consulte Transactions and Read Concern.

Preocupação de leitura sem suporte no banco de dados local

O banco de dados local não suporta questões de leitura. O MongoDB ignora silenciosamente qualquer read concern configurada para uma operação em uma coleção no banco de dados local.

Considerações

Leia seus próprios escritos

Você pode usar sessões causalmente consistentes para ler suas próprias gravações, se as gravações solicitarem confirmação.

Ordem em tempo real

Combinada com "majority" write concern, "linearizable" read concern permite que vários threads realizem leituras e gravações em um único documento como se um único thread executasse essas operações em tempo real; ou seja, o cronograma correspondente para essas leituras e gravações é considerado linearizável.

Comparações de desempenho

Ao contrário "majority", "linearizable" read concern confirma com membros secundários que a operação de leitura é leitura de um primário que é capaz de confirmar gravações com { w: "majority" } write concern. [4] Como tal, leituras com read concern linearizável podem ser significativamente mais lentas do que leituras com read concerns "majority" "local".

Sempre use maxTimeMS com read concern linearizável caso a maioria dos membros portadores de dados não esteja disponível. maxTimeMS garante que a operação não bloqueie indefinidamente e, em vez disso, garante que a operação retorne um erro se a read concern não puder ser executada.

Por exemplo:

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )
[4] Em alguns casos, dois nós em um conjunto de réplicas podem acreditar transitoriamente que são os primários, mas somente um deles poderá realizar gravações com restrição de gravação { w: "majority" }. O nó que consegue realizar gravações { w: "majority" } é o primário atual, e o outro nó é um antigo primário que ainda não reconheceu seu rebaixamento, normalmente devido a uma partição de rede. Quando isso ocorre, os clientes que se conectam ao antigo primário poderão ver dados obsoletos, apesar de terem solicitado uma preferência de leitura primary, e novas gravações no antigo primário acabarão sendo revertidas.

Ler operações e afterClusterTime

O MongoDB inclui suporte para sessões causalmente consistentes. Para operações de leitura associadas a sessões causalmente consistentes, o MongoDB oferece suporte à opção de preocupação de leitura afterClusterTime a ser definida automaticamente pelos drivers para operações associadas a sessões causalmente consistentes.

Importante

Não defina manualmente afterClusterTime para uma operação de leitura. Os drivers do MongoDB definem esse valor automaticamente para operações associadas a sessões causalmente consistentes. No entanto, você pode adiantar o tempo de operação e o tempo de cluster para a sessão, de modo a ser consistente com as operações de outra sessão de cliente. Para obter um exemplo, consulte Exemplos.

Observação

Não é possível especificar atClusterTime em conjunto com afterClusterTime. Para usar o atClusterTime com a read concern "snapshot", é necessário desativar as sessões causalmente consistentes.

Para satisfazer uma solicitação de leitura com um valor afterClusterTime de T, um mongod deve executar a solicitação depois que seu oplog atingir o tempo T. Caso seu oplog não tenha atingido o tempo T, o mongod deve aguardar para atender a solicitação.

As operações de leitura com um afterClusterTime especificado retornam dados que atendem ao requisito de nível de preocupação de leitura e ao requisito afterClusterTime especificado.

Para operações de leitura não associadas a sessões causalmente consistentes, afterClusterTime não está definido.

Read concern do Provenance

O MongoDB rastreia a preocupação de leitura provenance, que indica a origem de uma preocupação de leitura específica. Você pode ver provenance nas métricas getLastError, preocupação de leitura error objects e logs do MongoDB.

A tabela a seguir mostra os possíveis valores de read concern provenance e seu significado:

Proveniência
Descrição

clientSupplied

O read concern foi especificado no aplicativo.

customDefault

A read concern originou-se de um valor padrão personalizado definido. Consulte setDefaultRWConcern.

implicitDefault

A read concern a originou-se do servidor na ausência de todas as outras especificações de read concern.

Voltar

Objetos GeoJSON

Próximo

"local"