SGBD em embarcados: uma aplicação visando dados científicos · IZANDRO MONTEIRO METELLO...

UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTAÇÃO

COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM

BANCO DE DADOS

SGBD EM EMBARCADOS: UMA APLICAÇÃOVISANDO DADOS CIENTÍFICOS

IZANDRO MONTEIRO METELLO

CUIABÁ - MT

2016

UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTAÇÃO

COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM

BANCO DE DADOS

SGBD EM EMBARCADOS: UMA APLICAÇÃOVISANDO DADOS CIENTÍFICOS

IZANDRO MONTEIRO METELLO

Orientador: Prof. Dr. Roberto Benedito de Oliveira Pereira

Monografia apresentada ao Curso de Especializaçãoem Banco de Dados, do Instituto de Computaçãoda Universidade Federal de Mato Grosso, comorequisito para obtenção do título de Especialista emBanco de Dados.

CUIABÁ - MT

2016

Este trabalho é dedicado a todos que acreditaram

em mim e me ajudaram nos ultimos anos durante

essa difícil caminhada.

AGRADECIMENTOS

Agradeço a todos que me ajudaram a superar mais este desafio, eu não poderiame expressar de forma diferente. Agradeço ao professor Roberto que acreditou em mim,que me ajudou sempre que precisei, mesmo passando por dificuldades. Agradeço a todosque me deram uma segunda chance para poder concluir com sucesso mais esse passo naminha formação. Não posso deixar de agradecer a minha querida Alice que me apoiasempre. Agradeço também a minha família e minha mãe que sempre me ajuda apesar dosmeus erros. Aos amigos que sempre dão apoio e ideias e diminuem a dor das dificuldadesda vida.

RESUMO

A coleta de dados automatizada está presente em diversas atividades humanas. Seja paraatividades que possam colocar a vida de um ser humano em perigo, redução do gasto derecursos, melhoria de processos ou outras aplicações possíveis, pode-se utilizar sistemasembarcados em conjunto com sensores para a coleta de dados de forma automatizada.Dados provenientes de coleta tem um ou alguns dos seguintes propósitos: descrição,explicação ou predição. A descrição de cenários, a busca de explicações ou prediçõesbaseadas na compreensão da causa de eventos podem ser dependentes de coleta de dados.Com o crescente aumento de necessidade e oportunidade de coleta de dados visandoaplicações científicas, este trabalho busca demonstrar a aplicação de SGBD em dadoscaracterísticos de medições e monitoramento científico. Diversos fatores como qualidadee disponibilidade de comunicação, necessidade de disponibilidade imediata dos dados evolume de dados vão influenciar no tipo de arquitetura e qual SGBD será utilizado. Osestudos de caso foram feitos com o SGBD dentro de um computador embarcado quefaz ou recebe dados de coleta. Foram analisados um SGBD relacional e um NoSQL,MySQL e Redis respectivamente, em diversas fases desde a configuração dos ambientesaté a manipulação dos dados de medições simulados. Pode-se perceber a diferença dasarquiteturas dos SGBDs nos estudos de caso. Para realizar os experimentos foram utilizadoso pcDuino 1 e o Raspberry Pi 2. Ambos contêm processadores de arquitetura ARM, porémnão são iguais em velocidade, núcleos de processamento e outras características. Algumasdessas diferenças de arquitetura foram percebidas nos estudos de caso. Os estudos de casosugerem que a configuração escolhida para gerenciar dados de aplicações de coleta dedados depende de características específicas da aplicação e da necessidade de cada casoem particular já que cada SGDB mostrou pontos favoráveis e desfavoráveis nos estudosrealizados.

Palavras-chaves: Banco de Dados. Sensores. NoSQL.

ABSTRACT

Automatized data gathering makes part of various parts of human life. Whether it beactivities poses a person life at risk, resource spending reduction, processes improvementsor many other applications possibles, it is possible to use embedded systems along withsensors in automatized data gathering. Data provided by gather has one or more purpose:description, explanation or prediction. A scenery description, the search for explicationsor predictions based on comprehension of the causes of events can be dependents of datagathering. As the need and opportunity of data gathering is increasing, this study aims showa DBMS in management of usual scientific data. The study cases have been done withDBMS inside the embedded computer which gathers metering data. It has been analyzed arelational DBMS and a NoSQL DBMS, MySQL and Redis respectively, in various stagessince the enviroment setup to the data handling in study cases. It has been possible observethe architectural differences in study cases results. To run the experiments it has been useda pcDuino 1 and a Raspberry Pi 2. Both have ARM architecture processors, however theyhaven’t the same speed nor same amount of processing cores, among others differences.Some of those differences have been seen in the study cases results. The study cases haveshown the best configuration to be chosen for an application is particular to that applicationas each DBMS have shown upsides and downsides in the study cases.

Keywords: Databases. Sensors. NoSQL.

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . 5

2.1 Sistemas Gerenciadores de Banco de Dados . . . . . . . . . . . . 62.2 SGBDs relacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 SGBDs não relacionais . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . 14

3.1 Equipamentos utilizados . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Preparação do ambiente de pesquisa . . . . . . . . . . . . . . . . . 173.3 Armazenamento utilizado . . . . . . . . . . . . . . . . . . . . . . . 183.4 Preparação e configuração dos SGBDs . . . . . . . . . . . . . . . . 183.5 Características da massa de teste . . . . . . . . . . . . . . . . . . . 193.6 Carga dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7 Consulta dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 213.8 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . 24

4.1 Estudo de caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.1 Inserção de 1 milhão de elementos no pcDuino 1 . . . . . . . . . . . . 244.1.2 Inserção de 1 milhão de elementos no Raspberry Pi 2 . . . . . . . . . 254.1.3 Inserção de 25 milhões de elementos no pcDuino . . . . . . . . . . . 264.1.4 Inserção de 25 milhões de elementos no Raspberry Pi 2 . . . . . . . . 264.1.5 Tabela de resultados do estudo de caso 1 . . . . . . . . . . . . . . . . 274.2 Estudo de caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.1 Consultas em 1 milhão de elementos no pcDuino . . . . . . . . . . . . 284.2.2 Consultas em 1 milhão de elementos no Raspberry Pi 2 . . . . . . . . 294.2.3 Consultas em 25 milhões de elementos no pcDuino . . . . . . . . . . 304.2.4 Consultas em 25 milhões de elementos no Raspberry Pi 2 . . . . . . . 304.2.5 Tabelas com os resultados do estudo de caso 2 . . . . . . . . . . . . . 31

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . 34

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A GERADOR DE DADOS DE MEDIÇÃO DE SENSORES . . . . . . 37

B SCRIPT LUA DE CONSULTA NO SGBD REDIS . . . . . . . . . . 41

LISTA DE ILUSTRAÇÕES

Figura 1 – pcDuino 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figura 2 – Raspberry Pi 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figura 3 – Inserção de 1 milhão de registros no pcDuino 1 no Redis. . . . . . . . 24Figura 4 – Inserção de 1 milhão de registros no pcDuino 1 no Redis. . . . . . . . 25Figura 5 – Inserção de 1 milhão de registros no Raspberry Pi no Redis. . . . . . . 25Figura 6 – Inserção de 1 milhão de registros no Raspberry Pi 2 no MySQL. . . . 25Figura 7 – Tamanho dos arquivos do MySQL após inserção de 1 milhão no Rasp-

berry Pi 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 8 – Inserção de 25 milhões de registros no pcDuino no MySQL. . . . . . . 26Figura 9 – Inserção de 25 milhões de registros no Raspberry Pi 2 no MySQL. . . 26Figura 10 – Tamanho dos arquivos do MySQL após inserção de 25 milhões no

Raspberry Pi 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 11 – Uso de memória do Redis Server durante a tentativa de inserção. . . . 27Figura 12 – Uso de memória durante a tentativa inserção no Redis. . . . . . . . . . 27Figura 13 – Consulta de máximo e mínimo no pcDuino e Redis. . . . . . . . . . . 28Figura 14 – Consulta com condições e intervalos no pcDuino e Redis. . . . . . . . 28Figura 15 – Consultas com condições e intervalos no pcDuino e MySQL. . . . . . 29Figura 16 – Consulta de maior e menor no Raspberry Pi 2 e Redis. . . . . . . . . . 29Figura 17 – Consulta com condições e intervalos no Raspberry Pi 2 e Redis. . . . . 29Figura 18 – Consultas com condições e intervalos no Raspberry Pi 2 e MySQL. . . 30Figura 19 – Consultas com condições e intervalos no pcDuino e MySQL. . . . . . 30Figura 20 – Consulta com condições e intervalos no Raspberry e MySQL. . . . . . 31

LISTA DE TABELAS

Tabela 1 – Configuração do computador embarcado pcDuino 1. . . . . . . . . . . 15Tabela 2 – Configuração do computador embarcado Raspberry Pi 2. . . . . . . . 16Tabela 3 – Configuração da estrutura de dados utilizada no Redis. . . . . . . . . . 19Tabela 4 – Configuração das colunas do MySQL. . . . . . . . . . . . . . . . . . 20Tabela 5 – Gravação de dados média após ligar. . . . . . . . . . . . . . . . . . . 27Tabela 6 – Consulta de dados - leitura dos valores máximos e mínimos. . . . . . . 31Tabela 7 – Consulta de dados - busca com intervalos de valores. . . . . . . . . . 31

LISTA DE QUADROS

