Armazenamento do MongoDB para implantações autogerenciadas
Nesta página
Este documento aborda perguntas frequentes sobre o sistema de armazenamento do MongoDB.
Fundamentos do mecanismo de armazenamento
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.
Você pode misturar mecanismos de armazenamento em um conjunto de réplicas?
Sim. Você pode ter membros do conjunto de réplicas que usam diferentes mecanismos de armazenamento (WiredTiger e na memória)
Recomendações de armazenamento
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.
Mecanismo de armazenamento WiredTiger
Posso atualizar uma implantação existente para o WiredTiger?
Sim. Consulte:
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.
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
.
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 omaxPoolSize
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
- 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"
implicaj: true
se awriteConcernMajorityJournalDefault
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 ressincronizando um membro do conjunto de réplicas ou usando o comando compact
.
Diagnóstico de armazenamento de dados
Como posso verificar o tamanho de uma collection?
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:
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 é odefault for WiredTiger
), o tamanho do armazenamento refletirá o tamanho compactado e poderá ser menor do que o valor retornado pordb.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 é odefault 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.