Vamos falar um pouco do WiredTiger?

Vamos falar um pouco do WiredTiger?

Não abordaremos o MMAPv1. O mecanismo de armazenamento WiredTiger é uma melhoria significativa em relação ao MMAPv1 em desempenho e simultaneidade. Ele também oferece os benefícios de compactação e criptografia. O MMAPv1 foi descontinuado à partir da versão 4.0.

O WiredTiger foi pensado e criado para aproveitar ao máximo o desempenho do hardware multi-core e evitar o acesso ao disco. Usando o formato de arquivo compacto e compressão de dados. A baixo iremos detalhar um conjunto de utilitários fornecidos pelo mesmo para armazenamento.

Concorrência em nível de documento

WiredTiger usa controle de simultaneidade em nível de documento para operações de gravação. Como resultado, vários clientes podem modificar diferentes documentos de uma coleção ao mesmo tempo, o que aumenta substancialmente o desempenho. Para a maioria das operações de leitura e gravação, o WiredTiger usa controle de simultaneidade otimista. O WiredTiger usa bloqueios de intenção nos níveis global de banco de dados e de coleção. Quando o mecanismo de armazenamento detecta conflitos entre duas operações, uma das operações incorrerá em um conflito de gravação, fazendo com que o MongoDB repita essa operação de forma transparente.

Pontos de verificação e snapshots

O WiredTiger fornece um MultiVersion Concurrency Control (MVCC) que usa um snapshot point-in-time dos dados para apresentar uma visão consistente dos mesmos na memória. Quando uma operação de gravação chega o WiredTiger grava todos os dados em um snapshot no disco. Esses dados agora atuam como um ponto de verificação que garante que os arquivos de dados sejam consistentes até e incluindo o último ponto de verificação. Isso torna possível que um ponto de verificação possa ser usado para fins de recuperação. O MongoDB configura o WiredTiger para criar pontos de verificação em intervalos de 60 segundos ou 2 gigabytes de dados de diário. O novo checkpoint se torna acessível e permanente quando a tabela de metadados do WiredTiger é atomicamente atualizada para fazer referência ao novo checkpoint. Assim que o novo ponto de verificação estiver acessível, o WiredTiger libera as páginas dos antigos pontos de verificação. Você pode se recuperar do último ponto de verificação usando o WiredTiger, mas todos os dados gravados desde o último ponto de verificação serão perdidos. Para recuperar esses dados, você deve usar o registro no diário (journal).

Journal

WiredTiger usa um registro de transações de write-ahead em combinação com pontos de verificação para garantir a durabilidade dos dados. Ele usa o registro no diário para persistir todas as operações de gravação entre os pontos de verificação. O journal é compactado usando uma biblioteca rápida. O registro no journal é importante para instâncias autônomas para evitar a perda de dados quando o MongoDB falha entre os pontos de verificação. Não é tão crítico para os membros do conjunto de réplicas porque o processo de replicação fornece durabilidade suficiente para nossos dados.

Compactação

WiredTiger usa compactação de bloco com a biblioteca rápida para todas as coleções e uma compactação de prefixo para todos os índices. Pode-se usar, para coleções, a biblioteca de compactação zlib também. As configurações de compactação também são configuráveis por coleção e por índice durante a coleção e a criação do índice.

Memória

O MongoDB usa o cache interno e o cache do sistema de arquivos. Por padrão, o cache do WiredTiger usará: Na versão 3.0, 50% de RAM ou 1 GB, o que for maior.

Na versão 3.2, 60% de RAM menos 1 GB ou 1 GB, o que for maior.

 Na versão 3.4 e superior, 50% de RAM menos 1 GB, ou 256 MB, o que for maior.

Conclusão: Temos inúmeras vantagens ao se utilizar dessa maravilha de engine que os atuais Mongos usam. Desde acesso maximizado em disco a eficiência da utilização dos dados em memória.

Neste link MongoDB Tuning temos um artigo ao qual eu descrevo como podemos monitorar e até solucionar problemas de desempenho no WiredTiger.

Até a próxima!!

Marcado com: , ,
Publicado em NoSQL

Deixe um comentário

Arquivos
Follow SQL DATA BLOG on WordPress.com
Mais acessados
  • Nenhum