O que há de novo no MongoDB 4.2

As atualizações de banco de dados vêm com recursos aprimorados para desempenho, segurança e com novos recursos integrados. É sempre aconselhável testar uma nova versão antes de implantá-la em produção, apenas para garantir que ela atenda às suas necessidades e não haja possibilidade de travamentos.

Considerando muitos produtos, aqueles que precedem as primeiras versões secundárias de uma nova versão principal têm as correções mais importantes. Por exemplo, eu preferiria ter a versão 4.2.1 do MongoDB em produção alguns dias após o lançamento do que a versão 4.2.0.

Neste blog vamos discutir o que foi incluído e quais melhorias foram feitas no MongoDB versão 4.2

O que há de novo no MongoDB 4.2

1. Transações distribuídas
2. Índices curinga
3. Leituras e gravações que podem ser repetidas
4. Criptografia automática em nível de campo do lado do cliente.
5. Linguagem de consulta aprimorada para atualizações expressivas
6. Visualizações materializadas sob demanda
7. Operações de manutenção modernas

Transações distribuídas

As transações são importantes recursos de banco de dados que garantem a consistência e integridade dos dados, principalmente aqueles que garantem os procedimentos ACID. O MongoDB versão 4.2 agora oferece suporte a transações de vários documentos em conjuntos de réplicas e um cluster fragmentado por meio da abordagem de transação distribuída. A mesma sintaxe para usar transações foi mantida na versão 4.0 anterior.

No entanto, as especificações do driver do cliente mudaram um pouco, portanto, se alguém pretende usar transações no MongoDB 4.2, você deve atualizar os drivers para versões compatíveis com servidores 4.2.

Esta versão não limita o tamanho de uma transação em termos de uso de memória, mas depende apenas do tamanho do seu hardware e da capacidade de manuseio do hardware.

A reatribuição de localidade do cluster global agora é possível com a versão 4.2. Ou seja, para uma implementação de fragmentação de zona geográfica, se um usuário residente na região A se mudar para a região B, alterando o valor de seu campo de localização, os dados podem ser movidos automaticamente da região A para B por meio de uma transação.

O sistema de fragmentação agora permite alterar uma chave de fragmentação ao contrário da versão anterior. Literalmente, quando uma chave de fragmento é alterada, é equivalente a mover o documento para outro fragmento. Nesta versão, o MongoDB encapsula essa atualização e se o documento precisar ser movido de um shard para outro, a atualização será executada dentro de uma transação em segundo plano.

O uso de transações não é uma abordagem aconselhável, pois elas degradam o desempenho do banco de dados, especialmente se ocorrerem várias vezes. Durante um período de transação, há uma janela estendida para operações que podem causar conflitos ao fazer gravações em um documento afetado. Por mais que uma transação possa ser repetida, pode haver uma atualização feita no documento antes dessa nova tentativa e, sempre que a nova tentativa ocorrer, ela poderá lidar com a versão antiga do documento em vez da mais recente. As novas tentativas obviamente aumentam o custo de processamento, além de aumentar o tempo de inatividade do aplicativo por meio da latência crescente.

Uma boa prática sobre o uso de transações inclui:

1. Evite usar consultas não indexadas dentro de uma transação como forma de garantir que a operação não seja lenta.
2. Sua transação deve envolver alguns documentos.

Com o formato de esquema dinâmico do MongoDB e o recurso de incorporação, você pode optar por colocar todos os campos na mesma coleção para evitar a necessidade de usar transação como primeira medida.

Índices curinga

Os índices curinga foram introduzidos no MongoDB versão 4.2 para aprimorar as consultas em campos arbitrários ou cujos nomes não são conhecidos antecipadamente, indexando todo o documento ou subdocumento. Eles não se destinam a substituir os índices baseados em carga de trabalho mas serve para trabalhar com dados envolvendo padrão polimórfico. Um padrão polimórfico é onde todos os documentos em uma coleção são semelhantes, mas não possuem uma estrutura idêntica. Padrões de dados polimórficos podem ser gerados a partir de aplicativos envolvendo catálogos de produtos ou dados sociais. Abaixo está um exemplo de dados de coleta polimórfica

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

Ao indexar todo o documento usando índices curinga, você pode fazer uma consulta usando qualquer campo arbitrário como índice.

Para criar um índice curinga

$db.collection.createIndex({“fieldA.$**”: 1})

Se o campo selecionado for um documento aninhado ou uma matriz, o índice curinga será recorrente no documento e armazenará o valor de todos os campos no documento ou matriz.

Leituras e gravações que podem ser repetidas

Normalmente, um banco de dados pode incorrer em algumas interrupções transitórias de rede frequentes que podem resultar em uma consulta sendo parcial ou totalmente não executada. Esses erros de rede podem não ser tão sérios, portanto, oferecem a chance de uma nova tentativa dessas consultas uma vez reconectadas. A partir do MongoDB 4.2, a configuração de repetição é habilitada por padrão. Os drivers do MongoDB podem repetir leituras e gravações com falha para determinadas transações sempre que encontrarem pequenos erros de rede ou quando não conseguirem encontrar algum primário íntegro no conjunto de cluster/réplica fragmentado. No entanto, se você não quiser as gravações que podem ser repetidas, poderá desativá-las explicitamente em suas configurações, mas não encontro uma razão convincente para desativá-las.

