No mongoDB3 apareceu um novo mecanismo de armazenamento: WiredTiger . No entanto, o MMAPv1 ainda é a opção padrão no Mongo .

Um pode não ser melhor que o outro, geralmente é uma questão de caso de uso e a escolha da ferramenta certa para o trabalho. Mas qual mecanismo é adequado para qual trabalho?

De fato, enquanto o MMAPv1 é o mecanismo padrão, o WiredTiger parece melhor em quase todos os campos. Possui os mesmos recursos do MMAPv1 plus:

• melhor desempenho de gravação,
• simultaneidade no nível do documento,
• compressão,
• sistema de instantâneos e pontos de verificação.

Encontrei uma tabela comparativa no blog do MongoDB :

Portanto, exceto se você estiver no Solaris, existe um motivo para não escolher o WiredTiger?

EDITAR

Aqui estão dois vídeos que explicam em detalhes os internos do WiredTiger e MMAPv1 .

Pessoalmente, prefiro o mecanismo de armazenamento mmapv1 a partir de agora por três razões.

Razão 1: Maturidade

Não é que o WiredTiger seja imaturo. Mas o mmapv1 é bem compreendido e a batalha é testada para cima e para baixo, para frente e para trás e acima e além. O WiredTiger teve alguns problemas sérios (veja http://jira.mongodb.com para obter detalhes) recentemente, e não estou disposto a fazer com que meus clientes encontrem o próximo da maneira mais difícil.

Razão 2: Recursos

Dado, o WT possui alguns recursos ... basicamente impressionantes. O problema é que eu não vi ninguém se beneficiando deles. Compressão? De qualquer forma, você sacrifica bastante para obter desempenho por um espaço em disco bastante barato. Falta do problema de migração de documentos para expandir documentos? Bem, ainda temos o limite de tamanho de 16 MB e uma complexidade adicional para documentos incorporados, especialmente quando a incorporação é exagerada.

Existem outras características, mas em geral: não vejo muitos benefícios a partir de agora .

Razão 3: custo total de propriedade

Para novos projetos, o WT pode ser bom, especialmente desde o 3.2, pois o seguinte não se aplica.

Fazer migrações de dados é caro. Ele precisa ser planejado, o plano precisa ser acordado por todas as partes interessadas, os planos de emergência devem ser criados e acordados, a migração precisa ser preparada, executada e revisada. Agora multiplique o tempo necessário com as partes interessadas que fazem parte desse processo e os custos para a migração de dados disparada. O retorno do investimento, por outro lado, parece bastante pequeno. Você pode escalar um pouco em vez de fazer uma migração se levar esses fatores em consideração. Para lhe dar uma impressão: eu estimaria aproximadamente uma "semana-homem" por parte interessada, se uma migração fosse planejada, executada e revisada adequadamente. Com custos de US $ 100 por hora por pessoa e apenas três pessoas envolvidas (gerente, DBA e desenvolvedor), isso equivale a US $ 12.000. Observe que esta é uma estimativa conservadora.

Conclusão

Todos esses fatores acima levaram-me à conclusão de não usar a WT de maneira alguma. No momento.

Atualizar

Este post já está com alguns meses e merece uma atualização

No vencimento

Meus comentários originais sobre maturidade são meio obsoletos. O WiredTiger não apresenta grandes problemas há um tempo e se tornou o mecanismo de armazenamento padrão a partir do MongoDB 3.2

Em Recursos

Meus comentários originais ainda têm alguma validade, imho.

Compressão

No entanto, quando o orçamento é apertado ou, de maneira geral, o desempenho não é a principal preocupação, a troca de desempenho é bastante pequena e você basicamente troca pequenos impactos no desempenho (quando comparado à WT descompactada) por espaço em disco, utilizando o que de outra forma seria ocioso ao redor: a CPU.

Criptografia

O MongoDB 3.2 Enterprise introduziu a capacidade de criptografar os armazenamentos do WiredTiger. Para dados com necessidades de segurança aprimoradas, esse é um recurso matador e faz do WT o único mecanismo de armazenamento de escolha, tanto tecnicamente (o MMAPv1 não suporta criptografia) quanto conceitualmente. Deixando de lado a possibilidade de partições de disco criptografadas, é claro, embora você possa não ter essa opção em alguns ambientes.

Bloqueio no nível do documento

Devo admitir que basicamente omiti esse recurso da WT em minha análise acima, principalmente porque ele não se aplicava a mim ou a meus clientes quando escrevi a resposta original.

Dependendo da sua configuração, principalmente quando você tem muitos clientes de gravação simultâneos, esse recurso pode fornecer um excelente aumento de desempenho.

Em Custo total de propriedade

Fazer migrações ainda é caro. No entanto, levando em consideração as alterações na maturidade e a exibição alterada dos recursos, uma migração pode valer a pena o investimento se:

• Você precisa de criptografia (apenas Enterprise Edition!)
• O desempenho não é sua principal preocupação absoluta e você pode economizar dinheiro a longo prazo (calcular de maneira conservadora) usando a compactação
• Você tem muitos processos escrevendo simultaneamente, pois o aumento no desempenho pode economizar a escala vertical ou horizontal.

Conclusão atualizada

Para novos projetos, eu uso o WiredTiger agora. Como a migração de um armazenamento WiredTiger compactado para um não compactado é bastante fácil, costumo começar com a compactação para aprimorar a utilização da CPU ("obtenha mais retorno"). Se a compactação tiver um impacto notável no desempenho ou no UX, migrarei para o WiredTiger não compactado.

Para projetos com muitos escritores concorrentes, a resposta para migrar ou não é quase sempre também "Sim" também - a menos que o orçamento do projeto proíba o investimento. A longo prazo, o aumento de desempenho deve pagar por si mesmo, se a implantação tiver sido razoavelmente planejada. No entanto, é necessário adicionar algum tempo de desenvolvimento ao cálculo, pois em alguns casos o driver precisa ser atualizado e pode haver problemas que precisam ser resolvidos.

Para projetos com pouco orçamento e que não podem oferecer mais espaço em disco no momento, a migração para um WiredTiger compactado pode ser uma opção, mas a compactação coloca um pouco de carga na CPU, algo inédito no MMAPv1. Além disso, os custos de migração podem ser proibitivamente caros para esse projeto.

Meus dois centavos:

O registro no diário no WiredTiger pode perder atualizações em desligamentos rígidos porque usa o buffer na memória para armazenar os registros do diário.

Entre as operações de gravação, enquanto os registros do diário permanecem nos buffers do WiredTiger, as atualizações podem ser perdidas após um desligamento forçado do mongod.

O registro no diário no MMAPv1 grava alterações nos arquivos de diário no disco.

Se a instância mongod travasse sem aplicar as gravações nos arquivos de dados, o diário poderia reproduzir as gravações na exibição compartilhada para eventual gravação nos arquivos de dados.

Nós mudamos para o WiredTiger do MMAPv1 com o objetivo de obter um ganho de desempenho de 7x para 10x. Tivemos que voltar ao MMAPv1, pois o MongoDB travava quando o cache do WiredTiger atingia 100%. Documentamos nossa experiência aqui - https://blog.clevertap.com/sleepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmapv1/