MongoDB 4.2, o que vem por aí?

Fala pessoALL, hoje trago algumas das principais novidades da versão 4.2 do MongoDB que foi apresentada ao público durante a conferência anual realizada em Nova York. Pela quinta vez consecutiva eu tive a oportunidade de participar do evento e viver três dias revendo amigos, conversando com pessoas do mundo todo, vendo casos de uso e aplicações das mais diversas para o MongoDB. Diferentemente do ano passado, o evento esse ano foi bem mais empolgante e trouxe anúncios que eu particularmente gostei muito!

Transações Distribuídas

Desde a versão 4.0 o MongoDB implementou suporte à transações e garantias ACID para multi-documentos (lembrem-se que isso existe para um único documento desde o início!) em replicaset. Ano passado esse anúncio causou um grande movimento no mercado, ampliando a gama de aplicações para o MongoDB.

Como previsto no roadmap, esse ano esse suporte à transações multi-documentos se estendeu para o modelo distribuído, passando a ser suportado também em sharding.

Segundo o time de desenvolvimento da MongoDB, as transações distribuídas se aderem aos objetivos de design e se comportam exatamente com as transações que crescemos utilizando em bancos de dados relacionais. A sintaxe é semelhante, são multi-instruções e reforçam o snapshot isolation, deixando sua utilização bem familiar para qualquer pessoa que tenha utilizado transações anteriormente.

Outra boa notícia é que se você já utiliza transações no MongoDB 4.0, não há diferença nenhuma para usar transações distribuídas na 4.2. A API e a implementação é consistente, mesmo se você estiver utilizando transações em documentos, coleções e bancos de dados, em replicaset ou num shard cluster. A atomicidade total é mantida e se uma transação não for "comitada" em algum dos shards, ela será interrompida em todos os outros participantes.

Veja que o código para implementação de transações distribuídas não mudou mesmo:

with client.start_session() as s:
    s.start_transaction()
    collection_one.insert_one(doc_one, session=s) 
    collection_two.insert_one(doc_two, session=s) 
    s.commit_transaction()

Apenas reforçando, o uso de transações, distribuídas ou não deve ser muito bem pensado. De 80 a 90% das aplicações que utilizam MongoDB, não necessitam de transações por conta da garantia de atomicidade para um único documento. Portanto se você está pensando em utilizar transações, revise primeiramente seu modelo de dados e veja se ele não resolve seu problema. Em alguns dias trarei alguns exemplos onde a utilização de transações é bem-vinda e também o impacto que isso causa.

Mutable Shard Key Values

Pegando carona nas transações distribuídas, essa foi a feature que mais me impactou durante o anúncio. Daquelas de te deixar de boca aberta e pensando: putz, nunca imaginei que isso aconteceria!

Pois é, aconteceu... mais informações sobre o que é uma shard key você encontra aqui, porém, ela é o que determina o particionamento dos dados em um shard cluster e pode ser composta de um ou mais atributos do seu documento. Até a versão 4.0, quando você escolhia sua shard key, esse(s) atributo(s) não poderiam ter seus valores alterados, ou seja, se você escolheu o campo UF do seu cadastro de clientes como shard key, e seu cliente mudou de estado, o documento teria que ser inteiramente substituído, gerando um delete e um insert que você teria que controlar em duas operações diferentes, e isso com certeza seria um problemão.

Agora na versão 4.2, essa "limitação" não existe mais, tornando mais fácil a alteração desses dados. Com as transações distribuídas o MongoDB detecta automaticamente o update no valor da shard key e move o documento para o shard correto pra você!

Mais operadores, suporte a queries complexas e Real-time Analytics

A MQL, ou MongoDB Query Language, é bem rica em expressões e conseguimos utilizar vários recursos para extraímos dados de nossos bancos, mas a ausência de alguns recursos sempre causavam aquele efeito: "cara, como que não faz isso?". Em alguns desses casos nós tínhamos que recorrer a aplicação e fazer por lá, isso causava muita frustração em alguns DBAs que gostam de resolver tudo com o banco, ou até mesmo Devs que gostam de utilizar recursos mais avançados do banco.

