Forem: Leandro Domingues

MongoDB Client-Side Field Level Encryption

Leandro Domingues — Tue, 05 Mar 2024 17:27:08 +0000

Overview

Fala pessoALL, hoje venho trazer um overview de uma feature super interessante do ponto de vista de segurança e proteção de dados no MongoDB: o Client-Side Field Level Encryption (CSFLE).

Apresentado originalmente na versão 4.2, o CSFLE vem evoluindo a cada nova versão e recentemente trouxe grandes avanços. Mas o que realmente ele faz e como pode nos auxiliar? Vejamos a seguir alguns pontos.

O CSFLE está para compor juntos com outros recursos a camada de segurança do MongoDB (Autenticação, Autorização, Criptografia em Repouso e em Trânsito) e atua especificamente nos campos de uma collection criptografando os dados antes do transporte pela rede entre o cluster da base de dados e os servidores de aplicação. Com este recurso os dados estarão protegidos em diversos cenários como:

Captura do tráfego em uma rede não protegida (sem a utilização de TLS)
Dumping / leitura dos dados na memória do servidor
Acesso diretamente ao disco lendo arquivos da base de dados ou arquivos de backup
E até mesmo sendo um usuário com altos privilégios que não tenha as chaves de criptografia

Isso se dá porque o processo de criptografia é feito no cliente que utiliza um Key Management System (KMS) responsável por armazenar a chave de criptografia, dessa maneira os dados de campos sensíveis nunca serão armazenados em texto plano.

Entre as soluções de mercado cloud-based estão:

Amazon Web Services KMS
Azure Key Vault
Google Cloud KMS

Para utilização local podemos utilzar qualquer KMIP compatível, e para ambientes de testes podemos utilizar o que chamamos de Local Key Provider.

Vantagens do CSFLE

Segurança refinada: Protege seus dados confidenciais contra ataques e violações de segurança.
Conformidade com regulamentações: Facilita a conformidade com diversas normas e leis que exigem a proteção de dados confidenciais.
Maior controle: Permite definir quais campos devem ser criptografados e qual nível de criptografia usar.
Desempenho otimizado: A criptografia é realizada no lado do cliente, minimizando o impacto no desempenho do servidor.

Casos de uso do CSFLE

Armazenamento de informações de clientes: Nomes, endereços, números de telefone, etc.
Dados financeiros: Números de cartão de crédito, dados bancários, etc.
Informações de saúde: Registros médicos, históricos de saúde, etc.
Dados confidenciais de negócios: Propriedade intelectual, segredos comerciais, etc.

Começando com CSFLE

Adotar o uso do CSFLE em sua base de dados é relativamente simples devido a compatibilidade com os drivers suportados pelo MongoDB. Nesta série de artigos a intenção é demonstrar a utilização do CSFLE em uma aplicação de exemplo em Python com o AWS KMS. Fique ligado nos próximos posts!

Referências

Detectando índices no MongoDB

Leandro Domingues — Mon, 28 Aug 2023 17:46:51 +0000

Detecção de Índices

Será necessário?

Fala pessoALL, em algumas situações precisaremos identificar índices por algum motivo, seja para uma documentação do ambiente ou até mesmo para a reprodução desses índices em outro cluster, como por exemplo desenvolvimento, homologação ou até mesmo para colocá-los em produção. Ter um script que identifique estes índices é importante em vários sentidos e sempre bom tê-lo à mão.

No meu caso essa necessidade surgiu para efeito de documentação, principalmente para identificar se algumas coleções do banco de dados estavam com índices do tipo TTL, muito utilizados para o expurgo automático de dados.

Conectando

O cluster utilizado aqui está no MongoDB Atlas e se você não tem ainda um ambiente lá para testes pode criar um cluster totalmente free aqui.

Vamos utilizar o mongosh que é uma interface completa para administração do MongoDB, vou demonstrar passo-a-passo e por fim juntar tudo para criar o nosso script de saída. Também é importante ressaltar que os comandos à seguir foram executados na versão 7.0 do MongoDB.

mongosh "mongodb+srv://<seu_cluster>/myFirstDatabase" --apiVersion 1 --username <seu_usuario>

Listando os databases

Aqui é importante ressaltar que o usuário utilizado para a conexão / execução do script deve ter os privilégios necessários para algumas tarefas, como listar os databases, coleções e por fim os índices. Veja mais sobre as permissões no MongoDB neste link.

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    print(myDB);
});

Listando as coleções

Agora com os nomes dos databases de nosso cluster, podemos adicionar mais uma etapa e listar o nome das coleções de cada um deles. Note que não queremos listar as coleções dos databases admin e nem local, para isso, vamos adicionar uma condição que "exclua" esses databases.

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`Coleções no banco de dados ${myDB}:`);
        db.getCollectionNames().forEach(collectionName => {
            print(`- ${collectionName}`);
        });
    }
});

Listando os índices

Agora, vamos finalmente listar os índices de cada uma das coleções:

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`Coleções no banco de dados ${myDB}:`);
        db.getCollectionNames().forEach(collectionName => {
            print(`- ${collectionName}`);
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                print(`  - ${index.name} (${JSON.stringify(index)})`);
            });
        });
    }
});

Note que para cada índice temos seu nome e também as propriedades que compõem cada um deles. Isso é importante não só para a identificação dessas propriedades, mas também para gerar uma saída para a criação de cada um deles.

Adicionando o createIndex()

Vamos modificar um pouco o script para que ele nos dê o comando para a criação de cada um desses índices:

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`Coleções no banco de dados ${myDB}:`);
        db.getCollectionNames().forEach(collectionName => {
            print(`- ${collectionName}`);
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                print(`  - ${index.name} (${JSON.stringify(index)})`);
                print(`    -- create: db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
            });
        });
    }
});

Podemos também modificar um pouco mais para que o índice _id não gere o script para a criação:

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`Coleções no banco de dados ${myDB}:`);
        db.getCollectionNames().forEach(collectionName => {
            print(`- ${collectionName}`);
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                if(index.name !== "_id_"){
                    print(`  - ${index.name} (${JSON.stringify(index)})`);
                    print(`    -- create: db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
                }
            });
        });
    }
});

Identificando uma propriedade do índice

Ok, chegamos até aqui, mas e se quisermos listar somente os índices com a propriedade TTL (como se deu a origem desse post)?

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`Coleções no banco de dados ${myDB}:`);
        db.getCollectionNames().forEach(collectionName => {
            print(`- ${collectionName}`);
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                if(index.name !== "_id_"){
                    if (index.expireAfterSeconds !== undefined) {
                        print(`  - ${index.name} (${JSON.stringify(index)})`);
                        print(`    -- create: db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
                    }
                }
            });
        });
    }
});

Juntando tudo

Ufa, quanta coisa! Agora vamos juntar tudo para que nosso script seja realmente funcional em três pontos:

listar todos os índices (exceto o _id) de cada coleção de cada base de dados;
gerar o comando para a criação de cada um deles;
e por fim, somente os índices TTL. ### Todos os índices

var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`use ${myDB};`);
        db.getCollectionNames().forEach(collectionName => {
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                if (index.expireAfterSeconds !== undefined) {
                        printjson(`db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
                }
            });
        });
    }
});

Saída para arquivo

Aqui para facilitar, colocaremos o conteúdo de nosso script em um arquivo chamado verifyIndex.js, você pode criar esse arquivo como preferir. Com isso teremos um arquivo de saída chamado outputIndex.js.

crie o arquivo verifyIndex.js

cat << 'index' | tee verifyIndex.js
var myDBs = db.adminCommand({ listDatabases: 1 }).databases.map(db => db.name);
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`use ${myDB};`);
        db.getCollectionNames().forEach(collectionName => {
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                if(index.name !== "_id_"){
                    printjson(`db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
                }
            });
        });
    }
});
index

carregue o arquivo utilizando o mongosh. Aqui utilizamos os seguintes parâmetros:
- --file indicando o arquivo que será carregado
- --quiet para que o arquivo de saída não contenha nenhum registro sobre a execução do mongosh, como abertura de conexão e etc.
- e finalmente a saída será escrita no arquivo outputIndex.js

mongosh "mongodb+srv://<user>:<password>@<seu_cluster>/test" --file verifyIndex.js --quiet > outputIndex.js

Saída para arquivo somente dos índices TTL

cat << 'index' | tee verifyIndex.js
myDBs.forEach(myDB => {
    if (myDB !== 'admin' && myDB !== 'local') {
        db = db.getSiblingDB(myDB);
        print(`use ${myDB};`);
        db.getCollectionNames().forEach(collectionName => {
            let indexes = db.getCollection(collectionName).getIndexes();
            indexes.forEach(index => {
                if (index.expireAfterSeconds !== undefined) {
                        printjson(`db.getCollection("${collectionName}").createIndex(${JSON.stringify(index.key)}, ${JSON.stringify(index)});`)
                }
            });
        });
    }
});

Conclusão

É isso pessoALL... como sempre destaco em meus posts, existem diversas maneiras de fazer isso, uma delas é inclusive utilizando Python (o que particularmente eu gosto bastante), e prometo compartilhar o script mais a frente!

Espero que tenham gostado e fiquem à vontade para compartilhar!

Um abraço e até mais!

Upgrade de versão no MongoDB

Leandro Domingues — Mon, 21 Aug 2023 14:18:58 +0000

Fala pessoALL, parece que foi ontem, mas já estamos em mais da metade de Agosto/2023 e já fazem 3 meses que o MongoDB 4.2 teve o seu EOL (End of life), ou seja, não tem mais suporte oficial e também não recebe mais nenhum tipo de correção de bugs ou correções de segurança por exemplo. Com isso em mente, se você tem algum ambiente MongoDB 4.2 (seja ele Enterprise Advanced ou Community Edition) deve atualizá-lo imediatamente. Já no Atlas, o processo é um pouco diferente, e se você mesmo não atualizar até a data de EOL, o próprio Atlas cuida disso. Mas o que você deve saber ou fazer para que sua aplicação continue funcionado?

O processo de atualização dos binários é teoricamente simples e não exige nenhum tipo de alteração nos arquivos de dados, logs ou configuração (mongod.conf). A maior questão é com os drivers de sua aplicação, isso porque algumas funções ou métodos, podem ter sido descontinuados e então isso vai gerar um trabalho do lado do código.

Drivers

Procure sempre utilizar os drivers mais atualizados disponíveis para a sua linguagem de programação preferida. Atente-se aos recursos disponíveis e o nível de compatibilidade entre a versão do seu driver e a versão do MongoDB.

Neste link você pode consultar todos os drivers oficialmente suportados pelo MongoDB bem como as bibliotecas suportadas pela comunidade. Ao selecionar C# por exemplo, você pode ver a compatibilidade entre as versões:

Note que para utilizar o MongoDB 4.4 é necessário estar com a versão do driver .NET/C# minimamente na versão 2.11.

A atualização do driver pode ser a etapa mais trabalhosa quando você for atualizar a versão do MongoDB, isto porque, quanto mais antigo o driver, mais pontos de alterações você terá em sua aplicação. A dica aqui é sempre manter o driver atualizado, visto que a compatibilidade com versões anteriores do MongoDB é bastante ampla.

Release Notes

Uma outra fonte de consulta indispensável é a página de Release Notes, neste link você encontra todos os pontos de atualização, correção e melhorias da versão, e mais especificamente, você pode consultar a página mudanças de compatibilidade e consultar todas as mudanças efetuadas na versão desejada (neste caso falando da 4.4). Nestes links você tem um guia bem completo para seguir na sua caminhada de atualização do MongoDB.

Além de informações importantes sobre comandos, métodos, operadores e funções do MongoDB, é importante verificar a compatibilidade com o Sistema Operacional. Dependendo da sua versão, seu SO pode ter sido removido e não ter mais compatibilidade, isso leva um pouco mais de tempo, mas pode acontecer, e então antes de atualizar o MongoDB você precisará atualizar seu SO.

MongoDB Atlas Upgrade

O upgrade de versão no MongoDB Atlas é extremamente simples e com zero-downtime. Com as possíveis correções de compatibilidade executadas, você precisará apenas de alguns cliques. Vale ressaltar que o upgrade no MongoDB Atlas é compulsório quando a data limite for atingida, ou seja, se você tiver um cluster em uma versão já programada para o EOL e não tomar nenhuma ação o cluster será atualizado automaticamente. Outro ponto importante é que o MongoDB Atlas retira versões EOL assim que o prazo termina, por essa razão, não é possível construir um cluster no MongoDB Atlas com uma versão EOL, e também por isso, os prints à seguir são de um upgrade da versão 4.4 para a versão 5.0.

Acesse o dashboard do seu cluster e logo depois clique em Edit Configuration:
Na seção Advanced Setting, selecione a versão 5.0: Se você notar, outras versões do MongoDB estão disponíveis, porém, o upgrade deve ser feito seguindo a ordem das versões, ou seja, você não pode fazer o upgrade da versão 4.4 diretamente para a versão 6.0.
No rodapé, clique em Review Changes e logo após confirme as alterações:

Um aviso na parte superior nos alerta dizendo que essa mudança de versão é irreversível, ou seja, não podemos alterar um cluster para uma versão anterior. Para assegurar que você terá uma versão de seu banco de dados na versão anterior é importante fazer um backup, ali no próprio Atlas. Com esse backup é possível construir um novo cluster na versão compatível e restaurar o backup.

Ao aplicar as alterações, um plano de execução será montado pelo Atlas, que começará a atualizar cada um dos nós de seu cluster, e como eu disse sem nenhum tipo de downtime.

MongoDB Community Edition Upgrade

Para ambientes onpremisses na versão Community, o procedimento não é "visual" como no Atlas. Na demonstração à seguir utilizarei comandos baseados em uma distribuição Linux RHEL.

Faça backup dos dados:
```
mongodump --out <caminho_para_a_saida_do_backup>
```
Existem outras opções para o mongodump, mas não abordaremos aqui neste artigo.

Faça backup do arquivo de configuração:

cp /<caminho_do_arquivo>/mongod.conf /<caminho_do_arquivo>/mongod.conf_old

Pare o serviço do MongoDB:
```
sudo service mongod stop
```

Remova os binários da versão anterior:

sudo yum erase $(rpm -qa | grep mongodb-org)
sudo yum erase $(rpm -qa | grep mongodb-database-tools)

Remova o repositório da versão anterior:

rm -f /etc/yum.repos.d/mongodb-org-4.2.repo

Crie um novo arquivo para o repositório da versão desejada, neste caso a versão 4.4:

cat << 'ENDOFDOC' | sudo tee /etc/yum.repos.d/mongodb-org-4.4.repo
[mongodb-org-4.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc
sslverify=0
ENDOFDOC

Atualize o repositório e faça a instalação:

sudo yum update
sudo yum install -y mongodb-org

Copie o arquivo de configuração para o caminho correspondente utilizado na versão anterior. Note que no arquivo de configuração, nenhuma alteração foi necessária:
```
sudo cp /etc/mongod.conf_old /etc/mongod.conf
```
Inicie o serviço:
```
sudo systemctl start mongod
```

Execute esses procedimentos primeiro nos servidores secundários, sempre fazendo um nó a cada vez. Fazendo assim, todo o processo também não gerará downtime.

Ao chegar no servidor primário, não se esqueça de fazer um step down, este procedimento iniciará uma eleição, passando o atual primário para secundário e você poderá fazer o shutdown com segurança.

rs.stepDown()

Conclusão

Vimos que o processo de atualização de versão do MongoDB, tanto no MongoDB Atlas, quanto para servidores onpremisses não gera downtime quando executado adequadamente. Também vimos que é muito importante verificar a compatibilidade dos drivers utilizados pela aplicação, bem como verificar se métodos, funções, etc. tenham sido modificados ou até mesmo retirados e fazer as atualizações correspondentes. Além de ter sempre um backup com os dados na versão corrente (antes do upgrade), isso vai garantir que você possa reinstalar, ou construir um novo cluster, para restaurar seus dados.

Se precisar de ajuda, conte com a gente! E não se esqueça de deixar seu like e compartilhar à vontade.

Até mais!

Como listar Usuários e Permissões no MongoDB

Leandro Domingues — Thu, 09 Mar 2023 19:31:18 +0000

Listando usuários e privilégios no MongoDB

Fala pessoALL, já precisaram listar os usuários e seus privilégios em um ambiente MongoDB?

Em ambientes pequenos ou com poucos usuários isso pode parecer mais fácil, porque podemos ir diretamente em alguns usuários. Mas em ambientes maiores, com muitos usuários e também privilégios isso com certeza será uma tarefa difícil.

Para facilitar a vida vamos a um pequeno script para iterar sobre nossos usuários e privilégios.

Primeiramente, boas-práticas...

Ao utilizar o MongoDB, podemos criar usuários e privilégios em qualquer base de dados do cluster, mas por boa-prática (e acreditem, isso facilita muito), centralizamos as criações na base de dados admin.

Usuários e privilégios

Os usuários podem ter um ou mais privilégios (roles) e o script abaixo faz uma iteração para cada usuário e também dentro de cada role.

Dentro do mongosh

use admin;
db.getUsers().forEach(user => {
   print(user.user);
   user.roles.forEach(role => {
       var roleDetails = db.getRole(role.role, { showPrivileges: true });
       printjson(roleDetails);
   });
});

E é isso...

Sim, rápido e simples... claro que o script pode ser totalmente aprimorado, incluir algumas condições e tudo mais!

Espero que ajude e não esqueça de adicionar ao cinturão de atividades e compartilhar!

Mais performance e insight rápidos no Aggregation Framework - $facet

Leandro Domingues — Mon, 16 Sep 2019 15:08:41 +0000

Fala pessoALL, blz? Hoje vou mostrar um recurso muito bacana no Aggregation Pipeline, mais especificamente um estágio que pode ser muito útil para nos fornecer uma visão com múltiplas dimensões dos dados e até mesmo aumentar a performance da nossa agregação.

Estágios do Aggregation Pipeline

Para quem não tem familiaridade com o Aggregation Framework, um dos componentes são os estágios do pipeline. Os estágios contém desde as mais simples operações como um filtro através do $match até operações complexas de agrupamento e "separação" dos dados com $group ou $bucket. Hoje veremos o $facet.

O Dataset

Como base para nosso exemplo utilizarei uma base de dados que contém os dados demográficos de eleitores do Brasil. Essa base originalmente é disponibilizada através de um conjunto de arquivos .csv que eu já importei para uma instância do MongoDB Atlas. Abaixo a estrutura do documento:

{
    "_id" : ObjectId("5d532411541c5b6d0cfe90d3"),
    "ano" : 2018,
    "uf" : "SP",
    "codigoCidade" : 64777,
    "nomeCidade" : "GUARULHOS",
    "codigoSitBiometrica" : 1,
    "sitBiometrica" : "Biométrico",
    "zona" : 393,
    "codigoGenero" : 2,
    "genero" : "MASCULINO",
    "codigoEstadoCivil" : 7,
    "estadoCivil" : "SEPARADO JUDICIALMENTE",
    "codigoFaixaEtaria" : 6064,
    "faixaEtaria" : "60 a 64 anos",
    "codigoEscolaridade" : 8,
    "escolaridade" : "SUPERIOR COMPLETO",
    "qtdPerfil" : 13,
    "qtdBiometria" : 13,
    "qtdDeficiencia" : 1,
    "qtdNomeSocial" : 0
}

Veja que os dados estão classificados por perfil, ou seja, cada documento da minha coleção tem um total de pessoas que se encaixam em um determinado perfil. No exemplo acima podemos dizer que temos 13 pessoas no seguinte perfil:

cidade: Guarulhos
zona: 393
genero: MASCULINO
estado civil: SEPARADO JUDICIALMENTE
faixa etária: 60 a 64 anos
escolaridade: SUPERIOR COMPLETO

Se quisermos saber o total de eleitores por gênero, poderíamos fazer um $group simples:

db.eleitorado.aggregate([
    {
        $group: {
            _id: "$genero",
            total: {
                $sum: "$qtdPerfil"
            }
        }
     }
])

/* 1 */
{
    "_id" : "MASCULINO",
    "total" : 69902977
}

/* 2 */
{
    "_id" : "FEMININO",
    "total" : 77339897
}

/* 3 */
{
    "_id" : "NÃO INFORMADO",
    "total" : 63401
}

Isso nos permite agrupar por um dos atributos, no caso gênero, e se fizermos dessa maneira teremos que executar várias vezes o aggregate, trocando o atributo e teremos resultados separados. Utilizando essa abordagem perdermos muita performance e eficiência, por isso podemos utilizar o $facet!

Múltiplas dimensões

O operador $facet nos permite executar múltiplos estágios em paralelo e obter o resultado de cada um desses estágios de uma única vez. Dentro de cada execução do $facet podemos utilizar vários operadores, como $group, $unwind, $sort, etc.

O exemplo a seguir incrementa o nosso pipeline colocando um filtro por UF e Cidade e gera um agrupamento por cada um dos atributos contidos no documento:

db.eleitorado.aggregate([
    {
        $match: {
            "uf": "SP",
            "nomeCidade": "GUARULHOS"
        }
    }, 
    {
        $facet: {
            "genero": [ 
                {
                    $group: {
                        _id:"$genero",
                        total: {
                            $sum: "$qtdPerfil"
                        }
                    }
                },
                {
                    $sort: {
                        total: -1
                    }
                }
            ],
            "estadoCivil": [
                {
                        $group: {
                        _id: "$estadoCivil",
                        total: {
                            $sum: "$qtdPerfil"
                        }
                    }  
                },
                {
                    $sort: {
                        _id: 1
                    }
                }
            ],
            "escolaridade": [
                {
                    $group: {
                        _id: "$escolaridade",
                        total: {
                            $sum: "$qtdPerfil"
                        }
                    }
                },
                {
                    $sort: {
                        _id: 1
                    }
                }
            ],
            "faixaEtaria": [
                {
                    $group: {
                        _id: "$faixaEtaria",
                        total: {
                            $sum: "$qtdPerfil"
                        }
                    }
                },
                {
                    $sort: {
                        _id: 1
                    }
                }
            ]
        }
    }
])

/* 1 */
{
    "genero" : [ 
        {
            "_id" : "FEMININO",
            "total" : 439778
        }, 
        {
            "_id" : "MASCULINO",
            "total" : 374563
        }, 
        {
            "_id" : "NÃO INFORMADO",
            "total" : 1
        }
    ],
    "estadoCivil" : [ 
        {
            "_id" : "CASADO",
            "total" : 335326
        }, 
        {
            "_id" : "DIVORCIADO",
            "total" : 42696
        }, 
        {
            "_id" : "NÃO INFORMADO",
            "total" : 2
        }, 
        {
            "_id" : "SEPARADO JUDICIALMENTE",
            "total" : 8363
        }, 
        {
            "_id" : "SOLTEIRO",
            "total" : 403840
        }, 
        {
            "_id" : "VIÚVO",
            "total" : 24115
        }
    ],
    "escolaridade" : [ 
        {
            "_id" : "ANALFABETO",
            "total" : 13341
        }, 
        {
            "_id" : "ENSINO FUNDAMENTAL COMPLETO",
            "total" : 57995
        }, 
        {
            "_id" : "ENSINO FUNDAMENTAL INCOMPLETO",
            "total" : 140105
        }, 
        {
            "_id" : "ENSINO MÉDIO COMPLETO",
            "total" : 321555
        }, 
        {
            "_id" : "ENSINO MÉDIO INCOMPLETO",
            "total" : 94857
        }, 
        {
            "_id" : "LÊ E ESCREVE",
            "total" : 18788
        }, 
        {
            "_id" : "SUPERIOR COMPLETO",
            "total" : 122057
        }, 
        {
            "_id" : "SUPERIOR INCOMPLETO",
            "total" : 45644
        }
    ],
    "faixaEtaria" : [ 
        {
            "_id" : "100 anos ou mais",
            "total" : 4
        }, 
        {
            "_id" : "16 anos",
            "total" : 1464
        }, 
        {
            "_id" : "17 anos",
            "total" : 5595
        }, 
        {
            "_id" : "18 anos",
            "total" : 16434
        }, 
        {
            "_id" : "19 anos",
            "total" : 20556
        }, 
        {
            "_id" : "20 anos",
            "total" : 21905
        }, 
        {
            "_id" : "21 a 24 anos",
            "total" : 82067
        }, 
        {
            "_id" : "25 a 29 anos",
            "total" : 83577
        }, 
        {
            "_id" : "30 a 34 anos",
            "total" : 88977
        }, 
        {
            "_id" : "35 a 39 anos",
            "total" : 91908
        }, 
        {
            "_id" : "40 a 44 anos",
            "total" : 83734
        }, 
        {
            "_id" : "45 a 49 anos",
            "total" : 77979
        }, 
        {
            "_id" : "50 a 54 anos",
            "total" : 71406
        }, 
        {
            "_id" : "55 a 59 anos",
            "total" : 59686
        }, 
        {
            "_id" : "60 a 64 anos",
            "total" : 49362
        }, 
        {
            "_id" : "65 a 69 anos",
            "total" : 34511
        }, 
        {
            "_id" : "70 a 74 anos",
            "total" : 16506
        }, 
        {
            "_id" : "75 a 79 anos",
            "total" : 5951
        }, 
        {
            "_id" : "80 a 84 anos",
            "total" : 2005
        }, 
        {
            "_id" : "85 a 89 anos",
            "total" : 578
        }, 
        {
            "_id" : "90 a 94 anos",
            "total" : 117
        }, 
        {
            "_id" : "95 a 99 anos",
            "total" : 13
        }, 
        {
            "_id" : "Inválido",
            "total" : 7
        }
    ]
}

Notem que para o agrupamento de gênero, utilizei o estágio $sort para exibir pelo total em ordem decrescente, já para os outros utilizei o nome do perfil para classificar por ordem alfabética. Isso demonstra que os estágios são executados de forma independente e podem conter "sub-estágios" diferentes entre eles.

Bom, a ideia era demonstrar que podemos ter um pouco mais de performance e eficiência na classificação e agrupamento dos dados em uma coleção no MongoDB utilizando o Aggregation Framework.

Espero que tenham gostado, fiquem à vontade em compartilhar e comentar!

Até a próxima!

Wildcard Indexes com MongoDB 4.2

Leandro Domingues — Wed, 14 Aug 2019 14:55:50 +0000

Fala pessoALL, aproveitando a liberação da versão GA do MongoDB 4.2, vou mostrar um pouquinho de um dos recursos que achei bem interessantes para na questão de modelagem e performance, um novo tipo de índice: o Wildcard index.

Como o MongoDB suporta um schemas dinâmicos, nossas aplicações podem fazer queries utilizando campos onde os nomes desses campos sejam desconhecidos ou até mesmo em campos opcionais. Até a versão 4.0 nós tínhamos duas maneiras de fazer isso: criando um índice para cada um desses campos, porém, precisávamos conhecer cada um deles, ou criar algo parecido com um dicionário com chaves e valores, o que ficaria "feio" e parecido com isso:

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

O Wildcard Index vem pra nos auxiliar quando temos tanto campos com schema "fixo", ou o que eu acho mais bacana, quando temos campos com schema dinâmico. Vou dar um exemplo de com a base de candidatos de eleições no Brasil e fazer alguns testes de performance utilizando esse tipo de índice. Vejamos um exemplo de documento:

{
    "_id" : ObjectId("5d126803044a9b1399ba41e7"),
    "personalInformation" : {
        "maritalStatus" : [ 
            {
                "year" : 2018,
                "code" : 1,
                "description" : "SOLTEIRO(A)"
            }
        ],
        "schooling" : [ 
            {
                "year" : 2018,
                "code" : 8,
                "description" : "SUPERIOR COMPLETO"
            }
        ],
        "emailAddresses" : [ 
            {
                "year" : 2018,
                "email" : "gpm.guimaraes.adv@gmail.com"
            }
        ],
        "birth" : {
            "date" : ISODate("1987-04-13T00:00:00.000Z"),
            "city" : "RIO DE JANEIRO",
            "cityCode" : -3,
            "state" : "RJ"
        },
        "voterRegistration" : "133364270353",
        "nationality" : "BRASILEIRA NATA",
        "occupation" : [ 
            {
                "year" : 2018,
                "code" : 257,
                "description" : "EMPRESARIO"
            }
        ],
        "name" : "HIPOLITO LUIS NUNEZ DOMARCO NETO",
        "gender" : "MASCULINO",
        "race" : "BRANCA",
        "document" : "09866446760",
        "socialName" : "#NULO#"
    },
    "electionInformation" : [ 
        {
            "year" : 2018,
            "state" : "RJ",
            "role" : {
                "code" : 6,
                "description" : "DEPUTADO FEDERAL"
            },
            "politicalParty" : {
                "legend" : "PMN / AVANTE",
                "number" : 70,
                "name" : "AVANTE",
                "legendComposition" : [ 
                    "PMN", 
                    "AVANTE"
                ],
                "initials" : "AVANTE"
            },
            "candidateNumber" : 7015,
            "situation" : "APTO",
            "age" : 31,
            "nameExibition" : "HIPLITO DOMARCO"
        }
    ]
}

O atributo electionInformation é um array que pode armazenar várias eleições onde o candidato participou, e tem vários atributos que podem ser utilizados para fazer qualquer tipo de pesquisa. Por exemplo, se quisermos exibir todos os candidatos que fazem parte de um determinado Partido:

db.candidates.find({
    "electionInformation.politicalParty.initials":"AVANTE"
})

Executando essa consulta teríamos o seguinte plano de execução:

Na imagem acima temos algumas informações importantes sobre nossa query. A primeira delas é que como não temos um índice o jeito foi fazer um COLLSCAN, nesse caso o MongoDB teve que examinar cada um dos 7.651 documentos da coleção para retornar apenas 398 resultados e essa operação levou 8ms. E o MongoDB Compass nos sinalizou que não existe um índice para suportar essa query.

Agora vamos criar um índice do tipo Wildcard e ver como nosso plano de execução se comporta:

db.candidates.createIndex(
    { "electionInformation.$**" : 1 } 
)

Executando a mesma query, temos o seguinte plano de execução:

Bem melhor, né?! Agora o MongoDB conseguiu utilizar o índice criado e executou a query em 0ms! Notem que os números de documentos examinados (Documents Examined) e documentos retornados (Documents Returned) são iguais e também condizem com o número de "entradas no índice" (Index Key Examined), isso significa que ele utilizou somente o índice pra satisfazer essa query, por isso ficou bem mais rápido!

"Ah Leandro, mas isso eu conseguiria fazer criando um índice específico para o atributo electionInformation.politicalParty.initials. Onde o Wildcard entra nisso?"

Sim, um índice específico resolveria, mas lembra do início do post, podemos não saber quais atributos existem, ou não criar índices para cada um desses atributos, logo, podemos fazer uma query por outro atributo existente:

db.candidates.find({
     "electionInformation.role.description":"DEPUTADO FEDERAL"
})

O MongoDB utilizará o mesmo índice:

Viu só? Isso, como eu disse, facilita muito em casos de schema dinâmico e também na manutenção dos índices! Claro que existem considerações e restrições que devem ser observadas, mais informações sobre o Wildcard Index você encontra aqui.

Se quiser testar esse novo tipo de índice e não tem o MongoDB 4.2 instalado, utilize o MongoDB Atlas, lá você pode criar um Replica Set para testes totalmente free!

Também se quiser ter um overview sobre algumas das principais novidades da versão 4.2, dê uma olhada aqui.

É isso, espero que tenham gostado e fiquem à vontade para comentar e compartilhar!

Um abraço e até mais!

MongoDB Atlas Data Lake

Leandro Domingues — Mon, 22 Jul 2019 21:17:52 +0000

Eae pessoALL, tudo bem? Hoje vou falar um pouquinho sobre a nova funcionalidade disponível no MongoDB Atlas - o MongoDB Atlas Data Lake! Ainda está na versão Beta, mas já podemos testar e sentir um pouco mais sobre o que essa funcionalidade vai nos proporcionar... se você preferir no final do artigo tem o link para o vídeo onde eu demonstro como fazer. Vamos lá?

MongoDB Atlas Data Lake

Seguindo as tendências de Big Data, e olhando para o esse universo tão grande, em Junho durante o MongoWorld fomos apresentados a uma ferramenta que permite utilizar MQL (MongoDB Query Language) para fazer consultas em diversos tipos de arquivos num bucket do S3 na AWS (até agora é o único repositório compatível). Com apenas alguns cliques e algumas configurações é possível já sair executando consultas nos arquivos do bucket como se estivesse em um cluster MongoDB sem a necessidade de importação dos arquivos. Vários formatos são suportados como TXT, CSV, PARQUET, AVRO e claro, JSON.

Configurando um novo Data Lake

Como disse anteriormente, esse recurso é parte do MongoDB Atlas, portanto, para utilizá-lo você precisará ter um projeto rodando lá. Se você ainda não tem não se preocupe, é super simples e requer apenas seu e-mail e uma senha (não é necessário cartão de crédito), para saber como iniciar um projeto no MongoDB Atlas veja aqui.

Após criado o projeto você verá no menu a opção "Data Lake Beta":

Entrando nessa opção clique em "Try MongoDB Atlas Data Lake", você será guiado por um passo-a-passo bem simples:

Clicando em "Configure a New Data Lake", vamos dar um nome para nosso novo Data Lake:

Agora vamos dizer o nome do nosso bucket no S3. A configuração do bucket no S3 não é o foco do artigo, aqui presumo que você já tenha criado uma conta na AWS e tenha um bucket configurado, o meu bucket é o meetupatlasdatalake:

Note que você pode conectar mais de um bucket, é só separar os nomes por vírgula!

Após informar qual é o bucket, clique em "Save and Continue". Nesse momento o Atlas Data Lake nos informará o Unique External ID e o Atlas AWS IAM User ARN. Esses dados serão utilizados para a configuração da AWS IAM role bem como para a criação de uma policy no S3.

Basicamente iremos dar um nome para a role que será criada na AWS, no meu caso a role se chama dataLakeRole.

Seguindo o passo-a-passo, agora criaremos um arquivo chamado dl-role-trust.json, esse arquivo vai descrever uma política que você precisará para criar a IAM role. Copie o conteúdo descrito no passo 2 e cole nesse arquivo json:

O passo três utiliza o AWS CLI para rodarmos o comando para a criação da IAM role para o Atlas utilizar:

A saída desse comando nos dará uma informação para utilizarmos mais a frente, copie o conteúdo da chave Arn:

Agora criaremos mais um arquivo chamado dl-s3-role-policy.json e colocaremos nele o conteúdo do passo quatro. Esse arquivo tem as ações que são permitidas para a IAM role que criamos no passo anterior:

E finalmente utilizaremos novamente o AWS CLI para executar o comando para vincularmos essas ações à IAM role (esse comando não gerará nenhuma saída, não se preocupe!):

Clicando no botão "Next", vamos agora informar a Role Arn, é justamente o conteúdo da chave Arn gerada no passo três:

Agora é só clicar no botão "Validate & Launch"...

Conectando no Atlas Data Lake

Com os acessos configurados, agora já podemos nos conectar ao nosso novo Data Lake, como passo 2 da tela que está sendo exibida, clicaremos em connect e vamos escolher como iremos nos conectar:

É muito importante lembramos de liberar o nosso IP para acesso ao MongoDB Atlas e criar um usuário para o projeto (no caso de um projeto novo):

Após o IP liberado e usuário criado eu escolhi me conectar através do Mongo Shell, só precisaremos copiar a linha de comando e substituir o usuário e senha que acabamos de criar para nos conectarmos:

Feito isso já estaremos dentro de uma instância MongoDB conectada diretamente com o nosso bucket no S3!

Configurando o acesso aos arquivos no bucket

Nesse passo definimos alguns parâmetros para a "criação" do database e das collections a partir dos arquivos que estão no bucket. Utilizei um script bem simples que irá criar um database chamado sample e uma collection para cada arquivo no meu bucket, no meu caso tenho apenas o arquivo restaurants.json lá. Para todas as definições de configuração dê uma olhada na documentação. O script abaixo tem o necessário para podermos acessar os arquivos que estão lá:

use admin;
db.runCommand( { "storageSetConfig": {
  "stores": [{
    "s3": {
      "name": "s3store",              // Cria um store S3
      "region":"us-east-1",           // Altera o código da região do bucket
      "bucket": "meetupatlasdatalake" // Altera o nome do seu bucket
    }
  }],
  "databases": {
    "sample": {                    // Cria um novo database chamado sample
      "*": [{                      // Criará uma collection para cada arquivo no bucket
        "store": "s3store",        // Link o store S3 especificado acima
        "definition": "/{collectionName()}"
      }]
    }
  }
}})

Após executar o comando acima já teremos o database criado e a collection restaurants:

Agora é só executar alguns comandos como se estivéssemos numa instância normal de MongoDB:

db.restaurants.count()

db.restaurantes.findOne()

E até mesmo operações utilizando o Aggregation Framework

db.restaurants.aggregate([
    {
        $match: {
            name: "Wendy'S"
        }
    }, 
    {
        $group: {
            _id: "$name",
            total: {
                $sum: 1
            }
        }
    }
])

Acompanhando o consumo

Muito bacana, mas quanto isso custa? Bem, hoje o preço é de 5 USD por TB trafegado e você pode acompanhar o consumo através do painel do Atlas Data Lake:

Conclusão

Bem, viram como é simples conectar? Como disse é um funcionalidade que ainda está em Beta, e com certeza ainda vai evoluir muito!

Não deixe de conferir também o vídeo que explica todos isso que fizemos aqui e também compartilhe à vontade e deixe seu like aqui!

Um abraço e até mais!

MongoDB 4.2, o que vem por aí?

Leandro Domingues — Mon, 24 Jun 2019 08:05:26 +0000

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

MongoDB REST API

Leandro Domingues — Sat, 01 Jun 2019 04:13:15 +0000

Fala pessoALL, estou contente com a repercussão do meu último artigo onde iniciei uma série sobre o MongoDB Connector for BI. Os feedbacks têm sido muito bons e logo mais chega o segundo post. Porém, alguns questionamentos sugiram sobre a que o BI Connector não seria a única forma de se conectar uma instância MongoDB e ferramentas de BI, mas porque? Porque existem as REST APIs! Então vamos lá...

Deixando às claras

Antes de falar sobre uma dessas alternativas temos que entender alguns pontos e diferenças entre o BI Connector e as REST APIs.

A mais importante é que o BI Connector, assim como o driver OBDC para MongoDB são desenvolvidos seguindo os padrões e melhores formas de acesso a dados. Existem formas e formas de se acessar dados e se desenvolver drivers, logo o BI Connector e o ODBC Driver utilizam esses padrões pra entregar os dados de forma muito mais performática do que as REST APIs disponíveis. Mas então porque elas existem?

Existem para facilitar a vida de desenvolvedores oferecendo uma forma rápida de disponibilizar o acesso e troca de dados entre aplicações, aliás esse é o principal objetivo: troca de dados entre aplicações! Através dessas APIs é possível utilizar os métodos HTTP para fazer requisições no MongoDB e a maioria delas provê recursos que vão desde um simples CRUD quanto a comandos de administração de clusters!

Mas Leandro, já que o objetivo principal é a troca de dados entre aplicações, minha ferramenta de BI não se enquadra aí? Sim! Mas não é a melhor forma cara! Enquanto uma REST API disponibiliza um retorno em JSON a ser tratado 100% pela sua ferramenta, os drivers oferecem uma interação muito melhor com opções de queries mais avançadas. Portanto, se quer integrar com uma ferramenta de BI, utilize a forma correta! Se quiser ter um spoiler de uma outra forma, vá até o final do artigo, porque agora vou apresentar uma REST API muito bacana construída em Python... aliás, Python é vida e melhor que R! hahahahaha

Eve RESTful

Eve é uma REST API escrita em Python, tem vários métodos disponíveis e é compatível com Python 2.6, 2.7, 3.3 e 3.6.

O básico

Bom, depois de conhecer a história da Eve vamos ver como faremos para utilizá-la. Esse tutorial você pode encontrar diretamente na documentação, mas aqui vou fazer algumas observações.

A instalação do Eve é super simples: pip3 install eve (revisar isso)

Crie um arquivo chamado run.py e copie o seguinte conteúdo:

from eve import Eve
app = Eve()
if __name__ == '__main__':
    app.run()

Agora crie outro arquivo chamado settings.py, deixando no mesmo diretório do arquivo run.py. Esse é um arquivo de configurações que segue o padrão de um módulo Python e vai dizer para Eve que sua API só acessa um recurso: people.

DOMAIN = { ‘people’: {}}

Agora é só executar sua API:

python3 run.py

E para consumir:

curl -i http://127.0.0.1:5000

Feito, você já tem uma requisição GET e a resposta é parecida com essa:

Por default sua API é somente read-only, execute uma requisição de DELETE por exemplo e veja a resposta:

curl -X DELETE http://127.0.0.1:5000/people

Conectando com o MongoDB

No arquivo settings.py, adicione as seguintes linhas:

MONGO_HOST = ‘localhost’
MONGO_PORT = 27017

# Se você não tem autenticação habilitada na sua instância, ignore o bloco abaixo (mas é altamente recomendável o uso de autenticação)
MONGO_USERNAME = ‘<seu_usuario>’
MONGO_PASSWORD = ‘<sua_senha>’
#Nome do seu database de autenticação
MONGO_AUTH_SOURCE = ‘<dbname>’

#Nome do banco de dados onde você quer se conectar
MONGO_DBNAME = ‘<nome_do_database>’

Seguindo os princípios de laziness do MongoDB, você não precisa criar “formalmente” um database ou uma collection. Se você requisitar um GET num database vazio ou não existente você terá uma resposta 200 OK, outros métodos como DELETE/PATCH/PUT receberão 404 Not Found, já um POST fará a criação do database e da collection de acordo com o contexto.

Como disse, por default sua API é read-only, então vamos habilitar todos os métodos para um CRUD:

RESOURCE_METHODS = [‘GET’, ‘POST’, ‘DELETE’]
ITEM_METHODS = [‘GET’, ‘PATCH’, ‘PUT’, ‘DELETE’]

Os RESOURCE_METHODS equivale a todos os métodos que quero deixar exposto para os endpoints (/people), já o ITEM_METHODS equivale aos endpoints e itens (/people/). Essas duas configurações tem escopo global e se aplicam a todos os endpoints, mas podemos habilitar ou desabilitar métodos HTTP individualmente no nível de um endpoint.

Depois de liberarmos os métodos, podemos também criar um schema para o nosso recurso people. Adicione essas linhas ao arquivo settings.py:

schema = {
    # baseado no Cerberus grammar. Dê uma olhada no Cerberus project
    # (https://github.com/pyeve/cerberus) pra maiores detalhes.
    'firstname': {
        'type': 'string',
        'minlength': 1,
        'maxlength': 10,
    },
    'lastname': {
        'type': 'string',
        'minlength': 1,
        'maxlength': 15,
        'required': True,
        'unique': True,
    },
    'role': {
        'type': 'list',
        'allowed': ["author", "contributor", "copy"],
    },
    'location': {
        'type': 'dict',
        'schema': {
            'address': {'type': 'string'},
            'city': {'type': 'string'}
        },
    },
    'born': {
        'type': 'datetime',
    },
}

Mais detalhes sobre schema validation aqui.

Vamos agora customizar o acesso ao endpoint people:

Trocar o nome do item para person
Adicionar um endpoint customizado em /people/
Fazer um override nas diretivas de controle de cache
Desabilitar o método DELETE para o endpoint /people (deixaremos habilitado para os outros endpoints futuros)

Adicione mais essas linhas ao arquivo settings.py:

people = {
   'item_title': 'person',
    'additional_lookup': {
        'url': 'regex("[\w]+")',
        'field': 'lastname'
    },
    'cache_control': 'max-age=10,must-revalidate',
    'cache_expires': 10,
    'resource_methods': ['GET', 'POST'],
    'schema': schema
}

E finalmente e ainda no settings.py, faremos a atualização do domínio people:

DOMAIN = {
  'people': people,
}

Salve as alterações e execute novamente o run.py. E vamos inserir alguns documentos no endpoint people.

Depois de inserir, podemos dar um GET e recuperar os documentos através do endpoint /people/lastname:

$ curl -d '[{"firstname": "barack", "lastname": "obama"}, {"firstname": "mitt", "lastname": "romney"}]' -H 'Content-Type: application/json'  http://127.0.0.1:5000/people

Legal né? Rapidamente e com poucas linhas de código podemos expor os dados através de uma REST API. Obviamente, recursos mais avançados de segurança devem ser observados e configurados, mas voltando ao ponto inicial do artigo: essa é uma maneira de facilitar a vida de desenvolvedores que precisam trocar dados de forma rápida e simples!

Mas e o spoiler que você prometeu?

Sim... já ia me esquecendo! Uma ferramenta muito interessante também faz mais do que uma ponte entre um cluster MongoDB e sua ferramenta de BI: o Dremio! Como é apenas um spoiler, não vou entrar em detalhes aqui, mas garanto que é uma ferramenta muito legal e com vários recursos e também possui integração nativa com os principais players de mercado de BI. Aguardem que assim que terminar nossa série sobre o BI Connector escreverei sobre ele!

Até mais! ;)

MongoDB e Business Inteligence

Leandro Domingues — Thu, 30 May 2019 01:24:03 +0000

Fala pessoALL, hoje vou escrever um pouquinho sobre um tópico em que vejo pouco ou quase nada que é a utilização do MongoDB com ferramentas de BI.

Nessa primeira parte vou dar um panorama do que é necessário e como funciona essa comunicação, já que é muito mais comum vermos artigos, vídeos e mais sobre bancos de dados relacionais e BI. A ideia é escrever sobre arquitetura e os componentes disponíveis, bem como seus papéis. Vamos lá?

O ponto chave!

O primeiro componente e digamos, essencial, é o MongoDB Connector for BI ou BI Connector para os íntimos! Sem ele nós não conseguimos conectar nenhuma ferramenta de BI diretamente no MongoDB. Dito isso, tenho duas notícias pra vocês:

O MongoDB Connector for BI só pode ser utilizado com a versão Enterprise do MongoDB
Mas... está disponível pra download aqui e pode ser utilizado sem restrições para desenvolvimento e testes!

O que é?

Basicamente o MongoDB Connector for BI permite que criemos queries com SQL e visualizemos gráficos e relatórios a partir de dados do MongoDB utilizando ferramentas de BI existentes como PowerBI, Tableau ou Qlik.

O BI Connector atua como uma camada que traduz queries e dados entre instâncias MongoDB e a ferramenta de BI. Ele não armazena nenhum tipo de dados, no caso, ele é somente uma ponte entre o seu cluster MongoDB e suas ferramentas de BI. Basicamente assim:

Pra descrever um pouco mais os componentes da figura acima:

MongoDB: onde os dados estão armazenados
Bi Connector: Provê um esquema relacional e traduz as queries SQL entre a ferramenta de BI e o MongoDB
ODBC data source name (DNS): responsável pela autenticação e dados de configuração
BI Tool: Visualização e análise dos dados

Podemos observar também que a ferramenta de BI e o DSN sempre irão rodar localmente em seu desktop por exemplo, mas a base de dados MongoDB e a instância do BI Connector podem estar local, on premisses ou estar na nuvem. Veremos alguns cenários possíveis a seguir...

Nuvem e BI Connector

Se você não quiser se preocupar com a instalação de uma instância do BI Connector ou mesmo do MongoDB, você pode hospedar seus dados no MongoDB Atlas. Nesse cenário tanto o BI Connector quanto seu banco estarão na nuvem:

Banco de Dados na Nuvem e BI Connector On Premisses

Outro cenário é ter o banco de dados na nuvem e o BI Connector On Premisses. Nesse cenário você pode informar o host através do parâmetro --mongo-uri:

On Premisses

Em alguns casos não podemos contar com a nuvem por N motivos, na verdade esses motivos estão se esvaindo, porém, algumas empresas ainda preferem ter seus dados em ambientes totalmente on premisses, portanto podemos ter a seguinte arquitetura:

Tudo Local!!!

E finalmente para testes, também é possível fazer uma instalação 100% local no próprio desktop. Assim como o MongoDB o BI Connector está disponível para diversas plataformas e você pode instalar tudo localmente!

Próximos passos

Essa foi mesmo uma visão geral de como podemos resolver os aspectos de arquitetura para uma solução MongoDB e BI. Nos próximos posts abordarei outros conceitos poucos explorados mas que requerem uma grande atenção em projetos como esse! Discutiremos:

Instalação do MongoDB Connector for BI
Start da instância do BI Connector
Configuração do ODBC
Aspectos de Autenticação
Mapeamento de Esquemas Relacional para o MongoDB
DRDL - Document Relational Definition Language

Acredito que esses sejam pontos muito importantes para o sucesso de um projeto de visualização e análise de dados utilizando ferramentas de BI e o MongoDB.

Espero que tenham gostado e até a próxima!

Eu, eu mesmo e o NoSQL

Leandro Domingues — Fri, 17 May 2019 00:04:01 +0000

Fala pessoALL, hoje escrevo um post diferente. Diferente porque ele não será técnico, hoje vou contar pra vocês como entrei no universo NoSQL, como me apaixonei por MongoDB e o que tenho encontrado no meu dia-a-dia. Espero que seja uma leitura bacana e vocês se divirtam lendo tanto quanto eu me diverti escrevendo! Vamos lá?

Numa galáxia muito, muito distante... #sqn

Por gostar tanto de falar de NoSQL, muita gente acha que eu "nasci" nesse universo, quem dera, não sou tão novo assim! A verdade é que até 2014 eu trabalhava exclusivamente com SQL Server, meu background em desenvolvimento passando por tecnologias desde VB 6, ASP Clássico, PHP depois C# e ASP.NET me ajudaram em diversos aspectos e ambientes de trabalho. Durante esses períodos utilizei alguns bancos de dados (ou não) como Access, MySQL, Interbase, Firebase e SQL Server. Mas foi em 2007 quando entrei em uma empresa de dados e daí sim me especializei em desenvolvimento para SQL Server e também comecei a gostar mais de dados, mas sem nunca tirar o pezinho do desenvolvimento, e vai por mim, isso foi muito bom!

Nessa empresa tive mais contato com a parte de administração do SQL Server e funcionalidades que transcendiam o desenvolvimento puro e simples. Então foi aí que passei a administrar os servidores de banco da empresa que naquela época eram 100% SQL Server. Fiz vários treinamentos oficiais mas nunca me certifiquei (sinto falta disso e acho que ainda dá tempo).

Aprendi muito com o SQL Server, mas o mais importante foi aprender a gostar dos dados e uma frase que carrego pra vida: "Entrou lixo, vai sair lixo".

Mas como surgiu o NoSQL?

Bom, o ano era 2014 e nos deparamos com uma necessidade para um produto dessa mesma empresa. Como trabalhávamos com dados, àquela altura tínhamos vários servidores SQL Server suportando as aplicações, por esse motivo e por me considerar "bom" em query SQL disse que resolveria utilizando o SQL Server mesmo! Resolvi? Sim, mas a performance era sofrível e foi aí que fui procurar outras alternativa.

Foi aí que o NoSQL, mais especificamente o Neo4j entrou na minha vida! Apenas pra contextualizar o Neo4j é um banco de dados NoSQL que se enquadra na classe de Grafos, ou Graph Databases. Mas era um mundo totalmente novo pra mim, a documentação era muito escassa e não foi uma caminhada fácil, mas o resultado foi muito bom. Tive que aprender a dimensionar e fazer deploy do ambiente, aprender uma query language totalmente nova e diferente de tudo o que já tinha visto a Cypher Query (linguagem nativa do Neo4j), mas foi legal, estudei bastante e fui um dos 50 primeiros no mundo a me certificar em Neo4j, minha história com certificações começou aqui! Como nem tudo são flores, foi aí que aprendi que no NoSQL não existe "bala de prata", ou seja, aprendi que o Neo4j era muito bom em alguns aspectos e muito ruim em outros... estava lançado mais um desafio!

Humongous!

Gostei de sair do mundo relacional e comecei a explorar outras alternativas para o armazenamento de dados. Na época a uma das bases de dados que eu administrava tinha cerca de 2.5TB de dados e tabelas com batendo na casa dos bilhões de registros. Pra dar conta disso tudo, essa base era replicada em alguns servidores, logo, um dos problemas era espaço em disco, foi aí que conheci o MongoDB!

Confesso que esse foi um outro paradigma muito grande a ser quebrado. Sempre digo que pensava: "nossa, porque eu estou saindo do Management Studio pra vir pra essa "tela preta"?". Se hoje as ferramentas ainda são poucas, imagina isso no final de 2014. Tive que aprender o básico de Linux, entender como aquilo tudo funcionava pra montar uma infra mínima. Logo depois foi entender o modelo de dados orientado a documentos ou o Document Model.

Modelar bancos de dados relacionais está enraizado dentro de nós. Saímos da faculdade sabendo tudo de normalização de dados, relacionamentos e a "maravilha" que é isso. Porém quando você chega no MongoDB vê que isso já não te serve de muita coisa

E aí vem uma dica importante: não tente colocar seu modelo relacional dentro do MongoDB, você terá sérios problemas! Uma pesquisa indica que de 80 a 95% das soluções que tentam utilizar algum tipo de NoSQL falha não por conta da ferramenta, e sim por conta da modelagem de dados.

Lembra do meu skill em desenvolvimento? Ele me ajudou exatamente nesse ponto: trabalhar com dados agregados! A representação JSON dos dados no MongoDB torna a vida do desenvolvedor muito mais fácil, por outro lado, pode dificultar um pouco o entendimento por parte de alguns DBAs. me debrucei sobre o modelo de dados que tinha na época e remodelei utilizando o document model. Não foi de primeira, mas cheguei a um modelo bem performático e tive dois ganhos: o primeiro em performance e outro na economia de disco! Saíram as máquinas gigantes, como muito poder de processamento e memória, entraram máquinas bem mais simples para fazer parte do trabalho. Aqui a palavra parte é bem colocada porque o SQL Server não foi totalmente substituído, lembra que não existe "bala de prata"? O SQL Server continuou com um papel muito importante e o MongoDB assumiu outra parte da aplicação.

Mas confesso que de lá pra cá, não me lembro a última vez em que precisar "pensar relacional" para uma aplicação!

A comunidade

Tudo muito bom, tudo muito bem... mas eu estava a ponto de virar minha carreira para uma tecnologia open source, e aí veio a dúvida: e se essa coisa morre? Fui então conhecer onde estava me metendo, em 2015 fui para o meu primeiro MongoWorld que aconteceu em NYC. Cheguei pra conhecer uma comunidade que naquele ano estava representada por pessoas de mais de 64 países, e tentar absorver o máximo de conhecimento possível, ver se o que eu estava fazendo estava ao menos aderente. Voltei cheio de conteúdo e mais apaixonado ainda!

Comecei junto com um grande amigo a fazer alguns meetups aqui no Brasil e me envolver mais com a comunidade, que naquela época estava bem fraca por aqui, mas com muita gente boa envolvida! Conheci bastante gente e fiz vários amigos, voltei ao MongoWorld em 2016, mas foi em 2017, dessa vez em Chicago, que o primeiro reconhecimento internacional veio! Participei do Advocacy Day, um dia exclusivo para os membros do Advocacy Hub e que concentra evangelizadores MongoDB ao redor do mundo. Pelo trabalho desenvolvido no Brasil fui reconhecido como maior influenciador em língua portuguesa, isso foi muito legal, consegui ver que todo tempo (e dinheiro) investidos não estava sendo em vão e que estava no caminho certo! Fiz mais amigos: indianos, espanhóis, italianos, colombianos, americanos e até um brasileiro que vive lá nos EUA até hoje! Esses caras são incríveis.

E aqui no Brasil o trabalho continuou, vários meetups, eventos como TDC, NoSQL BR, Zero2Hero e evangelização em MongoDB me renderam o título de MongoDB Evangelist e depois MongoDB Ambassador... mas eu sentia falta de uma coisa: a certificação.

A certificação

Esse foi um ponto que sempre persegui, já tinha minha certificação em Neo4j e tentei me certificar em MongoDB. Minha primeira tentativa e eu não passei. Mas me motivou a continuar estudando e acima de tudo: praticando. A prova exige a prática e não só a teoria, esse é um ponto que considero bem bacana, nada de "decorebas", tem que chegar lá e realmente mostrar que você sabe! São 60 questões em 90 minutos com um indiano te observando o tempo todo pela câmera!

No início desse ano renovei minha certificação agora contemplando a versão 4.0 do MongoDB e estou desenvolvendo um conteúdo de treinamentos específico para quem quer se certificar. Veja que oportunidade: aqui no Brasil temos apenas 23 profissionais certificados em MongoDB!

Além de MongoDB Certified Developer, em 2018 me certifiquei como MongoDB Certified Trainer, com isso venho treinando equipes dos mais diversos skills em várias empresas pelo Brasil.

Dia-a-dia

No final de 2017 vi que o mercado necessitava de consultoria e treinamentos em NoSQL e abri minha empresa. O foco é justamente auxiliar empresas, desenvolvedores e administradores de dados a entrarem ou se manterem no universo NoSQL.

O que tenho visto são projetos incríveis com grande potencial que precisam de, digamos, uma tutoria para que consigam ultrapassar a barreira da "arrebentação" e consigam sobreviver em alto-mar. E aqui mais uma necessidade de mercado: profissionais que realmente façam, coloquem a mão na massa e façam acontecer.

Tem sido uma caminhada difícil, mas por outro lado bem bacana! Passar por vários cenários em diferentes empresas e ver o NoSQL sendo aplicado de diversas maneiras é muito legal, além de gerar uma vivência incrível. Essa vivência me permite falar com propriedade sobre essas aplicações e contribuir para o crescimento profissional de muita gente Brasil afora!

MVP

Depois de toda essa caminhada, em fevereiro desse ano a Microsoft me concedeu o tão sonhado título de MVP na categoria Data Platform. Esse título pra mim é um motivo de muito orgulho, porque mesmo sem ser especialista em ferramentas Microsoft, ou seja, falando de NoSQL ou mais especificamente de MongoDB, eles viram e reconheceram meu trabalho.

Isso me levou a conhecer mais gente e fazer novos amigos em uma outra comunidade. Esse é um outro ponto que não tem preço.

O que vem por aí...

Posso dizer que ainda não acabou, 2019 tem sido um ano muito bacana pra mim e muita coisa está por vir. Três coordenações no TDC já foram garantidas, SQL Saturdays pelo Brasil todo, e vários outros eventos.

Espero que um pouco dessa minha história incentive quem quer entrar ou já está na caminhada com dados, sejam eles relacionais ou não relacionais. E para o que precisarem é só me pingar por aí nas redes! Se quiser saber mais sobre os treinamentos, dê uma conferida aqui

Um abraço e até mais!

Dump não é backup! Mas pode ser?

Leandro Domingues — Fri, 10 May 2019 14:45:40 +0000

Fala pessoALL, neste post vou mostrar algumas dicas para utilizar o mongodump como parte da estratégia de backup de bases de dados MongoDB.

Estratégias de backup

Antes de mergulharmos no mongodump, vamos repassar algumas estratégias de backup disponíveis no MongoDB.

Backup com MongoDB Cloud Manager ou Ops Manager

MongoDB Cloud Manager

Com o MongoDB Cloud Manager você pode manter backups contínuos de ambientes replicaset ou sharded clusters através da leitura do oplog, como o próprio nome diz: na Nuvem. O MongoDB Cloud Manager cria snapshots dos seus dados em intervalos previamente configurados e também pode oferecer um point-in-time recovery de maneira mais simples.

Ops Manager

Essa é a opção on-premisses e funciona da mesma maneira que o MongoDB Cloud Manager, porém, é instalado dentro do seu ambiente. O Ops Manager está disponível somente para a versão Enterprise do MongoDB.

Backup por cópia dos arquivos de dados

Essa também é uma opção muito utilizada para ambientes que utilizam a versão MongoDB Community, isso auxilia tanto para backups propriamente ditos, quanto para um initial sync ou resync de membros de replicasets ou sharded clusters.

A opção que eu mais uso e recomendo é o rsync, mas não vou me aprofundar agora e prometo um artigo mostrando como fazer isso de maneira simples e segura.

Agora sim o mongodump

O mongodump faz parte do pacote de ferramentas que são instaladas juntamente com o MongoDB e contém várias opções que ajudam muito para backup de ambientes pequenos (leia-se com pouco volume de dados).

O funcionamento é bem simples, mas alguns pontos devem ser observados:

quando conectado a uma instância mongod vai afetar a performance
- se você estiver num ambiente standalone isso pode ser um problema dependendo do volume de dados
em ambientes replicaset o ponto 1 deixa de ser um problema
- como parte da estratégia, retiramos um nó do cluster e utilizamos esse nó para executar o dump
o mongodump cria uma cópia fiel dos dados no formato BSON, ou seja, uma cópia binária dos dados da maneira que o MongoDB usa para persistência dos dados em disco, assim, esses dados não são "humanamente legíveis", ou seja, podem ser lidos somente através de um restore para uma instância MongoDB ou pelo bsondump

Dito isso, vamos explorar algumas opções que acho muito interessantes!

Uma instância completa

Para executar o backup de uma instância completa de MongoDB, utilizamos seguinte comando:

mongodump --out meu_diretorio_de_backup

Notem que passei um único parâmetro para o mongodump, mas o que isso significa? Bem, o parâmetro informado foi o --out, ele recebe o caminho onde os arquivos serão gravados. Nesse caso o mongodump se conectará na instância que está rodando localmente, na porta padrão: 27017 e fará o backup de todas as bases de dados dessa instância (menos da base dados local, isso por default).

Mas e se quisermos o backup de uma outra porta ou de outro servidor? Basta adicionarmos os parâmetros --host e --port, assim:

mongodump --host nome_do_meu_servidor --port 19000 --out meu_diretorio_de_backup

Um banco de dados específico

Nesse caso adicionaremos mais um parâmetro:

mongodump --host nome_do_meu_servidor --port 19000 --db meu_banco_de_dados --out meu_diretorio_de_backup

Uma coleção específica

Essa é opção interessante também:

mongodump --host nome_do_meu_servidor --port 19000 --db meu_banco_de_dados --collection minha_colecao --out meu_diretorio_de_backup

Um conjunto de dados específico

Podemos querer apenas alguns dados por algum motivo, talvez um "backup" diferencial utilizando um campo data por exemplo:

mongodump --host nome_do_meu_servidor --port 19000 --db meu_banco_de_dados --collection minha_colecao --query "{data:{$gte:ISODate('2019-05-10T00:00:00.000Z')}}"

No exemplo acima temos o parâmetro --query e passamos um JSON, nesse caso foi uma query simples, mas podemos querer passar mais parâmetros de filtro nesse JSON, então podemos utilizar o parâmetro --queryFile passando o caminho de um arquivo JSON com a nossa query:

{
    "data": {
        "$gte": ISODate("2019-05-10T00:00:00.000Z")
    },
    "clienteID": {
        "$in": [1000,1001,1005,1010,1100]
    }
}

mongodump --host nome_do_meu_servidor --port 19000 --db meu_banco_de_dados --collection minha_colecao --queryFile meu_arquivo_json

Compactando os arquivos

Como saída podemos compactar os arquivos nativamente através da opção --gzip:

mongodump --host nome_do_meu_servidor --port 19000 --gzip --out meu_diretorio_de_backup

Arquivos gerados com a opção --gzip deverão ser restaurados com essa mesma opção utilizando o mongorestore ou se quisermos apenas a visualização do JSON, bsondump

Conclusão

Bom, mostrei alguns exemplos de utilização do mongodump como parte da estratégia de backup e o título foi mesmo para polemizar! ;)

Vimos que podemos utilizar o mongodump de diversas maneiras, e notem: os parâmetros não precisam seguir uma ordem (eu tenho TOC! :p). Podemos combinar os parâmetros e utilizá-los de acordo com nossas necessidades.

Em ambientes que tem autenticação implementada (altamente recomendável) utilizamos os mesmos parâmetros para entrar numa instância: --user, --password e --authenticationDatabase.

Ambientes replicados (replicasets) temos uma cópia idêntica dos dados em cada um dos nós de nosso cluster, por isso backup para o caso de alta disponibilidade pode não ser um problema nesses casos. Inclusive podemos ter nós que chamamos de delayded (ou nós atrasados), esses nós são muito úteis para evitarmos os famosos fatfingers, aqueles chamados que você pode receber: "cara, me ajuda... apaguei uma collection". Mas esse é um assunto bom para um próximo post!

Lembre-se dump PODE não ser backup mas vai ajudar na cópia dos arquivos de dados para um local diferente, podendo ser um outro servidor, um storage, ou até mesmo um local físico.

Veja também todas as opções do mongodump aqui

Quer se aprofundar mais nesse e em outros conceitos do banco de dados não relacional mais utilizado do mundo? Conheça o meu treinamento on-line e ao vivo, se preferir presencial corre porque as vagas estão se esgotando aqui em São Paulo, veja aqui

É isso, espero que gostem e fiquem à vontade para compartilharem e comentar!

Abs e até a próxima! ;)