Quadro 1 – Configuração do ’datadir’ do MySQL. . . . . . . . . . . . . . . . . . 19Quadro 2 – Estrutura dos dados no arquivo de "mass insertion"do Redis. . . . . . 20Quadro 3 – Comando ’SET’ do Redis no modo ’Mass Insertion’. . . . . . . . . . 20Quadro 4 – Criação da tabela de armazenamento dos dados de medições simulados. 21Quadro 5 – Comando utilizado para inserir dados no MySQL. . . . . . . . . . . 21Quadro 6 – Sequência de comandos para inserir dados com ’Mass Insertion’ do

Redis e inserir dados no MySQL. . . . . . . . . . . . . . . . . . . . 21Quadro 7 – Comando para executar o script Lua e medir o tempo gasto no servidor

Redis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Quadro 8 – Condições da consulta do segundo estudo de caso. . . . . . . . . . . 22Quadro 9 – Condições para consulta de maior e menor. . . . . . . . . . . . . . . 22Quadro 10 – Consulta SQL utilizada no segundo estudo de caso. . . . . . . . . . . 22Quadro 11 – Consulta SQL utilizada no segundo estudo de caso. . . . . . . . . . . 22

LISTA DE ABREVIATURAS E SIGLAS

ACID Atomicity, Consistency, Isolation, Durability

API Application Programing Interface

ARM Advanced RISC Machine

BASE Basically Available, Soft state, Eventual consistency

CLI command-line interface

CPU Central Processing Unit

DDL Data Definition Language

DML Data Manipulation Language

GCC GNU Compiler Collection

GPS Global System Position

mA mili-Ampére

NoSQL Not Only SQL

RAM Random-Access Memory

Redis Remote DIctionary Server

SGBD Sistema Gerenciador de Banco de Dados

SQL Structured Query Language

USB Universal Serial Bus

XML eXtensible Markup Language

XQuery XML Query

1

CAPÍTULO 1

INTRODUÇÃO

A coleta de dados por sensores está presente em diversas atividades humanas.Atividades como previsão do tempo, exploração extraterrestre, suporte a atividades cientí-ficas, conforto residencial, segurança, hospitalares, industriais e inúmeras outras são, cadavez mais, auxiliadas por coleta de dados.

Dados provenientes de coleta tem um ou alguns dos seguintes propósitos:descrição, explicação ou predição (KUMAR, 1988). Os dados descritivos respondemperguntas como “quem? ”, “o que? ” e “quando?”, mas não perguntas como “como?” ou“por que?”. Uma explicação necessita uma extrapolação de um relacionamento causa eefeito, no qual o investigador tenta entender por que um fenômeno, processo ou eventoaconteceu ou não. Predições são baseadas no entendimento da causa de eventos. Dados sãocoletados para esses fins e em aplicações científicas a coleta de dados pode ser essencialpara todo o processo de pesquisa, para identificar um problema, auxiliar na solução ouembasar uma teoria.

Sensores associados a unidades de processamento são cada vez mais utilizados(EVANS, 2011) para executar coleta automatizada de dados. Esses sistemas são importan-tes pois executam a coleta na maior parte das vezes com mais facilidade e precisão que umhumano, e a um custo menor. Ainda pode-se considerar os lugares aos quais os humanos

Capítulo 1. Introdução 2

não podem acessar como ambientes com radiação ou amostragens de alta frequência, porexemplo.

Dada a importância de sistemas de coleta de dados, este trabalho busca apre-sentar formas de gerenciar os dados armazenados em sistemas de coleta de dados voltadospara aplicações científicas.

Para verificar onde e como um banco de dados para sistemas embarcadospodem auxiliar o processo de coleta de dados é necessário mencionar o papel que outrastecnologias tem nas aplicações de análise de dados e como elas podem influenciar nautilização de bancos de dados em sistemas de coleta.

Sistemas de coleta de dados em geral são compostos por sistemas embarcadosdedicados exclusivamente a essa tarefa. Podem ter ou não acesso à internet. A energiapode originar da rede elétrica, baterias descartáveis ou alguma combinação de alimentaçãoexterna com bateria recarregável. A autonomia pode variar de dias até anos. O tipode amostragem pode ser desde baixa frequência e baixa resolução até amostras de altafrequência e alta resolução. Existem sistemas que não podem atrasar no processo de coletae entrega da informação e tem que ser extremamente previsíveis (hard real-time ou softreal-time). Com a diversidade de aplicações e avanços tecnológicos existem incontáveisaplicações com características variadas.

Compreendendo que existe uma variedade muito grande de sistemas de medi-ção, alguns casos podem tirar proveito de um armazenamento local dos dados de coletagerenciados por um banco de dados.

Para imaginar o impacto da conectividade à Internet em sistemas de coleta,serão nomeadas características de conexões como velocidade, disponibilidade e custo.Dentro dessas características, pode-se analisar se o dado coletado consegue chegar aodestino (velocidade e/ou disponibilidade), e com que custo. As atividades de coleta podemnecessitar de uma transmissão ainda em tempo real (aplicações médicas) ou de grandesvolumes de dados (coleta de imagens).

Se não houver algum tipo de conexão disponível ou sem todas as característicasnecessárias para fazer os dados da coleta chegarem ao destino ainda é possível utilizaroutros meios para transferí-los. Pode-se periodicamente transportar os dados por unidadesde armazenamento ou coleta-los manualmente com algum equipamento para esse fim.Porém esses meios simplesmente não atendem atividades que necessitam de transmissõesem tempo real, por exemplo. Para as aplicações que o armazenamento local dos dadospode substituir ou auxiliar conexão com a Internet para transmitir os dados coletados,pode-se utilizar bancos de dados.


Outro componente que está presente em sistemas embarcados de coletas au-tomatizadas são unidades de processamento. O constante aumento na capacidade deprocessamento aumenta as possibilidades de coleta de dados. Dessa forma, pode-se adicio-nar um armazenamento local de dados. Com os dados armazenados localmente, é possívelrealizar algum processamento prévio ou gerar estatística e/ou feedback para melhorar aprópria coleta de dados, por exemplo. Esse crescimento então aumenta as possibilidadesdo sistema de coleta.

A eficiência energética de sistemas de coleta baseados em sistemas embarcadosestá constantemente aumentando. Em conjunto com a melhora constante de baterias, exis-tem alguns cenários recorrentes: dispositivos que usam muito pouca energia e funcionampor mais tempo (chegando a mais de um ano) ou dispositivos que aproveitam a eficiênciaenergética e aumentam muito a capacidade de processamento. Pode-se ter situações derestrição de energia e necessidade de reduzir transmissões dos dados de medidoções, mascom um armazenamento local a atividade pode continuar, com as transmissões sendo feitasposteriormente.

Dependendo do tipo de configuração de sistema de medição utilizado, o equi-pamento sequer tem um sistema operacional como pode ter recursos semelhantes a compu-tadores pessoais. No primeiro caso, são equipamentos embarcados extremamente simplesque podem não dispor de recursos para sustentar um SGBD. Pela simplicidade da arquite-tura pode não compensar o custo de desenvolvimento e manutenção. No segundo caso,equipamentos embarcados com mais recursos disponíveis, pode-se utilizar um SGBD.

Quando a integração da aplicação de coleta é feita com o SGBD para arma-zenamento de dados locais, podemos adicionar características como maior segurança edisponibilidade dos dados, melhor recuperação, dentre outras vantagens de se utilizar umSGBD.

Espera-se apresentar e testar métodos de gerenciamento de dados característi-cos de sensores visando aplicações científicas. Os objetivos específicos são:

1. Investigar as tendências tecnologias de SGBD

2. Comparar a performance de sistemas embarcados com alguns SGBD investigados

3. Aplicar dois tipos de conjunto de dados para testar os sistemas embarcados e osSGBD.

4. Realizar teste de leitura e acesso, para avaliar desempenho tanto dos sistemasembarcados como dos SGBD.


Este estudo pode contribuir na discussão de como os dados de um sistema decoleta serão gerenciados em função de recursos disponíveis, configuração do sistema e osresultados que se buscam atingir.

Nesta introdução buscou-se descrever a importância da coleta de dados não sópara fins científicos, mas para várias atividades humanas atualmente. Além disso, foramdemonstrados alguns vários cenários e tecnologias dos quais alguns o uso de SGBD paraarmazenamento local beneficia a atividade de coleta de dados. Por fim, os objetivos queorientam esta pesquisa.

No capítulo 2, Revisão de Literatura, serão levantados conceitos e teoriarelativo à SGBDs em geral, como eles podem ajudar e sobre os dois utilizados nosexperimentos. Dada a ligação entre sistemas de coleta de dados exposta na introdução,serão abordados alguns conceitos relativos à sistemas embarcados.

No capítulo 3, Materiais e Métodos, serão descritos todos os componentesfísicos e de software selecionados para os testes. Além disso, será descrito como foramfeitos os testes.

No capítulo 4, Estudos de Caso, serão apresentados os testes feitos com osrespectivos parâmetros. No capítulo 5, Resultados, serão discutidos os resultados dosEstudos de Caso.

No capítulo 6, Trabalhos Futuros, busca-se levantar partes desta monografiaque podem ser ainda mais explorados.

O capítulo seguinte, a Conclusão, serão revistas as hipóteses iniciais compara-das aos resultados.

CAPÍTULO 2

FUNDAMENTAÇÃO TEÓRICA

