Monitoria do Canal da Piracema: Uso do MongoDB e do

Monitoria do Canal da Piracema:
Uso do MongoDB e do Node.js como parte da solução
Thiago Bitencourt, Luis Valdés, Gustavo Valiati e David Jourdain
[email protected] , [email protected] , [email protected] e [email protected]
Celtab – Centro Latino-americano de Tecnologias Abertas
www.celtab.org.br
– 18 de Julho de 2014 – Foz do Iguaçu/PR – Brasil
Abstract
We were questioned about what a kind of technology would the better one to
develop a whole system, integrating hardware and software (which means:
development framework, language, data base and web services) to RFID
system monitoring.
In a certain time of the process, were evaluated that the Node.js joint with
mongoDB would be the most consistent solution to integrate on that
development. And so we did.
Now, this article will describe some issues to justify why these technologies
are in use on the project, in detriment from other technologies, also
evaluated, but not totally adherent in a concept we considered: The closest
architecture to a "real time" concept, for system answers.
1o – Introdução
Os biólogos da Itaipu tem mantido sobre relativo controle dados referentes ao fluxo de peixes
sobre o canal artificial desenvolvido para permitir a manutenção do processo migratório,
alterado após a construção da barragem da Itaipu. Entretanto, a solução que encontra-se ainda
em uso atende parcialmente a este controle, bem como não garante a qualidade dos dados
coletados e não permite que a aferição feita possa garantir de que os dados coletados
representem a veracidade dos fatos.
Fator elementar: Neste modelo em uso, não há persistência de dados, cruzamento de dados ou
até mesmo um banco de dados que permita tal cruzamento de forma segura.
Sob este contexto, o Celtab foi acionado para elaborar um estudo e uma proposta de solução
que, após apresentada enquanto projeto, foi iniciado o desenvolvimento de protótipos para
atenderem a esta temática diária dos biólogos da Itaipu. Este artigo visa apresentar brevemente
a justificativa da escolha de parte das soluções adotadas no desenvolvimento. A saber: O banco
de dados e o web service.
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 1
2o – Contextualização da problemática
Quando a problemática foi trazida para o Celtab, foi nos apresentado de que o “problema” era a
monitoria dos peixes. Entretanto, após análise detalhada da problemática, ficou claro para a
equipe de pesquisadores que os peixes não eram o elemento principal da problemática.
Outrossim, a problemática real era a monitoria eficiente de dispositivos RFIDs.
Inicialmente, de um modelo e fabricante específico, para atender a uma necessidade
preexistente. Contudo, havia ficado claro para os pesquisadores de que esta solução deveria ser
pensada de forma a permitir a maior flexibilidade possível, fosse para a mudança de RFID, de
antenas e leitores, bem como sobre a problemática do armazenamento dos dados adquiridos a
partir da leitura dos RFIDs, bem como da melhor aderência aos aplicativos distintos a serem
desenvolvidos.
Mesmo que todo o desenvolvimento tenha sido pensado de forma modular (seja para que
diversos RFIDs ou leitores sejam assimilados na solução, seja para a adição de código para estes
novos dispositivos), a solução final deve ser considerada “como um todo”, com elementos
embarcados, e não como um produto segmentado, que não mantém a arquitetura planejada.
Alterações nesta arquitetura estável requisitam um volume considerável de retrabalho de
código.
3o – Levantamento de requisitos
Quando da avaliação dos requisitos a serem considerados para o estudo e a prototipagem de
uma solução que atendesse as demandas dos biólogos da Itaipu, o Celtab, sem receber claras
restrições, fosse para hardware ou para software, os pesquisadores avaliaram diversas soluções
que poderiam ser integradas ao projeto. De Julho/2013 a Novembro/2013, foram feitas
avaliações de diversos bancos de dados, SQL's e NoSQL's, assim como de tecnologias para web
services que fossem mais aderentes aos bancos de dados estudados. Apenas a partir de
Dezembro/2013 que MongoDB e Node.js começam a fazer parte da solução, depois de
avaliações comparativas com diversos bancos de dados.
Após a apresentação de proposta inicial, feita ao Comitê Gestor no dia 17/07/2013, a
coordenação técnica do Celtab também foi questionada, se haveria alguma limitação que
deveria ser considerada. A única limitação apresentada pelo coordenador técnico é que
deveriam ser observados o custo do protótipo final e o tempo de resposta do sistema como um
todo.
Tendo apenas estas restrições iniciais, foram avaliadas uma considerável gama de tecnologias
que pudessem ser aderentes ao conceito inicial proposto pela coordenação técnica do Celtab, e
que está contido no “Abstract”: “The closest architecture to a "real time" concept, for system
answers”.
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 2
4o – Desenvolvimento modular da solução
Para o projeto de monitoramento do canal da piracema, tendo como premissa o princípio do
desenvolvimento modular, para a criação de uma solução final integrada, um dos objetivos foi a
centralização dos dados em um servidor que se comunique diretamente com os pontos de
coleta de dados, para sincronização e monitoramento destes pontos de coleta, com o menor
tempo de resposta possível. Neste contexto, foram considerados diversos aspectos. Entre eles, o
banco de dados foi um dos principais.
Outro ponto considerado foi um servidor Web orientado a eventos, para elaboração de serviços
para o usuário final. Neste caso específico, os biólogos da Itaipu.
Por fim, foram avaliadas as linguagens de programação e frameworks a serem considerados no
processo de desenvolvimento.
Obs.: Cabe salientar que um dos fatores que também permeou todas as escolhas foi o de
que o resultado final deveria considerar o menor tempo de resposta entre unidade de
leitura e web service, assim como atender a um grande número de usuários e que solução
oferecida deveria atender a diversas problemáticas distintas, com campos de atuação
semelhantes. Pensando nisso, a solução a ser implementada foi pensada, estruturada e
desenvolvida para atender a outras realidades semelhantes em qualquer parte do mundo,
desde o início das atividades do projeto.
O problema abordado na Itaipu consiste em alguns pontos de coleta se comunicando com um
servidor, que será responsável pela centralização dos dados. Porém, em um ambiente mais
amplo, com milhares de pontos de coleta distribuídos remotamente, este mesmo sistema terá
que atender a uma demanda em expansão, e assim será, já que as tecnologias utilizadas
suportam expansão de maneira nativa (sem necessitar de nenhuma alteração) e sem perda de
desempenho.
De acordo com as características do projeto a ser desenvolvido e com os conhecimentos prévios
dos pesquisadores envolvidos, foram selecionadas as seguintes tecnologias. No ponto de
coleta, para desenvolver o sistema de monitoramento, foi utilizada linguagem de programação
C++ com framework Qt. No sistema servidor, foi utilizado Node.js, que é um Servidor Web
orientado a eventos e que utiliza a linguagem JavaScript como backend, e que tem como banco
de dados mais alinhado a persistência o MongoDB[1].
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 3
O Node.js possibilita a conexão com um grande número de pontos de coletas, simultaneamente,
sem perder performance. Esta tecnologia é utilizada para atender a grandes números de
conexões de maneira paralela, sem que uma conexão interfira na outra e sem que uma conexão
impossibilite que outras conexões aconteçam: Ou seja: Uma nova conexão sempre será aceita.
Isso porque todas as tarefas realizadas no Node.js são executadas paralelamente e de maneira
não bloqueante. Com isso, uma tarefa é enviada para execução e outra já é executada
paralelamente, sem que haja a necessidade de esperar o término da tarefa anterior.
O Node.js possibilita utilizar MongoDB como base de dados de maneira nativa. Tendo o Node.js
e o MongoDB trabalhando de forma integrada, a conexão e a manutenção dos dados acontece
de uma maneira muito mais simples e rápida. Essa característica por si só garante desempenho
ao trabalhar com dados sob persistência. Além disso, outras características pontuam a favor da
base de dados MongoDB junto com o Node.js, sendo elas:
• MongoDB é o banco de dados mais utilizado pela comunidade para desenvolvimento de
aplicações web. Em função disso existem muitos fóruns e documentação disponíveis
sobre desenvolvimento utilizando esta arquitetura. Um exemplo é o MEAN Stack que
fomenta o desenvolvimento de aplicações web utilizando MongoDB, Express, Angular.js e
Node.js[1].
• MongoDB é um bando de dados NoSQL orientado a documentos, o que possibilita o
crescimento dos dados armazenados sem perda de desempenho. Além disso, não precisa
ter um esquema fixo e permite uma configuração de escrita que otimiza a persistência
dos dados. Todas as informações relevantes a um determinado registro são persistidas
com apenas um comando para a base de dados[1];
• MongoDB permite a conexão e a gerência de muitas conexões simultâneas a mesma
base de dados, possibilitando a leitura e a escrita “ao mesmo tempo”, por conexões
distintas[1];
• Possibilita que a base de dados tenha um crescimento horizontal, através da utilização
de replica set. Em uma base de dados relacional convencional, conforme o número de
dados armazenados cresce, é necessário: + processamento, + armazenamento e +
memória na máquina onde a base de dados esta persistida. Portanto, quando a base de
dados é extremamente grande, é necessário equipamentos com grande poder
computacional e de custos relativamente altos (tanto para aquisição quanto para
manutenção). O replica set do MongoDB possibilita que os dados sejam distribuídos em
diferentes servidores de maneira fácil e de rápido acesso a cada ponto, e possibilita a
expansão da quantidade de dados sem acrescentar em complexidade e sem perder
performance. Essa característica permite ainda a alta disponibilidade dos dados
armazenados[1];
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 4
• Considerando que o MongoDB é orientado a documentos, a consulta dos dados é
otimizada. Todas as informações relevantes são armazenadas em um mesmo documento,
o que agiliza a recuperação das informações. Ou seja: Em uma base de dados relacional
para buscar todos os dados relacionados, seria necessárias várias consultas a base de
dados (o que se torna um problema quando a quantidade de dados é muito grande),
enquanto que, com MongoDB, uma única consulta traz todas as informações necessárias.
Este mesmo efeito acontece na inclusão e na alteração de dados[1].
Um dos objetivos considerados em cada um dos projetos de pesquisa é estudar e identificar as
melhores soluções para atender a um determinado problema e, devido as características e
possibilidades de expansão do projeto de monitoramento do canal da piracema, essas
tecnologias se mostraram capazes de atender as necessidades do projeto, da forma mais
robusta e que menos impacte no processo de expansão de seu uso.
5o – Custo da migração
O projeto de monitoramento do canal da piracema se encontra em uma fase avançada, com
protótipos sendo preparados para implantação nos cinco pontos de monitoramento, no canal da
piracema. O sistema servidor, responsável por se comunicar com os pontos de coleta e
centralizar os dados, já está preparado para ser implantado.
Para uma eventual alteração na base de dados será necessário um estudo, replanejamento e
reimplementação do sistema servidor, sem que isso possa garantir o mesmo grau de eficiência
estudado na proposta desenvolvida. Como já mencionado, o Node.js e o MongoDB interagem de
maneira nativa e, para utilizar uma nova base de dados, será necessário a utilização de um driver
para comunicação, o que eliminará o benefício da interação nativa entre ambos.
O MongoDB tem estrutura e características completamente distintas de banco de dados
relacionais convencionais. Portanto, para migrar a base de dados, será necessário reimplementar
a base de dados para que seja relacional e também será necessário reimplementar todos os
comandos de consultas, inserções e alterações de dados. Com isso, toda a parte de
comunicação e interação com a base de dados (além da própria base de dados em si) deverá ser
reimplementada.
É conveniente salientar de que, mesmo tendo sido desenvolvido de forma modular, devemos
considerar as tecnologias Node.js e o MongoDB como elementos embarcados da solução final.
Por isso, toda alteração que impacte em sua remoção também impactará no redesenho da
solução em si.
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 5
Foi considerada a execução de um benchmark para comparação entre bancos de dados
relacionais e NoSQL's. Entretanto, conforme diversas fontes salientam, por se tratarem de
métodos de armazenamento e chamada distintos, as comparações mediante apenas avaliação
do fator segurança de dados poderia ser tendenciosa, já que ambos apresentam robustez.
Quanto ao tempo de resposta, por conta da forma de acesso aos dados, bancos NoSQL's tendem
a ter um tempo de resposta consideravelmente menor, sem que isso represente demérito para
bancos SQL's, considerando de que bancos NoSQL's tem aplicabilidades específicas, distintas
de bancos SQL's[2].
Para realizar todas essas alterações, será necessário um tempo para estudos, definições,
implementações, testes e eventuais correções, sem que isso represente que esta modificação
oferecerá o mesmo tipo de desempenho.
6o – Contextualização do MongoDB
• MongoDB é um banco de dados NoSQL orientado a documentos o que facilita bastante o
crescimento dos dados armazenados já que não precisa ter um esquema fixo e permite
uma configuração de escrita que otimiza a persistência de dados, uma forma fácil de
explicar é que desativando o acknowledge of writes and journal writes é possível
escrever muitos dados por segundo recebendo os mesmos de centenas ou milhares de
usuários ao mesmo tempo, com isso a escalabilidade do sistema de armazenamento é
muito maior que outros bancos de dados existentes no mercado[3].
• O sistema de crescimento do MongoDB é um sistema horizontal, para ter uma
capacidade maior de armazenamento somente é necessário adicionar um novo Shard e
configurá-lo, esse novo Shard estará composto por um Replica Set de 3 ou mais Nodes,
cada shard pode estar fisicamente separado dos outros, permitindo a distribuição dos
dados a nível mundial, formando um sistema distribuído de persistência de baixo custo e
alta disponibilidade, em comparação com outros sistemas de bancos de dados
relacionais que somente podem crescer de forma vertical (supercomputadores com alto
custo de compra e manutenção)[4].
7o – Conclusão
Em concordância com solicitação efetuada mediante email no dia 15/07/2014, será feito o
devido planejamento e a modificação para adoção do PostgreSQL, para o protótipo.
Considerando o prazo executado para o desenvolvimento da aplicação, com os devidos enlaces
para o mongoDB e o Node.js, estimasse uma extensão na conclusão do produto final entre 4 a 6
meses[5].
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 6
Contudo, É conveniente salientar de que a solução final, com a modificação efetuada para uso
com o PostgreSQL, não estará plenamente aderente ao conceito inicial avaliado para a solução
final, apresentado no “Abstract”. Sob esta ótica, segue sendo o binômio “MongoDB + Node.js” o
mais aderente ao desenvolvimento iniciado, de acordo com todos os estudos feitos desde
Julho/2013. Inclusive, diversos autores acreditam e defendem tecnicamente de que o MongoDB
(ou melhor, NoSQL's) atende de forma mais efetiva, no que tange o tempo de resposta final,
permitindo um acréscimo fractal de dados, sem que haja risco de formação de “gargalo” para a
chamada aos dados[6].
Para alguns tipos específicos de serviços, como para uma rede social, esta forma de
manipulação de dados não se apresenta como a mais apropriada. Entretanto, para a coleta e o
acesso a dados, em uma estrutura equivalente ao campo de estudo (coleta de dados de RFID's
para a monitoria do fluxo migratório de peixes), NoSQL's se revelam soluções robustas, estáveis,
de rápida resposta e as mais indicadas para este fim[6].
REFERÊNCIAS
[1] Node.js and MongoDB
- http://mean.io
[2] MongoDB vs PostreSQL : Comparancy
- http://blog.pingoured.fr/index.php?post/2012/05/20/PostgreSQL-vs-MongoDB
- http://vschart.com/compare/postgresql/vs/mongodb
- http://db-engines.com/de/system/MongoDB%3BPostgreSQL%3BRedis
- http://dba.stackexchange.com/questions/57448/mongodb-performance-vs-postgresql-with-5-5-million-rows-documents
[3] Write Concern and Journaling
- http://docs.mongodb.org/manual/core/write-concern
[4] Vertical versus Horizontal scaling
- http://docs.mongodb.org/manual/core/sharding-introduction
[5] MongDB vs PostgreSQL, with node.js app
- http://stackoverflow.com/questions/18776088/mongodb-vs-postgres-in-a-nodejs-app
[6] When not use MongoDB
- http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Monitoria do Canal da Piracema: Uso do MongoDB e do Node.js como parte da solução
Pg 7