Perguntas frequentes: Armazenamento MongoDB

O que é um mecanismo de armazenamento?

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.

Quantas collections e índices podem estar em um cluster?

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.

Posso atualizar uma implantação existente para o WiredTiger?

Sim. Consulte:

• Alterar autônomo para WiredTiger

• Alterar conjunto de réplicas para WiredTiger

• Alterar Cluster fragmentado para WiredTiger

Quanta compactação o WiredTiger oferece?

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.

Qual tamanho devo definir o cache interno do WiredTiger?

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

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.

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 container (por exemplo, lxc, cgroups, Docker, etc.) que não tem acesso a toda a RAM disponível em um sistema, você deverá definir storage.wiredTiger.engineConfig.cacheSizeGB para um valor menor que a quantidade de RAM disponível no container. A quantidade exata depende dos outros processos em execução no container. Consulte memLimitMB.

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

Quanto memória o MongoDB aloca por conexão?

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.

Com que frequência o WiredTiger grava no disco?

Pontos de verificaçã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.

Dados do diário

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 houver operações aguardando entradas de oplog. As operações que podem esperar pelas entradas do oplog incluem:

    • encaminhar queries de verificação contra o oplog

    • operações de leitura realizadas como parte de sessões causalmente consistentes

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

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

  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.

Como recupero espaço em disco no WiredTiger?

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 usando o comando compact . Para mais informações sobre seu comportamento e outras considerações, consulte compact.

Como posso verificar o tamanho de uma collection?

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

db.orders.stats();

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

• db.collection.dataSize() para retornar os dados descompactados com tamanho de em bytes para a coleta.

• db.collection.storageSize() para retornar o tamanho em bytes da collection no armazenamento em disco. Se os dados de collection forem compactados (que é o default for WiredTiger), o tamanho do armazenamento refletirá o tamanho compactado e poderá ser menor do que o valor retornado por db.collection.dataSize().

• db.collection.totalIndexSize() para devolver os tamanhos do índice em bytes para a collection. Se um índice utilizar compressão de prefixo (que é o default for WiredTiger), o tamanho retornado refletirá o tamanho comprimido.

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);
   })
})

Como posso verificar o tamanho dos índices individuais para uma collection?

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.

Como posso obter informações sobre o uso do armazenamento de um banco de dados?

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.