AUTOMALABS

Neste tutorial vamos usar uma conta gratuita MongoDB Atlas, que é limitada a 500MB (04/2020) de dados.

Visite https://www.mongodb.com/cloud/atlas e clique em Start Free (1). Na próxima página você pode se registrar usando uma conta Google ou email, nome, sobrenome e senha (2). Essas
são as únicas informações pedidas e pelo menos até abril de 2020 não era pedida confirmação do email até a data deste trabalho. Preencha tudo como no exemplo e clique em Get Started Free (3):

Agora clique em Create a Cluster – FREE para criar uma conta gratuita

Na próxima tela você escolhe o provedor de nuvem e a localidade. O default (no caso abaixo, um servidor Amazon na Virgínia do Norte) é suficiente. Clique em Create Cluster.

A seguir MongoDB Atlas vai instalar e configurar o MongoDB no provedor de nuvem escolhido. Esse processo pode levar alguns minutos e você deve esperar enquanto os avisos, em inglês, estiverem aparecendo na tela:

Quando os avisos sumirem você pode passar para o próximo passo, que é criar um usuário. Clique em Create your first database user.

Clique em Database Access:

Clique em Add New Database User:

Na próxima tela não altere as opções padrão. Insira um nome de usuário (1), senha (2) e clique em Add User.

Esse usuário vai ser criado com permissões para ler e escrever em qualquer banco de dados, mas não vai poder administrar o banco de dados. Isso é o bastante para nossa aplicação.

Agora clique em Whitelist your IP addres:

Clique em Network Access:

Clique em Add IP Address:

Você pode clicar em ADD CURRENT IP ADDRESS (1) para colocar o seu endereço IP externo público, mas a menos que você esteja em uma conexão que tem IP fixo esse IP vai mudar pelo menos toda vez que você reiniciar seu modem. Pelo menos durante a fase de aprendizagem é melhor clicar em ALLOW ACCESS FROM ANYWHERE (2), que vai dar acesso ao banco de dados de qualquer lugar (adiciona 0.0.0.0/0, como mostrado). Finalize clicando em Confirm (3).

O próximo passo da lista, Load Sample Data, é opcional, mas pode ser interessante. Ele carrega no banco de dados algumas coleções de documentos de exemplo que você pode usar enquanto está
aprendendo MongoDB. Ocupa mais da metade do espaço disponível no serviço gratuito, mas não vamos precisar de muito espaço neste projeto. De qualquer forma este tutorial vai prosseguir sem
esse passo opcional. Você terá outras oportunidades de carregar essas coleções.
Também não vamos precisar do passo Connect your Cluster, porque vamos usar o serviço Stitch. Então finalize o assistente clicando em No thanks:

Em seguida clique em Dismiss it:

Agora nós vamos criar uma coleção. Isso não é estritamente necessário porque, como veremos adiante, a coleção é automaticamente criada quando necessário. Mas mostraremos como é feito
assim mesmo. Em um banco de dados orientado a documentos uma coleção é o equivalente a uma tabela em um banco relacional.
Clique em Collections:

Clique em Add My Own Data:

Dê um nome para o banco de dados (1), um nome para a coleção (2) e clique em Create (3):

Para criar um novo banco de dados, clique em Create Database (1). Para criar uma nova coleção mova o mouse sobre o nome do banco de dados e clique no sinal + que aparece (2).

Pronto. Você já tem o necessário para criar o equivalente a bancos e tabelas no MongoDB. Em outros posts eu explicarei como inserir dados nesse banco usando um ESP8266 e como extrair dados dele usando o Delphi.

Nota do autor: Este texto foi originalmente escrito para um projeto de 73 páginas (inclui figuras e código-fonte) que fiz na faculdade intitulado BANCO DE DADOS ORIENTADO A DOCUMENTOS – UMA APLICAÇÂO PRÁTICA e seguiu alguns requerimentos burocráticos que eu apaguei e outros que mantive. O projeto completo inclui uma aplicação em Delphi para Windows e outra para Arduino/ESP8266 e será tudo detalhado em outros posts.

Quando pensamos hoje em banco de dados quase sempre ainda estamos pensando em um banco de dados relacional. Segundo pesquisa mensal da consultoria austríaca Solid IT, os
quatro SGBD (Sistema Gerenciador de Banco de Dados) mais populares são relacionais, o que corresponde a 75% do total.

O que pode surpreender muitos programadores que por não conhecerem as alternativas podem se espantar por esse número não ser 100%. Mas provavelmente todo programador deve ter se deparado com alguma situação em que seu SGBD (relacional) favorito gerava um incômodo que precisou ser contornado de alguma forma pouco ou nada elegante e que poderia ter sido resolvido com a troca do paradigma.

Mas antes de introduzir a alternativa é conveniente dar um exemplo do tipo de problema que ela resolve.

