Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

Armazenamento do MongoDB para implantações autogerenciadas

Nesta página

  • Fundamentos do mecanismo de armazenamento
  • Você pode misturar mecanismos de armazenamento em um conjunto de réplicas?
  • Recomendações de armazenamento
  • Mecanismo de armazenamento WiredTiger
  • Diagnóstico de armazenamento de dados

Este documento aborda perguntas frequentes sobre o sistema de armazenamento do MongoDB.

Um mecanismo de armazenamento é a parte de um banco de dados responsável por gerenciar como os dados são armazenados, tanto na memória quanto no disco. Muitos bancos de dados oferecem suporte a vários mecanismos de armazenamento, onde mecanismos diferentes funcionam melhor para volumes de trabalho específicos. Por exemplo, um mecanismo pode oferecer melhor desempenho para volumes de trabalho de leitura pesados, e outro pode oferecer suporte a uma maior taxa de transferência para operações de gravação.

Dica

Veja também:

Mecanismos de armazenamento para implantações autogerenciadas

Sim. Você pode ter membros do conjunto de réplicas que usam diferentes mecanismos de armazenamento (WiredTiger e na memória)

O desempenho do cluster poderá diminuir quando o número combinado de coletas e índices ultrapassar 100.000. Além disso, coletas grandes têm um impacto maior no desempenho do que coletas menores.

Sim. Consulte:

A proporção de dados compactados para dados descompactados depende dos seus dados e da biblioteca de compressão usada. Por padrão, os dados de collection no WiredTiger usam compressão de bloco Snappy; zlib e zstd também estão disponíveis. Os dados do índice usam compactação de prefixo por padrão.

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 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 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.

Observação

O storage.wiredTiger.engineConfig.cacheSizeGB limita o tamanho do cache interno do WiredTiger. O sistema operacional usa a memória livre disponível para o cache do sistema de arquivos, o que permite que os arquivos de dados compactados do MongoDB permaneçam na memória. Além disso, o sistema operacional usa qualquer RAM livre para armazenar em buffer blocos do sistema de arquivos e cache do sistema de arquivos.

Para acomodar os consumidores adicionais de RAM, pode ser necessário diminuir o tamanho do cache interno do WiredTiger.

O valor padrão do tamanho do cache interno do WiredTiger pressupõe que haja uma única instância mongod por máquina. Se uma única máquina contiver várias instâncias do MongoDB, você deverá diminuir a configuração para acomodar as outras instâncias mongod.

Se você executar mongod em um contêiner (por exemplo, lxc, cgroups, Docker etc.) que não tenha acesso a toda a RAM disponível em um sistema, será necessário definir storage.wiredTiger.engineConfig.cacheSizeGB como um valor menor que a quantidade de RAM disponível no contêiner. A quantidade exata depende dos outros processos em execução no contêiner. Consulte memLimitMB.

Para exibir estatísticas sobre o cache e a taxa de despejo, consulte o campo wiredTiger.cache retornado pelo comando serverStatus.

Cada conexão utiliza até 1 megabyte de RAM.

Para otimizar o uso de memória para conexões, certifique-se de:

  • Monitore o número de conexões abertas para o seu sistema. O excesso de conexões abertas resulta no uso excessivo da RAM e reduz a memória disponível para o conjunto de trabalho.

  • Feche os pools de conexões quando eles não forem mais necessários. Um pool de conexões é um cache de conexões de banco de dados abertas e prontas para uso, mantidas pelo driver. O fechamento de pools desnecessários disponibiliza recursos adicionais de memória.

  • Gerencie o tamanho do seu pool de conexões. A opção de cadeia de conexão maxPoolSize especifica o número máximo de conexões abertas no pool. Por padrão, você pode ter até 100 conexões abertas no pool. Reduzir o maxPoolSize reduz a quantidade máxima de RAM usada para conexões.

    Dica

    Para configurar o pool de conexões, consulte Definições de configuração do pool de conexões.

Pontos de verificaçã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.
Journal Data
O WiredTiger sincroniza os registros do diário em buffer com o disco em qualquer uma das seguintes condições:
  • Para membros do conjunto de réplicas (membros primários e secundários):

    • Se uma operação de gravação incluir ou implicar uma write concern de j: true.

    • Além disso, para membros secundários, após cada aplicação em lote das entradas oplog.

    Observação

    Write concern "majority" implica j: true se a writeConcernMajorityJournalDefault for verdadeira.

  • A cada 100 milissegundos (consulte storage.journal.commitIntervalMs).

  • Quando o WiredTiger cria um novo arquivo de diário. Como o MongoDB usa um limite de tamanho de arquivo de diário de 100 MB, o WiredTiger cria um novo arquivo de diário aproximadamente a cada 100 MB de dados.

O mecanismo de armazenamento WiredTiger mantém listas de registros vazios em arquivos de dados à medida que exclui documentos. Esse espaço pode ser reutilizado pelo WiredTiger,mas não será devolvido ao sistema operacional, a menos que esteja abaixo de circunstâncias muito específicas.

A quantidade de espaço vazio disponível para reutilização pelo WiredTiger é refletida na saída de db.collection.stats() abaixo do cabeçalho wiredTiger.block-manager.file bytes available for reuse.

Para permitir que o mecanismo de armazenamento WiredTiger libere esse espaço vazio para o sistema operacional, você pode desfragmentar seu arquivo de dados. Isso pode ser feito ressincronizando um membro do conjunto de réplicas ou usando o comando compact .

Para visualizar as estatísticas de uma coleção, incluindo o tamanho dos dados, use o método db.collection.stats() de dentro de mongosh. O exemplo a seguir emite db.collection.stats() para a coleção orders:

db.orders.stats();

O MongoDB também fornece os seguintes métodos para retornar tamanhos específicos para a coleta:

O script a seguir imprime as estatísticas para cada banco de dados:

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
printjson(mdb.stats());
})

O script a seguir imprime as estatísticas para cada coleta em cada banco de dados:

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
mdb.getCollectionNames().forEach(function(c) {
s = mdb[c].stats();
printjson(s);
})
})

Para visualizar o tamanho dos dados alocados para cada índice, utilize o método db.collection.stats() e marque o campo indexSizes no documento retornado.

Se um índice usar a compactação de prefixo (que é o default for WiredTiger), o tamanho retornado para esse índice refletirá o tamanho compactado.

O método db.stats() em mongosh retorna o estado atual do banco de dados "ativo". Para a descrição dos campos retornados, consulte dbStats Output.

Voltar

GridFS