A utilização de um SGBD (Sistema Gerenciador de Banco de Dados) trazimpactos positivos e negativos decorrentes da combinação das variáveis de característicasdo SGBD em si, de sua arquitetura e da aplicação.

Sistemas de coleta automatizada de dados científicos podem ser construídosutilizando Sistemas Embarcados. Um sistema embarcado é definido pela sua aplicação,pois tendem a ser equipamentos com função bem definida. Ao variar a aplicação, mudam-sejunto os recursos e atributos do equipamento.

Considerando essas combinações, temos cenários favoráveis ou não a utilizaçãode um SGBD para gerenciar dados localmente em um sistema de coleta automatizado.Neste capitulo serão apresentados os conceitos necessários para evidenciar as principaisvariáveis dos elementos envolvidos neste experimento e como as mesmas podem influenciarna aplicação.

Serão abordados conceitos gerais sobre SGBDs dos tipos relacionais e NoSQL.Em seguida referências sobre sistemas embarcados, dado que o mesmo tem influência nautilização ou não de SGBD em uma aplicação de coleta.

Capítulo 2. Fundamentação Teórica 6

2.1 Sistemas Gerenciadores de Banco de Dados

Um SGBD é um sistema computadorizado para armazenar registros, segundo(DATE, 2004). Bases de dados estão presentes em computadores de diferentes escalas,desde pequenos sistemas embarcados até clusters de mainframes. É normalmente utilizadapara o software que gerencia a base de dados, enquanto a denominação banco de dados oubase de dados se refere ao conjunto de dados gerenciado (DATE, 2004).

A automação do processamento de dados é mais antiga que os próprios com-putadores. Silberchatz (SUDARSHAN., 2004) afirma que cartões perfurados, inventadospor Herman Hollerith foram usados no começo do século 20 nos Estados Unidos paraarmazenar dados de censo. Sistemas mecânicos foram usados para processar os cartões eapresentar os resultados.

Com a evolução dos meios de armazenamento e processamento, entre asdécadas de 50 e 60, fitas magnéticas foram usadas para armazenamento de dados. Comofitas tem forma de acesso sequencial, os dados tinham que ser acessados ou modificadosde forma sequencial.

Desde o fim dos anos 60 até os anos 70, houve a disseminação do uso dodisco rígido, a utilização de vários discos, o uso de sistemas de arquivos e aumento nasvelocidades de transferência por conta de novos materiais e processos de fabricação. Alémdisso, o modelo de acesso aleatório alterou a forma como os dados eram acessados emodificados (SPELIOTIS, 2000).

Nos aos 80 foi criado o modelo relacional de dados que foi implementado noSystem R da IBM, que desenvolveu técnicas eficientes de construção de bases de dadosrelacionais.

No início dos anos 90, a linguagem SQL foi escolhida para aplicações desuporte a decisão, que fazem muitos acessos ao banco de dados. As bases de dadospassaram a ter que oferecer suporte a uma taxa muito alta de processamento de transações,além de ser mais confiáveis, manter disponibilidade 24x7 e suportar dados de interfaceWeb. SQL fornece vários recursos como DDL (Data-Definition Language) para trabalharcom esquemas e relacionamentos por exemplo, DML (Data Manipulation Language) parafazer consultas, apagar, inserir ou modificar tuplas no banco, controles de integridade,geração de visões, controle transacional, permissões de acesso, e outros.

No começo da década 2000, houve a adoção do XML em associação com alinguagem XQuery como nova tecnologia de consulta. Nesse período também houve umcrescimento na utilização de SGBDs open-source como o PostgresSQL e o MySQL.


No fim da década de 2000, houve o crescimento de SGBDs especializados emanalises de dados, como os column-store. Novos sistemas de armazenamento de dadosdistribuídos foram construídos para ter capacidade para análise de dados de sites comoAmazon.

Com o passar do tempo, as mudanças de hardware, capacidade de processa-mento e armazenamento, velocidades de conexões, dados disponíveis e necessidades/opor-tunidades influenciaram o desenvolvimento dos SGBDs. Verificamos que esse processoteve duas vias: o desenvolvimento de recursos gerou espaço para mudanças e as neces-sidades também levaram ao desenvolvimento e popularização de outras tecnologias deSGBDs.

2.2 SGBDs relacionais

SGBDs relacionais foram desenvolvidos nos anos 70 como uma tecnologiapara armazenar dados estruturados organizados como tabelas com sua própria linguagem –o SQL (OUNALLI, 2012).

Segundo (SUDARSHAN., 2004), um SGBD relacional é baseado no modelorelacional e usa uma coleção de tabelas para representar os dados e os relacionamentosentre esses dados. O tipo relacional de SGBD é hoje em dia o principal utilizado nomercado.

Uma base relacional consiste em um conjunto de tabelas. As tabelas têmvárias colunas e cada coluna tem um único nome. Em geral uma linha representa orelacionamento entre um conjunto de valores e são chamadas de tuplas. O esquema deuma base relacional contém os atributos, tipos e regras das relações como chaves primáriase estrangeiras.

As tuplas podem ter um atributo do tipo chave primária, que é a identificaçãoúnica e não repetida daquele registro. Essas chaves podem ser referenciadas por outrosregistros, por meio de um atributo do tipo chave estrangeira.

Uma característica dos SGBDs e linguagens relacionais é a implementação daálgebra relacional. Ela define um conjunto de operações:

1. Seleção - retorna as linhas que satisfazem a condição de seleção;

2. Projeção - retorna atributos específicos de todas as linhas da entrada da relação.Remove as linhas duplicadas da saída;

3. Natural join - retorna os pares de linhas de duas entradas que tem o mesmo valor emtodos os atributos que tem o mesmo nome;


4. Produto cartesiano - retorna todos os pares de linhas de duas relações de entradasindependente de ter os mesmos nomes ou valores em comum;

5. União - retorna a união de tuplas de duas relações.

Linguagens como o SQL, utilizadas para fazer operações nas bases de dados,são baseadas em álgebra relacional que provê vários recursos para gerar as consultas. SQLé a linguagem relacional mais influente do mercado.

2.2.1 MySQL

O MySQL é um SGBD do tipo relacional que implementa um padrão SQL,com algumas extensões. Foi comprado pela Sun Microsystems em 2008 (WIDENIUS,2008) e é parte da Oracle que ao comprar a Sun Microsystems comprou todos os seusprodutos também. O MySQL tem como pontos positivos um suporte bom dos usuários nosfóruns e grande e bem detalhada documentação. É um SGBD com baixo overhead, o quepermite a execução em computadores com poucos recursos de memória e processamento.

Porém, a capacidade de execução e armazenamento do SGBD será propor-cional à arquitetura de hardware e software que o executa. O MySQL é um SGBDopen-source, e o banco de dados, dependendo da arquitetura de execução e mecanismo dearmazenamento, pode chegar a ter até 64TB de tamanho (MYSQL, 2015).

É escrito em C e C++, e tem compatibilidade com arquiteturas de hardwareSPARC 64, SPARC 32, x86, x86 64, IA64, e ARM. É possível acessar o banco de dadospor meio de uma interface CLI (command-line interface – interface de linha de comando)ou pelo Connector/ODBC. Existe APIs para C, C++, Eiffel, Java, PHP, Python, Ruby eTcl.

O MySQL disponibiliza algumas opções de armazenamento das bases de dados(MYSQL, 2015):

1. InnoDB: o mecanismo padrão de armazenamento do MySQL. É compatível comACID, e dispõem de recursos como commit e rollback. É o mais indicado paraser usado na maioria das aplicações, por ter alto desempenho e operar de formatransacional.

2. MyISAM: é uma forma de armazenamento mais simples. A trava para escrita emnível de tabela limita o desempenho para operações que envolvem leitura e escrita.

Existem outros mecanismos de armazenamento, porém ou tem uso muitorestrito ou estão em desuso, como CSV, Archive, Federated e Merge. Outro exemplo é


o mecanismo de armazenamento Memory, que guarda os dados na memória RAM e deacordo com o manual está caindo em desuso. O mecanismo InnoDB pode ser configuradocom buffers que podem em alguns casos substituir o Memory, e ainda com a vantagem depersistir os dados em um armazenamento não volátil.

2.3 SGBDs não relacionais

Com o constante aumento dos dados armazenados e analisados, os SGBDsrelacionais estão apresentando várias limitações. As consultas aos dados estão perdendoa eficiência pelo grande volume de dados. Esse volume de dados está crescendo cadavez mais por conta da evolução constante das tecnologias de captura de informação, deprocessamento e da inteligência para dar significado a tudo isso. Abramova (ABRAMOVA;BERNADINO; FURTADO, 2014) afirma que o NoSQL foi desenvolvido para superaralgumas dessas limitações das bases de dados atuais.

Os bancos NoSQL são representados pela não existência de uma estrutura dedados rígida comparado ao SQL. É possível ter num mesmo espaço de armazenamentoobjetos com membros diferentes. Isso não acontece no SQL, onde todos os registros têmque seguir o modelo das colunas da tabela onde estão inseridos. O conceito de NoSQLfoi usado pela primeira vez em 1998 por Carlo Strozzi (ABRAMOVA; BERNADINO;FURTADO, 2014) para se referir a um banco que não usa interface SQL.