Considere um problema comum de IoT (Internet of Things – Internet das Coisas) onde você tem um sensor para acompanhar o desenvolvimento minuto a minuto de uma certa grandeza (temperatura, por exemplo) e deseja armazenar isso em um banco de dados para análise posterior. A informação mínima útil a armazenar seria a temperatura e o horário da medição. Uma representação tabular da informação armazenada ficaria assim:

Mas digamos que em um momento qualquer no futuro você decidiu acrescentar mais um sensor. Em uma aplicação convencional usando um SGBD relacional, além de ter que atualizar todos os componentes do projeto que acessam o banco de dados é preciso alterar o próprio banco de dados mudando o seu schema (sua estrutura lógica) acrescentando no mínimo uma coluna (campo), e o resultado poderia ser algo assim:

O fato de todos os registros anteriores à alteração ficarem vazios pode ou não ser um problema, mas o fato de ter que alterar o schema é. Além do mero incômodo de ser um passo adicional, normalmente alterar o schema requer downtime. Todos os acessos à tabela a modificar precisam ser interrompidos durante a operação. Em um sistema local isso pode significar apenas “pedir a todo mundo que saia do sistema”, mas à medida que aumenta a complexidade e a utilização do sistema, interromper o acesso aos dados mesmo que por um intervalo curto de tempo vai se tornando uma decisão mais difícil, impactando negativamente na escalabilidade. Sam Saffron, um dos criadores do popular software de código aberto de gerenciamento de listas de discussão Discourse, afirma que “uma das razões mais comuns para interrupções de serviço durante o deployment de uma aplicação é a alteração do schema do banco de dados”.

Agora digamos que você como desenvolvedor antecipa a necessidade futura de acrescentar sensores e pensando em evitar esse passo adicional e o downtime, decide criar a tabela já com os campos necessários para acomodar mais sensores. Mas quantos campos adicionais antecipar? Dois? Cinco? Dez? Cem? E se você precisar fazer alguma alteração que torne essa antecipação inútil? O nosso exemplo é propositalmente bem simples, mas existem outras situações similares bem mais complexas.

Nesse ponto é interessante avaliar os SGBD NoSQL.
Bancos de dados NoSQL

NoSQL é um paradigma de banco de dados que é modelado de uma forma diferente da tradicional representação tabular dos bancos relacionais. Esse tipo de banco de dados existe desde os anos 1960, mas apenas cerca de dez anos atrás foi o adotado o termo “NoSQL” para se referir ao paradigma.  Bancos NoSQL tem um foco em simplicidade de projeto e escalabilidade e suas estruturas de dados são diferentes das usadas em bancos relacionais fazendo com que algumas operações sejam mais rápidas em NoSQL.

Os requerimentos do nosso exemplo são a capacidade de mudar o schema facilmente e fazer buscas simples no banco de dados. O primeiro é uma característica dos bancos NoSQL mas os recursos de busca dependem do SGBD NoSQL escolhido.

Os SGBD NoSQL podem ser divididos em quatro grandes categorias:

• Chave-Valor (key-value);
• Armazenamento de Documentos (document-store);
• Armazenamento de coluna ampla (wide colum stores);
• Graph Database.

Novamente usando como referência  a DB-Engines, podemos ver que os modelos mais populares são chave-valor e armazenamento de documentos:

Por brevidade, vamos nos ater a analisar apenas esses dois modelos.

Chave-Valor
Nesse modelo o banco de dados usa um simples método chave-valor para armazenar os dados. É mais fácil entender esse método pensando que um dicionário é um exemplo de chave-valor: a chave sendo uma palavra e o valor sendo o significado. O nome do método pode ser enganador, levando você a pensar que o “valor” pode ser uma entidade apenas, mas não é bem assim. Abaixo temos um exemplo perfeitamente válido de armazenamento chave-valor:

No exemplo acima, cada chave dá acesso a duas entidades: uma temperatura e o horário. Chave-valor não tem nenhum schema definido e você está livre para mais tarde ao descobrir que precisa colocar mais um sensor fazer algo assim:

Como se pode ver, o valor do segundo sensor foi simplesmente acrescentado aos novos registros armazenados. Isso pode ser feito indefinidamente e não apenas com o valor de outros sensores. Você pode adicionar qualquer outra informação ao registro que queira, como notas. Você faz o seu schema e isso é transparente para o banco de dados.
Além disso, como a única coisa que define a chave é que é um valor que só pode ocorrer uma vez no banco de dados, você pode perfeitamente usar o horário como chave:

Parece perfeito para a nossa aplicação, mas existe um problema. Segundo a IBM Cloud Education:

“Em geral, armazenamentos key-value não tem linguagem de consulta. Eles simplesmente proporcionam um modo de armazenar, recuperar e atualizar dados usando simples comandos GET, PUT e DELETE. A simplicidade deste modelo torna um armazenamento key-value rápido, fácil de usar, escalável, portável e flexível.”

