Desempenho de Consultas vs. Atualizações: Escolhendo Operações de Escrita Eficientes

O desempenho de escrita do MongoDB não se resume apenas à rapidez com que o servidor pode aceitar dados. Trata-se da forma da escrita, dos índices que ela deve manter, do documento que ela toca, da confirmação que o cliente espera e se o mesmo registro está sendo martelado por muitas solicitações ao mesmo tempo.

Leituras e escritas falham de maneiras diferentes. Uma leitura ruim geralmente escaneia demais. Uma atualização ruim pode escanear primeiro, depois reescrever um documento crescente, atualizar vários índices, esperar pela replicação e bloquear outro trabalho no mesmo registro quente. É por isso que escolher a operação de escrita correta é importante.

O Trade-off Central: Velocidade de Leitura vs. Durabilidade de Escrita

Em qualquer sistema de banco de dados, existe uma tensão inerente entre garantir a segurança dos dados (durabilidade) e alcançar alta velocidade de transação (taxa de transferência). O MongoDB gerencia isso por meio de dois mecanismos principais relevantes para o desempenho de escrita: Write Concerns e o tipo de operação de escrita em si (por exemplo, inserções simples versus atualizações complexas).

Entendendo os Write Concerns

Write Concerns definem o nível de confirmação que a aplicação requer do MongoDB antes de considerar uma operação de escrita bem-sucedida. Um write concern mais rigoroso aumenta a durabilidade, mas geralmente reduz a taxa de transferência de escrita porque o cliente deve esperar mais tempo pela confirmação.

Nível de Write Concern	Descrição	Durabilidade	Impacto na Latência/Taxa de Transferência
`0` (Fire and Forget)	Nenhuma confirmação necessária.	Mais Baixa	Maior Taxa de Transferência, Menor Latência
`majority`	Escrita confirmada pela maioria dos membros do conjunto de réplicas.	Alta	Latência Moderada, Boa Taxa de Transferência
`w: 'all'`	Escrita confirmada por todos os membros do conjunto de réplicas.	Mais Alta	Maior Latência, Menor Taxa de Transferência

Exemplo Prático: Configurando Write Concern

Ao inserir documentos, você define o write concern no nível do driver:

const options = { writeConcern: { w: 'majority', wtimeout: 5000 } };

db.collection('logs').insertOne({ message: "Evento Crítico" }, options, (err, result) => {
  // Operação é concluída somente após confirmação da maioria
});

Melhor Prática: Para registro de alto volume ou dados não críticos onde a perda ocasional é tolerável, usar w: 0 pode reduzir a latência de confirmação, embora com o risco de perda de dados durante um desligamento sujo.

Características de Desempenho de Consultas

Leituras (Consultas) geralmente não afetam inerentemente a durabilidade, focando puramente na velocidade de recuperação. O desempenho da consulta é governado principalmente por:

Indexação: A indexação adequada é o fator mais importante. Uma consulta que atinge um índice quase sempre superará uma varredura de coleção.
Tamanho da Recuperação de Dados: Buscar menos campos ou documentos menores acelera a transferência de rede e o uso de memória.
Complexidade da Consulta: Pipelines de agregação, especialmente aqueles que envolvem $lookup (junções) ou operações pesadas de $group, exigem tempo de CPU e memória significativos, impactando a capacidade de resposta geral do servidor.

Exemplo: Estrutura de Consulta Eficiente

Sempre prefira campos indexados no predicado da consulta:

// Suponha que o campo 'status' seja indexado
db.items.find({ status: 'active', lastUpdated: { $gt: yesterday } }).limit(100);

Implicações de Desempenho de Atualizações

Atualizações são fundamentalmente operações de escrita e estão sujeitas às mesmas considerações de durabilidade que as inserções. No entanto, as atualizações introduzem complexidades com base em se modificam a estrutura ou o tamanho do documento.

Atualizações no Local vs. Reescritas

O MongoDB tenta realizar atualizações no local sempre que possível. Uma atualização no local é muito mais rápida porque a localização do documento no disco não muda. Isso é possível se:

Os campos atualizados não fizerem o documento exceder seu espaço de armazenamento alocado atual.
A operação de atualização não alterar o tamanho do documento de uma forma que exija reestruturação interna.

Se uma atualização fizer o documento crescer mais do que seu espaço alocado atual, o MongoDB deve reescrever o documento para um novo local no disco. Esta operação de reescrita gera uma sobrecarga significativa de E/S e bloqueia o documento por uma duração mais longa, degradando severamente o desempenho, especialmente em cenários de alta concorrência.

Minimizando Reescritas

Para otimizar atualizações:

Pré-alocar Espaço: Se você sabe que certos campos crescerão significativamente (por exemplo, adicionando elementos a um array), considere inicializar esses campos com dados de espaço reservado para reservar espaço suficiente inicialmente.
Evite Atualizações Excessivas: Se os documentos estão sendo redimensionados com frequência, considere reestruturar o esquema para usar documentos separados e menores vinculados por referências.

Modificadores de Atualização e Velocidade

Diferentes operadores de atualização acarretam custos de desempenho distintos:

Operações Atômicas ($set, $inc): Geralmente são rápidas se resultarem em uma atualização no local.
Manipulação de Array ($push, $addToSet): Podem ser particularmente lentas se causarem repetidamente reescritas de documentos devido ao crescimento do array.
Substituição de Documento (replaceOne): Substituir o documento inteiro (replaceOne ou usando { upsert: true, multi: false } com findAndModify que sobrescreve o documento inteiro) força uma reescrita e deve ser usado com moderação, pois invalida quaisquer índices existentes que apontam para o local antigo que podem precisar de atualização.

Comparando Desempenho de Consultas vs. Escritas

Embora as consultas sejam tipicamente mais rápidas do que as escritas porque evitam a sobrecarga de durabilidade, a comparação é matizada:

Tipo de Operação	Principal Direcionador de Desempenho	Sobrecarga de Durabilidade	Cenário de Pior Caso
Consulta (Leitura)	Eficiência do índice, Latência de rede.	Nenhuma (a menos que leia de uma réplica desatualizada).	Varredura completa da coleção devido à falta de índice.
Atualização (Escrita)	Confirmação do Write Concern, No local vs. Reescrita.	Alta (depende da configuração `w`).	Reescritas frequentes de documentos em todo o cluster.

Insight Acionável: Se sua aplicação é limitada por escrita, primeiro verifique os filtros de atualização, documentos quentes, crescimento de documentos e manutenção de índices. O write concern é uma alavanca útil, mas reduzir a durabilidade deve ser uma decisão de produto, não um reflexo.

Escolhendo a Forma da Escrita, Não Apenas o Write Concern

O write concern controla quando o MongoDB informa ao cliente que uma escrita foi confirmada. Ele não corrige um padrão de atualização ineficiente. Duas escritas podem usar a mesma configuração w: "majority" e ainda ter custos muito diferentes porque uma toca um campo pequeno e a outra continua crescendo um grande array dentro de um documento quente.

Um exemplo comum é um documento de usuário com um array events que nunca para de crescer:

db.users.updateOne(
  { _id: userId },
  { $push: { events: { type: "login", at: new Date() } } }
)

Isso é conveniente no início. Mais tarde, o documento do usuário se torna grande, cada login altera o mesmo documento e as atualizações começam a competir com as leituras do perfil do usuário. Um modelo melhor é frequentemente uma coleção separada user_events:

db.user_events.insertOne({
  userId,
  type: "login",
  at: new Date()
})

Agora, o documento de perfil permanece pequeno e as escritas de eventos anexam novos documentos em vez de modificar repetidamente um documento crescente. Você pode indexar { userId: 1, at: -1 } para telas de atividade recente e expirar eventos antigos com um índice TTL se os dados não forem permanentes.

Outro padrão são contadores. Se cada solicitação incrementa um documento global, esse documento se torna um ponto de acesso de escrita:

db.metrics.updateOne(
  { _id: "page_views" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Para tráfego baixo, isso é aceitável. Sob tráfego intenso, use contadores em baldes, como um documento por minuto, tenant, rota ou chave de shard. Você troca um pouco de agregação em tempo de leitura por uma distribuição de escrita muito melhor.

db.metrics.updateOne(
  { metric: "page_views", minute: "2026-05-24T10:31Z" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Upserts merecem cuidado especial. Um upsert deve primeiro encontrar um documento correspondente. Se o filtro não for indexado, um caminho de escrita se transforma em uma varredura de leitura mais uma escrita. Para um callback de pagamento idempotente, por exemplo, você deseja uma chave indexada única:

db.payment_events.createIndex({ providerEventId: 1 }, { unique: true })

db.payment_events.updateOne(
  { providerEventId },
  { $setOnInsert: { providerEventId, receivedAt: new Date(), payload } },
  { upsert: true }
)

Isso permite que as tentativas sejam seguras sem escanear a coleção ou criar registros duplicados. Também dá à aplicação uma maneira limpa de lidar com conflitos de chave duplicada.

Escritas em lote são outra alavanca útil. Se você está importando 10.000 alterações de status, uma viagem de ida e volta de rede por atualização é geralmente um desperdício. bulkWrite permite que você envie um lote, e lotes não ordenados podem continuar após falhas individuais quando isso for aceitável para o trabalho.

db.orders.bulkWrite(
  updates.map(({ id, status }) => ({
    updateOne: {
      filter: { _id: id },
      update: { $set: { status, updatedAt: new Date() } }
    }
  })),
  { ordered: false }
)

Não relaxe cegamente o write concern para buscar velocidade. Mudar de majority para w: 1 pode reduzir a latência, mas também altera o que pode acontecer durante um failover. Mudar para w: 0 significa que o cliente pode não saber se a escrita falhou completamente. Isso pode ser aceitável para telemetria descartável. É uma escolha ruim para pedidos, alterações de conta ou qualquer coisa que um usuário espera ver confirmada.

A melhor pergunta é: você pode tornar a escrita menor, mais direcionada, menos disputada e mais fácil de repetir? Use $set, $inc, $unset e $setOnInsert em vez de substituir documentos inteiros quando apenas um campo mudou. Mantenha arrays ilimitados fora de documentos que são atualizados com frequência. Adicione índices para filtros de atualização, não apenas para filtros de leitura. Projete tentativas em torno de chaves únicas para que solicitações duplicadas não criem efeitos duplicados.

Medindo o Desempenho de Escrita Sem se Enganar

Um benchmark que insere documentos minúsculos em um banco de dados local vazio não lhe diz muito sobre o desempenho de escrita em produção. Escritas reais competem com índices, replicação, journaling, trabalho em segundo plano e outros clientes. Se você está testando um caminho com muitas atualizações, execute o teste contra documentos que se parecem com documentos reais e índices que correspondem à produção.

Acompanhe pelo menos quatro números: latência da aplicação, duração do comando MongoDB, lag de replicação e erros de escrita ou timeouts. Uma mudança que melhora a latência média, mas cria lag de replicação, pode simplesmente estar movendo a dor para os secundários. Uma mudança que parece rápida com w: 1 pode não atender ao requisito de durabilidade que o produto realmente precisa.

Índices fazem parte do custo de escrita. Cada inserção ou atualização que altera um campo indexado deve atualizar as entradas de índice relevantes. Isso não significa que índices são ruins; significa que índices não utilizados não são gratuitos. Se uma coleção tem muitos índices criados durante anos de trabalho de funcionalidades, revise se eles ainda suportam consultas reais. Remover um índice não utilizado pode melhorar a velocidade de escrita e reduzir o armazenamento, mas faça isso com cuidado após verificar os logs de consulta e testar planos de rollback.

Escolhendo Operações para Tarefas Comuns de Aplicação

Para um formulário de edição de perfil, use $set nos campos que o usuário alterou. Não substitua o documento de usuário inteiro a partir de uma cópia de cliente desatualizada, porque isso pode apagar acidentalmente campos adicionados por outro processo.

Para reservas de inventário, use uma atualização condicional para que a verificação e a alteração ocorram juntas:

db.inventory.updateOne(
  { sku, available: { $gte: quantity } },
  { $inc: { available: -quantity, reserved: quantity } }
)

Em seguida, verifique matchedCount e modifiedCount. Isso evita a condição de corrida onde dois clientes leem a mesma quantidade disponível e ambos decidem que podem reservá-la.

Para exclusões suaves, $set um campo deletedAt e certifique-se de que as leituras normais o filtrem. Se você consulta frequentemente registros ativos, inclua esse campo nos índices relevantes. Para exclusões definitivas em massa, exclua em lotes para não criar operações de longa duração que perturbem o resto da carga de trabalho.

Para migrações em segundo plano, prefira pequenos lotes com pontos de verificação. Um único updateMany massivo pode ser simples, mas pode criar pressão de replicação e tornar o rollback mais difícil. Uma migração que atualiza 1.000 ou 5.000 documentos por vez, registra o progresso e dorme quando o lag de replicação aumenta é menos dramática e geralmente mais segura.

O padrão é o mesmo nesses casos: faça o banco de dados realizar uma única alteração atômica precisa, torne as tentativas seguras e evite crescer documentos quentes para sempre.

Uma Nota Prática de Encerramento: Estratégia de Ajuste de Desempenho

Escolher operações de escrita eficientes no MongoDB depende de alinhar as necessidades da aplicação com as capacidades do banco de dados. Requisitos de alta durabilidade (usando w: 'all') são inerentemente mais lentos do que requisitos de alta taxa de transferência (usando w: 0). Simultaneamente, os desenvolvedores devem se proteger contra a degradação de desempenho causada pela força de reescrita de documentos em disco devido a atualizações que excedem o armazenamento alocado.

Ao selecionar cuidadosamente os write concerns com base na criticidade dos dados e estruturar as atualizações para favorecer modificações no local, você pode equilibrar efetivamente a persistência robusta de dados com as demandas de alta concorrência das aplicações modernas.