Mecanismo de armazenamento WiredTiger
Nesta página
O mecanismo de armazenamento WiredTiger é o mecanismo de armazenamento padrão. Para implantações existentes, se você não especificar a configuração do --storageEngine ou storage.engine, a instância mongod poderá determinar automaticamente o mecanismo de armazenamento utilizado 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 do 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 com 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 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 bloqueio global de "instância". Outras operações, como renameCollection, ainda exigem uma bloqueio de banco de dados de dados exclusiva em determinadas circunstâncias.
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.
O MongoDB configura o WiredTiger para criar pontos de verificação, especificamente, gravando os dados do instantâneo no disco em intervalos de 60 segundos.
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.
Usando o WiredTiger, mesmo sem registro no diário, o MongoDB pode se recuperar do último checkpoint; no entanto, para recuperar as alterações feitas após o último checkpoint, execute com o registro no diário.
Observação
Você não pode especificar a opção --nojournal ou storage.journal.enabled: false para membros do conjunto de réplicas que usam o mecanismo de armazenamento WiredTiger.
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.
Journal
O WiredTiger utiliza um log de escrita antecipada (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
No caso de um registro de log menor ou igual a 128 bytes (o tamanho mínimo do registro de log para o WiredTiger), o WiredTiger não compactará esse registro.
You can disable journaling for standalone instances by setting storage.journal.enabled to false, which can reduce the overhead of maintaining the journal. Para instâncias standalone , não usar o diário significa que, quando o MongoDB for encerrado inesperadamente, você perderá todas as modificações de dados após o último checkpoint.
Observação
Você não pode especificar a opção --nojournal ou storage.journal.enabled: false para membros do conjunto de réplicas que usam o mecanismo de armazenamento WiredTiger.
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.
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 4 GB de RAM, o cache WiredTiger usa 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, o 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.