Pessoal, ontem após ler o Release Notes do MongoDB 4.0, fiquei super empolgado com os recursos que virão! Baseado no release escrito originalmente pelo Mat Keep, trago minha versão dessas novidades.

O MongoDB permite que você atenda as demandas das aplicações modernas com uma base tecnológica que permite:

1) Modelo de dados orientado a documentos - apresentando a você a melhor maneira de trabalhar com dados

2) Um design de sistemas distribuídos - permitindo que você coloque seus dados de maneira inteligente onde quiser

3) Uma experiência unificada que te dá liberdade de rodar em qualquer lugar - proteger seu trabalho com segurança e deixar de ficar preso a fornecedores

Com base nos fundamentos acima, a versão 4.0 é um marco significativo na evolução do MongoDB, e acaba de ser lançado o primeiro Release Candidate (RC), pronto para você testar.

Por que isso é tão significativo? Vamos dar uma olhada rápida pelos principais novos recursos.

Transações ACID Multi-documentos

Anteriormente anunciada em Fevereiro, transações ACID multi-documentos fazem parte da 4.0RC. Com snapshot isolation e execução all-or-nothing, transações extendem as garantias de integridade de dados do ACID do MongoDB para várias instruções e documentos em uma ou várias coleções. Elas são exatamente como as transações com as quais você está familiarizado em banco de dados relacionais, são fáceis de adicionar em qualquer aplicação que necessitem delas e não alteram a maneira como as operações não transacionais são realizadas. Com as transações multi-documentos, ficou mais fácil do que nunca para todos os desenvolvedores abordarem uma gama completa de casos de uso com o MongoDB, enquanto para muitos deles, simplesmente sabendo que elas estão disponíveis fornecerá a paz de espírito essencial para atender qualquer requisito no futuro. No MongoDB 4.0, as transações funcionam dentro do replicaset, e o MongoDB 4.2 suportará transações em shard.

Para dar uma ideia de como são as transações de multi-documentos, aí vai um trecho de código Python da API de transações.

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()

E até pra Java =p:

try (ClientSession clientSession = client.startSession()) {
          clientSession.startTransaction();
           try {
                   collection.insertOne(clientSession, docOne);
                   collection.insertOne(clientSession, docTwo);
                   clientSession.commitTransaction();
          } catch (Exception e) {
                   clientSession.abortTransaction();
           }
    }

O caminho para transações representa vários anos de esforço da engenharia, começando 3 anos atrás com integração do WiredTiger storage engine. O alicerce foi lançado em praticamente todas as partes da plataforma, desde a própria camada de armazenamento até o protocolo de consenso de replicação, até a arquitetura de sharding. Garantias finas de consistência e durabilidade foram criadas, introduziram o global logical clock, refatoraram o gerenciamento de metadados de cluster e muito mais. E todas essas melhorias foram expostas através de APIs totalmente consumíveis pelos drivers. A feature de transações multi-documentos para replicaset está completa e 90% dos recursos restantes necessários para entregar transações em sharding estão concluídos.

Dê uma olhada no site de transações ACID multi-documentos, para saber mais detalhes.

Conversão de tipos no Aggregation Pipeline

Uma das maiores vantagens do MongoDB sobre os bancos de dados tabulares é modelo de dados flexível. Os dados podem ser inseridos no banco de dados sem a necessidade de predefinir sua estrutura. Isso te ajuda a construir aplicações rapidamente e responder facilmente às mudanças envolvendo alterações de aplicações. Isso também é essencial para suportar iniciativas como single customer view ou data lakes operacionais para suportar real-time analytics onde os dados vem de várias origens diferentes. Claro que com o MongoDB Schema Validation, essa flexibilidade é totalmente ajustável, possibilitando impor controles estritos na estrutura de dados, tipos e conteúdo quando você precisar de mais controle.

Portanto, embora o MongoDB facilite a inserção de dados sem um tratamento ou uma estrutura rígida dos campos da coleção, significa que trabalhar com esses dados pode ser mais difícil quando uma aplicação que os consome espera tipos de dados uniformes para alguns campos em todos os documentos. O tratamento de diferentes tipos de dados aumenta a complexidade do aplicativo e as ferramentas de ETL disponíveis, fornecem um suporte bem limitado para essas transformações. Com o MongoDB 4.0, você pode manter todas as vantagens de um modelo de dados flexível, enquanto prepara os dados no próprio banco para os processos de carga.

