Rede de Sensores

Sistema IoT para Aquisição de Dados com REDIS e Linguagem GO – Parte III

Proposta de arquitetura de IoT para o módulo de aquisição de dados de sensores usando o Banco de Dados REDIS e a linguagem GO Modelagem de Dados

Parte III: Modelagem de Dados

Parte I   Parte II  Parte IV

Nesta sequência do artigo sobre o sistema de IoT para aquisição de dados, vamos falar sobre o REDIS e como será usado neste módulo do projeto.
O REDIS funcionará como um banco de dados auxiliar para o SGBD principal do sistema supervisório. A função principal do REDIS será a de armazenar os dados da rede de sensores para serem exibidos (e processados) em tempo (quase) real.
Devido ao seu excelente desempenho, o REDIS é ideal para esse tipo de aplicação e isso também vai poupar o BD principal do sistema.
No módulo do sistema supervisório, o REDIS terá outras funções não abordadas aqui.

Para quem não acompanhou o artigo anterior, veja aqui.

O Cenário

O cenário que queremos modelar é o seguinte: Vários sensores dispostos local ou remotamente vão enviar os dados de suas medições periodicamente para um servidor. A rotina coletora (GOLANG) irá armazenar os dados no REDIS para que a aplicação supervisória possa processar e apresentar as informações em um dashboard.

O que queremos armazenar dos sensores são apenas as seguintes informações:

    • Identificação do sensor que está enviando a informação;
    • A Data e hora de envio;
    • O Valor da medição.

As outras informações como, por exemplo, qual o tipo de sensor, localização, unidade de medida e outras NÃO são de responsabilidade do REDIS. Isso ficará a cargo da aplicação WEB supervisória.
A função do REDIS neste módulo é apenas ser rápido e desafogar a aplicação, então estamos deixando a complexidade para o sistema supervisório tratar.

Identificação do sensor: Este é o ID do sensor que é uma String composta de 3 letras e uma sequência numérica unidas pelo separador pipe (“|”).

Por exemplo:
♦ Um sensor de temperatura, não importa qual padrão ou modelo, poderá ter o ID “TMP|1”
♦ Um sensor de umidade poderá ter o ID “UMD|100” e assim por diante.

Obviamente, os IDs não se repetem, ou seja, não podem haver dois sensores com a mesma identificação, como em uma chave primária!
Para o REDIS, o ID do sensor é apenas uma chave burra e ele não sabe nada sobre ela, a não ser que é, possivelmente, única.

Data e hora de envio: Por questões de agilidade a data será armazenada no formato Unix Time Stamp.

Valor da medição: Essa é uma String armazenando um valor numérico. Da mesma forma o REDIS não sabe nada sobre esse valor, nem de onde ele vem.

Obs: O ID do sensor e sua medição são fornecidos pela placa microcontroladora na qual o sensor está conectado (Arduino, família e etc.). Já a data de envio é de responsabilidade da aplicação receptora desenvolvida na linguagem GO. Isso por questões de padronização e economia (as placas não necessitam possuir um módulo RTC).

Estrutura de Dados

Para quem trabalha com bancos de dados relacionais, pode estranhar a forma como os dados são armazenados e acessados no REDIS. Sobre isso Já indicamos nos artigos anteriores vários tutoriais, então vamos direto ao assunto…

Dentre as estruturas de dados disponibilizadas pelo REDIS, escolhemos as listas ligadas pois as operações de inserção e remoção no final da lista são extremamente rápidas, que é o que precisamos.

Vejamos, como exemplo, como seriam as operações de inserção e remoção da lista.

Supondo que, no dia “01/01/2020” às “01:00:05” horas o sensor de código “TMP|5” enviou o valor “25.25”.

A chave da nossa lista será simplesmente o ID do sensor. Portanto, teremos uma lista para cada sensor.
Convertendo a data para Unix, temos: “1577840405”. Então o comando para armazenar esse dados no fim da lista seria esse:

RPUSH TMP|5 1577840405|25.25

Para obter o último valor enviado pelo sensor “TMP|5”, emitimos o seguinte comando:

RPOP TMP|5

Conclusão

Alternativamente, por motivos de legibilidade, poderíamos representar os valores no formato JSON, procedimento muito comum no mundo REDIS que possui suporte para essa técnica.

Este capítulo foi curto, mas importante para facilitar o entendimento da parte final dessa série onde iremos colocar a mão na massa e desenvolver um exemplo usando o NodeMCU e WEBSockets.

Parte I   Parte II  Parte IV

Referências

 

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *