DEV Community: Paulo Benjamin

Upgrade do MongoDB - o guia definitivo.

Paulo Benjamin — Mon, 04 Nov 2024 22:13:42 +0000

Uma das maiores dúvidas [e medos] dos desenvolvedores, e dos DBAs relacionais que herdam a administração de servidores MongoDB, é o upgrade de versão do binário - afinal, em time que ganha não se mexe, certo? ERRADO! Manter os binários atualizados, é uma das principais recomendações da fabricante.

Então, segue aqui um passo a passo que vai ajudar você a realizar o upgrade do MongoDB na maioria dos ambientes e cenários sem dor de cabeça. Claro, é impossível prever todos os possíveis cenários de implementação de MongoDB - por exemplo, não estou abordando nada envolvendo kubernetes aqui - mas fiz meu melhor para ajudar o maior número de pessoas possíveis.

PS.: Originalmente eu deveria lançar dois artigos esta semana, já que não consegui lançar o da última semana a tempo, visto que minha programação é lançar um artigo por semana. Mas com a correria do MongoDB .Local de São Paulo, no último 30 de Outubro, não consegui lançar o artigo da semana passada, e vou lançar dois esta semana. Como havia prometido ha um amigo no .Local este artigo para hoje, inverti a ordem dos artigos, para cumprir com minha palavra. Espero que seja de ajuda!

Considerações iniciais:

É importante verificar se os diretórios onde estão os arquivos de dados, o keyfile e verificar se o .pid foi apagado.

No Ubuntu o nome do usuário de serviço do MongoDB é mongodb enquanto que na maioria das outras distros é mongod.

Arquivos de dados - pode ser obtido no arquivo de configuração */etc/mongod.conf*:
- chown -R mongod:mongod
- chmod -R 744
Keyfile - pode ser obtido no arquivo de configuração /etc/mongod.conf:
- chown mongod:mongod
- chmod 400
.PID - este último varia muito de acordo com a distro:
- rm -F /var/run/mongod/*.pid

Tendo estas informações em vista, segue o padrão para upgrade de versão do MongoDB:

Upgrade

O upgrade do MongoDB, quando em replica set ou shard deve começar com os nós secundários. Nos shard ele o ideal é fazer um shard por vez. O último nó a ser atualizado é o primário.

A atualização sempre deve ocorrer de versão em versão, ou seja, um MongoDB 4.4 não pode ir direto para a 8.0. Ele deve seguir o caminho 4.4 → ****5.0 → 6.0 → 7.0 → 8.0.

O processo consiste em atualizar o arquivo de repositório, realizar o shutdown do MongoDB por dentro dele, verificar se ele realmente não está mais em execução, rodar o comando de upgrade, iniciar o serviço do MongoDB, e atualizar o compatibility version do MongoDB para a nova versão. Abaixo segue um script de upgrade de versão para CentOS 9.

Passo 1: Silent Shutdown

Para garantir que não haverá corrupção ou perda de dados é importante fazer o shutdown do Mongo corretamente, isto é, por dentro dele.

Para isso precisamos logar no Mongo, localmente, com um usuário com permissão root e executar o db.shutdownServer(), executando linha a linha do código que segue:

# mongo admin --host localhost --port <27017> --username <admin> --password <admin>
...
rs01 [secondary] admin> db.shutdownServer()
rs01 [secondary] admin> exit

Passo 2: Verificação do shutdown

Em seguida é bom verificar se o serviço realmente está parado. No CentOS pode ser feito executando a primeira linha do código abaixo. A saída esperada são as linhas que seguintes.

# systemctl status mongod
● mongod.service - MongoDB Database Server
   Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
   Active: inactive (**dead**) since Sun 2024-03-24 04:23:19 UTC; 8s ago
     Docs: https://docs.mongodb.org/manual
  Process: 32831 ExecStart=/usr/bin/mongod $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 32831 (code=exited, status=0/SUCCESS)

Mar 24 03:47:10 ip-172-31-38-118.sa-east-1.compute.internal systemd[1]: Started MongoDB Database Server.
Mar 24 03:47:10 ip-172-31-38-118.sa-east-1.compute.internal mongod[32831]: {"t":{"$date":"2024-03-24T03:47:10.931Z"},"s>
Mar 24 04:23:19 ip-172-31-38-118.sa-east-1.compute.internal systemd[1]: mongod.service: Succeeded.

Passo 3: Atualização do repositório

Nesse passo alteramos o repositório para o repositório da nova versão. Em distros RHEL o repositório fica em “/etc/yum.repos.d/”. O nome do arquivo sempre começa com “mongodb” e termina com “.repo”.

O script abaixo já faz a substituição do conteúdo do arquivo do repositório ao ser executado. No caso deste código, o nome do arquivo de repositório, que está no fim da primeira linha é mongodb.repo.

O repositório é para Linux REHL 8 (em laranja a seguir) e para a versão 8.0 do MongoDB (em azul) como mostra a 4ª linha do código: “baseurl=https://repo.mongodb.org/yum/**redhat/8**/**mongodb-org/8.0**/x86_64/”.

