Consultas distribuídas
Nesta página
Ler operações para conjuntos de réplicas
Por padrão, os clientes leem a partir do primary de um conjunto de réplicas; no entanto, os clientes podem especificar uma preferência de leitura para direcionar operações de leitura a outros membros. Por exemplo, os clientes podem configurar read preferences para ler de secundários ou do nó mais próximo para:
reduzir a latência em sistemas de vários centros de dados;
melhorar a taxa de transferência da leitura ao distribuir altos volumes de leitura (em relação ao volume de gravação);
realizar operações de backup e/ou
permitir leituras até que uma nova primária seja eleita.
As operações de leitura de nós secundários de conjuntos de réplicas podem não refletir o estado atual da primary. As read preferences que direcionam as operações de leitura para diferentes servidores podem resultar em leituras não monotônicas.
Os clientes podem usar sessões causalmente consistentes, que oferecem várias garantias, incluindo leituras monotônicas.
Você pode configurar a read preference por conexão ou por operação. Para obter mais informações sobre a read preference ou sobre os modos de read preference, consulte Read preference e Modos de read preference.
Gravar operações em conjuntos de réplicas
Em conjuntos de réplicas, todas as operações de gravação vão para o primary do conjunto. O primary aplica a operação de gravação e registra as operações no registro de operações ou oplog do primary. O oplog é uma sequência reproduzível de operações para o conjunto de dados. Os nós secundários do conjunto replicam continuamente o oplog e aplicam as operações a si mesmos em um processo assíncrono.
Para obter mais informações sobre conjuntos de réplicas e operações de gravação, consulte Replicação e preocupação com a gravação.
Operações de leitura para clusters fragmentados
Clusters fragmentados permitem fazer a partição de um conjunto de dados entre um cluster de instâncias mongod de forma praticamente transparente para o aplicativo. Para obter uma visão geral de clusters fragmentados, consulte a seção Fragmentação neste manual.
Para um cluster fragmentado, os aplicativos emitem operações para uma das instâncias do mongos associadas ao cluster.
As operações de leitura em clusters fragmentados são mais eficientes quando direcionadas para um shard específico. As queries de collections fragmentadas devem incluir a chave de shard da collection. Se uma query inclui uma chave de shard, o mongos poderá usar metadados de cluster do banco de dados de configuração para rotear as queries em shards.
Se uma query não incluir a chave de shard, o mongos deverá direcionar a query para todos shards no cluster. Essas queries de dispersão podem ser ineficientes. Em clusters maiores, queries de dispersão são inviáveis para operações de rotina.
Para shards de conjuntos de réplicas, as operações de leitura de nós secundários de conjuntos de réplicas podem não refletir o estado atual da primary. As read preferences que direcionam as operações de leitura para diferentes servidores podem resultar em leituras não monotônicas.
Observação
Os clientes podem usar sessões causalmente consistentes, que oferecem diversas garantias, como leituras monotônicas.
Todos os membros de um conjunto de réplicas de shards, não apenas a primary, mantêm metadados relacionados aos metadados de chunk. Isso evita que leituras dos secundários gerem dados órfãos se não estiverem usando read concern
"available". Em versões anteriores, leituras de secundários, independente do read concern, poderiam gerar documentos órfãos.
Para obter mais informações sobre operações de leitura em clusters fragmentados, veja as seções mongos e Chaves de shard.
Gravar operações em clusters fragmentados
Para collection fragmentadas em um cluster fragmentado, o mongos direciona as operações de gravação de aplicativos para os shards responsáveis pela parte específica do conjunto de dados. O mongos usa os metadados do cluster do banco de dados de configuração para rotear a operação de gravação para os shards apropriados.
O MongoDB particiona os dados em uma collection fragmentada em faixas com base nos valores da chave de shard. Em seguida, o MongoDB distribui esses chunks para o shard. A chave de shard determina a distribuição dos chunks para o shard. Isso pode afetar o desempenho das operações de gravação no cluster.
Importante
Operações de atualização que afetam um único documento devem incluir a chave de shard ou o campo _id. Atualizações que afetam vários documentos são mais eficientes em determinadas situações se tiverem a chave de shard, mas podem ser transmitidas para todos os fragmentos.
Se o valor da chave de shard aumentar ou diminuir a cada inserção, todas as operações de inserção terão como alvo um único shard. Como resultado, a capacidade de um único shard se torna o limite para a capacidade de inserção do cluster fragmentado.
Para mais informações, consulte Fragmentação e Operações de gravação em massa.
Alterar fluxos e documentos órfãos
A partir do MongoDB 5.3, durante a range migration, os eventosde change stream não são gerados para atualizações de documentos órfãos.