O novo operador $convert permite ao aggregation pipeline transformar diferentes tipos de dados em um formato padronizado nativamente dentro do banco de dados. Os dados inseridos podem ser convertidos para um formato padronizado, higienizado e exposto para múltiplas aplicações que os consumirão - como os conectores MongoDB BI e Spark para visualizações de alta performance, algoritmos avançados de analytics e machine learning, ou diretamente para o front-end da aplicação. Convertendo os dados em tipos higienizados facilita o processamento, ordenação e comparação de dados na sua aplicação. Por exemplo, um dado financeiro inserido como long, pode ser convertido para decimal sem perda de precisão e processamento.

Quando $convert é combinado com mais de 100 operadores diferentes disponíveis como parte do MongoDB aggregation pipeline, você pode reformatar, transformar e higienizar seus documentos sem incorrer na complexidade, fragilidade e latência da execução dos processos externos de ETL.

Non-Blocking Secondary Reads

Para assegurar que as leituras nunca retornem dados que não estejam na mesma causal order do nó primário, o MongoDB bloqueia os leitores enquanto as entradas de oplog são aplicadas em lotes ao nó secundário. Isso pode fazer com que leituras secundárias tenham uma latência variável, o que se torna muito mais evidente quando o cluster está servido workloads com uso intensivo de escritas. Porque o MongoDB precisa bloquear leituras secundárias? Quando você aplica uma sequência de gravações a um documento, o MongoDB é projetado para que cada um dos nós mostre as gravações na mesma casual order. Então se você alterar o campo "A" em um documento e, em seguida, alterar o campo "B", não será possível ver esse documento com o campo "B" e nem o campo "A" alterados. Sistemas eventualmente consistentes sofrem desse comportamento, mas o MongoDB não.

Aproveitando os timestamps e os snapshots do storage engine implementados para suportar transações ACID multi-documentos, as leituras secundárias no MongoDB 4.0 tornam-se não-bloqueantes. Com as leituras secundárias sem bloqueio, você agora tem baixa latência de leitura e aumento no throughput do seu replicaset, mantendo uma visualização consistente dos dados. Workloads que tiram maior proveito desses benefícios são aquelas em que os clients distribuídos estão acessando réplicas locais de baixa latência que são geograficamente longe em relação ao primary.

Data Migrations 40% mais rápidas

Muito poucos workloads são estáticos hoje em dia. Por exemplo, o lançamento de um novo produto ou jogo, ciclos de relatórios sazonais, podem levar a picos súbitos de cargas que podem derrubar um banco de dados a menos que se possa provisionar um aumento de capacidade rapidamente. Se e quando a demanda diminuir, você deverá ser capaz de redimensionar seu cluster de volta, ajustando a capacidade e o custo.

Para responder a essas flutuações na demanda, o MongoDB permite que você elasticamente adicione e remova nós de um cluster shard em real time, reequilibrando automaticamente os dados nos nós em resposta a essas mudanças. O balanceador, responsável por distribuir uniformemente os dados pelo cluster, foi significativamente aprimorado no MongoDB 4.0. Ao buscar e aplicar documentos simultaneamente, os shards podem concluir migrações de chunks em até 40% mais rápido, permitindo que você atinja novos nós mais rapidamente no momento exato em que precise e reduza a escala quando a carga retornar aos níveis normais.

Ampliações nos Change Streams

Os Change Streams, lançados com o MongoDB 3.6, permitem que os desenvolvedores criem aplicativos reativos, Web, mobile e IoT que podem visualizar, filtrar e agir sobre as alterações de dados à medida que ocorrem no banco de dados. Os Change Streams permitem a movimentação contínua de dados em bancos distribuídos, simplificando o fluxo de alterações de dados e acionando ações onde elas forem necessárias, usando um estilo de programação totalmente reativo.

Com o MongoDB 4.0, os Change Streams agora podem ser configurados para rastrear alterações em um banco de dados ou cluster inteiros. Além disso, eles agora retornarão a hora do cluster associado a um evento, que pode ser usado pelo aplicativo para fornecer a hora associada para o evento.

Iniciando com o MongoDB 4.0

Espero que isso tenha dado um gostinho do que está por vir na 4.0. Existe um monte de outras coisas que não abordamos hoje, mas você pode aprender tudo sobre os recursos abaixo.

1) Visite o MongoDB download center para baixar a última versão.

2) Revise o release notes do 4.0

3) Inscreva-se no próximo treinamento para o 4.0 na MongoDB University

Você também pode conversar comigo no linkedin e conhecer mais sobre os serviços da Cluster Consultoria

Valeu e até a próxima!