Mecanismos de armazenamento MongoDB MMAPv1 vs WiredTiger

25

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 :

Comparação WiredTiger e MMAPv1

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 .

Buzut
fonte
Todas as pessoas aqui ... você pode visitar blog.clevertap.com/… para uma explicação muito boa sobre o assunto
therealprashant

Respostas:

26

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.

Markus W Mahlberg
fonte
Obrigado Markus pela sua resposta. Eu entendo seus argumentos. Você recomendaria voltar ao MMAPv1 por padrão para novos projetos? Quero dizer, se o desempenho é uma preocupação, a compactação também pode ser totalmente desativada. O espaço em disco é barato, mas a compactação pode ajudar a ajustar o conjunto de trabalho na RAM ... e, assim, ganhar mais desempenho. Ou eu estou errado?
Buzut
11
Até onde eu sei, a compactação é aplicada apenas aos arquivos de dados. Quanto aos novos projetos, deixe-me colocar dessa maneira: eu pediria uma decisão de gerenciamento, exibindo prós e contras. Pessoalmente, uso o WT em um de meus projetos e ainda não tive problemas, mas pode haver outros fatores, como SLAs (que eu posso calcular muito bem com base na experiência com o mmapv1), orçamentos apertados (o que exigiria WT compactado). economize espaço em disco) e muitos outros fatores. A ponderação de riscos e oportunidades não é uma decisão dos DBAs. Um DBA deve fornecer as informações necessárias para fazer uma chamada.
Markus W Mahlberg
11
Este artigo parece indicar que a maneira como os índices são armazenados é um benefício enorme, pois pode reduzir o espaço que seus índices ocupam em 10 vezes: ilearnasigoalong.blogspot.com/2015/03/… . O espaço em disco é barato, mas o ram não.
BT
Estou um pouco confuso sobre o seu ponto em Recursos, você está dizendo que existem recursos que o MMAPv1 possui que o WiredTiger não possui? Seria bom se essa seção fosse um pouco mais clara.
BT
@ BT Não é de todo. O que eu estava tentando dizer é que o WT possui alguns recursos bastante interessantes que, em alguns casos de uso, podem ser úteis, mas geralmente não são. Prefiro um mecanismo de armazenamento testado em batalha do que o de ponta quando se trata de armazenamento de dados. Conforme o artigo: Sim, é possível com a compactação do prefixo salvar a RAM, e isso pode ser uma boa ideia se não houver outra preocupação. Imagine que você pode ser considerado confiável por perda de dados ou problemas de desempenho.
Markus W Mahlberg
5

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.

gabrielgiussi
fonte
4

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/

Anand
fonte
2
Boa redação. Meio que me faz lembrar de Uber indo do MySQL para PostgreSQL em 2013 e, em seguida, voltar para MySQL em junho de 2016.
RolandoMySQLDBA
bem explicado também temos mesma experiência com tigre com fio de modo revreted-lo para MMAPV1
viren