Foi anunciado em fevereiro de 2018 que o MongoDB 4.0 teria suporte a transações e às propriedades ACID!
Achei o máximo!!!
Passados alguns meses comecei a me preocupar um pouco com esta notícia. Porque embora eu adore o MongoDB, ele não é um banco de dados adequado para todas as situações. E confiem em mim, nenhum BD é! Na minha opinião o segredo para o sucesso é usar o BD certo na situação certa.
Antes de começar a conversar sobre as novidades da versão 4.0 eu peço para vocês me acompanharem em algumas reflexões.
- Os BDs relacionais não morreram!!!
Amigos… Os BDs relacionais existem há quase 40 anos e são adequados para situações onde é necessária a integridade referencial, onde os dados estão em formato tabular e as propriedades ACID são necessárias.
- Conheça o MongoDB
Antes de usar o MongoDB é preciso conhecer, muito bem, as características dele. Recentemente um amigo me questionou sobre a arquitetura que ele especificou para uma pequena aplicação, e ficou abismado quando eu falei para ele não instalar o MongoDB no servidor de aplicação!
Quando eu propus uma arquitetura com um replicaset de 2 servidores de dados e um arbitro ouvi a seguinte queixa: “Mas desta forma usar o MongDB vai ser muito caro!”
Vamos esclarecer alguns pontos importantes:
- Você precisará investir em infraestrutura para usar o MongoDB, uma vez que ele deve ser instalado em servidores (talvez mais baratos do que os servidores usados em bancos de dados relacionais… Mas são servidores!).
- Em produção você deve usar o replicaset! Para a sua aplicação a replicação é transparente, ou seja nada de mudanças. Mas use pelo menos dois servidores de dados e um arbitro para garantir a alta disponibilidade dos seus dados.
- Existem configurações importantes e que devem ser conhecidas, como ReadPreference e WriteConcern.
- Faça o certo no início do projeto! Crie o ambiente e a modelagem dos dados corretamente! Vai ser mais fácil, barato e menos arriscado do que fazer correções em um banco de dados com grande volume.
- Você pode usar a versão Community (gratuita) no ambiente corporativo! Mas lembre-se que as interfaces para a administração do MongoDB não são intuitivas, o que torna a vida do DBA bem complicada! E que se você não usa a versão Enterprise você não terá o suporte oficial da MongoDB.
Alertas dados… Vamos para as novidades!!!
Esta semana recebi um e-mail falando que o Release Candidate 0 da versão 4.0 estava liberado para download. Ainda não testei todas as novidades, mas vou compartilhar neste post as mudanças divulgadas no Release Notes oficial.
A novidade mais aguardada… Transações!!!
Há vários anos a equipe de engenheiros da MongoDB vem trabalhando nesta funcionalidade. E agora ela está disponível para ambientes replicados… Mas não está disponível ainda para ambientes particionados (sharding).
Se você não sabe o que é uma transação, recomendo que leia o post que eu escrevi ano passado sobre este assunto.
Imagine uma transação como um bloco de comandos que devem ser executados como uma unidade (ou executa tudo com sucesso, ou não executa nada). No MongoDB este bloco pode conter vários comandos, afetando vários documentos, de várias coleções. Muito parecido com o que existe nos bancos de dados relacionais.
Por meio do isolamento de snapshot, as transações fornecem uma visão globalmente consistente dos dados e reforçam a execução de tudo ou nada para manter a integridade dos dados
Para quem está se perguntando qual será o impacto das transações no desempenho geral do MongoDB, trago boas notícias! As alterações no MongoDB que permitem transações não afetarão o desempenho de cargas de trabalho que não as exigem.
Uma coisa que eu achei bacana, é que a implementação é muito simples… Primeiro crie uma seção, abra a transação, execute os comandos, se ocorrer algum erro aborte a transação, se não ocorreu nenhum erro efetive a transação (commit).
Veja um exemplo usando o código Python:
with client.start_session() as s: s.start_transaction(): try: collection.insert_one(doc1, session=s) collection.insert_one(doc2, session=s) except: s.abort_transaction() raise s.commit_transaction()
Uma novidade que me dá calafrios… Conversão de data type no Aggregation Framework
Vou ser muito honesta… Conversão de tipos de dados tem cara de modelagem mal feita! (Momento opinião da Dani – por favor, tenham paciência com meu lado AD!).
Uma das novidades da versão 4.0 é o operador $convert do Aggregation Framework, que permite que o pipeline de agregação transforme tipos de dados mistos em formatos padronizados, por exemplo, as datas inseridas como strings podem ser transformadas no tipo de data nativo do MongoDB.
Leituras nos secundários sem bloqueio
Se você não conhece a replicação no MongoDB, veja o post no blog.
Como as coisas são hoje (versão 3.6.4): Para garantir que as leituras nunca retornem dados que não estejam na mesma ordem causal do primário, o MongoDB bloqueia as leituras (no secundário), enquanto as entradas de oplog são aplicadas em lotes no secundário.
Isso pode fazer com que leituras no secundário tenham latência variável, o que se torna mais evidente, chato e perigoso, quando as cargas de gravação são mais intensas.
E por que isso ocorre? Porque o MongoDB foi projetado para que cada um dos nós mostre as gravações na mesma ordem em que aconteceram no primário.
Aproveitando as mudanças feitas para o suporte para transações, as leituras secundárias no MongoDB 4.0 não tem bloqueios! Tornando a latência de leitura previsível e mantendo uma visualização consistente dos dados.
O maior benefício desta funcionalidade, é “sentido” nas cargas em lote e quando os clientes distribuídos estão acessando réplicas locais de baixa latência que são geograficamente remotas em relação à réplica primária.
Migrações de dados 40% mais rápidas
Vou confessar… Esta melhoria me deixou muito feliz! Porque nas versões anteriores quando eu criava um novo nó e o adicionava no sharding a migração dos dados era bem lenta…
Agora foram feitas melhorias que garantem migrações 40% mais rápidas (Amém!!!)
Melhorias no Change Stream
Este é um recurso que foi lançado na versão 3.6 e eu adoro! Porque com ele fica mais fácil garantir a integridade dos dados no MongoDB (ele tem outras características e pode ser usado para outras finalidades, mas eu gosto muito dessa! #LadoAD).
Com este recurso é possível monitorar um determinado evento e executar uma ação de forma automática.
Com o MongoDB 4.0, o Change Streams pode ser configurado para rastrear mudanças em um banco de dados inteiro ou até em um cluster inteiro (antes ele estava associado a uma coleção) . Além disso, os fluxos de alterações agora retornarão um timestamp associado ao evento, que pode ser usado pela aplicação.
E na nuvem?
Em ambientes corporativos nem sempre é simples instalar uma versão nova de um SGBD para fazer testes. Por isso, eu recomendo que você utilize o Azure para fazer os testes e avaliar esta versão.
Você pode criar uma máquina virtual no Azure, instalar na VM o sistema operacional que você preferir e instalar o MongoDB 4.0 nesta VM. Usar o Azure tem como principal vantagem a utilização de um ambiente isolado (uma vez que esta versão é o RC 0, e pode ter bugs).
Crie sua máquina virtual com a menor configuração possível, porque nesta etapa creio que você testará as novas funcionalidades usando um volume baixo de dados. Isso te ajudará a economizar, se você já tem uma conta no Azure. Se você não tem uma conta, crie uma e faça seus testes livremente!
Conclusão
A versão 4.0 deve ser lançada em fevereiro e torna a escolha entre um BD relacional e o MongoDB mais complicada, uma vez que teremos transações e suporta às propriedades ACID (recurso já consolidado nos BD relacionais) no MongoDB.
A versão 4.0 me parece uma versão disruptiva! Com melhorias e novidades esperadas a tempos pela comunidade.
Estamos ganhando muitas possibilidades novas e fantásticas! O que torna o trabalho de análise e projeto cada vez mais importante, então se te perguntarem qual SGBD é melhor… Análise antes e lembre que cada um é bom em uma situação!
Esta semana precisei quebrar um pouco a nossa sequência de posts… Mas era impossível deixar uma novidade destas passar sem fazer um post compartilhando as novidades com vocês.
Em junho estarei em Nova York participando do MongoDB World 2018, então aguardem lives, posts, twittes, fotos e afins!!!
Para acompanhar tudo, me sigam nas redes sociais 🙂
- Twitter: @DaniMonteiroDBA
- Facebook: DB4Beginners
- Instagram: @DaniMonteiroDBA
- YouTube
Nas próximas semanas terminaremos o assunto SQL Server, e novos desafios chegarão!
Referências e Links
Post sobre replicação no MongoDB