Os bancos NoSQL são normalmente baseados no teorema BASE (BasicallyAvailable, Soft State and Eventually consistente) (VIEBRANTZ;, 2012). Os bancos relacio-nais são representados pelo ACID (Atomicidade, Consistência, Isolamento e Durabilidade).Diferente do ACID, o BASE sacrifica um pouco da consistência dos dados para ganhardesempenho. Essa troca é descrita pelo teorema CAP: (Consistency, Availability, Partitiontolerance). Segundo (BROWNE, 2015), teorema CAP diz que somente é possível ter duasdas três características ao mesmo tempo.

Apesar de não ser possível consultar dados usando SQL, esta abordagempermite fácil armazenamento e consulta de dados independente da estrutura do conteúdo(ABRAMOVA; BERNADINO; FURTADO, 2014). Bancos NoSQL também demonstrammelhor escalabilidade horizontal (EVANS, 2011). Isso significa que servidores de baixocusto podem satisfazer as requisições, enquanto os custos são reduzidos. O gerenciamentodesse grande volume de dados seria difícil, porem essas bases de dados são projetadaspara gerenciá-los automaticamente, recuperar de falhas e consertar o sistema por completo(STOLERU;, 2010).


Os bancos NoSQL são caracterizados por não existir relações entre diferentesregistros. Porém, de acordo com otimizações, eles podem ser divididos em (INDRAWAN-SANTIAGO, 2012):

• Key-Value: Nesse tipo de base de dados os dados são armazenados como paresde chave e valor. O acesso ao valor armazenado é feito pela chave, que é única.Bases de dados do tipo chave-valor são adequadas para aplicações que processamtransações em uma chave por vez, e executam muitas leituras.

• Document Store: Uma base do tipo Document-Store armazena documentos e atribuiuma chave a estrutura armazenada. Além disso, essas informações são armazenadascomo XML ou JSON, guardando mais informações sobre a estrutura do dado,comparado a bases do tipo chave-valor.

• Column Family: Bases de dados da família de colunas tem como característicatabelas que podem ter muitas colunas, mas com mais flexibilidade para se adicionaroutras colunas em produção.

• Graph Database: Uma base do tipo grafo usa grafos para representar o seu esquema.Diferente das bases relacionais, o importante são as tuplas e suas coleções que sãoas relações. O relacionamento entre tuplas individuais é definido por uma chaveestrangeira. Numa base de grafos, tanto a relação como os relacionamentos sãoimportantes.

NoSQL é uma tecnologia disruptiva e pode ser usada como complemento ousubstituta para os bancos relacionais. Atualmente existem mais de 150 bancos NoSQL (??).Cattell (CATTELL, 2010) afirma que uma das maiores diferenças entre bancos NoSQL ebancos relacionais (RDBMS) é que o NoSQL separa armazenamento de gerenciamento,enquanto RDBMS tenta satisfazer os dois.

2.3.1 Redis

O SGBD Redis é um banco de dados do tipo in-memory, chave-valor com acapacidade de persistir os dados no sistema de arquivos. O nome Redis significa RemoteDIctionary Server (REDISLAB, 2015). Apesar de oferecer a possibilidade de persistência,o banco de dados de uma instância do Redis não pode ser maior que a memória RAM.Porém, como o conjunto de dados está por completo na memória RAM, as operações nobanco de dados sendo feitos diretamente na RAM e o desempenho do banco de dadosaumenta muito.

Outra vantagem, além do ganho de desempenho, é a facilidade de trabalharcom estruturas complexas na memória, comparado a trabalhar com esse mesmo tipo de


dado no disco. Uma das aplicações desse SGBD, sugerida pelo desenvolvedor, é utiliza-lopara vários dados pequenos com muitas operações de escrita.

Como a base de dados fica inteiramente contida na memória RAM, se faznecessário utilizar mais computadores para aumentar a memória total da base de dados.Na documentação do Redis isso pode ser alcançado com um recurso chamado Partitioning.O processo é feito dividindo o grupo de chaves entre as instâncias do SGBD. É possíveldividir pelos níveis de valores das chaves ou por um cálculo modular do hash da chave,por exemplo.

Existem algumas desvantagens ao fazer essa divisão na base de dados: opera-ções que envolvem múltiplas chaves não são suportadas diretamente se as chaves estãoem diferentes instância. O back-up dos arquivos de persistência em banco deve ser feitopara todas as instâncias e adicionar ou remover nós de instâncias pode ser complexo.Uma sugestão feita pela documentação é desde o início já utilizar um valor grande denós no cluster Redis. Uma instância do SGBD utiliza cerca de 1MB, então é possível jáestabelecer um número como 64 nós mesmo que não for necessário. Porém, ao configurara base de dados desde o começo assim, o crescimento do cluster é mais simples.