Então com satisfazer o requerimento de poder fazer buscas no banco? De acordo com DB-Engines, o mais popular SGBD com suporte a chave-valor é o Redis:

Este parece suportar buscas, mas após uma verificação superficial da documentação não conseguimos uma resposta clara de como fazer o tipo de busca que desejamos.

Armazenamento de Documentos

Esse nome pode dar a impressão inicial que essa categoria objetiva armazenar arquivos do Word, Excel, AutoCAD, etc. Os arquivos que nós geralmente chamaríamos de “documentos” em um computador. Mas não se trata disso. No contexto dos bancos de dados um documento pode ser algo tão simples quanto a seguinte linha de texto:

{“Temperatura1”:”22.4”}

De acordo com DB-Engines, o mais popular SGBD orientado a documentos é o MongoDB:

Em teoria você pode armazenar o documento em qualquer formato que queira, mas se você quer aproveitar as vantagens do NoSQL é prudente seguir formatos padronizados e cada SGBD tem suas preferências, sendo os mais comuns XML e JSON. Abaixo uma comparação simples dos dois formatos:

Como se pode notar o formato JSON é mais “natural”, mais fácil de ler e menos “verboso”, isto é: requer menos texto para transmitir a mesma informação. E de fato o mais popular SGBD NoSQL, o MongoDB, optou pelo JSON. E acabamos optando por esse também.

Os documentos não seguem nenhum schema rígido, por isso você pode a qualquer tempo adicionar novos campos ao documento, como no exemplo abaixo:

No exemplo nós simplesmente acrescentamos um campo a mais: temperatura2, mas novos campos podem ser acrescentados indefinidamente. Quanto ao nosso requerimento de fazer buscas nos dados, a documentação do MongoDB nesse aspecto é muito mais fácil de entender que a do Redis.

É importante notar que, mesmo usando JSON, document-store desperdiça muito espaço em comparação com um banco de dados relacional ou mesmo o modelo chave-valor por causa da alta repetição de informação. Por exemplo, digamos que desejamos apenas armazenar o valor em ponto flutuante de dois sensores no formato: “12,34” e que esse valor seja armazenado como string ASCII (cinco bytes por valor armazenado). Vamos considerar um “id” para identificar o registro, também string, com dois bytes:

Banco Relacional:

Cada registro ocupa 12 bytes

Agora, o mesmo registro codificado como JSON:

{
“Id”=”01”
“Sensor1”:”23,34”;
“Sensor2”:”23,45”;
}
Como cada caractere precisa ser contado, a mesma quantidade de informação ocupa agora (ignorando caracteres de quebra de linha) 47 bytes por registro.  Essa diferença só piora à medida que mais valores precisarem ser armazenados em cada documento. Em muitas aplicações essa diferença é irrelevante diante das vantagens, mas precisa ser levada em consideração onde espaço é problemático, como nas aplicações embarcadas. Espaço não será problema na nossa demonstração, pois mesmo na versão gratuita, com 500MB de espaço, o serviço escolhido pode suportar nossos requerimentos básicos por mais de três anos.

Podemos reduzir essa desvantagem no uso de espaço usando um formato binário de codificação como o BSON, mas em alguns casos BSON pode ocupar ainda mais espaço que JSON porque, de acordo com o FAQ “…adiciona informação extra aos documentos, como o comprimento das strings e subobjetos” e tem a desvantagem de não ser uma codificação legível por humanos.

Suporte a relações

Apesar de NoSQL se referir especificamente a bancos de dados não relacionais achar que você não pode armazenar relações em um bancos de dados NoSQL é um engano. Segundo a MONGODB, Inc: “Um equívoco comum é achar que bancos de dados NoSQL ou bancos de dados não-relacionais não armazenam dados de relacionamento bem. Bancos de dados NoSQL podem armazenar dados de relacionamento – eles apenas o fazem diferentemente de como é feito pelos bancos de dados relacionais. ”

Então não existe problema se futuramente nosso projeto necessitar de suporte a relações.

Diante do exposto, decidi pelo uso do modelo Armazenamento de Documentos com o MongoDB como SGBD.

Para demonstrar o uso de NoSQL irei usar um Arduino com dois sensores de temperatura publicando uma vez por minutos as temperaturas em um servidor NoSQL MongoDB Atlas e uma interface de usuário Windows onde se pode coletar e analisar esses dados. O projeto inteiro foi desenvolvido em três linguagens: javascript nos scripts Atlas, Delphi na aplicação Windows que fornece a interface gráfica com usuário e C++ no programa que roda no Arduino.

Nesta aplicação foi descartado o uso de um servidor de banco de dados NoSQL local porque reduziria sua utilidade. Dentre as opções online optamos pelo MongoDB por oferecer um serviço gratuito na forma do MongoDB Atlas. A única limitação dessa versão gratuita que afeta nossa demonstração é estar limitada a 500MB.

Próxima parte: Criando e configurando uma conta MongoDB Atlas