MongoDB é o banco de dados NoSQL mais usado no mundo, e quando utilizado com sabedoria é uma grande escolha!
Sou suspeita para falar de MongoDB… É um SGBD que eu adoro, e tenho alguns casos de sucesso!
Nos últimos anos ganhei dois prêmios importantes da MongoDB Inc., MongoDB Female Innovator (2018) e o Prêmio William Zola (2019). Além disso fui a primeira mulher brasileira a palestrar no MongoDB World que acontece anualmente em NY.
Apesar das alegrias que eu tive com o MongoDB, não vim dizer que ele é perfeito, ou que serve para tudo! Prepare-se!
No nosso primeiro post, conversamos sobre quando usar um banco de dados relacional… Neste post teremos uma introdução aos fundamentos de NoSQL, e conversaremos sobre o MongoDB. Posteriormente em cada post, conversaremos os tipos de BD NoSQL.
Antes de começar, precisamos entender alguns conceitos bem importantes.
O que é um banco de dados NoSQL?
NoSQL é o nome que foi dado para reunião que aconteceu em 2009 em São Francisco (EUA) para discutir sobre projetos de bancos de dados de código aberto, não relacionais, sem esquema e distribuídos. Podemos destacar também que eles possuem linguagens de consultas próprias, embora algumas sejam baseadas no SQL como o HQL do Hive e o CQL do Cassandra.
O modelo de dados é usado para categorizar bancos de dados NoSQL[1], de forma que podem ser divididos em Key-Value, Documentos, Colunares e Grafos.
Bancos de dados Key-Value
Como o próprio nome diz armazena uma chave (usada na consulta) e um valor (retorno da consulta). São muito usados como cache das aplicações porque armazenam partes críticas de dados na memória para acesso de baixa latência.
Os exemplos de bancos de dados desta categoria são:
- Redis;
- Voldemort;
- Memcahed
- Riak;
Banco de Dados orientados a Documentos
Nesta categoria os dados normalmente são armazenados no formato JSON, o mais conhecido e na minha opinião mal utilizado (juro que nos próximos parágrafos você entenderá) é o MongoDB que recebe os valores no formato JSON e os armazena em um formato binário chamado BSON. Fazem parte desta categoria também:
- CouchDB
- OrientDB
- RavenDB
- TerraStore
Bancos de Dados Colunares
Podemos pensar nesta categoria como uma estrutura agregada de dois níveis, onde existe um identificador da linha e um mapa com valores mais detalhados. Como pode ser visto na figura abaixo
Exemplos de bancos de dados colunares são:
- Cassandra
- HBase
- Hipertable
- Amazon SimpleDB
Banco de Dados orientados a Grafos
Adoro trabalhar com grafos!!! Tanto que meu próximo desafio é palestrar na Bélgica, falando sobre Grafos. Olha que fofo o anúncio da palestra.
Sendo assim, imagina qual é o assunto do post da próxima semana?
Voltando às definições, este são bancos de dados onde registros pequenos possuem relações complexas. A figura abaixo possui um exemplo de grafo.
Exemplos de bancos de dados orientado a grafos:
- Neo4J
- OrientDB
- Infinit Graph
Agora que você já conhece cada um dos tipos de bancos de dados NoSQL, importante que você entenda algumas coisas importantes…
O hardware
Quando falamos dos primeiros SGBDs precisamos lembrar que o hardware era um fato limitante, de forma que os dados eram organizados para minimizar a redundância, porque um alto volume de dados aumentaria muito o custo dos sistemas.
O tempo foi passando, o volume de dados foi aumentando, o hardware foi ficando mais barato as redes melhores.
Surge então a possibilidade de escalar os sistemas verticalmente, ou seja, aumentar a capacidade de um sistema trocando de servidor (para um mais potente) ou adicionando no servidor mais memória, CPU…
Mas e se o volume de dados continuar aumentando, e não existir a possibilidade de melhorar o servidor?
Neste caso precisamos da possibilidade de escalar os sistemas horizontalmente, ou seja, distribuir os dados entre vários servidores comodities (mais baratos), aumentando assim a sua capacidade.
Resumidamente quando falamos em escalar um sistema, falamos da capacidade de um sistema suportar um aumento substancial de carga sem comprometer o seu desempenho.
O Teorema De CAP
Se os dados estão distribuídos, é preciso ter atenção porque de um conjunto de 3 propriedades, é possível atender somente 2.
A wikipedia tem uma definição linda do teorema de CAP:
1. Consistência
Cada leitura recebe a escrita mais recente.
2. Availability (Disponibilidade)
Cada pedido recebe uma resposta (sem erro) – sem garantia de que contém a escrita mais recente.
3. Partition Tolerance (tolerância a partição de redes)
O sistema continua a funcionar apesar de um número arbitrário de mensagens serem descartadas (ou atrasadas) pela rede entre nós
Se um sistema só pode atender 2 propriedades, na escolha de um NoSQL, leve isto em consideração.
Para te ajudar na escolha segue uma imagem bem “clássica” e com algumas informações muito importantes.
Bancos de Dados NoSQL não tem schema
Entenda que isso não significa bagunça! Significa que as evoluções são mais simples e com downtime menor!
Os bancos de dados relacionais exigem que as estruturas sejam definidas antes que você possa adicionar dados.
Os bancos de dados NoSQL permitem a inclusão dos dados sem um esquema predefinido. Isso facilita fazer alterações nos aplicativos em tempo real, sem se preocupar com interrupções de serviço para atualização da estrutura, de forma que o desenvolvimento tende a ser mais rápido.
Propriedades BASE
Em muitas situações, as transações ACID são pessimistas (isto é, estão mais preocupadas com a segurança dos dados) do que o domínio realmente exige.
Quando falamos de NoSQL, as transações ACID nem sempre são uma verdade absoluta, pois alguns bancos de dados diminuíram os requisitos de consistência imediata, atualização e precisão dos dados para obter outros benefícios, como escala e resiliência.
Em inglês BASE quer dizer:
Basic Availability
- O banco de dados parece funcionar a maior parte do tempo.
Soft-state
- Os dados não precisam ser consistentes com gravação, nem réplicas diferentes precisam ser mutuamente consistentes o tempo todo.
Eventual consistency
- Os dados ficarão consistentes em algum momento
As propriedades BASE são muito mais “suaves” do que as garantias ACID, mas não há um De-Para entre os dois modelos.
Lembre-se que um banco de dados NoSQL valoriza a disponibilidade (já que isso é importante para sistemas que escalam horizontalmente), mas não oferecem consistência garantida de dados replicados no momento da gravação. No geral, o modelo de consistência do BASE fornece uma garantia menos rigorosa do que o ACID.
O que é, e para que serve MongoDB?
Agora que já conversamos de forma genérica sobre características dos bancos de dados NoSQL, vamos conversar sobre o MongoDB.
Ele é um banco de dados NoSQL, que não armazena seus dados em tabelas e tem o código aberto.
Ele está enquadrado na categoria de bancos de dados orientado a documentos, e manipula dados semiestruturados.
Uma característica importante é que o MongoDB não usa a linguagem SQL.
Structured Query Language é a linguagem mais conhecida e mais usada para consulta de dados. É usada principalmente com os bancos de relacionais, mas tem suas adaptações para bancos de dados não relacionais como o Hive que possui o HQL, o Cassandra que possui o CQL.
Os documentos recebidos pelo MongoDB normalmente estão no formato JSON, e são armazenados em um formato aberto e binário desenvolvido pela equipe do MongoDB, o BSON (Binary JSON).
Cabe dizer que:
- O BSON normalmente não ocupa menos espaço que o JSON;
- Para o MongoDB é mais fácil e rápido analisar e indexar os dados no formato BSON;
- O BSON pode ser convertido para um formato de dados nativo de uma linguagem de programação de forma muito mais rápida.
Como os dados são organizados dentro do MongoDB?
Uma instância do MongoDB pode possuir vários bancos de dados, cada banco de dados possui várias coleções, e cada coleção possui documentos. Que são conteúdos indexáveis recebidos normalmente no formato JSON e armazenados no formato BSON.
Se fizermos um paralelo com um banco de dados relacional teremos o seguinte:
BD Relacional | MongoDB |
Banco de Dados | Banco de dados |
Tabela | Coleção |
Linha | Documento |
Mas… Porque usar o MongoDB?
Agora que já conversamos sobre as características gerais do MongoDB, vamos começar a entender quando ele é uma excelente alternativa.
Vamos além da discussão SQL VS NoSQL… prepare-se!Vamos jogar e entender quando devemos usar o MongoDB
A primeira característica importante é que seus dados devem estar preferencialmente no formato JSON.
Quando é necessário manipular os atributos do documento JSON, damos mais um passo importante.
Com servidores mais baratos, e/ou se você precisa de mecanismos nativos de alta disponibilidade (saiba mais sobre a replicação do MongoDB neste link), avançamos mais alguns pontos.
Para alto desempenho, e/ou se não tem problemas com a consistência eventual, avançamos mais um pouco…
Se o schema evolui constantemente e a evolução precisa ser rápida, avançamos mais um pouco.
Quando você está usando DDD (Domain Driven Design) corretamente, ou seja, quando o projeto da aplicação é orientado ao domínio, avançamos uma casa .
Segundo Eric Evans (autor do DDD), banco de dados relacionais não são apropriados para armazenar objetos que mapeiam entidades de domínio, neste caso o MongoDB tende a ser uma alternativa mais sábia.
Embora o MongoDB tenha suporte a transações, elas são lentas (se comparadas com as transações nos BD Relacionais), e neste caso pense muito para usar, volte duas casas.
O fato do MongoDB não ter schema, não isenta ninguém do processo de modelagem de dados! É sério! Pular a etapa de modelagem dos dados, vai tirar você do jogo.
Aproveitando o embalo... Em abril vai sair um e-book bem lindo sobre modelagem de dados no MongoDB! Se inscreve aqui no blog para ficar sabendo do lançamento.
Quando você precisa de processamento de dados, próximo do tempo real, você tem a possibilidade de usar o Change Stream que é uma API simples e bem poderosa. Não avance nenhuma casa, porque é só um recurso fofinho que eu queria que você conhecesse.
Tenha atenção com a versão do MongoDB que você irá usar. Versão Community significa que a sua aplicação é open source (sendo muito simplista). Tenha cuidado com isso, para não ter problemas legais. Saiba mais sobre a licença em https://www.mongodb.com/community/licensing
Dicas de MongoDB para iniciantes em NoSQL
Meus amigos, produção não é teste! Se você vai usar o MongoDB, conheça os recursos e as possibilidades para que ele não vire uma incrível e gigante fonte de problemas.
Aqui no blog temos vários posts que podem te ajudar, e mesmo assim nada como colocar a mão na massa e fazer testes, muitos testes.
Um fator muito importante, são as interfaces que permitem a interação com o MongoDB. Nada te impede de usar o Mongo Shell (aplicativo mongo.exe, disponível depois da instalação do MongoDB Server), que é um prompt de comando (popular tela preta). Mas eu te aconselho a buscar interfaces que colaborem com a sua produtividade.
O que é o MongoDB Compass?
É uma interface gráfica (bonitinha) criada pela MongoDB , e que permite a exploração dos dados (com comandos), a execução de consultas, e a análise visual dos dados, a criação de índices, validação dos dados… e o melhor, tem o Agreggation Pipeline Builder (saiba porque eu acho esse recurso tão fofo nos posts:
- http://db4beginners.com/blog/views-materializadas/
- http://db4beginners.com/blog/join-no-mongodb/
- http://db4beginners.com/blog/group-by-no-mongodb/
Outras possibilidades de IDE que eu gosto muito são;
- O Mongo3T (que já se chamou RoboMongo) , e tem uma versão paga chamado de Studio 3T (https://robomongo.org/download)
- DBKoda que é uma ferramenta bem completa, porque além de permitir a interação com o MongoDB tem alguma features para monitoração (https://www.dbkoda.com/)
Para fazer o download do MongoDB Compass acesse o link https://www.mongodb.com/products/compass
Sistema Operacional… MongoDB no Windows?
Não é nenhuma heresia!
De acordo com a documentação do MongoDB, ele tem o mesmo desempenho quando executado no Linux e no Windows.
Diferenças? Existem, mas não use o argumento de desempenho.
MongoDB Download
No site oficial da empresa MongoDB, temos muitos produtos interessantes. Neste post conversamos muito sobre o MongoDB Server, que é um SGBD NoSQL e orientado a documentos (a repetição neste caso é proposital).
Ele está disponível nos links:
Para finalizar o post e sem fechar o assunto…
Dando continuidade para a nossa super planilha, adicionei mais uma aba, indicando quando usar o MongoDB.
Lembre-se que a planilha é nossa, então fique a vontade para mandar suas colaborações.
Indicações
Você conhece meu canal no Youtube? Ele é um dos meus focos de 2020, e já tem alguns vídeos fofos sobre bancos de dados NoSQL.
Recomendo especificamente os seguintes:
Referências
https://pt.wikipedia.org/wiki/Teorema_CAP
https://www.mongodb.com/nosql-explained
https://medium.com/leroy-merlin-brasil-tech/devo-usar-nosql-e-mongodb-951693aa0d34
[1] Para verificar todos os bancos de dados NoSQL divulgados, verifique o site http://nosql-database.org/
Agenda
Esta semana já começamos com os eventos!
O primeiro será PRESENCIAL e GRATUITO, no dia 17/01. Eu vou palestrar a convite da comunidade Azure Talks. O meetup acontecerá na FC Nuvem – Rua Bela Cintra, 986 – São Paulo-SP – próximo das Estações de Metrô Paulista (Linha Amarela) e Consolação (Linha Verde).
Eu vou falar de Análise de Dados com MongoDB + Excel. Vai ser bem legal, e eu ficarei muito feliz de encontrar amigos lá!
Saiba mais em https://www.meetup.com/pt-BR/Databases-SP/events/267781530/
Autora
Este post foi escrito por mim! Danielle Monteiro 🙂
Outros posts desta série
Se você quer ler os outros posts desta série, acesse os links abaixo:
- SQL ou NoSQL – Parte 1 – http://db4beginners.com/blog/sql-ou-nosql/
- SQL ou NoSQL – Parte 3 – Quando usar o Neo4J? http://db4beginners.com/blog/sql-ou-nosql-Neo4J
Novidades
Agora o blog tem parceiros! Estou tão feliz e orgulhosa desta conquista!
O nosso primeiro parceiro é a SPEsportes, uma loja super legal, com produtos incríveis e preço justo! Os leitores do blog tem desconto de 20% em todos os produtos, informando o cupom de desconto DB4BEGINNERS
Se a sua empresa quiser ser parceira também, temos algumas possibilidades.