O armazenamento em disco é um recurso crítico para qualquer sistema de banco de dados escalável. O desempenho dos bancos de dados baseados em disco dependerá de como os dados são gerenciados no disco. Seu servidor MongoDB oferece suporte a vários mecanismos de armazenamento conectáveis que lidam com o gerenciamento de armazenamento e armazenam inicialmente todos os documentos sequencialmente. À medida que o banco de dados cresce e várias operações de gravação são executadas, esse espaço contíguo é fragmentado em blocos menores com pedaços de espaço livre entre eles. A solução típica é aumentar o tamanho do disco. No entanto, existem alternativas que podem ajudar você a recuperar o espaço livre sem precisar dimensionar o tamanho do disco. Uma coisa importante a ser observada são as estatísticas de armazenamento do MongoDB e como você pode compactar ou reparar o banco de dados para lidar com a fragmentação.
Qual é o tamanho do seu banco de dados, realmente?
Você deve sempre ficar de olho na quantidade de espaço livre em disco em seu servidor de produção e também é prudente saber o tamanho do seu banco de dados quando estiver pagando por ele em uma plataforma de nuvem. O MongoDB tem um comando db.stats() que pode fornecer informações sobre as estatísticas de armazenamento de uma instância do MongoDB.
>db.stats()
{
"db" : "test",
"collections" : 5,
"views" : 0,
"objects" : 53829,
"avgObjSize" : 43.555,
"dataSize" : 2344556121,
"storageSize" :3124416336,
"numExtents" : 0,
"indexes" : 7,
"indexSize" : 8096876,
"ok" : 1
}
tamanho dos dados
O tamanho total em bytes dos dados não compactados mantidos neste banco de dados.
tamanho do armazenamento
A quantidade total de espaço em disco alocado para todas as coleções no banco de dados.
A resposta de db.stats() depende do tipo de mecanismo do MongoDB. Você pode encontrar sua descrição dependente da versão das métricas acima na documentação do MongoDB.
Por que a grande diferença entre storageSize e tamanho dos dados ? Isso se deve à fragmentação dos arquivos de dados explicados anteriormente. O MongoDB tenta reutilizar o espaço livre entre dados fragmentados sempre que possível e não o libera para o sistema operacional. No entanto, no WiredTiger, storageSize pode ser menor que dataSize se a compactação estiver habilitada.
Caso um grande bloco de dados seja excluído de uma coleção e a coleção nunca use o espaço excluído para novos documentos, esse espaço precisará ser devolvido ao sistema operacional para que possa ser usado por outros bancos de dados ou coleções. Você precisará executar um compacto ou reparar operação para desfragmentar o espaço em disco e recuperar o espaço livre utilizável.
Compactação do MongoDB
A operação compacta do MongoDB reescreve todos os documentos e índices em uma coleção para blocos contíguos de espaço em disco. No entanto, esta operação bloqueia todas as outras operações no banco de dados ao qual a coleção pertence. Portanto, para um servidor autônomo, é recomendável executá-lo durante uma janela de manutenção e, para conjuntos de réplicas, você deve executá-lo de forma contínua para cada estilhaço. Isso significa compactar todos os secundários primeiro e, por fim, o primário para que a disponibilidade do banco de dados não seja afetada. A sintaxe do comando é:
db.runCommand({compact: collection-name }) 1. MMAPv1
- A operação de compactação desfragmenta arquivos de dados e índices. No entanto, lembre-se de que ele não libera espaço para o sistema operacional. A operação ainda é útil para desfragmentar e criar mais espaço contíguo para reutilização pelo MongoDB, mas não adianta quando o espaço livre em disco é muito baixo.
- É necessário um espaço em disco adicional de até 2 GB durante a operação de compactação.
- Um bloqueio de nível de banco de dados é mantido durante a operação de compactação.
2. Tigre com fio
O mecanismo WiredTiger fornece compactação por padrão, que consome menos espaço em disco que o MMAPv1.
- O processo compacto libera o espaço livre para o sistema operacional.
- É necessário um espaço mínimo em disco para executar a operação compacta.
- O WiredTiger também bloqueia todas as operações no banco de dados, pois precisa de bloqueio no nível do banco de dados.
Se você estiver executando o WiredTiger, recomendamos executar a operação compacta quando o armazenamento atingir 80% do tamanho do disco. Você pode fazer isso acionando a operação ‘Compacta’ em nossa página de detalhes.
Reparar MongoDB
MongoDB reparar A operação repara todos os erros e inconsistências no armazenamento de dados, semelhante ao comando fcsk para um sistema de arquivos. Este comando garante a integridade dos dados após um desligamento ou travamento inesperado. No entanto, se o registro no diário estiver habilitado no servidor, não haverá necessidade de reparo, pois o servidor usará o diário para entrar no estado limpo automaticamente após a reinicialização. Se seu banco de dados foi corrompido, então um reparar banco de dados não salvaria os dados corrompidos, portanto, não é recomendável usar esta operação para recuperação de dados quando você tem outras opções.
Para MMAPv1, repare o banco de dados é a única maneira de recuperar espaço em disco se você achar que seu banco de dados não foi corrompido e tem espaço suficiente necessário para a operação de reparo. A sintaxe do comando é:
db.runCommand({repairDatabase: 1}) - Este comando compacta todas as coleções no banco de dados e recria todos os índices.
- O job requer espaço livre em disco igual ao tamanho do conjunto de dados atual mais 2 gigabytes.
No ScaleGrid, usamos o repairDatabase operação para recuperar espaço livre para MMAPv1 conjuntos de motores.
