Embora esse mecanismo de armazenamento tenha sido preterido desde a versão 4.0 do MongoDB, existem alguns recursos importantes nele. MMAPv1 é o mecanismo de armazenamento original no MongoDB e é baseado em arquivos mapeados. Somente a arquitetura Intel de 64 bits (x86_64) oferece suporte a esse mecanismo de armazenamento.
O MMAPv1 gera excelente desempenho em cargas de trabalho com...
- Grandes atualizações
- Leituras de alto volume
- Inserções de alto volume
- Alta utilização da memória do sistema
Arquitetura MMAPv1
O MMAPv1 é um sistema baseado em árvore B que alimenta muitas das funções, como interação de armazenamento e gerenciamento de memória para o sistema operacional.
Era o banco de dados padrão do MongoDB para versões anteriores à 3.2 até a introdução do mecanismo de armazenamento WiredTiger. Seu nome vem do fato de usar arquivos mapeados na memória para acessar os dados. Ele faz isso carregando e modificando diretamente o conteúdo do arquivo, que está em uma memória virtual por meio de uma metodologia syscall mmap().
Todos os registros estão localizados de forma contígua no disco e no caso de um documento se tornar maior que o tamanho do registro alocado, o MongoDB aloca um novo registro. Para o MMAPv1 isso é vantajoso para o acesso sequencial de dados, mas ao mesmo tempo uma limitação, pois vem com um custo de tempo, pois todos os índices de documentos precisam ser atualizados e isso pode resultar na fragmentação do armazenamento.
A arquitetura básica do mecanismo de armazenamento MMAPv1 é mostrada abaixo.
Como mencionado acima, se o tamanho do documento ultrapassar o tamanho do registro alocado, isso resultará em uma realocação que não é uma coisa boa. Para evitar isso, o mecanismo MMAPv1 utiliza uma alocação de potência de 2 tamanhos para que cada documento seja armazenado em um registro que contenha o próprio documento (incluindo algum espaço extra conhecido como preenchimento). O preenchimento é então usado para permitir o crescimento de qualquer documento que possa resultar de atualizações enquanto reduz as chances de realocações. Caso contrário, se ocorrerem realocações, você pode acabar tendo fragmentação de armazenamento. O preenchimento troca espaço adicional para melhorar a eficiência, reduzindo assim a fragmentação. Para cargas de trabalho com grandes volumes de inserções, atualizações ou exclusões, o poder de alocação 2 deve ser mais preferido, enquanto a alocação de ajuste exato é ideal para coleções que não envolvem nenhuma atualização ou exclusão de cargas de trabalho.
Poder de Alocação de 2 Tamanhos
Para um crescimento suave de documentos, essa estratégia é empregada no mecanismo de armazenamento MMAPv1. Cada registro tem um tamanho em bytes que é uma potência de 2, ou seja (32, 64, 128, 256, 512...2 MB). 2 MB sendo o limite maior padrão qualquer documento que ultrapasse isso, sua memória é arredondada para o múltiplo de 2 MB mais próximo. Por exemplo, se um documento tiver 200 MB, esse tamanho será arredondado para 256 MB e 56 MB de espaço comercial estarão disponíveis para qualquer crescimento adicional. Isso permite que os documentos cresçam em vez de desencadear uma realocação que o sistema precisará fazer quando os documentos atingirem seus limites do espaço disponível.
Méritos do Poder 2 Alocações de Tamanho
- Reutilização de registros liberados para reduzir a fragmentação: Com esse conceito, os registros são quantizados na memória para ter um tamanho fixo grande o suficiente para acomodar novos documentos que caberiam no espaço alocado criado por uma exclusão ou realocação de documento anterior.
- Reduz a movimentação de documentos: Como mencionado anteriormente, por padrão, as inserções e atualizações do MongoDB que tornam o tamanho do documento maior que o tamanho do registro definido resultarão na atualização dos índices também. Isso significa simplesmente que os documentos foram movidos. No entanto, quando houver espaço suficiente para crescimento em um documento, o documento não será movido, portanto, menos atualizações nos índices.
Uso de memória
Toda a memória livre na máquina no mecanismo de armazenamento MMAPv1 é usada como cache. Conjuntos de trabalho de tamanho correto e desempenho ideal são alcançados por meio de um conjunto de trabalho que cabe na memória. Além disso, a cada 60 segundos, o MMAPv1 libera as alterações nos dados para o disco, economizando na memória cache. Este valor pode ser alterado para que a lavagem possa ser feita com frequência. Como toda a memória livre é usada como cache, não se surpreenda se as ferramentas de monitoramento de recursos do sistema indicarem que o MongoDB usa muita memória, pois esse uso é dinâmico.
Méritos do mecanismo de armazenamento MMAPv1
- Fragmentação reduzida no disco ao usar a estratégia de pré-alocação.
- Leituras muito eficientes quando o conjunto de trabalho foi configurado para caber na memória.
- Atualizações no local, ou seja, atualizações de campo individuais podem resultar no armazenamento de mais dados, melhorando a atualização de documentos grandes com o mínimo de escritores simultâneos.
- Com um número baixo de gravadores simultâneos, o desempenho de gravação pode ser aprimorado por meio do conceito de liberação frequente de dados para o disco.
- O bloqueio em nível de coleção facilita as operações de gravação. O esquema de bloqueio é um dos fatores mais importantes no desempenho do banco de dados. Neste caso, apenas 1 cliente pode acessar o banco de dados por vez. Isso cria um cenário em que as operações fluem mais rapidamente do que quando apresentadas de maneira serial pelo mecanismo de armazenamento.
Limitações do mecanismo de armazenamento MMAPv1
- Alta utilização de espaço ao fazer iterações. O MMAPv1 não possui uma estratégia de compactação para o sistema de arquivos, portanto, faz uma alocação excessiva de espaço de registro.
- Restrição de acesso à coleção para muitos clientes ao realizar uma operação de gravação. O MMAPv1 usa a estratégia de bloqueio em nível de coleção, o que significa que 2 ou mais clientes não podem acessar a mesma coleção ao mesmo tempo, portanto, uma gravação bloqueia todas as leituras dessa coleção. Isso leva a uma simultaneidade grosseira que torna impossível dimensionar o mecanismo MMAPv1.
- A falha do sistema pode resultar em perda de dados se a opção de registro no diário não estiver habilitada. No entanto, mesmo que seja, a janela é muito pequena, mas pelo menos pode protegê-lo de um grande cenário de perda de dados.
- Utilização de armazenamento ineficiente. Ao usar a estratégia de pré-alocação, alguns documentos ocuparão mais espaço no disco do que os próprios dados.
- Se o tamanho do conjunto de trabalho exceder a memória alocada, o desempenho cairá bastante. Além disso, o crescimento significativo do documento após o armazenamento inicial pode acionar E/S adicional, causando problemas de desempenho.
Comparação de mecanismos de armazenamento MMAPv1 e WiredTiger
| Principal recurso | MMAPv1 | Tigre com fio |
|---|---|---|
| Desempenho da CPU | Adicionar mais núcleos de CPU infelizmente não aumenta o desempenho | O desempenho melhora com sistemas multicore |
| Criptografia | Devido ao uso de arquivos mapeados na memória, ele não suporta nenhuma criptografia | A criptografia para dados em trânsito e em repouso está disponível na instalação corporativa e Beta do MongoDB |
| Escalabilidade | Gravações simultâneas que resultam do bloqueio em nível de coleção impossibilitam a expansão. | Altas chances de dimensionar, pois o menor nível de bloqueio é o próprio documento. |
| Ajuste | Poucas chances de ajustar esse mecanismo de armazenamento | Muitos ajustes podem ser feitos em torno de variáveis como tamanho do cache, intervalos de checkpoint e tickets de leitura/gravação |
| Compressão de dados | Sem compactação de dados, portanto, mais espaço pode ser usado | Métodos de compactação Snappy e zlib disponíveis, portanto, os documentos podem ocupar menos espaço do que no MMAPv1 |
| Transações atômicas | Aplicável apenas a um único documento | A partir da versão 4.0, há suporte para transações atômicas em vários documentos. |
| Memória | Toda a memória livre na máquina é usada como cache | O cache do sistema de arquivos e o cache interno são utilizados |
| Atualizações | Suporta atualizações in-loco, portanto, se destaca em cargas de trabalho com inserções de grande volume, leituras e atualizações in-loco | Não suporta atualizações in-loco. Todo o documento deve ser reescrito. |
Conclusão
Ao escolher o mecanismo de armazenamento para um banco de dados, muitas pessoas não sabem qual escolher. A escolha normalmente depende da carga de trabalho a que será submetida. Em um medidor geral, o MMAPv1 seria uma má escolha e é por isso que o MongoDB fez muitos avanços na opção WiredTiger. No entanto, ainda pode superar alguns outros mecanismos de armazenamento, dependendo do caso de uso, por exemplo, onde você precisa executar apenas cargas de trabalho de leitura ou precisa armazenar muitas coleções separadas com documentos grandes em que 1 ou 2 campos são atualizados com frequência.