O desenvolvedor afirma (http://redis.io/topics/data-types-intro) que o Redisnão é um SGBD chave-valor no sentido literal, pois também suporta estrutura de dadosmais complexas que simples conjuntos chave-valor. Os tipos disponíveis são:

1. Binary-Safe strings.

2. Listas encadeadas que armazenam elementos de acordo com inserção.

3. Conjuntos ordenados que têm elementos associados a um valor chamado score quepode auxiliar em consultas.

4. Hashes são mapas compostos por campos associados a valores, onde ambos sãostrings.

5. Bit array ou bitmaps onde cada bit de uma string pode ser manipulado individual-mente.

6. Hyperloglogs que são estruturas probabilísticas e são usadas para estimar a cardina-lidade de um conjunto.

Os comandos de operação dependem de cada estrutura que está sendo utilizada.Os comandos e as operações podem ser enviados por meio de integração de uma bibliotecacom a aplicação que deseja se comunicar com o servidor Redis ou por meio da CLI doRedis.


O servidor do Redis é capaz de executar scripts utilizando um interpretadorLua integrado. Desse modo, é possivel fazer algumas operações mais complexas nãodisponíveis por meio dos comandos internos do Redis. Isso acontece por conta de o Redisser focado em consultar e armazenar os dados e não dispor de uma linguagem de consultacomo SQL.

A tecnologia de construção do Redis prove acesso extremamente rápido aosdados, porém a natureza do armazenamento e acesso dos dados é bem diferente dosSGBDs relacionais tradicionais. Isso traz características que podem ser ou não vantajosasdependendo da aplicação.

2.4 Sistemas Embarcados

Barr 2007 define sistemas embarcados como combinações de hardware, soft-ware e em alguns casos partes adicionais, focados na realização de uma tarefa especÍfica.(KOOPMAN, 1996) afirma que além de uma CPU e uma memória, existem várias interfa-ces que permite ao sistema medir, manipular ou até interagir com o ambiente.

O software gravado em um sistema embarcado geralmente tem uma funçãofixa, e é específica para a aplicação. Sistemas embarcados tem como elemento central eprincipal microcontroladores na grande maioria dos equipamentos.

Um microcontrolador é um chip que contém várias estruturas que o faz se-melhante a um computador (SOUSA, 2006). Há uma unidade de processamento lógica,memórias e unidades periféricas. Dado seu tamanho geralmente reduzido, é ideal paraaplicações que requerem portabilidade.

Em muitos casos, realizam medições e ou atuam de alguma forma sobre oambiente em que se encontram. Têm como característica a restrição de recursos, comoenergia, memória, processamento, tamanho, etc.

Podem ser classificados como soft real time ou hard real-time. Soft real-timesão sistemas que, caso tenha alguma resposta atrasada, não compromete gravemente outraz prejuízos à atividade. Sistemas hard real-time são sistemas embarcados de aplicaçãocrítica, como controles de aeronaves, marca-passo, airbags de automóveis, por exemplo.

Cada aplicação tem, portanto, um sistema customizado para atender as neces-sidades com eficiência. Isso faz esses equipamentos possuirem muitas variações, desdeprocessadores com velocidades na casa dos MHz até processadores com vários núcleos evários GHz, por exemplo.


São exemplos de sistemas embarcados: Fornos micro-ondas, celulares, calcu-ladoras, relógios digitais, mísseis, receptores GPS, monitores cardíacos, impressoras laser,computadores de bordo de carros, câmeras digitais, controles remotos, dentre outros.

2.5 Resumo

Foram verificados vários assuntos que tem influência ou fazem parte dosestudos de caso. Os SGBDs são uma parte muito importante de uma grande quantidadede sistemas computacionais, sejam eles de pequeno ou de grande porte. Eles podem serde vários tipos como chave-valor, relacionais, de colunas, de grafos e outros. Os estudosde caso utilizam dois tipos: relacionais e chave-valor. Por isso foi dado ênfase nessesdois tipos de SGBDs. Os computadores embarcados utilizados têm características desistemas embarcados, primáriamente restrição de recursos. Restrição de recursos e outrascaracterísticas de sistemas embarcados pode impactar diretamente na forma de se utilizarSGBDs.

14

CAPÍTULO 3

MATERIAIS E MÉTODOS

Com o objetivo de analisar o comportamento e o desempenho de SGBDsgerenciando dados locais de coleta, foram selecionados dois computadores embarcados:pcDuino1 e Raspberry Pi 2. O primeiro não é tão popular quanto o segundo e existemalgumas diferenças entre as arquiteturas.

Os SGBDs escolhidos foram o MySQL e o Redis. Como exposto na Revi-são de Literatura, a utilização de ambos é importante pelo primeiro ser muito utilizadocomo produto e arquitetura, contrapondo o segundo que representa um tipo diferente dearquitetura e aplicações.

O conjunto de dados escolhido visa utilizar uma estrutura recorrente em apli-cações de coleta científica. O volume de dados foi configurado para avaliar desempenho epossíveis limites. Todas essas variáveis serão descritas a seguir.

3.1 Equipamentos utilizados

O pcDuino1 (figura 1) contém um processador de 1Ghz da arquitetura ARMv7. É necessário especificar o modelo pois existem outras versões. É uma plataforma demini PC econômica e de alta performance que roda sistemas operacionais como Ubuntu eAndroid.

Capítulo 3. Materiais e Métodos 15

É possível liga-lo a um monitor por meio de sua porta HDMI. Além disso écompatível com o ecossistema popular do Arduino, como os Shields do Arduino (pode sernecessário um Shield de ponte) e projetos open-source. O sistema operacional utilizado,Ubuntu 12.04, foi instalado na memória Flash de 2GB.

Para os experimentos que serão realizados não será necessário utilizar osrecursos de conexão com Shields de Arduino. A conexão com a internet é feita pormeio de rede cabeada conectada a LAN RJ45. Não é necessário utilizar dissipadores nomicrocontrolador. A Tabela 1 descreve algumas características do hardware do pcDuino 1.

Item DetalhesCPU 1GHz ARM Cortex A8GPU OpenGL ES2.0, OpenVG 1.1 Mali 400 coreMemoria 1GByteArmazenamento Integrado 2GB Flash, microSD card (TF) de até 32GBSaída de Vídeo HDMISOs suportados Linux3.0 + Ubuntu 12.04 Android ICS 4.0Interface de Extensão Conjunto de pinos de 2.54mm semelhante aos do ArduinoInterface de Rede 10/100Mbps RJ45 e adaptador USB WiFi (não incluso)Energia recomendada 5V, 2000mADimensões 125mm X 52mmPreço 38 USD

Tabela 1 – Configuração do computador embarcado pcDuino 1.

Figura 1 – pcDuino 1

O outro sistema utilizado foi o Raspberry Pi 2 B+. O Raspberry Pi 2 é umaplataforma de mini PC popular utilizada em milhares de projetos. Esse é um dos váriosprojetos da onda de hardwares open source iniciada pelo Arduino. Os modelos existentessão o Raspberry Pi, Raspberry Pi 2, e mais recentemente o Raspberry Pi 3.


Dentre esses modelos, alguns tem variações A e B, relacionadas a característi-cas físicas como tamanho e conectores disponíveis. O modelo utilizado nos experimentos,o Raspberry Pi 2 B+, possui um processador Broadcom de arquitetura ARM v7 CortexA7 com quatro núcleos de 900MHz. Esse processador tem 1GByte de memória RAMseparada do chip. Tem saídas HDMI, 4 USB 2.0 e um slot micro SD. A placa não temarmazenamento interno e o sistema operacional é instalado em um cartão de memória noslot micro SD. A conexão com a internet é feita por meio da interface LAN ou adaptadoresUSB.

Adicionalmente, a placa tem conexões para display, câmera e áudio vídeocomposto por meio de um conector de 3,5 mm. Essas últimas não serão necessárias paraos estudos de caso. O sistema operacional instalado foi o Raspibian que é derivado doDebian. A tabela 2 lista algumas características do Raspberry Pi 2.

Item DetalhesCPU 900MHz quad-core ARM Cortex-A7 CPUGPU VideoCore IV 3D graphics coreDRAM 1GB RAMArmazenamento Integrado slot para microSD cardSaída de Vídeo e audio HDMI e 3,5mm com video e audio integradosSOs suportados Noobs, Raspibian, AndroidInterface de Rede 10/100Mbps RJ45 e adaptador USB WiFi (não incluso)Energia recomendada 5V, 2000mAConexões adicionais 4x USB 2.0, camera e displayDimensões 85mm x 56mmPreço 35 USD

Tabela 2 – Configuração do computador embarcado Raspberry Pi 2.


Figura 2 – Raspberry Pi 2

3.2 Preparação do ambiente de pesquisa

Foi feito nos dois computadores embarcados (pcDuino 1 e Raspberry Pi 2)uma instalação nova do sistema operacional.

No caso do pcDuino 1, os passos seguidos se encontram no link: http://learn.linksprite.com/pcduino/quick-start/steps-to-flash-ubuntu-images-to-pcduino/. O guia in-dica dois arquivos para ser copiados: um para um cartão de memória com o software de có-pia de arquivos de imagem de disco para unidades de armazenamento “win32diskimager”,que é um kernel do Linux que vai em inicializar a placa; o outro é uma imagem compactadaque deve ser colocada em um pendrive para o instalador concluir o procedimento.

No caso do Raspberry Pi 2, os procedimentos seguidos foram seguidos doseguinte guia: https://www.raspberrypi.org/documentation/installation/installing-images/windows.md. Esse guia sugere a utilização também do “win32diskimager”. Após fazer odownload do sistema operacional desejado, disponível na seção de downloads do mesmosite, utiliza-se o “win32diskimager” para gravar a imagem do disco de instalação para ocartão de memória. Em seguida, insere-se o cartão no Raspberry 2 e ao liga-lo a instalaçãocomeça automaticamente. O sistema operacional instalado foi o Raspibian.

Ambas as placas têm instalação relativamente simples e rápida. No casodo pcDuino ocorre apenas um passo a mais no início, mesmo assim, ainda pode serconsiderado sem muito obstáculo. A reinstalação dos sistemas operacionais foi feita paraos Estudos de Caso sofrerem o mínimo de interferência de outros programas, que no casoestavam instalados anteriormente.


3.3 Armazenamento utilizado

Para reduzir o impacto da unidade de armazenamento nos experimentos, seráutilizado a mesma nas duas placas embarcadas. Tirando proveito do fato de ambas asplacas terem portas USB 2.0, será utilizado para todos os testes a mesma unidade USBmass storage de 8GBytes.

Essa decisão foi tomada por conta da diferença do armazenamento do pcDuino1e do Raspberry Pi 2: o primeiro tem o sistema operacional dentro da memória flash daplaca, enquanto o segundo tem o sistema operacional instalado em um cartão de memóriamicro SD. O sistema de arquivos é o Ext4, formatado com o utilitário Disks disponível noUbuntu.

Esse sistema de arquivos foi utilizado por conta da compatibilidade com oscomputadores embarcados e as aplicações. Porém, para disponibilizar os scripts de inserçãoaos computadores embarcados foi utilizado um pen-drive de 8 GBytes com sistema dearquivo FAT.

3.4 Preparação e configuração dos SGBDs

Os procedimentos seguidos para instalar o Redis foram os disponíveis na pró-pria página do produto http://redis.io/download. Os procedimentos são fazer o download,extrair o arquivo compactado baixado e com o comando ‘make’ compilar o software.

Não é necessário para a maior parte dos casos nenhuma biblioteca adicional.Foi utilizado o GCC 4.6.3 no pcDuino 1 e no Raspberry Pi 2 o GCC 4.8.4. Em ambos sãoos compiladores que vêm por padrão com os respectivos sistemas operacionais. A versãodo Redis utilizada é a 3.2.0 que até a presente data é a mais recente estável.

No caso do MySQL o cliente e o servidor estão disponíveis nos repositóriosdos computadores embarcados utilizados. Foi utilizado no pcDuino e no Raspberry Pi 2 ogerenciador de pacotes disponível ‘apt-get’. A versão disponível nos repositórios é a 5.5.

Para trocar os arquivos da base de dados do local padrão no SGBD MySqlde “/var/lib/mysql” que fica na unidade de armazenamento do sistema operacional foiutilizado os passos (o diretório que representa o pen-drive é ’mysql’) descritos no quadro1.


Cria-se a pasta no diretório raiz do sistema operacional “ / ”:mkdir /mysqlEm seguida, é necessário montar a unidade USB de armazenamento que será utilizada:mount /dev/sda1 /mysql/É necessário copiar a pasta “mysql” de “/var/lib/” para o pendrive:cp –R /var/lib/mysql /mysql/mysqlE para ser permitida a execução posteriormente:chown –R mysql.mysql /mysql

Quadro 1 – Configuração do ’datadir’ do MySQL.

3.5 Características da massa de teste

Foi utilizado como referência, para configurar as estruturas de dados, o modeloproposto por (MEIJER, 2012). Nesse modelo é feito um comparativo entre SGBDs dostipos NoSQL e SQL. As estruturas construídas para ambos os bancos de dados armazenamas seguintes informações: idMedicao, idSensor, tempoMedicao, valorMedicao.

No Redis foi feita no modelo da tabela 3. Essa estrutura é armazenada utili-zando o HMSET no Redis. Os dados de medições simuladas foram formatados em umscript de inserção padrão SQL, para gravá-los no MySQL. No caso do Redis foi tambémgerado um script de inserção automática utilizando o recurso Mass Insertion. Uma amostrade ambos está disponível nos anexos. A geração foi feita em um computador com sistemaoperacional Windows, com um programa feito em C++ disponível em anexo. A amostrasforam geradas de maneira a ter elementos equivalentes para ambos os SGBDs para que ascomparações gerem os mesmos resultados nas consultas.

Nome do campo ValorMedicao "numero"Idmedidor "id"horaMedicao "hora de medição"valorMedicao "valor de medição"

Tabela 3 – Configuração da estrutura de dados utilizada no Redis.

No MySQL as colunas idMedicao, idSensor e tempoMedicao foram confi-guradas com o tipo BigInt. O valorMedicao é do tipo decimal que por padrão tem 10dígitos base 10 sem casa decimal. Para o escopo dos estudos de caso não será utilizadatoda a capacidade de armazenamento dessa estrutura, porém ela foi selecionada paraaumentar a dificuldade de processamento. Para cada SGBD foi criado então uma estruturade armazenamento correspondente. No caso do MySQL foi criada uma tabela, com asseguintes colunas (tabela 4):


Nome coluna TipoidMedicao bigint unsigned not null auto_increment primary keyidSensor Bigint unsigned not nulltempoMedicao Bigint unsigned not nullvalorMedicao decimal

Tabela 4 – Configuração das colunas do MySQL.

3.6 Carga dos dados

No Redis foi utilizada a interface Mass Insertion, disponível no cliente “redis-cli”. Essa interface permite a inserção de uma maior quantidade de dados em menos tempoe com menos recursos comparada a inserção manual ou comando por comando, como ditopelo fabricante do software (http://redis.io/topics/mass-insert). Os dados são gerados nomodelo no quadro 2.

*$

...

Quadro 2 – Estrutura dos dados no arquivo de "mass insertion"do Redis.

No quadro 2: * é o número de argumentos do comando, é umcaractere nova linha, $ é a quantidade de caracteres do próximo argumento e é um argumento do comando. Por exemplo o comando de inserção “SET chave valor” nopadrão Mass Insertion pode ser visto no quadro 3.

*3 -> três parâmetros$3 -> três caracteres do primeiro parâmetro

SET -> primeiro parâmetro$5 -> cinco caracteres do segundo parâmetro

chave -> Segundo parâmetro$5 -> cinco caracteres do terceiro parâmetro

valor -> terceiro parâmetro

Quadro 3 – Comando ’SET’ do Redis no modo ’Mass Insertion’.

Com o arquivo criado pelo programa de geração que está no apêndice A, pode-se fazer a inserção também no terminal do computador embarcado. Para medir o tempo deexecução, foi utilizado o comando ’time’ disponível no Linux para executar o comando deinserção descrito no quadro 6.


O procedimento para inserir os dados no MySQL foi a geração de um scriptcom vários comandos “INSERT” para ser processado pelo cliente do MySQL e inserir osdados na tabela correspondente. Inicialmente foi necessário criar uma database e a tabelaque recebe os dados como descrito no quadro 4.

CREATE DATABASE dadosColetados;CREATE TABLE IF NOT EXISTS dadoscoletados(idMedicao BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,idSensor BIGINT UNSIGNED NOT NULL,tempoMedicao BIGINT UNSIGNED NOT NULL,valorMedicao DECIMAL NOT NULL,PRIMARY KEY (idMedicao));

Quadro 4 – Criação da tabela de armazenamento dos dados de medições simulados.

Foi utilizado para tanto um arquivo de texto SQL com sucessivos comandos“INSERT INTO”. Para executar o script que faz as inserções sucessivas pode-se utilizar oseguinte comando no terminal do computador embarcado como descrito no quadro 5.

mysql -u root -p “database” < “/endereço/scriptinserçãoSQL.sql”

Quadro 5 – Comando utilizado para inserir dados no MySQL.

Uma configuração adicional foi feita nos arquivos de inserção do MySQL:todas as operações de “INSERT INTO” foram colocadas entre os comandos “STARTTRANSACTION;” e “COMMIT;”. Esses comandos fazem todas as alterações pertencerema uma transação.

Os comandos ficaram no seguinte formato para o Redis:time –p cat “dadosmassinsertion.txt” | redis-cli –pipe e para o MySQL

time -p mysql -u root -p “database” < “/endereço/scriptinserçãoSQL.sql”

Quadro 6 – Sequência de comandos para inserir dados com ’Mass Insertion’ do Redis einserir dados no MySQL.

3.7 Consulta dos dados

Para executar o script Lua que faz as consultas e filtragens foi utilizado ocódigo descrito no quadro 7.

time -p ./redis-cli eval "$(cat script.lua)"0

Quadro 7 – Comando para executar o script Lua e medir o tempo gasto no servidor Redis.


Esse comando além de executar o script dentro do servidor retorna o tempo deexecução. O trecho de código Lua utilizado para fazer a filtragem por intervalo de valores,sensor e intervalo de tempo está descrito no quadro 8. O script completo está no apêndiceB.

if tonumber(mytable[’valormedicao’]) > 59000 andtonumber(mytable[’valormedicao’]) < 59200 and

mytable[’idmedidor’] == ’000004’ andtonumber(mytable[’horamedicao’]) > 990000 andtonumber(mytable[’horamedicao’]) < 993468 then

– executa acaoend

Quadro 8 – Condições da consulta do segundo estudo de caso.

Para listar os valores maior e menor foi utilizado o código Lua do quadro 9.

if tonumber(mytable[’valormedicao’]) > maior thenmaior = tonumber(mytable[’valormedicao’])

endif tonumber(mytable[’valormedicao’]) < menor then

menor = tonumber(mytable[’valormedicao’])end

Quadro 9 – Condições para consulta de maior e menor.

As consultas equivalentes em SQL no MySQL estão descritas nos quadros 10e 11.

SELECT * from dadoscoletados where idSensor = 4 and valorMedicao > 59000 andvalorMedicao < 59200 and tempoMedicao > 990000 and tempoMedicao < 993468;

Quadro 10 – Consulta SQL utilizada no segundo estudo de caso.

SELECT MIN(valorMedicao) AS min, MAX(valorMedicao) AS max FROMdadoscoletados;

Quadro 11 – Consulta SQL utilizada no segundo estudo de caso.

3.8 Resumo

Neste capítulo buscou-se descrever os detalhes dos estudos de caso: os com-putadores embarcados utilizados, os sistemas operacionais e suas respectivas instalações,unidades de armazenamento utilizadas e seus preparos, geração das massas de teste e


características, a carga das massas de teste em ambos os SGBDs avaliados e por fim aconsulta dos dados. Durante o processo de configuração, verificou-se que ambos os SGBDstêm grandes diferenças nos modos de configuração e operação.

24

CAPÍTULO 4

RESULTADOS E DISCUSSÕES

4.1 Estudo de caso 1

No primeiro estudo de caso foi feita a carga dos dados e a medida do tempo decada carga por SGBD por computador embarcado testado. Foram testados dois tipos decargas: 1 milhão de elementos e 25 milhões de elementos.

4.1.1 Inserção de 1 milhão de elementos no pcDuino 1

Executando o testes no pcDuino 1 com o arquivo de 1 milhão de registros doRedis as medições foram 54,68 segundos (figura 3). O arquivo dump.rdb ficou com 96MB. O arquivo de inserção utilizado tem 149 MB.

Figura 3 – Inserção de 1 milhão de registros no pcDuino 1 no Redis.

Capítulo 4. Resultados e discussões 25

Para o SGBD MySQL no pcDuino, utilizando o arquivo de inserção com 1milhão de registros, os dados foram inseridos em 400,66 segundos (figura 4).

Figura 4 – Inserção de 1 milhão de registros no pcDuino 1 no Redis.

4.1.2 Inserção de 1 milhão de elementos no Raspberry Pi 2

No Raspberry Pi 2, o tempo de carga de 1 milhão de elementos no Redisdemandou 59,05 segundos (figura 5). O arquivo dump.rdb ficou com 96 MBytes. Oarquivo de texto de inserção tem 149 MBytes.

Figura 5 – Inserção de 1 milhão de registros no Raspberry Pi no Redis.

No mesmo computador embarcado, foi executada uma carga de dados dessavez no MySQL utilizando um arquivo com 1 milhão de elementos. O tempo para completara operação foi 407,4 segundos (figura 6). O arquivo de inserção de dados ficou com 70MBytes e a pasta com os dados do SGBD ficou com 93 MBytes (figura 7).

Figura 6 – Inserção de 1 milhão de registros no Raspberry Pi 2 no MySQL.


Figura 7 – Tamanho dos arquivos do MySQL após inserção de 1 milhão no Raspberry Pi2.

4.1.3 Inserção de 25 milhões de elementos no pcDuino

Executando o script de inserção de 25 milhões de elementos no pcDuinoutilizando o SGBD MySQL os tempos de inserção foi 9937,95 (figuras 8). O arquivo deinserção de dados ficou com 1,8 GBytes e a pasta com os dados do SGBD ficou com 1,7GBytes.

Figura 8 – Inserção de 25 milhões de registros no pcDuino no MySQL.

4.1.4 Inserção de 25 milhões de elementos no Raspberry Pi 2

Executando o script de inserção de 25 milhões de elementos no Raspberry Pi2 utilizando o SGBD MySQL o tempo de inserção foi 10800,72 segundos (figura 9). Oarquivo de inserção de dados ficou com 1,8 GBytes e a pasta com os dados do SGBD ficoucom 1,7 GBytes (figura 10).

Figura 9 – Inserção de 25 milhões de registros no Raspberry Pi 2 no MySQL.


Figura 10 – Tamanho dos arquivos do MySQL após inserção de 25 milhões no RaspberryPi 2.

Ao fazer a mesma operação no Raspberry Pi 2 com o SGBD Redis, a partirde um certo ponto de inserção dos 25 milhões de elementos houve uma sequência defalhas (figuras 11 e 12). Isso ocorreu por conta do limite de armazenamento do Redisestar ligado ao tamanho da memória RAM de onde ele é executado, como descrito nareferência bibliográfica. Não foi possível encerrar os processos de inserção e do SGBD, foinecessário reiniciar o sistema. Após o reinicio, verificou-se o tamanho maxímo do arquivodump.rdb com 296 MBytes.

Figura 11 – Uso de memória do Redis Server durante a tentativa de inserção.

Figura 12 – Uso de memória durante a tentativa inserção no Redis.

4.1.5 Tabela de resultados do estudo de caso 1

Na tabela 5 é mostrado um resumo os resultados do Estudo de Caso 1.

SGBDpcDuino Raspberry Pi 2

1 milhão 25 milhões 1 milhão 25 milhõesMySQL 400,66 s 9937,95 s 407,4 s 10800,72 sRedis 54,68 s erro 59,05 s erro

Tabela 5 – Gravação de dados média após ligar.


4.2 Estudo de caso 2

No segundo estudo de caso buscou-se fazer consultas com resultados equivalen-tes no Redis e no MySQL nos computadores embarcados. Para verificar o desempenho dascombinações de computadores embarcados, SGBDs e cargas de dados foram construídasduas consultas que podem ser utilizadas em ambos os SGBDs. A forma como as consultasforam criadas foi descrita no capítulo 3.

4.2.1 Consultas em 1 milhão de elementos no pcDuino

Consultando o conjunto de 1 milhão de dados em no SGBD Redis, na consultade máximo e mínimo o tempo gasto foi 146,36 segundos (figura 13). A consulta deintervalo de valores de medição levou 150,01 segundos para ser concluída (figura 14).

Figura 13 – Consulta de máximo e mínimo no pcDuino e Redis.

Figura 14 – Consulta com condições e intervalos no pcDuino e Redis.

Consultando o conjunto de 1 milhão de dados em no SGBD MySQL, naconsulta dos valores máximos e mínimos o tempo gasto foi 4,19 segundos (figura 15). Aconsulta de intervalo de valores levou 3,65 segundos para ser concluída (figura 15).


Figura 15 – Consultas com condições e intervalos no pcDuino e MySQL.

4.2.2 Consultas em 1 milhão de elementos no Raspberry Pi 2

Consultando o conjunto de 1 milhão de dados em no SGBD Redis, na consultade máximo e mínimo o tempo gasto foi 192,3 segundos (figura 16). A consulta de intervalode valores de medição levou 192,56 segundos para ser concluída (figura 17).

Figura 16 – Consulta de maior e menor no Raspberry Pi 2 e Redis.

Figura 17 – Consulta com condições e intervalos no Raspberry Pi 2 e Redis.


Consultando o conjunto de 1 milhão de dados em no SGBD MySQL, naconsulta dos valores máximos e mínimos o tempo gasto foi 3,88 segundos (figura 18). Aconsulta de intervalo de valores levou 3,29 segundos para ser concluída (figura 18).

Figura 18 – Consultas com condições e intervalos no Raspberry Pi 2 e MySQL.

4.2.3 Consultas em 25 milhões de elementos no pcDuino

Consultando o conjunto de 25 milhão de dados em no SGBD MySQL, naconsulta dos valores máximos e mínimos o tempo gasto foi 182,97 segundos (figura 19).A consulta de intervalo de valores levou 168,58 segundos para ser concluída (figura 19.

Figura 19 – Consultas com condições e intervalos no pcDuino e MySQL.

4.2.4 Consultas em 25 milhões de elementos no Raspberry Pi 2

Consultando o conjunto de 1 milhão de dados em no SGBD MySQL, naconsulta dos valores máximos e mínimos o tempo gasto foi 190,8 segundos. A consulta deintervalo de valores levou 171,51 segundos para ser concluída (figura 20).


Figura 20 – Consulta com condições e intervalos no Raspberry e MySQL.

4.2.5 Tabelas com os resultados do estudo de caso 2

A tabela 6 mostra um resumo das consultas de valores máximos e mínimosdos conjuntos de amostras e em seguida a tabela 7 mostra um resumo do tempo consumidopara uma consulta específica nos conjuntos de amostras.


1 milhão 25 milhões 1 milhão 25 milhõesMySQL 4,19 s 182,97 s 3,88 s 190,8 sRedis 146,36 s N/A 192,3 s N/A

Tabela 6 – Consulta de dados - leitura dos valores máximos e mínimos.


1 milhão 25 milhões 1 milhão 25 milhõesMySQL 3,65 s 168,58 s 3,29 s 171,51 sRedis 150,01 s N/A 192,56 s N/A

Tabela 7 – Consulta de dados - busca com intervalos de valores.

32

CAPÍTULO 5

CONCLUSÕES

Verificou-se que para sistemas embarcados com maiores recursos como osdois computadores embarcados utilizados é possível utilizar SGBDs para gerenciar dadosde origens como sensores.

O pcDuino 1 e o Raspberry Pi 2 tiveram desempenhos semelhantes em todasas tarefas. As diferenças ficaram apenas no tempo de execução das operações e ambos osSGBDs apresentados e avaliados mostraram-se capazes de realizar quase todas as tarefaspropostas de armazenar uma quantidade de dados e fazer consultas neles.

No caso do MySQL, foi possível armazenar os conjuntos de 1 milhão deregistros e 25 milhões de registros. No caso do Redis, por ser um SGBD primariamentein-memory, não foi possível inserir e trabalhar um conjunto de 25 milhões de elementos.O conjunto de 1 milhão de elementos, porém não teve problemas: foi feita a inserção e asconsultas satisfatóriamente.

Analisando os resultados verifica-se que o Redis foi muito mais rápido do queo MySQL para fazer a gravação dos dados utilizando o mass-insert, levando menos de 20%do tempo para executar a operação com o conjunto de 1 milhão de registros. Por outrolado, para consultar o MySQL foi muito mais rápido que o Redis, levando menos de 10%do tempo para executar as operações de consulta no conjunto de 1 milhão de registros.

Capítulo 5. Conclusões 33

Pela arquitetura do Redis, que é um SGBD chave-valor primariamente, con-sultas mais complexas podem ser muito caras computacionalmente. A arquitetura deletanto favorece acesso direto a um registro que para executar consultas equivalentes às doMySQL foi necessário utilizar-se do recurso de execução de script Lua no servidor Redis,não tendo no cliente "redis-cli"ferramentas para consultas com condições atuando sobre osdados membros dos registros. Já o MySQL fornece suporte a consultas mais complexasque simples consultas de valor de chaves.

Com base nesses resultados, quando não for necessário ou com pouca frequen-cia fazer consultas complexas, o SGBD Redis pode ser o mais indicado. Caso contrário oMySQL é extremamente rápido ao fazer consultas com varias condições ou se necessitarfazer junções. Uma característica que difere o Redis do MySQL é a flexibilidade nas estru-turas de dados: no Redis é possível ter objetos com membros diferentes automaticamenteenquanto no MySQL uma vez definidas as tabelas elas não aceitam colunas a mais semreconfiguração ou migração. Um problema que o Redis apresenta em relação ao MySQLé apenas trabalhar dentro da memória RAM, ou seja, não existe nenhum mecanismo depaginação. Isso foi demonstrado na prática ao fazer a inserção de 25 milhões de elementose o computador travou.

Analisando as diferenças de tempos de execução entre o MySQL e o Redis nosdois computadores embarcados verifica-se que o Redis foi mais rápido no pcDuino que temum núcleo de 1 GHz e o MySQL foi mais rápido no Raspberry Pi 2 que tem quatro núcleosde 900 Mhz. É possível dizer que o Redis seja mais sensível a diferença de processadorespor conta de executar primariamente apenas na memória RAM. O MySQL suportou melhorum grande conjunto de dados, comparado ao Redis. Foi possível manipular quase 2 GBytesde dados nas tabelas e aparentemente esse não é o limite nos computadores embarcados.

A adoção de um SGBD ou de nenhum em uma aplicação de coleta de dadosfica a cargo então da própria aplicação.

34

CAPÍTULO 6

TRABALHOS FUTUROS

Vários pontos desta pesquisa podem ser explorados como uma investigação douso de dados originados de sensores e não simulados como foi o caso. Outro aspecto aser investigado é a possibilidade de as característica dos dados de medições influenciarna escolha de um SGBD. Não foi levado em consideração a integração do SGBD comoutra aplicação ou serviço para gerenciar os dados. Dependendo de como o SGBD seráintegrado com outras partes de um sistema maior pode influenciar na escolha de se ter ounão um SGBD e qual deles utilizar.

Outras características que foram citadas que devem ser investigadas são restri-ções e características do sistema ao qual um computador embarcado com o SGBD estarásituado. Características como restrição de energia ou acesso meios de comunicação vãoinfluenciar na configuração do caminho dos dados de sensores.

Redes de coleta de dados de diferentes sensores podem também ser alvo depesquisa: a partir de que ponto, por exemplo, um SGBD NoSQL vai ser mais vantajosoque um relacional ao se trabalhar com dados heterogêneos. Outra característica que podeser explorada são estudos sobre a alteração dos dados, visto que este trabalho focou naconsulta.

35

REFERÊNCIAS

ABRAMOVA, V.; BERNADINO, J.; FURTADO, P. Experimental evaluation of nosqldatabases. International Journal of Database Management Systems, v. 6, n. 3, jun. 2014. 9

BARR, M. Embedded systems glossary. 2007. 04-21 p. Disponível em: . 12

BROWNE, J. Brewer’s CAP Theorem. 2015. Disponível em: . 9

CATTELL, R. Scalable sql and nosql data stores. SIGMOD, v. 39, n. 4, 2010. 10

DATE, C. J. Database Systems. 8. ed. [S.l.]: Addison-Wesley, 2004. 6

EVANS, D. The internet of things - how the next evolution of the internet is changingeverything. Cisco Internet Business Solutions Group (IBSG)., 2011. 1, 9

INDRAWAN-SANTIAGO, M. Database research: Are we at a crossroad? 15thInternational Conference on Network-Based Information Systems, 2012. 10

KOOPMAN, P. Embedded system design issues (the rest of the story). IEEE. ComputerDesign: VLSI in Computers and Processors ICCD-96. Proceedings., p. 310–317, 1996. 12

KUMAR, D. J. C. K. The Collection, Analysis, and Use of Monitoring and EvaluationData. [S.l.]: World Bank Publication, 1988. 1

MEIJER, J. S. van der Veen; Bram van der W. R. J. Sensor data storage performance: Sqlor nosql, phisical or virtual. IEEE Fifth International Conference on Cloud Computing,2012. 19

MYSQL. MYSQL -The Main Features of MySQL. 2015. 8

OUNALLI, I. F. H. Towards a flexible database interrogation. IJDMS, v. 4, n. 3, 2012. 7

REDISLAB. REDIS. 2015. Disponível em: . 10

http://www.barrgroup.com/Embedded-Systems/Glossary-Ahttp://www.barrgroup.com/Embedded-Systems/Glossary-Ahttp://www.julianbrowne.com/article/viewer/brewers-cap-theoremhttp://www.julianbrowne.com/article/viewer/brewers-cap-theoremhttp:/redis.io

Referências 36

SPELIOTIS, D. E. Magnetic recording beyond the first 100 years magnetic recordingbeyond the first 100 year. In: THIC Meeting at the Naval Surface Warfare Center. [S.l.:s.n.], 2000. 6

STOLERU;, S. M. G. W. Z. H. C. M. W. Y. O. L. A. P. R. Distressnet: A wireless ad hocand sensor network architecture for situation management in disaster response. IEEECommunications Magazine., 2010. 9

SUDARSHAN., A. S. H. F. K. S. Database System Concepts. 8. ed. [S.l.]: Addison-Wesley,2004. 6, 7

VIEBRANTZ;, M. R. V. J. M. de F. G. L. A. F. M. Bancos de dados nosql: Conceitos,ferramentas, linguagens e estudos de casos no contexto de big data. Simpósio Brasileiro deBancos de Dados - SBBD 2012, 2012. 9

WIDENIUS, M. M. Sun buys MySQL AB. 2008. Disponível em: . 8

http://monty-says.blogspot.com.br/2008/01/sun-buys-mysql-ab.htmlhttp://monty-says.blogspot.com.br/2008/01/sun-buys-mysql-ab.html

37

APÊNDICE A

GERADOR DE DADOS DE MEDIÇÃODE SENSORES

Este é o programa utilizado para gerar os dados de medição utilizados nosestudos de caso.

# i n c l u d e < c s t d i o ># i n c l u d e < i o s t r e a m ># i n c l u d e < f s t r e a m ># i n c l u d e < s t r i n g ># i n c l u d e < c s t d l i b ># i n c l u d e # i n c l u d e < c s t r i n g >

us ing namespace s t d ;

c l a s s g e r a d o r {p r i v a t e :

i n t f l a g ;

APÊNDICE A. Gerador de dados de medição de sensores 38

p u b l i c :g e r a d o r ( ) ;~ g e r a d o r ( ) ;void r e d i s ( i n t pAmostras ) ;void mysql ( i n t ) ;void geraAoMesmoTempo ( i n t ) ;

} ;

i n t main ( i n t argc , char ∗∗ a rgv ){

g e r a d o r o b j G e r a d o r ;o b j G e r a d o r . geraAoMesmoTempo ( 1 5 ) ;

p r i n t f ( " h e l l o wor ld \ n " ) ;re turn 0 ;

}

g e r a d o r : : g e r a d o r ( ) {f l a g = 0 ;

}

g e r a d o r : : ~ g e r a d o r ( ) {f l a g = 1 ;

}

void g e r a d o r : : geraAoMesmoTempo ( i n t pAmostras ) {o f s t r e a m a r q u i v o S a i d a R e d i s ;o f s t r e a m a r q u i v o S a i d a M y s q l ;s t r i n g chave = " a m o s t r a " ;s t r i n g nome_ tabe l a = " d a d o s c o l e t a d o s " ;s t r i n g cod ig o ;char c s t r c o d i g o [ 6 4 ] ;s t r i n g s t r v a l o r ;char c h r v a l o r [ 6 4 ] ;i n t v a l o r = 0 ;i n t l e n g t h ;i n t a m o s t r a s = pAmostras ;


char c s t r i d s e n s o r [ 3 0 ] ;

a r q u i v o S a i d a R e d i s . open ( " r e d i s m a s s i n s e r t . t x t " , i o s : : o u t | i o s : : t r u n c ) ;a r q u i v o S a i d a M y s q l . open ( " m y s q l i n s e r t . t x t " , i o s : : o u t | i o s : : t r u n c ) ;

s r a n d ( t ime (NULL ) ) ;

a r q u i v o S a i d a M y s q l


a r q u i v o S a i d a R e d i s

41

APÊNDICE B

SCRIPT LUA DE CONSULTA NOSGBD REDIS

Este programa escrito em Lua foi utilizado para executar as consultas noservidor do SGBD Redis. Aqui estão inclusos varios trechos de código comentados comalgumas condições utilizadas nas consultas. Dois traços (–) fazem da linha um comentário.

l o c a l sum = 0l o c a l matches = r e d i s . c a l l ( ’KEYS ’ , ’ a m o s t r a :∗ ’ )

l o c a l menor = 99999 ;l o c a l maior = 0 ;

l o c a l h g e t a l l = f u n c t i o n ( key )l o c a l bu lk = r e d i s . c a l l ( ’HGETALL ’ , key )

l o c a l r e s u l t = {}l o c a l n e x t k e yf o r i , v in i p a i r s ( bu lk ) do

i f i % 2 == 1 thenn e x t k e y = v

e l s e

APÊNDICE B. Script Lua de consulta no SGBD Redis 42

r e s u l t [ n e x t k e y ] = vend

endreturn r e s u l t

end

f o r _ , key in i p a i r s ( matches ) do−− l o c a l v a l = r e d i s . c a l l ( ’GET ’ , key )−− p u t t h e r e d i s hash i n t o a d i c t i o n a r y t a b l el o c a l mytab le = h g e t a l l ( key )i f tonumber ( my tab le [ ’ v a l o r m e d i c a o ’ ] ) > 55030 andtonumber ( my tab le [ ’ v a l o r m e d i c a o ’ ] ) < 73000 andmytab le [ ’ i d m e d i d o r ’ ] == ’ 000004 ’ andtonumber ( my tab le [ ’ horamed icao ’ ] ) > 1234565 andtonumber ( my tab le [ ’ horamed icao ’ ] ) < 12345614 then−− i f m y t a b l e [ ’ i d m e d i d o r ’ ] == ’000005 ’ t h e np r i n t ( key )−− i f tonumber ( m y t a b l e [ ’ v a l o r m e d i c a o ’ ] ) > maior t h e n

−− maior = tonumber ( m y t a b l e [ ’ v a l o r m e d i c a o ’ ] )−−end−− i f tonumber ( m y t a b l e [ ’ v a l o r m e d i c a o ’ ] ) < menor t h e n

−−menor = tonumber ( m y t a b l e [ ’ v a l o r m e d i c a o ’ ] )−−endf o r k , v in p a i r s ( my tab le ) do

p r i n t ( ’ ’ . . k . . ’ −> ’ . . v )endend

end

−− p r i n t ( ’ maior : ’ )−− p r i n t ( maior )−− p r i n t ( ’ menor : ’ )

DedicatóriaAgradecimentosResumoAbstractSumárioLista de ilustraçõesLista de tabelasLista de quadrosLista de abreviaturas e siglasIntroduçãoFundamentação TeóricaSistemas Gerenciadores de Banco de DadosSGBDs relacionaisMySQL

SGBDs não relacionaisRedis

Sistemas EmbarcadosResumo

Materiais e MétodosEquipamentos utilizadosPreparação do ambiente de pesquisaArmazenamento utilizadoPreparação e configuração dos SGBDsCaracterísticas da massa de testeCarga dos dadosConsulta dos dadosResumo

Resultados e discussõesEstudo de caso 1Inserção de 1 milhão de elementos no pcDuino 1Inserção de 1 milhão de elementos no Raspberry Pi 2Inserção de 25 milhões de elementos no pcDuinoInserção de 25 milhões de elementos no Raspberry Pi 2Tabela de resultados do estudo de caso 1

Estudo de caso 2Consultas em 1 milhão de elementos no pcDuinoConsultas em 1 milhão de elementos no Raspberry Pi 2Consultas em 25 milhões de elementos no pcDuinoConsultas em 25 milhões de elementos no Raspberry Pi 2Tabelas com os resultados do estudo de caso 2

ConclusõesTrabalhos FuturosReferênciasGerador de dados de medição de sensoresScript Lua de consulta no SGBD Redis

SGBD em embarcados: uma aplicação visando dados científicos · IZANDRO MONTEIRO METELLO...

Documents

Transcript of SGBD em embarcados: uma aplicação visando dados científicos · IZANDRO MONTEIRO METELLO...