Na penúltima linha também há citação da versão do MongoDB, que deve ser alterada junto com as outras informações caso o upgrade não seja para as mesmas versões, seja de Linux, seja de Mongo.

No fim deste passo a passo vou juntar algumas partes que podem ser executadas em conjunto.

#  cat << 'ENDOFDOC' | sudo tee /etc/yum.repos.d/mongodb.repo 
[mongodb-org]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/8/mongodb-org/8.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://pgp.mongodb.com/server-8.0.asc
ENDOFDOC

Passo 4: Atualizar o binário

Aqui fazemos diretamente a atualização do binário do MongoDB. Por segurança é bom realizar um backup do arquivo de configuração do Mongo. Para isso, podemos executar os comando a seguir no Shell.

# sudo cp /etc/mongod.conf /etc/mongodconf.upgradeBkp
# sudo yum upgrade mongodb-org -y

Para algumas versões do Mongo essa instrução pode falhar. Isso por que o nome do pacote muda em algumas versões. Você pode tentar as seguinte variações para o nome do pacote:

mongodb
mongodb-org
mongodb-*
mongodb*

Passo 5: Iniciar o Mongo com o novo binário

Para iniciar o MongoDB com o novo binário usamos o systemctl start mongod. E em seguida é importante utilizar o comando systemctl status mongod para verificar se o serviço foi iniciado sem nenhum problema. Se tudo estiver ok, o resultado será como o mostrado a seguir:

# systemctl start mongod
# systemctl status mongod
● mongod.service - MongoDB Database Server
   Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
   Active: active (**running**) since Sun 2024-03-24 04:40:06 UTC; 24s ago
     Docs: https://docs.mongodb.org/manual
 Main PID: 59443 (mongod)
   Memory: 170.8M
   CGroup: /system.slice/mongod.service
           └─59443 /usr/bin/mongod -f /etc/mongod.conf

Mar 24 04:40:06 ip-172-31-38-118.sa-east-1.compute.internal systemd[1]: **Started** MongoDB Database Server.

No caso de haver algum erro seguem alguns passos importantes a verificar já citados no início do arquivo:

Verificar permissão de diretórios e arquivos

Todos os diretórios e arquivos citados no arquivo de configuração do MongoDB, exceto o de time zone, precisam ter como dono o usuário de serviço do MongoDB: mongod. Por isso podemos iniciar verificando todos os paths citados lá, no arquivo /etc/mongod.conf.

Em geral teremos os seguinte paths:

systemLog: /var/log/mongodb/mongod.log
storage: /var/lib/mongo
security.keyFile: /etc/mongodb.key

Os arquivos e diretório acima são os padrão. É importante lembrar que cada instalação pode ter estes arquivos em outros caminhos. Pensando nos caminhos padrão, a correção para os problemas de permissão seria executar o seguinte script:

# chmod -R mongod:mongod /var/log/mongodb/mongod.log
# chown -R 744 /var/log/mongodb/mongod.log
# chmod -R mongod:mongod /var/lib/mongo
# chown -R 744 /var/lib/mongo
# chmod mongod:mongod /etc/mongodb.key
# chown 400 /etc/mongodb.key

Observe que a permissão do keyFile é bem restritiva, permitindo leitura somente ao usuário mongod, e nada mais.

Passo 6: Atualizar a primária

Após concluir a atualização de todos os nós secundários, vamos partir para atualizar o nó primário. O processo em si é basicamente o mesmo, mas há uma pequena diferença no silent shutdown: antes de executar o db.shutdownServer(), devemos forçar uma troca de nó primário com o comando stepdown, como mostra a seguir:

# mongo admin --host localhost --port <27017> --username <admin> --password <admin>
...
rs01 [primary] admin> rs.stepDown()
rs01 [secondary] admin> db.shutdownServer()
rs01 [primary] admin> exit

Após a execução deste passo, você pode seguir dos passos 2 a 5.

Passo 7: Atualizar o Compatibility Version do replica set

Se você chegou aqui, é por que você terminou a atualização com sucesso. No entanto, o MongoDB continua funcionando com a versão anterior, por que ele tem algo chamado compatibility version, o que permite que atualizemos um nó para uma versão superior a dos demais sem que ele pare de funcionar ou apresente conflitos.

Essa configuração também é a que permite fazer um downgrade de forma tranquila para a maioria das versões. De forma que, para finalizar esta atualização precisamos atualizar o compatibility version, o que fazemos com o código a seguir no nó primário:

# mongo admin --host localhost --port <27017> --username <admin> --password <admin>
...
rs01 [primary] admin> db.adminCommand({setFeatureCompatibilityVersion: "8.0", 
                                      confirm: true})

Para confirmar se realmente estamos com o compatibility version correto, podemos executar o seguinte comando na mesma sessão do Mongo, recebendo o resultado:

rs01 [primary] admin> db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})
{
  ***featureCompatibilityVersion: { version: '8.0' }*,**
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1660318752, i: 5 }),
    signature: {
      hash: Binary(Buffer.from("ce0cff3621e9b089fa6d8e9a1e1efc1a1ff15dab", "hex"), 0),
      keyId: Long("7129893797260951557")
    }
  },
  operationTime: Timestamp({ t: 1660318752, i: 5 })
}

Códigos agrupados:

Atualização de repositório, upgrade do binário e restart do serviço.

Após realizar o Silent Shutdown do nó, podemos executar o código abaixo que realizará a alteração do repositório, o backup do arquivo de configuração, e o upgrade do binário, bem como o restart do serviço do MongoDB.


cat << 'ENDOFDOC' | sudo tee /etc/yum.repos.d/mongodb.repo 
[mongodb-org]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/8/mongodb-org/8.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://pgp.mongodb.com/server-8.0.asc
ENDOFDOC

sudo cp /etc/mongod.conf /etc/mongodconf.upgradeBkp
sudo yum upgrade mongodb-org -y
systemctl start mongod
systemctl status mongod

Correção das permissões dos diretórios e arquivos

No caso de ocorrer algum erro no restart do serviço é importante verificar a permissão dos arquivos. O código abaixo é um exemplo de correção das permissões. Mas é sempre importante lembrar que os caminhos podem variar de instalação para instalação. Os caminhos que estão no script são os caminhos padrão para o CentOS. No entanto, por exemplo, nas instalações que eu faço, eu costumo mudar o diretório de log e de dados bem como o keyfile para o diretório /mongo. Dentro dele eu crio subdiretórios ssh, data, log. Com isso, eu precisaria alterar os caminhos no script abaixo.

chmod -R mongod:mongod /var/log/mongodb/mongod.log
chown -R 744 /var/log/mongodb/mongod.log
chmod -R mongod:mongod /var/lib/mongo
chown -R 744 /var/lib/mongo
chmod mongod:mongod /etc/mongodb.key
chown 400 /etc/mongodb.key

