Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Mecanismo de armazenamento WiredTiger
Nesta página
A partir do MongoDB 3.2, o mecanismo de armazenamento WiredTiger é o mecanismo de armazenamento padrão. Para sistemas existentes, se você não especificar a configuração --storageEngine ou storage.engine , a versão 3. A instância 2+ mongod pode determinar automaticamente o mecanismo de armazenamento usado para criar os arquivos de dados no --dbpath ou storage.dbPath.
As implementações hospedadas nos seguintes ambientes podem usar o mecanismo de armazenamento WiredTiger:
MongoDB Atlas: o serviço totalmente gerenciado para implantações MongoDB na nuvem
Observação
Todas as implementações do MongoDB Atlas utilizam o mecanismo de armazenamento WiredTiger.
MongoDB Enterprise: a versão autogerenciada e baseada em assinatura do MongoDB
MongoDB Community: uma versão código-disponível, de uso gratuito e autogerenciada do MongoDB
Para saber mais sobre o uso de memória WiredTiger para implantações hospedadas no MongoDB Atlas, consulte Memória.
Operação e Limitações
As seguintes notas operacionais e limitações se aplicam ao motor WiredTiger:
Não é possível fixar documentos no cache do WiredTiger.
WiredTiger não reserva uma parte do cache para leituras e outra para gravações.
Uma carga de trabalho de gravação pesada pode afetar o desempenho, mas o WiredTiger prioriza o cache do índice nesses casos.
WiredTiger aloca seu cache para toda a instância
mongod. O WiredTiger não aloca cache em um nível por banco de dados ou por collection.
Simultaneidade de transação (leitura e gravação)
A partir da versão 7.0, o MongoDB usa um algoritmo padrão para ajustar dinamicamente o número máximo de transações simultâneas do mecanismo de armazenamento (tickets de leitura e gravação). O algoritmo de transação do mecanismo de armazenamento simultâneo dinâmico otimiza a taxa de transferência do banco de dados durante a sobrecarga de cluster. O número máximo de transações simultâneas do mecanismo de armazenamento (tickets de leitura e gravação) nunca excede 128 tíquetes de leitura e 128 tíquetes de gravação e pode diferir entre nós em um cluster. O número máximo de tíquetes de leitura e tíquetes de gravação em um único nó é sempre igual.
Para especificar um número máximo de transações de leitura e escrita (tickets de leitura e escrita) que o máximo dinâmico não pode exceder, use storageEngineConcurrentReadTransactions e storageEngineConcurrentWriteTransactions.
Se quiser desabilitar o algoritmo de transações do mecanismo de armazenamento dinâmico simultâneo, registre uma solicitação de suporte para trabalhar com um engenheiro de serviços técnicos do MongoDB.
Para visualizar o número de transações de leitura simultâneas (tickets de leitura) e transações de gravação (tickets de gravação) permitidas no mecanismo de armazenamento WiredTiger, use o comando serverStatus e consulte o parâmetro wiredTiger.concurrentTransactions .
Observação
Um valor baixo de wiredTiger.concurrentTransactions não indica uma sobrecarga de cluster. Use o número de tíquetes de leitura e gravação em fila como indicativo da sobrecarga do cluster.
Simultaneidade em Nível de Documento
O WiredTiger usa controle de simultaneidade em nível de documento para operações de gravação. Com isso, vários clientes podem modificar documentos diferentes de uma collection ao mesmo tempo.
Para a maioria das operações de leitura e escrita, o WiredTiger usa controle de concorrência otimista. WiredTiger usa apenas bloqueios de intenção nos níveis de banco de dados e coleção. Quando o mecanismo de armazenamento detecta conflitos entre duas operações, uma incorrerá em um conflito de gravação fazendo com que o MongoDB repita essa operação de forma transparente.
Algumas operações globais, normalmente operações de curta duração envolvendo vários bancos de dados, ainda exigem uma trava global de "instância". Outras operações, como collMod, ainda exigem uma trava de banco de dados exclusiva.
Snapshots e Checkpoints
O WiredTiger usa o MVCC (MultiVersion Concurrency Control). No início de uma operação, o WiredTiger fornece um snapshot de ponto no tempo dos dados para a operação. Um snapshot apresenta uma visão consistente dos dados na .
Ao gravar em disco, o WiredTiger grava todos os dados em um snapshot no disco de forma consistente em todos os arquivos de dados. Os dados agoraduráveis atuam como um checkpoint nos arquivos de dados. O checkpoint garante que os arquivos de dados sejam consistentes até o último checkpoint, inclusive; ou seja, os checkpoints podem atuar como pontos de recuperação.
A partir da versão 3,6, o MongoDB configura o WiredTiger para criar pontos de verificação (ou seja, escrever os dados de snapshot em disco) em intervalos de 60 segundos. Em versões anteriores, o MongoDB define pontos de verificação como ocorrer no WiredTiger nos dados do usuário em um intervalo de 60 segundos ou quando 2 GB de dados do diário tiverem sido gravados, o que ocorrer primeiro.
Durante a escrita de um novo ponto de verificação, o ponto de verificação anterior ainda é válido. Como tal, mesmo se o MongoDB terminar ou encontrar um erro enquanto escrevendo um novo ponto de verificação, ao reiniciar, o MongoDB pode se recuperar do último ponto de verificação válido.
O novo posto de controle se torna acessível e permanente quando o WiredTiger a tabela de metadados é atualizada atomicamente para referenciar o novo ponto de verificação. Quando o novo ponto de controle estiver acessível, o WiredTiger libera as páginas dos pontos de controle antigos.
Retenção do Histórico de Snapshot
A partir do MongoDB 5.0, você pode usar o parâmetro minSnapshotHistoryWindowInSeconds para especificar por quanto tempo o WiredTiger mantém o histórico de snapshots.
Aumentar o valor de minSnapshotHistoryWindowInSeconds aumenta o uso do disco porque o servidor precisa manter o histórico dos valores modificados mais antigos dentro da janela de tempo especificada. A quantidade de espaço em disco usada depende da sua carga de trabalho, com cargas de trabalho de maior volume exigindo mais espaço em disco.
O MongoDB mantém o histórico de captura instantânea no arquivo WiredTigerHS.wt localizado em seu dbPath especificado.
Diário
O WiredTiger usa um log write-ahead (ou seja, diário) em combinação com checkpoints para garantir a durabilidade dos dados.
O diário do WiredTiger persiste todas as modificações de dados entre os pontos de controle. Se o MongoDB sair entre pontos de verificação, ele usará o diário para reproduzir todos os dados modificados desde o último checkpoint. Para obter informações sobre a frequência com que o MongoDB grava os dados do diário em disco, consulte Processo de Registro no Diário.
O diário WiredTiger é comprimido usando a biblioteca de compressão snappy. Para especificar um algoritmo de compressão diferente ou nenhuma compressão, utilize a configuração do storage.wiredTiger.engineConfig.journalCompressor. Para obter detalhes sobre como alterar o compressor de diário, consulte Alterar o compressor de diário do WiredTiger.
Observação
Se um registro de log for menor ou igual a 128 bytes (o tamanho mínimo do registro de log para o WiredTiger), o WiredTiger não compactará esse registro.
Dica
Veja também:
Compressão
Com o WiredTiger, o MongoDB suporta compressão para todas as coletas e indexações. A compressão minimiza o uso do armazenamento em detrimento de custos adicionais COPO.
Por padrão, o WiredTiger usa a compactação de blocos com a biblioteca de compactação snappy para todas as collections e a compactação de prefixo para todos os índices.
Para collections, as seguintes bibliotecas de compressão de bloco também estão disponíveis:
Para especificar um algoritmo de compressão alternativo ou nenhuma compressão, utilize a configuração do storage.wiredTiger.collectionConfig.blockCompressor.
Para índices, para desativar a compactação de prefixo, use a configuração storage.wiredTiger.indexConfig.prefixCompression.
As definições de compactação também podem ser configuradas por coleta e por índice durante a criação da coleta e do índice. Consulte Especificar Opções do Mecanismo de Armazenamento e a opção storageEngine db.collection.createIndex().
Para a maioria das cargas de trabalho, as configurações de compactação padrão equilibram o armazenamento eficiência e requisitos de processamento.
O diário WiredTiger também é compactado por padrão. Para obter informações sobre a compactação do diário, consulte Diário.
Uso da Memória
Com o WiredTiger, o MongoDB utiliza o cache interno do WiredTiger e o cache do sistema de arquivos.
A partir do MongoDB 3.4, o tamanho do cache interno padrão do WiredTiger é o maior entre:
50% de (RAM - 1 GB) ou
256 MB.
Por exemplo, em um sistema com um total de 4GB de RAM, o cache WiredTiger utiliza 1.5GB de RAM (0.5 * (4 GB - 1 GB) =
1.5 GB). Por outro lado, em um sistema com um total de 1.25 GB de RAM WiredTiger aloca 256 MB para o cache do WiredTiger porque isso é mais da metade da RAM total menos um gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).
Observação
Em alguns casos, como quando executado em um container, o banco de dados pode ter restrições de memória inferiores à memória total do sistema. Nesses casos, esse limite de memória, em vez do total memória do sistema, é usado como a RAM máxima disponível.
Para ver o limite de memória, consulte hostInfo.system.memLimitMB.
Por padrão, o WiredTiger usa compressão de bloco Snappy para todas as collections e compactação de prefixo para todos os índices. Os padrões de compactação são configuráveis em nível global e também podem ser definidos por collection e por índice durante a criação da collection e do índice.
Diferentes representações são usadas para dados no cache interno do WiredTiger versus o formato no disco:
Os ficheiros de dados no cache do sistema de arquivos são os mesmos do formato no disco, incluindo os benefícios de qualquer compactação para ficheiros de dados. O cache do sistema de arquivos é usado pelo sistema operacional para reduzir a E/S do disco.
Os índices carregados no cache interno do WiredTiger têm uma representação de dados diferente do formato no disco, mas ainda podem aproveitar a compactação de prefixo do índice para reduzir o uso de RAM. A compactação de prefixo de índice deduplica prefixos comuns de campos indexados.
Os dados de coleta no cache interno do WiredTiger são descompactados e utilizam uma representação diferente do formato no disco. A compactação de blocos pode proporcionar uma economia significativa de armazenamento em disco, mas os dados devem ser descompactados para serem manipulados pelo servidor.
Com o cache do sistema de arquivos, o MongoDB usa automaticamente toda a memória livre que não é usada pelo cache do WiredTiger ou por outros processos.
Para ajustar o tamanho do cache interno do WiredTiger, consulte storage.wiredTiger.engineConfig.cacheSizeGB e --wiredTigerCacheSizeGB. Evite aumentar o tamanho do cache interno do WiredTiger acima do
valor padrão.