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 thiago.mb@pti.org.br, luis.iv@pti.org.br, gustavo.rv@pti.org.br e jourdain@pti.org.br 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