Por que usar o MongoDB?

Paulo Benjamin — Mon, 21 Oct 2024 16:54:42 +0000

Fala ae galerinha!

Nesse artigo eu decidi voltar na base de o que é o MongoDB e suas vantagens. Os outros artigos que tenho aqui no Dev.to, eu falei alguns pontos interessantes, mas a verdade é que o MongoDB possui muitas features interessantes. Nesse artigo, eu quero focar na parte de infraestrutura.

A grande verdade é que os bancos de dados relacionais são um ponto de falha preocupante para as aplicações. Por mais que tenhamos uma aplicação clusterizada, ou funcionando em uma estrutura como kubernetes, por exemplo, mas o banco sempre está em uma única máquina, o que aumenta a possibilidade de uma falha no ambiente.

Alguns bancos até apresentam estruturas de replicação, mas os que são de licença livre apresentam um alto nível de complexidade na configuração de um HA e DR, já os pagos, vão gerar um custo maior com licenciamento. Mas o MongoDB oferece isso como uma feature básica.

A estrutura básica do MongoDB para produção é chamada Replica Set. O Replica Set é um conjunto de maquinas que funciona em cluster, replicando os dados entre eles. O objetivo principal do Replica Set é Recuperação de Desastres (DR) e Alta Disponibilidade (HA), ou seja, manter o serviço de banco de dados sempre disponível independente de falha lógica, física, de redes, ou outras situações como atualizações de sistema ou upgrade de versão de banco de dados ou SO.

No Replica Set, a aplicação se conecta a todos os nós, mas realiza as leituras e escritas, por padrão, somente com o nó primário. Como a aplicação já conhece todos os nós, no caso de uma falha, ela vai passar a transacionar automaticamente com o nó que assumir a role de primária de forma transparente, sem necessidade de qualquer interação com o banco ou aplicação.

O Replica Set em ambiente produtivo deve ser composto por pelo menos três maquinas, e pode ser escalado em números ímpares. A titulo de exemplo, no MongoDB Atlas - o MongoDB como serviço hospedado na nuvem e gerido pela própria MongoDB - são oferecidos nos clusters 3, 5 ou 7 nós com o papel de DR e HA.

Outro ponto interessante é que diferente de outros SGBDs a configuração da replicação é bem simples. Em um cluster sem autenticação, por exemplo, basta executar o script a seguir no bash:

# sudo cat /etc/mongod.conf | sed '/#replication/s/#//' | sed '/replication/a \ \ replSetName: "rs0"' > /etc/mongod.conf.tmp
# sudo mv /etc/mongod.conf.tmp /etc/mongod.conf
# sudo systemctl restart mongod
# mongosh
> rs.initiate()

No script acima, estamos considerando um MongoDB recém instalado, sem outras configurações realizadas.

Se você gostou desse artigo, não deixe da dar uma olhada nos outros artigos publicados no meu perfil no Dev.to, e fique atento para novas publicações.

Inclusive, se você ficou interessado em saber como montar um Replica Set para produção, fique atento, que este será um dos meus próximos artigos!

Replication - MongoDB Manual
Replica Sets Distributed Across Two or More Data Centers

Migrando para o Atlas com Live Migrate

Paulo Benjamin — Wed, 16 Oct 2024 18:33:42 +0000

Você já precisou migrar dados de um servidor de banco de dados para outro? Ou mover um MongoDB Replica Set ou Sharded Cluster para uma nova infraestrutura? A primeira preocupação geralmente é: quanto tempo a aplicação precisará ficar offline?

Nos dias de hoje, manter uma aplicação offline é praticamente impensável para muitas empresas. Isso faz com que muitas delas acabem presas em ambientes limitados, sem escalabilidade adequada. Afinal, por mais avançado que seja um datacenter próprio, ele raramente alcança o nível de flexibilidade e crescimento que a nuvem oferece.

Pensando nisso, a MongoDB disponibiliza diversas ferramentas para facilitar migrações, como o mongomirror, o MongoDB Cluster-to-Cluster Sync (ou MongoSync) e o Live Migrate. Hoje, nosso foco será o Live Migrate.

O Live Migrate é, essencialmente, uma versão hospedada e gerenciada do MongoSync, oferecida pela MongoDB via internet para simplificar a migração de dados de um servidor MongoDB (seja no Atlas ou On-Premise) para um servidor MongoDB no Atlas.

Para contextualizar, segundo o próprio site da MongoDB, o MongoDB Atlas é um conjunto integrado de serviços de dados centrado em um banco de dados na nuvem, projetado para acelerar e simplificar o desenvolvimento de aplicações. Ele oferece gerenciamento de clusters hospedados nas três principais nuvens do mercado: AWS, Azure e GCP.

Mas o que torna o Live Migrate tão especial? Ele funciona como uma integração entre dois clusters, porém, com um fluxo de dados unidirecional. Inicialmente, é feita uma cópia bruta dos dados (o chamado initial sync), seguida pela reprodução do oplog.

Como o oplog registra todas as alterações feitas em um servidor MongoDB, o Live Migrate aplica essas modificações no servidor de destino, sincronizando os dados até que tudo o que acontece no cluster de origem seja replicado no destino.

Vamos no nosso Cluster no Atlas, clicando no menu a esquerda em Database, clicamos nos três pontos ao lado do botão Browse Collections, e então chegamos na tela inicial do Live Migrate, como mostrado na sequencia de imagens a seguir:

Logo em seguida, nos será apresentada uma tela para preenchermos os dados do nó primário do nosso Cluster, bem como alguns IPs que precisamos liberar em nossa rede para acessar nosso replica set.

Nessa tela também precisamos informar um usuário e senha, que tenha as permissões readAnyDatabase, clusterMonitor e backup. No fim dessa tela, temos um botão para validar as informações que colocamos, que faz um teste de conexão, e o botão para iniciar a migração, com mostrado a continuação.

A vantagem é que essa replicação pode continuar pelo tempo necessário, até que você esteja pronto para concluir a migração. Nesse momento, a única ação necessária será a troca da URI de conexão do banco de dados na aplicação. E dependendo de como sua aplicação foi implantada, talvez nem seja necessário interromper seu funcionamento.

Quais são as principais recomendações e exigências para os clusters durante essa migração? Para o cluster de origem, é necessário liberar o acesso aos IPs requisitados pelo Atlas. Já para o cluster de destino, é recomendável usar, pelo menos, um cluster Tier M60 no Atlas durante o initial sync e até que o atraso (lag) entre os clusters seja zerado. Após isso, você pode redimensionar o cluster conforme o tamanho adequado ao seu ambiente.

Finalizada a migração, é hora de realizar o cutover, ou seja, encerrar a replicação entre o servidor antigo e o novo, diretamente no painel do Atlas.

Pronto! Bom vindo ao MongoDB Atlas!

MongoDB - MQL Básico

Paulo Benjamin — Wed, 26 Oct 2022 17:11:08 +0000

MQL - MongoDB Query Language

Como em qualquer outro banco de dados, a manipulação dos dados também tem suas peculiaridades no MongoDB. Todos os bancos relacionais utilizam SQL para realizar consultas, mas a principal linguagem utilizada pelo MongoDB é a MQL - MongoDB Query Language. A instalação do MongoDB com fim de estudos é bem simples. Para usuários Windows, a instalação não foge do padrão “next - next - finish”. Já para usuário Linux, basta adicionar o repositório e utilizar o seu gerenciador de pacotes, assim como para o MacOS. Quando instalamos o MongoDB, o banco vem sem segurança configurada, e o acesso é bem simples: basta digitar mongosh no cmd/shell. Feito isso, você já pode começar seus estudos! No entanto, lembre-se, com essas configurações, o MongoDB deve ser utilizado somente para estudos. A utilização do MongoDB sem segurança habilitada, e sem um replicaset não é recomendada principalmente para ambientes produtivos! Dito isso, vamos em frente: Quando nos conectamos no banco de dados sem passar parâmetros adicionais somos direcionados para o database test. Nossos primeiros comandos no MongoDB são bem parecidos com o de MySQL: show dbs, show collections e use . Aqui também podemos trabalhar alguns conceitos básicos do MongoDB. Em um de - para, podemos dizer o seguinte ao compararmos o MongoDB com um banco relacional:

MongoDB	Relacional
Database	Database
Tabela	Collection
Linha	Documento

Ao executar o show dbs você vai perceber que o banco de dados test - em que estamos conectados - não existe, e isso é normal para o MongoDB. O MongoDB não exige comandos do tipo DDL (Data Definition Language). Assim, para criamos um banco de dados precisamos apenas nos conectar nele, ter permissão de escrita e inserir um documento. Para fazer o teste, execute os comandos a seguir depois de se conectar ao mongo pelo mongosh:

No primeiro comando, nos conectamos no banco db01. Logo em seguida, ao listar os bancos, vemos que somente os bancos admin, local e config existem. Logo em seguida você vai executar seu primeiro comando MQL e inserir um documento no banco db01, e após verificar os bancos existentes de novo, verá que o banco db01 agora existe. Os comandos utilizados para CRUD no MongoDB seguem o seguinte padrão: db..({…}). Os comandos para CRUD são os seguintes: insertOne, insertMany, findOne, find, updateOne, updateMany, deleteOne e deleteMany. Todos eles recebem pelo menos um documento como parâmetro. Destes comandos, os que terminam com Many permitem trabalhar com operações do tipo bulk - que são bem mais performáticas ao se trabalhar com grandes massas de dados. Abaixo seguem algumas peculiaridades dos comandos acima: ## insertOne e insertMany

Estes comandos gravam dados em um namespace (banco.coleção). Quando o namespace não existe, ele é automaticamente criado. O insertOne recebe um documento, enquanto o insertMany recebe um array de documentos.

//insertOne
db.test.insertOne(
    {
        'comando': 'insertOne',
        'valor': 1
    }
)

//insertMany
db.test.insertMany(
    [
        {
            'comando': 'insertMany',
            'valor': 1
        },
        {
            'comando': 'insertMany',
            'valor': 2
        }
    ]
)

Após executar esses comandos no seu shell, você pode executar o bloco abaixo, de finds. Nos demais comandos, vou adicionar um find sem filtros para que vocês possam visualizar tudo que está acontecendo com os documentos do banco de vocês.

findOne e find

Com estes comandos podemos selecionar documentos de uma coleção. Ambos recebem um documento com os campos e valores que queremos usar como filtro.

//findOne
db.test.findOne(
    {
        'valor': 1
    }
)

//find com filtro
db.test.find(
    {
        'valor': 1
    }
)

//find sem filtros para retornar tudo de uma coleção
db.test.find()

updateOne e updateMany

O updateOne e updateMany são os únicos que precisam de dois documentos para funcionar, já que o primeiro será o filtro, e o segundo contém as alterações que devem ser realizadas. É bom lembrar que se não utilizarmos operadores como o $set, o documento anterior será totalmente substituído pelo conteúdo do segundo documento que estamos enviando nos comandos de update. No exemplo abaixo utilizamos o operador $set para alterar o valor somente de um campo do documento, e não o documento todo.

//updateOne
db.test.updateOne(
    {
        'insertOne': 1
    },
    {
        $set: {
            'comando': 'updateOne'
        }
    }
)

//find sem filtro
db.test.find()

//updateMany
db.test.updateMany(
    {
        'comando': 'insertMany'
    },
    {
        $set: {
            'comando': 'updateMany'
        }
    }
)

//find sem filtro
db.test.find()

Antes de seguirmos a diante, vamos executar um aggregate (abordaremos mais detalhes sobre esse tipo de comandos em outro posto) para poder criar um cenário legal para testarmos o delete:

db.test.aggregate(
    [
        {
            $project: {
                _id: 0
            }
        },{
            $set: {
                'aggregate': true
            }
        },{
            $merge: {
                into: 'test',
                whenNotMatched: 'insert'
            }
        }
    ]
)