Esse recurso é para garantir que, em qualquer caso, a infraestrutura do MongoDB seja alterada, o código do aplicativo não seja afetado. Em relação a um exemplo explicado por Eliot Horowitz, o cofundador do MongoDB, para uma página da Web que faz 20 operações de banco de dados diferentes, em vez de recarregar a coisa inteira ou ter que envolver a página inteira em algum tipo de loop, o driver nos bastidores pode simplesmente decidir tentar novamente a operação. Sempre que uma gravação falhar, ele tentará novamente automaticamente e terá um contrato com o servidor para garantir que cada gravação ocorra apenas uma vez.

As gravações que podem ser repetidas fazem apenas uma única tentativa de repetição, o que ajuda a resolver as eleições do conjunto de réplicas e os erros de rede transitórios, mas não os erros de rede persistentes.

Gravações que podem ser repetidas não tratam de instâncias em que o período de failover excede o valor serverSelectionTimoutMs nas configurações de parâmetro.

Com esta versão do MongoDB, é possível atualizar os valores da chave de fragmentação do documento (exceto se a chave de fragmentação for o campo _id imutável) emitindo uma operação findAndModify/update de documento único em uma transação ou como uma gravação que pode ser repetida .

O MongoDB versão 4.2 agora pode tentar novamente uma operação de upsert de documento único (ou seja, upsert:true e multi:false) que pode ter falhado devido a um erro de chave duplicada se a operação atender a estas condições de chave:

1. A coleção de destino contém um índice exclusivo que causou o erro de chave duplicada.
2. A operação de atualização não modificará nenhum dos campos no predicado da consulta.
3. A condição de correspondência de atualização é um único predicado de igualdade {field:“value”} ou um AND lógico de predicados de igualdade {filed:“value”, field0:“value0”}
4. O conjunto de campos no padrão de chave de índice exclusivo corresponde ao conjunto de campos no predicado de consulta de atualização.

Criptografia automática em nível de campo do lado do cliente

O MongoDB versão 4.2 vem com a criptografia automática de nível de campo do lado do cliente (CSFLE), um recurso que permite que os desenvolvedores criptografem seletivamente campos individuais de um documento no lado do cliente antes de enviá-lo ao servidor. Os dados criptografados são assim mantidos privados dos provedores que hospedam o banco de dados e de qualquer usuário que possa ter acesso direto ao banco de dados.

Somente aplicativos com acesso às chaves de criptografia corretas podem descriptografar e ler os dados protegidos. Caso a chave de criptografia seja excluída, todos os dados que foram criptografados serão tornados ilegíveis.

Observação:este recurso está disponível apenas com o MongoDB Enterprise.

Linguagem de consulta aprimorada para atualizações expressivas

MongoDB versão 4.2 fornece uma linguagem de consulta mais rica do que seus predecessores. Agora, ele suporta agregações e operações modernas de casos de uso ao longo das linhas de pesquisas com base geográfica, pesquisa de gráficos e pesquisa de texto. Ele integrou um mecanismo de pesquisa de terceiros que torna as pesquisas mais rápidas, considerando que o mecanismo de pesquisa está sendo executado em um processo/servidor diferente. Isso geralmente melhora o desempenho do banco de dados, ao contrário de se todas as pesquisas fossem feitas no processo mongod, o que tornaria a latência da operação do banco de dados volátil sempre que o mecanismo de pesquisa fosse reindexado.

Com esta versão, agora você pode manipular arrays, fazer somas e outras operações matemáticas diretamente por meio de uma instrução de atualização.

Visualizações materializadas sob demanda

A estrutura de pipeline de agregação de dados no MongoDB é um ótimo recurso com diferentes estágios de transformação de um documento em algum estado desejado. A versão 4.2 do MongoDB apresenta um novo estágio $merge que, para mim, direi que me economizou algum tempo trabalhando com a saída final que precisava ser armazenada em uma coleção. Inicialmente, a etapa $out permite criar uma nova coleção com base na agregação e preencher a coleção com os resultados obtidos. Se a coleção já existir, ela substituirá a coleção pelos novos resultados, ao contrário do estágio $merge, que incorpora apenas os resultados do pipeline em uma saída existente, em vez de substituir totalmente a coleção. A regeneração de uma coleção inteira sempre com o estágio $out consome muita CPU e E/S, o que pode prejudicar o desempenho do banco de dados. O conteúdo de saída será, portanto, atualizado em tempo hábil, permitindo que os usuários criem visualizações materializadas sob demanda

Operações de manutenção modernas

Os desenvolvedores agora podem ter uma ótima experiência operacional com o MongoDB versão 4.2 com recursos integrados que aprimoram a alta disponibilidade, a estratégia de backup gerenciado na nuvem, melhoram o poder de monitoramento e os sistemas de alerta. O MongoDB Atlas e o MongoDB Ops Manager são as plataformas que fornecem esses recursos. O último foi rotulado como o melhor para executar o MongoDB na empresa. Ele também foi integrado ao operador Kubernetes para usuários locais que estão migrando para a nuvem privada. Essa interface permite controlar diretamente o Ops Manager.

Existem algumas alterações internas feitas no MongoDB versão 4.2, que incluem:

1. Listando cursores abertos.
2. Remoção do mecanismo de armazenamento MMAPv1.
3. Melhoria no reparo do arquivo de dados do WiredTiger.
4. Os campos de diagnóstico agora podem ter queryHash
5. O encadeamento de divisão automática para nós mongos foi removido.

Conclusão