MongoDB 3.0 – Grandes novidades

MongoDB

MongoDB

Post atualizado em 03/03/2015

Passei os últimos dias estudando o MongoDB 3.0, participei de um webinar e conversas com outros colegas desenvolvedores sobre as novidades da versão 3.0, que neste momento, está em fase beta já está em sua versão final e liberado para download! (atualização 03/03/2015).

São muitas melhorias e novidades, começando pelo Pluggable Storage Engines, que permite adequar a infra do MongoDB para vários cenários de uso, aproveitando melhor os recursos de hardware. Também foram feitas otimizações gerais, melhorias no MongoDB Query Language entre outros pontos. Vou resumir nesse as principais novidades e algumas que pude testar em meu ambiente de desenvolvimento.

Storage Engine Layer

Os storage engines determinam como seus dados serão persistido em disco e qual formato dos arquivos. Ele permite também otimizar recursos de hardware e alocação de memória, seja reduzir o espaço ocupado pelas bases MongoDB, melhorar fragmentação dos dados, reduzir lock, entre outros recursos. A grande vantagem é que você pode ter vários storages engines em um mesmo ambiente MongoDB, como replicas, onde uma pode MMAPv1 e outra WiredTiger. Outra grande vantagem é que não muda nada a maneira em que os dados são acessados, ou seja, a MongoDB Query Language ou acesso via drivers de programação continuam exatamente da mesma forma, independente do storage engine utilizado.

Como é possível ver no gráfico abaixo, os Storage Engines são camadas mais baixo nível. Clique na imagem para ampliar.

Storage Engine Layer

Storage Engine Layer

A tabela abaixo mostra uma diferença entre o WiredTiger (que vou explicar mais abaixo) e o MMAP V1:

 

Storage Engine Layer

Storage Engine Layer – clique para ampliar

 

Sobre o WiredTiger (WT)

O WT nasceu de algumas fraquezas do MMAPv1, como:

  • Compressão;
  • Compactação online;
  • Melhorias na concorrência e escala horizontal
    • O lock é feito no documento, ótimo para ambientes com muita escrita;
    • Permite uso otimizado de hardware;
    • Mais opções para tuning;

Ou seja, em ambientes com muita concorrência entre leitura e escrita, pode fazer uma diferença enorme!

E por que a MongoDB resolveu adotar o WT como um storage engine layer padrão?

Primeiro, maturidade do WT. Foi desenvolvido por antigos membros da Berkeley DB, esse time tem uma grande experiência com banco de dados;

Segundo, a MongoDB comprou a WiredTiger, levou junto seus desenvolvedores, assim como o produto, que está sob seus cuidados.

Terceiro, o produto é bastante utilizado por grandes players, como Amazon. (Saiba mais visitando o site da WiredTiger e também o anúncio da compra pela MongoDB).

Melhoras na concorrência e redução de problemas com lock

No início do MongoDB, muita gente tinha problemas com locks. Isso acontece porque o banco precisa persistir os dados, até aí tudo bem, mas o que acontece quando 2 ou mais processos querem gravar no mesmo lugar ao mesmo tempo? É necessário ter uma fila e algum processo controlando isso. Se o lock for global, é necessário parar todo o banco para persistir uma informação. Outros processos que chegam ao mesmo tempo ficam na fila esperando o anterior concluir sua escrita. O lock por banco reduz a fila para cada base, deixando outros bancos livres para receber seus processos de escrita. Isso vai descendo até chegar no documento, que é um grande avanço, aumenta a granularidade dos locks, pulverizando ações de escrita. Com isso, fica muito mais difícil coincidir dois processos gravando no mesmo lugar ao mesmo tempo.

A concorrência chegando no mesmo nível do documento é um avanço imenso!

 Compactação

A compactação vem habilitada por padrão no WT. Até o momento, existem 2 tipos de compactação:

  1. Snappy (é o padrão)
    1. Possui boa compactação;
    2. Não consome muita CPU;
  2. Zlib
    1. Possui ótima compactação (melhor que o Snappy);
    2. Mas usa muita CPU, pode ter uma performance mais baixa;

Melhorias na performance e uso de espaço em disco

Além do que foi explicado acima, o resultado da implementação do WT mostra uma melhora de 7 a 10 vezes na escrita em disco e uma redução de espaço que pode chegar a 80%.

Melhorias na escrita resultam em um aplicação mais rápida e fluída. E a redução de espaço em disco pode reduzir também os custos de hospedagem e uso do disco. Isso facilita backups e snapshots. Fazer mais usando menos espaço é tudo que precisamos!

Ainda tem mais: agora as réplicas podem crescer para até 50 membros, reduzindo problemas de rede, latência e permitindo que a estrutura seja melhor organizada geograficamente, ficando mais próxima do usuário final.

Melhorias na “query language” e nas ferramentas administrativas

As ferramentas mongoimport, mongoexport, mongodump, mongorestore e mongooplog receberam várias melhorias, deixando suas operações bem mais rápidas depois de alterações nos processos multi-thread. Ou seja, podem realizar mais operações simultâneas.

O método explain() agora permite ser executado sem precisar processar uma query inteira, o que agiliza muito o trabalho para quem precisa otimizar o banco e entender melhor questões de índices e performance. O explain() também foi melhorado para mostrar mais detalhes das queries. Isso eu considero muito útil!

Outra melhoria importante é inclusão do método agregador $dateToString que agiliza muito o trabalho em séries temporais, reduzindo a quantidade de código. Agora o banco pode realizar essa operação automaticamente! 🙂

Melhorias nos índices geográficos

Índices geográficos são utilizados para aplicações que trabalham com localização e mapa. O MongoDB 3.0 implementou os operadores $intersects e $within. Ambos permitem cálculos geográficos para áreas extensas, continentais e trabalhando com múltiplos hemisférios. É um grande avanço!

Como migrar uma base para o WT?

O WT é um outro backend e totalmente incompatível com versões antigas do MongoDB. Se você apenas trocar os binários de uma instalação do MongoDB 2.x para o 3.0 as bases não estarão no formato do WT, é necessário fazer uma migração.

O jeito mais rápido é fazer um backup da base antiga (2.x) usando mongodump e depois importar na base nova (3.0) com mongorestore. Assim terá 100% de certeza que seus dados estarão no formato WT.

Importante também subir o mongod com a flag –storageEngine=wiredTiger

Quero testar, como faço?

O MongoDB 3.0 ainda está em fase beta, não é recomendado para produção. Mas você pode baixar para fins de teste aqui.

A versão final foi disponibilizada para download no dia 03/03/2015, pode ser baixada aqui. (atualização 03/03/2015)

Outra dica importante: se for desenvolver alguma aplicação, verifique se está com as últimas versões dos drivers da sua linguagem de programação favorita. Os drivers antigos não possuem os novos recursos!

Essas melhorias representam um grande avanço ao NoSQL mais popular! Eu ainda estou realizando vários testes em laboratório, mas estou bem satisfeito com o que já vi. Consegui migrar bases grandes para o 3.0 sem nenhum problema. Mas é válido apenas em ambientes controlados, de testes. Só coloque em produção/missão crítica depois que a versão final estiver disponível e depois que testar sua aplicação e infra com o WT!


Veja também