//find sem filtro
db.test.find()

Observe que agora você terá 6 documentos, sendo que 3 deles possuem o campo aggregate com o valor true. Agora podemos seguir!

deleteOne e deleteMany

Por último, temos os documentos de deleção do MongoDB: deleteOne e deleteMany

db.test.deleteOne(
    {
        aggregate: {
            $exists: false
        },
        valor: 2
    }
)

//find sem filtro
db.test.find()

db.test.deleteMany(
    {
        aggregate: {
            $exists: true
        },
        valor: 1
    }
)

//find sem filtro
db.test.find()

Extra

O MongoDB também tem mais um comando que permite realizar inserções, deleções e atualizações: o bulkWrite. Ao invés de receber um filtro, ou um array de documentos, ele recebe um array de operações. Ou seja, podemos enviar ao banco vários comandos de escrita misturados. Mas vamos deixar isso para um papo futuro.

Agora você já pode começar a treinar CRUD com MongoDB!

MongoDB - O banco NoSQL mais utilizado no mundo

Paulo Benjamin — Wed, 19 Oct 2022 14:12:57 +0000

O MongoDB é um banco de dados NoSQL que foi lançado em 2009. De lá pra cá, este banco de dados tem crescido em utilização e em popularidade. Hoje já estamos na versão 6.0 dele. Mas, qual a diferença dela para outros bancos de dados como SQL Server, Oracle ou MySQL?
O MongoDB é um banco de dado que não armazena os dados em um formato tabelar e relacional. Os documentos são armazenados em "documentos".
Os documentos são expressos no tão conhecido formato JSON, e armazenados no formato BSON (que não significa um JSON armazenado em binário, mas sim uma serialização binária de json). Este formato armazena os dados de maneira tipada, diferente do JSON.
Dessa forma, informações que seriam expressas assim em um banco relacional:

id	nome	titulo	email	linkedin
1	Paulo Benjamin	Consultor MongoDB	paulo.benjamin@phdatatech.com	linkedin.com/in/pcjuniorrj

Passam a ser expressas assim:

{
    id: 1,
    nome: "Paulo Benjamin",
    titulo: "Consultor MongoDB",
    email: "paulo.benjamin@phdatatech.com",
    linkedin: "linkedin.com/in/pcjuniorrj"
}

A princípio parece simplesmente uma mudança na forma como os dados são visualizados e armazenados, mas essa diferença é bem mais profunda. Com essas alterações, podemos utilizar toda a flexibilidade do JSON para guardar as informações. Assim, o documento acima poderia ser convertido para o seguinte:

{
    id: 1,
    nome: "Paulo Benjamin",
    titulo: "Consultor MongoDB",
    contato: [
        {tipo: "email", contato: "paulo.benjamin@..."},
        {tipo: "linkedin", contato: "@pcjuniorrj"}
    ],
    stacks: [
        "MongoDB",
        "SQL Server",
        "Oracle",
        "MySQL",
        "Redis"
    ]
}

Para armazenar o documento acima, seriam necessárias pelo menos 3 tabelas. E aí começamos a ter vantagens na utilização do MongoDB. As consultas passam a ser mais rápidas já que evitamos a utilização de joins a todo custo. A comparação entre os dados armazenados e os objetos de uma aplicação se tornam mais fáceis.
Outro ponto é que o MongoDB permite uma flexibilidade muito grande do esquema. Assim, para converter o primeiro documento no segundo modelo, basta um update, o que facilita muito a implementação e evoluções do esquema de dados de uma aplicação.
No entanto, estas facilidades vêm com responsabilidades. É importante lembrar que o MongoDB não vai criticar a inserção de um documento sem um campo, ou com o nome do campo errado. Essa abstração e responsabilidade, assim como outras, ficam a cargo da aplicação.
Por isso, Devs, lembrem-se: "Com grandes poderes vem grandes responsabilidades" - Tio Ben/Tia May.