Updates mais expressivos

Agora podemos utilizar um aggregation pipeline para especificar um update baseado em valores de outros campos e aplicar esse update atomicamente.

Para update ou findAndModify, também é possível setar um campo onde o valor dependa de outro(s) valor(es) do mesmo documento:

db.collection.update(
   {_id:100},
   {
      $set: { "c": { $sum: [ "$a", "$b" ] } }
   }
)

Nesse exemplo, estamos atribuindo a soma dos valores dos campos a e b ao campo c. Esse caso é bem simples, mas podemos sofisticar e muito nossos updates com esses operadores de agregação.

Novos operadores de agregação e expressões

A versão 4.2 adiciona suporte a novos operadores de agregação com regex, vários novas expressões matemáticas para arredondamento e trigonometria, também operadores de current time como o $$NOW, todos esses diminuem muito a quantidade de código implementada do lado da aplicação para resolver essas questões. Esse é um assunto que requer um post exclusivo, porque são quase 100 expressões no aggregation pipeline que deixam mais fácil o cálculo e a transformação dos dados.

Views materializadas

O novo operador de output do aggregation pipeline $merge, permite criar views materializadas que serão atualizadas on-demand. Ou seja, agora quando um valor for alterado em uma collection que uma dessas views utilizem, a view será atualizada automaticamente. Um recurso muito comum nos bancos de dados relacionais que nos permite pré-calcular e armazenar dados para queries analíticas.

Com as views materializadas da 4.2, você tem a flexibilidade de escrever os resultados em shard collections, possibilitando que você escale suas views à medida em que o volume de dados aumenta. Você também pode escrever esses outputs em base de dados diferentes, assim, você consegue isolar melhor os workloads analíticos de outros. Como as views materializadas são armazenadas em uma coleção comum do MongoDB, você pode criar índices específicos para cada uma delas, para otimizar o acesso aos dados e análises mais profundas utilizando o MongoDB Charts, BI ou Apache Spark Connectors.

Wildcard Index

Indexar sub-documentos ou array de sub-documentos sempre foi um desafio. Por ser um recurso tão importante ("embedar" documentos ou valores), não podemos abrir mão de utilizá-lo. A solução para indexar esses valores até a versão 4.0 era criar um índice para cada atributo desejado do sub-documento ou utilizar uma abordagem diferente utilizando um esquema, digamos, mais feio:

{
  "k": "nome do atributo",
  "v": "valor do atributo"
}

Agora com os Wildcard indexes, podemos modelar mais naturalmente e ter um suporte eficiente para servir um range de queries mais diverso.

Ao invés de tentarmos "adivinhar" um padrão de acesso antecipadamente, agora podemos definir um filtro que indexe automaticamente todos os campos, sub-documentos e arrays correspondentes em uma coleção. Para efeitos de memória e armazenamento, os índices Wildcard são implementados como sparse index, onde o índice contém somente entradas para os campos com valores.

Os Wildcard indexes não substituem o planos de índices baseado em workloads, mas permitem simplificar o desenho de estruturas de documentos polimórficas, como um catálogo de produtos por exemplo.

Tem mais...

Bem, esses foram apenas alguns pontos do que vi por lá na última semana, vou continuar escrevendo e trazendo exemplos práticos para a utilização desses novos recursos e ainda falar sobre o MongoDB Atlas que está com um serviço incrível de full-text search utilizando o Lucene como engine, Atlas Datalake, Auto Scaling, Retryable Reads, MongoDB Compass e Schema Validation, Zstandard Compression, Client-side Field Level Encryption (feature muito legal para proteção de dados) e muito mais...

Espero que tenham gostado e até mais!

Eu, Rodrigo Nascimento (NetApp) e Danielle Graziani (MongoDB)

Twitter do Michael Lynn Diretor do Advocacy Hub MongoDB