Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things...
Transcript of Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things...
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EM
BANCO DE DADOS
MODELAGEM DE BANCO DE DADOS NAtildeORELACIONAL EM PLATAFORMA BIG DATA
VISANDO DADOS DE INTERNET DAS COISAS
CLEITON VITOR FERNANDES
CUIABAacute - MT
2017
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EM
BANCO DE DADOS
MODELAGEM DE BANCO DE DADOS NAtildeORELACIONAL EM PLATAFORMA BIG DATA
VISANDO DADOS DE INTERNET DAS COISAS
CLEITON VITOR FERNANDES
Orientador Prof Dr Roberto Benedito de Oliveira Pereira
Coorientador Prof MSc Nilton Hideki Takagi
Monografia apresentada ao Curso de Especializaccedilatildeoem Banco de Dados do Instituto de Computaccedilatildeoda Universidade Federal de Mato Grosso comorequisito para obtenccedilatildeo do tiacutetulo de Especialista emBanco de Dados
CUIABAacute - MT
2017
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EMBANCO DE DADOS
CERTIFICADO DE APROVACcedilAtildeO
Tiacutetulo Modelagem de banco de dados Natildeo Relacional em plataformaBig Data visando dados de Internet das Coisas
Autor Cleiton Vitor Fernandes
Trabalho aprovado em 17 de Fevereiro de 2017
Comissatildeo examinadora
Prof Dr Roberto Benedito de OliveiraPereira
Orientador
Prof MSc Nilton Hideki TakagiInstituto de Computaccedilatildeo - UFMT
Prof MSc Nielsen Cassiano SimotildeesInstituto de Computaccedilatildeo - UFMT
- Dedico primeiramente ao meu pai Vitor Mauro
Alvellos Fernandes que me incentivou acredi-
tou investiu ajudou e jamais me deixou desistir
ou desanimar nessa missatildeo de estudar aprender
e trabalhar na aacuterea que escolhi Foi ele a pri-
meira pessoa a me dar apoio e que me colocou
desde meus 10 anos de idade a seguir na aacuterea da
informaacutetica Posteriormente a minha matildee Car-
melinda Almeida Fernandes que na ausecircncia de
meu pai foi quem continuou dando forccedila em to-
dos os sentidos para que eu pudesse conquistar
tudo que eu tenho ateacute agora
AGRADECIMENTOS
Agradeccedilo a Deus por tudo que tenho conquistado em minha vida e a todas aspessoas envolvidas diretamente e indiretamente neste trabalho
Agradecimentos especiais aos professores Dr Roberto Benedito de OliveiraPereira e MSc Nilton Hideki Takagi por me orientar e acreditar neste trabalho e a minhacolega de sala e de trabalho Thais Fernanda Bueno da Silva que tanto me incentivou desdeo inicio deste projeto ateacute a sua conclusatildeo
Sem orientaccedilatildeo opiniatildeo correccedilatildeo e empreacutestimos destas pessoas teria sidomuito mais difiacutecil realizar este trabalho
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EM
BANCO DE DADOS
MODELAGEM DE BANCO DE DADOS NAtildeORELACIONAL EM PLATAFORMA BIG DATA
VISANDO DADOS DE INTERNET DAS COISAS
CLEITON VITOR FERNANDES
Orientador Prof Dr Roberto Benedito de Oliveira Pereira
Coorientador Prof MSc Nilton Hideki Takagi
Monografia apresentada ao Curso de Especializaccedilatildeoem Banco de Dados do Instituto de Computaccedilatildeoda Universidade Federal de Mato Grosso comorequisito para obtenccedilatildeo do tiacutetulo de Especialista emBanco de Dados
CUIABAacute - MT
2017
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EMBANCO DE DADOS
CERTIFICADO DE APROVACcedilAtildeO
Tiacutetulo Modelagem de banco de dados Natildeo Relacional em plataformaBig Data visando dados de Internet das Coisas
Autor Cleiton Vitor Fernandes
Trabalho aprovado em 17 de Fevereiro de 2017
Comissatildeo examinadora
Prof Dr Roberto Benedito de OliveiraPereira
Orientador
Prof MSc Nilton Hideki TakagiInstituto de Computaccedilatildeo - UFMT
Prof MSc Nielsen Cassiano SimotildeesInstituto de Computaccedilatildeo - UFMT
- Dedico primeiramente ao meu pai Vitor Mauro
Alvellos Fernandes que me incentivou acredi-
tou investiu ajudou e jamais me deixou desistir
ou desanimar nessa missatildeo de estudar aprender
e trabalhar na aacuterea que escolhi Foi ele a pri-
meira pessoa a me dar apoio e que me colocou
desde meus 10 anos de idade a seguir na aacuterea da
informaacutetica Posteriormente a minha matildee Car-
melinda Almeida Fernandes que na ausecircncia de
meu pai foi quem continuou dando forccedila em to-
dos os sentidos para que eu pudesse conquistar
tudo que eu tenho ateacute agora
AGRADECIMENTOS
Agradeccedilo a Deus por tudo que tenho conquistado em minha vida e a todas aspessoas envolvidas diretamente e indiretamente neste trabalho
Agradecimentos especiais aos professores Dr Roberto Benedito de OliveiraPereira e MSc Nilton Hideki Takagi por me orientar e acreditar neste trabalho e a minhacolega de sala e de trabalho Thais Fernanda Bueno da Silva que tanto me incentivou desdeo inicio deste projeto ateacute a sua conclusatildeo
Sem orientaccedilatildeo opiniatildeo correccedilatildeo e empreacutestimos destas pessoas teria sidomuito mais difiacutecil realizar este trabalho
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
UNIVERSIDADE FEDERAL DE MATO GROSSOINSTITUTO DE COMPUTACcedilAtildeO
COORDENACcedilAtildeO DE ENSINO DE ESPECIALIZACcedilAtildeO EMBANCO DE DADOS
CERTIFICADO DE APROVACcedilAtildeO
Tiacutetulo Modelagem de banco de dados Natildeo Relacional em plataformaBig Data visando dados de Internet das Coisas
Autor Cleiton Vitor Fernandes
Trabalho aprovado em 17 de Fevereiro de 2017
Comissatildeo examinadora
Prof Dr Roberto Benedito de OliveiraPereira
Orientador
Prof MSc Nilton Hideki TakagiInstituto de Computaccedilatildeo - UFMT
Prof MSc Nielsen Cassiano SimotildeesInstituto de Computaccedilatildeo - UFMT
- Dedico primeiramente ao meu pai Vitor Mauro
Alvellos Fernandes que me incentivou acredi-
tou investiu ajudou e jamais me deixou desistir
ou desanimar nessa missatildeo de estudar aprender
e trabalhar na aacuterea que escolhi Foi ele a pri-
meira pessoa a me dar apoio e que me colocou
desde meus 10 anos de idade a seguir na aacuterea da
informaacutetica Posteriormente a minha matildee Car-
melinda Almeida Fernandes que na ausecircncia de
meu pai foi quem continuou dando forccedila em to-
dos os sentidos para que eu pudesse conquistar
tudo que eu tenho ateacute agora
AGRADECIMENTOS
Agradeccedilo a Deus por tudo que tenho conquistado em minha vida e a todas aspessoas envolvidas diretamente e indiretamente neste trabalho
Agradecimentos especiais aos professores Dr Roberto Benedito de OliveiraPereira e MSc Nilton Hideki Takagi por me orientar e acreditar neste trabalho e a minhacolega de sala e de trabalho Thais Fernanda Bueno da Silva que tanto me incentivou desdeo inicio deste projeto ateacute a sua conclusatildeo
Sem orientaccedilatildeo opiniatildeo correccedilatildeo e empreacutestimos destas pessoas teria sidomuito mais difiacutecil realizar este trabalho
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
- Dedico primeiramente ao meu pai Vitor Mauro
Alvellos Fernandes que me incentivou acredi-
tou investiu ajudou e jamais me deixou desistir
ou desanimar nessa missatildeo de estudar aprender
e trabalhar na aacuterea que escolhi Foi ele a pri-
meira pessoa a me dar apoio e que me colocou
desde meus 10 anos de idade a seguir na aacuterea da
informaacutetica Posteriormente a minha matildee Car-
melinda Almeida Fernandes que na ausecircncia de
meu pai foi quem continuou dando forccedila em to-
dos os sentidos para que eu pudesse conquistar
tudo que eu tenho ateacute agora
AGRADECIMENTOS
Agradeccedilo a Deus por tudo que tenho conquistado em minha vida e a todas aspessoas envolvidas diretamente e indiretamente neste trabalho
Agradecimentos especiais aos professores Dr Roberto Benedito de OliveiraPereira e MSc Nilton Hideki Takagi por me orientar e acreditar neste trabalho e a minhacolega de sala e de trabalho Thais Fernanda Bueno da Silva que tanto me incentivou desdeo inicio deste projeto ateacute a sua conclusatildeo
Sem orientaccedilatildeo opiniatildeo correccedilatildeo e empreacutestimos destas pessoas teria sidomuito mais difiacutecil realizar este trabalho
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
AGRADECIMENTOS
Agradeccedilo a Deus por tudo que tenho conquistado em minha vida e a todas aspessoas envolvidas diretamente e indiretamente neste trabalho
Agradecimentos especiais aos professores Dr Roberto Benedito de OliveiraPereira e MSc Nilton Hideki Takagi por me orientar e acreditar neste trabalho e a minhacolega de sala e de trabalho Thais Fernanda Bueno da Silva que tanto me incentivou desdeo inicio deste projeto ateacute a sua conclusatildeo
Sem orientaccedilatildeo opiniatildeo correccedilatildeo e empreacutestimos destas pessoas teria sidomuito mais difiacutecil realizar este trabalho
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
RESUMO
A Internet das Coisas trabalha com uma grande quantidade de dispositivos ligados a inter-net e o constate crescimento de usuaacuterios que utilizam estes dispositivos gera uma massagigantesca de dados que cresce a cada ano por esta razatildeo o Big Data tem sido o maisrecomendado para armazenar os dados gerados Este trabalho visou ajudar na necessidadede melhorar o armazenamento dos dados e disponibiliza-los de forma mais raacutepida atraveacutesde uma modelagem de um banco de dados natildeo relacional baseado em Big Data Testesde exportaccedilatildeo de dados foram realizados em um banco de dados relacional PostgreSQL eimportaccedilatildeo destes dados em um banco de dados natildeo relacional MongoDB de duas fontesde dados meteoroloacutegicos diferentes Nestes testes foi constatado a flexibilidade e escala-bilidade da modelagem Ainda foram realizados testes que constataram a performancedo banco de dados com esta modelagem atraveacutes de consultas realizadas diretamente nobanco de dados MongoDB que encontrou uma dificuldade na consulta com mais de 50 milregistros executado na interface graacutefica Robomongo Dificuldade esta que natildeo inviabilizaa utilizaccedilatildeo da modelagem para o seu fim principal que eacute o armazenamento flexibilidadeadaptabilidade e escalabilidade
Palavras-chaves Modelagem de Banco de Dados Natildeo Relacional MongoDB Internetdas Coisas
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
ABSTRACT
Internet of Things works with a great amount of devices connected to Internet and theconstant growth of users who use these devices generates a huge mass of data that growsevery year for this reason Big Data has been the most recommended to store the generateddata This work aimed to help in this need to improve the storage of the data and to makeit available more quickly through a non-relational database modeling based on Big DataData export tests were performed in PostgreSQL relational database and imported this datainto a non-relational database MongoDB from two different meteorological data sourcesThese tests verified the flexibility and scalability of the modeling Was also performs teststhat verified the performance of the database with this modeling through queries performeddirectly in the MongoDB database Tests that also found a difficulty in the query with morethan 50 thousand records executed in the graphical interface Robomongo Difficulty isthis that doesnrsquot prevent the use of modeling for its main purpose that is storage flexibleadaptable and scalable
Keywords Non-Relational Database Modeling MongoDB Internet of Things
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
SUMAacuteRIO
1 INTRODUCcedilAtildeO 1
2 FUNDAMENTACcedilAtildeO TEOacuteRICA 6
21 Modelagem de Dados 6
211 Modelos Loacutegicos com Base em Objetos 8
2111 Modelo Entidade-Relacionamento 8
2112 Modelo Orientado a Objeto 9
2113 Modelo Semacircntico de Dados 9
2114 Modelo Funcional de Dados 10
212 Modelos Loacutegicos com Base em Registros 10
2121 Modelo Relacional 10
2122 Modelo de Rede 14
2123 Modelo Hieraacuterquico 14
2124 Modelo Orientado a Objetos 14
213 Modelos Fiacutesicos de Dados 14
214 Modelo Natildeo Relacional 15
2141 ChaveValor 15
2142 Orientado a Colunas 15
2143 Orientado a Documentos 15
2144 Grafos 16
22 Banco de Dados 16
23 Sistema Gerenciador de Banco de Dados 16
231 SGBD - Relacional 19
232 SGBD - Natildeo Relacional 22
24 PostgreSQL 24
25 MongoDB 26
251 JSON 27
252 BSON 28
26 Big Data 29
261 PostgreSQL x MongoDB 30
27 Resumo do Capiacutetulo 31
3 DESENVOLVIMENTO DO TRABALHO 32
31 Origem dos Dados 32
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
311 Dados do Instituto Nacional de Meteorologia 32
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universi-
dade Federal de Mato Grosso 34
32 Cenaacuterio 35
321 Preparaccedilatildeo dos Dados 36
322 Equipamentos Utilizados 41
33 Estudo de Caso 42
331 Estudo de Caso 1 Modelagem dos dados 42
332 Estudo de Caso 2 Popular base de dados 44
333 Estudo de Caso 3 Verificaccedilatildeo de performance 45
34 Resumo do Capiacutetulo 47
4 RESULTADOS E DISCUSSOtildeES 48
41 Resultado do Estudo de Caso 1 Modelagem dos dados 48
42 Resultado do Estudo de Caso 2 Popular base de dados 50
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance 52
5 CONCLUSOtildeES 55
REFEREcircNCIAS 57
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
LISTA DE ILUSTRACcedilOtildeES
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012) 2Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de
banco de dados Fonte (ELMASRI NAVATHE 2011) 7Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria
fonte (Abraham Silberschatz Henry Korth 1999) 9Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham Silbers-
chatz Henry Korth 1999) 11Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos
Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para
muitos Fonte (Abraham Silberschatz Henry Korth 1999) 13Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados
Fonte (ELMASRI NAVATHE 2011) 18Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados
Fonte (Abraham Silberschatz Henry Korth 1999) 20Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL
para consumidor e seus pedidos Fonte (SADALAGE FOWLER 2012) 23Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015) 25Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016) 26Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016) 27Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006) 28Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016) 29Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB 30Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os
utilizados pelo MongoDB 31Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011) 34Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009) 35Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do PGFA 36Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais
do INMET 37Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de inter-
face graacutefica PgAdmin 37Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL 38
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados da PGFA 38
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dosdados do INMET 39
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA 39Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET 40Figura 27 ndash Tela mostrando alguns dados importados no banco de dados Post-
greSQL com formato JSON 40Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de
execuccedilatildeo do script 41Figura 29 ndash Exemplo da modelagem vazia 43Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados 44Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte
codigo Json com os dados do INMET 49Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte
codigo Json com os dados do PGFA 50Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB 51Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado
da inserccedilatildeo dos dados do PGFA 51Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resul-
tado da inserccedilatildeo dos dados do INMET 52Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de
dados PostgreSQL e MongoDB 53Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples
realizados no banco de dados PostgreSQL e MongoDB 53Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas
realizados no banco de dados PostgreSQL e MongoDB 54
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
LISTA DE ABREVIATURAS E SIGLAS
BSON Binary JSON - JSON Binaacuterio
CAP Consistency Availability and Partition Tolerence - Consistecircncia Dispo-nibilidade e Toleracircncia a Particcedilatildeo
CERN Conseil Europeacuteen pour la Recherche Nucleacuteaire - Organizaccedilatildeo Europeacuteiapara Pesquisa Nuclear
DDL Data-Definition-Language - Linguagem de Definiccedilatildeo de Dados
DML Data-Manipulation-Language - Linguagem de Manipulaccedilatildeo de Dados
EMA Estaccedilatildeo Meteoroloacutegica Automaacutetica
GB Gigabyte
INMET Instituto Nacional de Meteorologia
IoT Internet of Things - Internet das Coisas
JSON JavaScript Object Notation - Notaccedilatildeo de Objeto de JavaScript
NoSQL Not Only SQL - Natildeo Somente SQL
PB Petabyte
PGFA Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental
RAM Random Access Memory
RFID Radio-Frequency IDentification - Identificaccedilatildeo por Radiofrequecircncia
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
SGBD Sistema Gerenciador de Banco de dados
SQL Structured Query Language - Linguagem de Consulta Estruturada
TE Terabyte
TI Tecnologia da Informaccedilatildeo
VM Virtual Machine - Maacutequina Virtual
XML eXtensible Markup Language - Linguagem de Marcaccedilatildeo Extensiacutevel
ZB Zettabyte
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
1
CAPIacuteTULO 1
INTRODUCcedilAtildeO
Vivi-se hoje na era da informaccedilatildeo como diz Negroponte (2003) na quala cada dia mais dispositivos estatildeo conectados e possuem cada vez mais sensores quecoletam por sua vez mais informaccedilotildees Em 2010 a quantidade total de dados geradospor estes dispositivos ultrapassou a marca de 1 zettabyte (ZB) ao final de 2011 o nuacutemerocresceu para 18ZB aleacutem disso espera-se que esse nuacutemero chegue a 35ZB em 2020(ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
O gerenciamento de grandes volumes de dados como os gerados por essesdispositivos eacute um requisito importante de uma plataforma de sistema permitindo que elapossa acompanhar a demanda de coleta e anaacutelise de dados e consequentemente proverrespostas decisotildees eou atuaccedilotildees de maneira eficiente
Neste contexto surgem desafios para a persistecircncia consulta indexaccedilatildeo pro-cessamento e manipulaccedilatildeo de transaccedilotildees Recentemente soluccedilotildees baseadas em Big Datatecircm surgido como uma potencial resposta a alguns desses desafios a fim de permitir lidarcom um imenso volume de dados diverso e natildeo estruturado (SOLDATOS SERRANOHAUSWIRTH 2012)
Natildeo existe uma definiccedilatildeo exata do que eacute Big Data contudo no intuito de tentardefinir satildeo usados como base algumas de suas caracteriacutesticas principais A Gartner eacute umaempresa americana de pesquisa e consultoria que fornece informaccedilotildees sobre tecnologia da
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 1 Introduccedilatildeo 2
informaccedilatildeo para liacutederes de TI e outros liacutederes de negoacutecios localizados em todo o mundo ea mesma convencionou junto a induacutestria de tecnologia trecircs caracteriacutesticas que podem serusadas para melhor definir Big Data conhecidas como 3V volume variedade e velocidade(ZASLAVSKY PERERA GEORGAKOPOULOS 2012) conforme Figura 1
Figura 1 ndash Caracteriacutesticas do Big Data Fonte (LI et al 2012)
Contudo (LI et al 2012) define essas caracteriacutesticas da seguinte forma
bull Volume refere-se ao tamanho dos dados tais como terabytes (TB) petabytes (PB)zettabytes (ZB) e assim por diante
bull Variedade eacute tipos de dados por exemplo os dados podem ser logs da web leiturasde sensores RFID dados de redes sociais natildeo estruturados streaming de viacutedeo eaacuteudio
bull Velocidade significa a frequecircncia com que os dados satildeo gerados Por exemplo cadamilissegundo segundo minuto hora dia semana mecircs ano Alguns dados precisamser processados em tempo real jaacute outros podem ser processados quando necessaacuterioTipicamente podemos identificar trecircs categorias principais ocasionais frequentes eem tempo real
Segundo (LI et al 2012) haacute uma seacuterie de desafios relacionados a grandemassa dados Devido agraves suas caracteriacutesticas alguns dos desafios herdados satildeo capturaarmazenamento pesquisa anaacutelise e virtualizaccedilatildeo
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 1 Introduccedilatildeo 3
Atualmente Big Data considera volume de dados que podem chegar ateacute Te-
rabytes em um futuro natildeo muito distante Big Data iraacute considerar volumes
de dados a partir de Petabytes Aleacutem disto a proposta deve ser capaz de dar
suporte ao processamento desses dados () com uma modelagem capaz de
facilitar tanto as consultas quanto as inferecircncias sobre os dados ou seja uma
modelagem adaptaacutevel capaz de suportar dados heterogecircneos de forma simples
(PERNAMBUCO 2014)
Dadas as caracteriacutesticas da proposta de modelagem citadas eacute necessaacuterio es-colher um banco de dados que atenda de forma mais simples e eficiente Os bancos dedados relacionais satildeo estruturados e muito riacutegidos dificultando uma modelagem com estascaracteriacutesticas
Em comparaccedilatildeo com os bancos de dados relacionais os bancos de dadosnatildeo relacionais atualmente tambeacutem chamado de NoSQL satildeo mais flexiacuteveis e escalaacuteveishorizontalmente Uma das principais vantagens das bases de dados NoSQL eacute representadapela inexistecircncia de uma estrutura de dados riacutegida que nos bancos de dados relacionaisdeve ser definida antes que os dados possam ser armazenados O banco de dados NoSQLpermite o gerenciamento de aplicativos mais faacutecil e remove a necessidade de modificaccedilatildeode aplicativos ou mudanccedila de esquema de banco de dados e aleacutem disso eacute melhor emais faacutecil em escalabilidade horizontal (Veronika Abramova Jorge Bernardino and PedroFurtado 2005)
No entanto haacute ainda uma seacuterie de desafios a serem superados para alavancar aampla disseminaccedilatildeo desse paradigma principalmente com relaccedilatildeo ao desenvolvimento deaplicaccedilotildees e agrave alta heterogeneidade decorrente da inerente diversidade de tecnologias dehardware e software desse ambiente (PIRES et al 2015)
Apesar de todos estes desafios existe um crescimento da produccedilatildeo de dispo-sitivos e sistemas inteligentes que cada vez mais se conectam atraveacutes de redes locais epela internet e que juntos estes dispositivos formam o que hoje eacute chamado de Internetdas Coisas A grande quantidade de conectividade entre esses dispositivos tem criadouma grande massa de dados e para poder trabalhar com tal volume eacute necessaacuterio projetarmodelar e implantar soluccedilotildees usando uma tecnologia como Big Data que pode utilizardados estruturados e natildeo estruturados (SOUZA SANTOS 2015)
Baseado na anaacutelise das caracteriacutesticas dos dados da Internet das Coisas Li etal (2012) propotildee uma soluccedilatildeo de gerenciamento de armazenamento diferente com baseem NoSQL como soluccedilatildeo para os armazenamentos atuais que natildeo suporta muito bem oarmazenamento de dados massivos e heterogecircneos da Internet das coisas
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 1 Introduccedilatildeo 4
Para se ter uma ideia da importacircncia da Internet das Coisas a IBM anunciou acompra da empresa de informaccedilotildees meteoroloacutegicas Weathercom e mais um investimentode 3 bilhotildees de doacutelares em serviccedilos relacionados agrave Internet das Coisas No caso da transaccedilatildeocom a Weather Company o que interessa agrave IBM em particular eacute a plataforma dinacircmicade dados em nuvem que eacute o motor do seu aplicativo moacutevel - o quarto aplicativo maisusado nos Estados Unidos - e que lida com 26 bilhotildees de requisiccedilotildees por dia no seu serviccedilobaseado em nuvem A aquisiccedilatildeo faz parte da estrateacutegia da IBM de aumentar sua presenccedilano mercado de Internet das Coisas (IoT) e vai integrar a nova divisatildeo Watson IoT Unit e aplataforma Watson IoT Cloud Booton (2016)
Para atender a demanda de tamanho volume variedade e velocidade da internetdas coisas eacute necessaacuterio entre outras coisas um banco de dados NoSQL que em conjuntocom uma arquitetura integrada de Big Data revolve boa parte desses itens Talvez a soluccedilatildeoque chegue mais proacutexima mesmo assim muito longe do que deve atingir a Internet dasCoisas em um futuro proacuteximo eacute a arquitetura mista baseada em uma modelagem de bancode dados NoSQL adequada com computaccedilatildeo distribuiacuteda em nuvem Como principal objetode proposta deste trabalho eacute tatildeo somente a Modelagem de Banco de Dados NoSQL natildeoseraacute abordado as outras camadas da arquitetura de uma soluccedilatildeo de Internet das Coisas
O objetivo geral desse trabalho visando atender uma necessidade da Internetdas Coias se concentra na modelagem de dados estrutural em banco de dados NoSQLbaseado em Big Data
A modelagem proposta deve ser escalaacutevel adaptaacutevel e que seja mais adequadapara utilizaccedilatildeo de dados preacute-processados gerados por sensores meteoroloacutegicos
Para atingir tal objetivo foram propostos os seguintes objetivos especiacuteficos
bull Investigar os modelos de banco de dados natildeo relacional disponiacuteveis no mercado queseja escalaacutevel e adaptaacutevel
bull Investigar o armazenamento de dados oriundos da Internet das Coisas
bull Desenvolver um estudo de caso utilizando dados sensoriais meteoroloacutegicos doInstituto Nacional de Meteorologia e do programa de poacutes-graduaccedilatildeo da FiacutesicaAmbiental da Universidade Federal de Mato Grosso
bull Avaliar e homologar o estudo de caso 1 Modelagem dos dados onde seraacute realizadoa modelagem do banco de dados estudo de caso 2 Popular base de dados ondeos dados seratildeo preparados e populados no banco de dados com a modelagem destetrabalho e estudo de caso 3 Verificaccedilatildeo de performance onde seratildeo realizados testesde performance atraveacutes de consultas
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 1 Introduccedilatildeo 5
Para todos os objetivos propostos neste trabalho seratildeo realizados os seguintesprocedimentos
Pesquisa bibliograacutefica consiste na busca e leitura de material de caraacuteter ci-entifico por meio impresso ou digital Este material eacute fundamental para embasamentoteoacuterico do projeto Pesquisa experimental seraacute utilizado um banco de dados natildeo relacionalpara desenvolver e aplicar uma modelagem voltado para dados sensoriais A modelagemseraacute testada com dados meteoroloacutegicos fornecidos pelo programa de poacutes-graduaccedilatildeo emFiacutesica Ambiental da Universidade Federal de Mato Grosso e do site do INMET (InstitutoNacional de Meteorologia)
A partir dos objetivos definidos este trabalho foi organizado em 5 capiacutetulos
No Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica eacute apresentado o resultado da pesquisabibliograacutefica realizada sobre todos os principais itens de estudo envolvidos como osconceitos de Big Data banco de dados relacional e natildeo relacional ou NoSQL modelagemde banco de dados NoSQL e Internet das Coisas para fundamentar os estudos de caso aquipropostos
No capiacutetulo 3 Desenvolvimento da Modelagem de banco de dados Natildeo Re-lacional em plataforma Big Data visando dados de Internet das Coisas seratildeo descritostodos os componentes de hardware e software escolhidos para realizaccedilatildeo de cada estudode caso e os detalhes dos cenaacuterios dos testes propostos como os scripts a serem utilizadosno desenvolvimento de cada estudo de caso
No capiacutetulo 4 Resultados e Discussotildees seratildeo discutidos os resultados docenaacuterio de cada estudo de caso proposto
No Capitulo 5 Conclusotildees seratildeo revistas as hipoacuteteses iniciais comparadas aosresultados e explicado se os resultados conseguiram atingir de forma satisfatoacuteria ou natildeo osobjetivos propostos
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
CAPIacuteTULO 2
FUNDAMENTACcedilAtildeO TEOacuteRICA
Este capitulo se dedica a apresentar o resultado dos estudos bibliograacuteficosrealizados inciando com o conceito de modelagem de dados descrevendo os modelos dedados relacional e natildeo relacional conceito de banco de dados demostrando um sistemagerenciador de banco de dados e principais caracteriacutesticas de Big Data que foram pesqui-sados em livros artigos documentaccedilatildeo de software para fundamentar os objetivos destetrabalho
21 Modelagem de Dados
Modelagem eacute o processo de criaccedilatildeo de um modelo de dados para um sistema deinformaccedilatildeo atraveacutes da aplicaccedilatildeo de teacutecnicas de modelagem de dados Eacute um processo usadopara definir e analisar os requisitos necessaacuterios para suportar os processos de negoacuteciosno acircmbito dos sistemas de informaccedilatildeo correspondentes nas organizaccedilotildees (SILVERSTON1997)
A modelagem conceitual eacute uma fase muito importante no projeto de uma apli-caccedilatildeo de banco de dados em muitas ferramentas de projeto de software as metodologiasde projeto de banco de dados e de engenharia de software satildeo interligadas pois essasatividades estatildeo fortemente relacionadas (ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 7
O projeto de um banco de dados eacute dividido em algumas etapas como a delevantamento e anaacutelise de requisitos projeto conceitual projeto loacutegico ou mapeamento domodelo de dados e projeto fiacutesico conforme a Figura 2
Figura 2 ndash Diagrama simplificado para ilustrar as principais fases do projeto de banco dedados Fonte (ELMASRI NAVATHE 2011)
Embora existam muitas maneiras de criar modelos de dados de acordo com(SILVERSTON 1997) apenas duas metodologias de modelagem se destacam bottom-up
e top-down
Os modelos Bottom-up ou View Integration geralmente comeccedilam com for-mulaacuterios de estruturas de dados existentes campos em telas de aplicativos ou relatoacuterios
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 8
Esses modelos satildeo geralmente fiacutesicos especiacuteficos da aplicaccedilatildeo e incompletos do ponto devista empresarial Eles natildeo podem promover a partilha de dados especialmente se foremconstruiacutedos sem referecircncia a outras partes da organizaccedilatildeo
Modelos de dados loacutegicos Top-down por outro lado satildeo criados de formaabstrata obtendo informaccedilotildees de pessoas que conhecem a aacuterea de assunto Um sistemapode natildeo implementar todas as entidades em um modelo loacutegico mas o modelo serve comoum ponto de referecircncia
O modelo de dados eacute um conjunto de ferramentas conceituais para a descriccedilatildeorelacionamento semacircntica de dados e regras de consistecircncia Os modelos mais conhecidossatildeo modelos loacutegicos com base em objetos modelos loacutegicos com base em registros emodelo fiacutesicos de dados (Abraham Silberschatz Henry Korth 1999)
211 Modelos Loacutegicos com Base em Objetos
Satildeo usados na descriccedilatildeo de dados no niacutevel loacutegico e de visotildees Existem vaacuteriosmodelos mas os mais conhecidos satildeo
2111 Modelo Entidade-Relacionamento
Haacute vaacuterias anotaccedilotildees para modelagem de dados O modelo real eacute frequentementechamado de Modelo de Entidade-Relacionamentoporque retrata dados em termos dasentidades e relacionamentos descritos nos dados (WHITTEN BENTLEY DITTMAN1998)
A modelagem Entidade-Relacionamentos eacute um meacutetodo de modelagem debanco de dados de esquema relacional usado na engenharia de software para produzir ummodelo de dados conceitual ou modelo de dados semacircntico de um sistema muitas vezesum banco de dados relacional e seus requisitos Esses modelos satildeo usados na primeirafase do projeto do sistema de informaccedilotildees durante a anaacutelise de requisitos para descreveras necessidades de informaccedilatildeo ou o tipo de informaccedilatildeo que deve ser armazenada em umbanco de dados As teacutecnicas de modelagem de dados podem ser usadas para descreverqualquer ontologia isto eacute uma visatildeo geral e classificaccedilotildees de termos usados e suas relaccedilotildeespara um determinado universo de discurso ou aacuterea de interesse (WHITTEN BENTLEYDITTMAN 1998)
O modelo Entidade-Relacionamento tem por base a percepccedilatildeo do mundo realcomo um conjunto de objetos chamados entidade Entidade eacute um objeto do mundo real quepode se relacionar com outros objetos atraveacutes dos seus atributos (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 9
Por exemplo um relacionamento eacute uma associaccedilatildeo entre entidades o deposi-tante associa um cliente a cada conta que ele possui Uma linha pode-se armazenar umaentidade como um cliente e em cada coluna ou atributo desta entidade pode ser armazenadoinformaccedilotildees do mesmo como nome e endereccedilo Toda estrutura loacutegica do banco de dadospode ser expressa graficamente por meio do diagrama Entidade Relacionamento cujosconstrutores dos seguintes componentes satildeo (Abraham Silberschatz Henry Korth 1999)
bull Retacircngulo representa os conjuntos de entidades
bull Elipses representam os atributos
bull Losango representam os relacionamentos entre os conjuntos de entidades
bull Linhas unem os atributos aos conjuntos de entidades e o conjunto de entidades aosseus relacionamentos
Cada componente eacute rotulado com o nome da entidade ou relacionamento querepresenta conforme Figura 3
Figura 3 ndash Diagrama Entidade-Relacionamento representando uma conta bancaria fonte(Abraham Silberschatz Henry Korth 1999)
2112 Modelo Orientado a Objeto
O modelo orientado a objetos tem por base um conjunto de objetos que conteacutemvalores armazenados em variaacuteveis instacircncias e um conjunto de coacutedigos chamados meacutetodos(Abraham Silberschatz Henry Korth 1999)
2113 Modelo Semacircntico de Dados
Nos modelos semacircnticos o processo de combinaccedilatildeo de documentos com deter-minada consulta eacute baseado no niacutevel de conceito e combinaccedilatildeo semacircntica As Abordagens
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 10
semacircnticas incluem diferentes niacuteveis de anaacutelise como as anaacutelises morfoloacutegica sintaacutetica esemacircntica para recuperar documentos com mais eficiecircncia (ELMASRI NAVATHE 2011)
2114 Modelo Funcional de Dados
O modelo funcional de dados eacute uma representaccedilatildeo estruturada das funccedilotildees (ati-vidades accedilotildees processos operaccedilotildees) dentro do sistema modelado (ELMASRI NAVATHE2011)
212 Modelos Loacutegicos com Base em Registros
Modelos loacutegicos com base em registros satildeo usados para descrever os dados noniacutevel loacutegico e de visatildeo
2121 Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dadoscomo a relaccedilatildeo entre eles Cada tabela possui uma ou mais colunas e cada uma possui umnome uacutenico A maior vantagem deste tipo de banco de dados eacute a habilidade de descreverrelacionamento entre os dados utilizando junccedilotildees entre tabelas distintas fortemente tipadaschaves primaacuterias e chaves estrangeiras entre outros
A chave primaria eacute uniacutevoca o atributo da chave primaacuteria tecircm um valor uacuteniconatildeo redundante e natildeo nulo A chave estrangeira que determina o relacionamento eacute umsubconjunto de atributos que constituem a chave primaacuteria de uma outra relaccedilatildeo (AbrahamSilberschatz Henry Korth 1999)
No modelo relacional uma linha eacute chamada de tupla um cabeccedilalho da colunaeacute chamado de atributo e a tabela eacute chamada de relaccedilatildeo O modelo relacional representa obanco de dados como uma coleccedilatildeo de relaccedilotildees Quando uma relaccedilatildeo eacute considera uma tabelade valores cada linha na tabela representa uma coleccedilatildeo de valores de dados relacionadosUma linha representa um fato que corresponde a um entidade ou relacionamento do mundoreal conforme Figura 4
Uma Entidade pode ser concreta como uma pessoa ou livro ou abstrata comoum empreacutestimo ou viagem Ela pode ser representada por um conjunto de atributos que satildeopropriedades descritivas de cada membro de um conjunto entidade (Abraham SilberschatzHenry Korth 1999)
Os valores de um atributo que descrevem as entidades podem ser simples oucompostos monovalorados ou multivalorados nulos e derivados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 11
bull Valores simples quando natildeo satildeo divididos em partes como por exemplo nome_clienteendereccedilo_cliente
bull valores compostos quando satildeo divididos em partes como por exemplo prenomenome_intermediaacuterio sobrenome rua numero bairro cidade uf cep
bull Valores monovalorados quando um atributo simples pode possuir apenas um valor
bull valores multivalorados quando um atributo possui um nenhum ou mais de um valorpor exemplo um funcionaacuterio pode possuir um dependente nenhum dependente oumais de um dependente
bull valores nulos quando um valor natildeo eacute preenchido por exemplo quando um funcio-naacuterio natildeo possui nenhum dependente nenhum valor eacute aplicado fazendo com que oatributo assuma o valor nulo
bull Valores derivados quando o valor eacute dependente de outro valor como por exemploum funcionaacuterio possui um atributo chamado data_contrataccedilatildeo e outro tempo_casaem que o atributo tempo_casa depende do valor armazenado no atributo data_contrataccedilatildeoe a data atual
Um relacionamento eacute uma associaccedilatildeo entre uma ou vaacuterias entidades A funccedilatildeoque uma entidade desempenha em um relacionamento eacute chamada de papel
Figura 4 ndash Exemplo de um banco de dados relacional Fonte (Abraham SilberschatzHenry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 12
Normalmente os papeis satildeo distintos poreacutem quando o mesmo conjunto deentidades participa de um conjunto de relacionamento mais de uma vez pode exercerdiferentes papeacuteis Assim podemos obter o grau dos relacionamentos sendo de grau 2 orelacionamento binaacuterio e de grau 3 o relacionamento ternaacuterio Para o funcionamento destesconjuntos de relacionamentos eacute necessaacuterio definir algumas restriccedilotildees as quais o conteuacutedodo banco de dados deve respeitar
O mapeamento das cardinalidades expressa o nuacutemero de entidades agraves quaisoutras entidades podem estar associadas via um conjunto de relacionamentos Um exemplode relacionamento R binaacuterio entre os conjuntos de entidades A e B o mapeamento dascardinalidades deve seguir uma das instruccedilotildees abaixo (Abraham Silberschatz Henry Korth1999)
bull Um para Um uma entidade em A esta associada no maacuteximo a uma entidade em Be uma entidade em B estaacute associada a no maacuteximo uma entidade em A conforme aFigura 5(a)
bull Um para muitos uma entidade em A estaacute associada a vaacuterias entidades em B Umaentidade em B entretanto deve estar associada a no maacuteximo uma entidade em Aconforme a Figura 5(b)
bull Muitos para um uma entidade em A estaacute associada a no maacuteximo uma entidade emB Uma entidade em B entretanto pode estar associada a um nuacutemero qualquer deentidades em A conforme a Figura 6(a)
bull Muitos para muitos uma entidade em A estaacute associada a qualquer nuacutemero deentidades em B e uma entidade em B estaacute associada a um nuacutemero qualquer deentidade em A conforme a Figura 6(b)
O rateio de cardinalidades de um relacionamento pode afetar a colocaccedilatildeo dosatributos nos relacionamentos Um esquema de banco de dados relacional tem por basetabelas derivadas de Entidade-Relacionamento onde eacute possiacutevel determinar a chave primaacuteriapara um esquema de relaccedilatildeo das chaves primaacuterias dos conjuntos de relacionamentos ouentidades cujos esquemas satildeo (Abraham Silberschatz Henry Korth 1999)
bull Conjunto de entidade forte onde a chave primaacuteria do conjunto de relacionamentostorna-se a chave primaacuteria da relaccedilatildeo
bull Conjunto de entidades fracas onde a chave primaacuteria do conjunto de entidades fortesdo qual o conjunto de entidades fracas eacute dependente
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 13
bull Conjunto de relacionamentos quando a uniatildeo das chaves primaacuterias dos conjuntos deentidades relacionados tornam-se superchaves da relaccedilatildeo
bull Tabelas combinadas quando a chave primaacuteria do conjunto de entidades muitostorna-se a chave primaacuteria da relaccedilatildeo
Figura 5 ndash Mapeamento das cardinalidades (a) Um para Um (b) Um para muitos Fonte(Abraham Silberschatz Henry Korth 1999)
Figura 6 ndash Mapeamento das cardinalidades (a) Muitos para Um (b) Muitos para muitosFonte (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 14
Da lista descrita se verifica que um esquema de relaccedilatildeo pode incluir entreseus atributos a chave primaacuteria de outro esquema essa chave eacute chamada chave estrangeiraCom estas informaccedilotildees sobre relacionamentos e chaves eacute possiacutevel realizar operaccedilotildees deconsultas atraveacutes da aacutelgebra relacional que eacute uma linguagem de consultas proceduralConsiste em um conjunto de operaccedilotildees tendo como entrada uma ou mais relaccedilotildees eproduzindo como resultado uma nova relaccedilatildeo A aacutelgebra relacional eacute considerada a basepara a linguagem SQL (ELMASRI NAVATHE 2011)
Poreacutem a linguagem SQL eacute basicamente relacional natildeo sendo possiacutevel utilizaacute-laem modelagem natildeo relacional(STROZZI 2007)
2122 Modelo de Rede
Modelo de rede satildeo representados por um conjunto de registros e as relaccedilotildeesentre estes registros satildeo representados por links organizados no banco de dados por umconjunto arbitraacuterio de graacuteficos
2123 Modelo Hieraacuterquico
Modelo hieraacuterquico eacute similar ao modelo em rede pois os dados e suas relaccedilotildeessatildeo representados respectivamente por registros e links poreacutem no modelo hieraacuterquico osregistros estatildeo organizados em aacutervores
2124 Modelo Orientado a Objetos
Modelo orientado a objetos tem por base um conjunto de objetos Um objetoconteacutem valores armazenados em variaacuteveis conjunto de coacutedigos chamados de meacutetodos queoperam esse objeto e os objetos que contecircm os mesmos tipos de valores e meacutetodos satildeoagrupados em classes
213 Modelos Fiacutesicos de Dados
Os modelos fiacutesicos de dados descrevem o niacutevel mais baixo do banco de dados esatildeo poucos sendo os mais conhecidos modelo unificado e modelo de particcedilatildeo de memoacuteria(Abraham Silberschatz Henry Korth 1999)
Poreacutem para esse trabalho o modelo de dados mais importante eacute o Modelo NatildeoRelacional
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 15
214 Modelo Natildeo Relacional
Segundo (SADALAGE FOWLER 2012) o banco de dados NoSQL surgiumotivada pela necessidade de trabalhar com grandes volumes de dados Seus defenso-res afirmam que os sistemas desenvolvidos com banco de dados Natildeo Relacionais satildeomais flexiacuteveis do que os bancos de dados Relacionais jaacute que satildeo livres de esquemasriacutegidos satildeo distribuiacutedos escalaacuteveis possuem melhor desempenho e natildeo necessitam deuma infraestrutura robusta para armazenar seus dados
Carlo Strozzi introduziu este nome em 1998 como o de um banco de dadosrelacional de coacutedigo aberto que natildeo possuiacutea uma interface SQL O termo NoSQL foire-introduzido no iniacutecio de 2009 por um funcionaacuterio do Rackspace Eric Evans quandoJohan Oskarsson da Lastfm queria organizar um evento para discutir bancos de dadosopen source distribuiacutedos(STROZZI 2007)
Dentre os banco de dados NoSQL existem vaacuterias categorias com caracteriacutesticase abordagens diferentes para o armazenamento relacionadas principalmente com o modelode dados utilizado as principais categorias satildeo (PERNAMBUCO 2014)
2141 ChaveValor
Os dados satildeo armazenados sem esquema preacute-definido no formato de paresChaveValor onde tem-se uma Chave que eacute responsaacutevel por identificar o dado e seu valorque corresponde ao armazenamento do dado em siacute
2142 Orientado a Colunas
Os dados satildeo armazenados em famiacutelias de colunas com a adiccedilatildeo de algunsatributos dinacircmicos Por exemplo satildeo utilizadas chaves estrangeiras mas que apontampara diversas tabelas diferentes sendo assim este banco de dados natildeo eacute relacional
2143 Orientado a Documentos
Cada documento conteacutem uma informaccedilatildeo uacutenica pertinente a um uacutenico objetomantendo a estrutura dos objetos armazenados Em geral todos os dados satildeo assumidoscomo documentos que por sua vez satildeo encapsulados e codificados em algum formatopadratildeo podendo ser estes formatos XML YAML JSON BSON assim como formatosbinaacuterios como PDF e formatos do Microsoft Office
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 16
2144 Grafos
Os dados satildeo armazenados em uma estrutura de noacutes arestas e propriedadescom os noacutes representando as entidades em si as arestas representando os relacionamentosentre os noacutes e as propriedades representando os atributos das entidades podendo estasserem representadas tanto nos noacutes quanto nas arestas do grafo
Esse tipo de banco de dados utiliza teorias matemaacuteticas dos grafos muitoutilizadas nas mais diversas aplicaccedilotildees com uma modelagem mais natural dos dados Eacutepossiacutevel realizar consultas com um alto niacutevel de abstraccedilatildeo Por esses motivos esta categoriaeacute indicada para aplicaccedilotildees em redes sociais e que necessitam de processamento inteligentecomo inferecircncias a partir dos dados armazenados
22 Banco de Dados
Banco de dados eacute uma coleccedilatildeo organizada de dados relacionados (ELMASRINAVATHE 2011) Um banco de dados representa algum aspecto do mundo real logica-mente coerente com algum significado inerente Sistemas de banco de dados satildeo projetadosconstruiacutedos e populados com dados para uma finalidade especifica O gerenciamento des-ses dados implica na definiccedilatildeo das estruturas de armazenamento e dos mecanismos demanipulaccedilatildeo dessas informaccedilotildees e ainda na garantia de seguranccedila dos dados tanto noarmazenamento quanto no acesso de usuaacuterios natildeo autorizados(Abraham SilberschatzHenry Korth 1999)
Um banco de dados pode ter qualquer tamanho complexidade e pode sergerado e mantido manualmente ou computadorizado Um cataacutelogo de fichas clinicas depacientes de uma clinica odontoloacutegica pode ser criado e mantido manualmente em papele armazenado em gavetas de armaacuterio jaacute um banco de dados computadorizado pode sercriado e mantido por um grupo de aplicaccedilotildees especiacuteficas para esta tarefa ou por um sistemagerenciador de banco de dados (ELMASRI NAVATHE 2011)
23 Sistema Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) eacute uma coleccedilatildeo de progra-mas que permite aos usuaacuterios criar e manter um banco de dados (ELMASRI NAVATHE2011) O principal objetivo de um SGBD eacute proporcionar um ambiente tanto convenientequanto eficiente para a recuperaccedilatildeo e armazenamento das informaccedilotildees no banco de dadose facilitar o processo de definiccedilatildeo construccedilatildeo manipulaccedilatildeo e compartilhamento de bancode dados entre usuaacuterios e aplicaccedilotildees (Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 17
A definiccedilatildeo ou informaccedilatildeo descritiva do banco de dados tambeacutem eacute armazenadapelo SGDB na forma de cataacutelogo ou dicionaacuterio chamado de metadados A manipulaccedilatildeo deum banco de dados inclui funccedilotildees como consulta ao banco de dados para recuperar dadosespeciacuteficos O compartilhamento de um banco de dados permite que usuaacuterios e programasacessem simultaneamente Um programa de aplicaccedilatildeo acessa o banco de dados ao enviarconsultas ou solicitaccedilotildees de dados ao SGDB (ELMASRI NAVATHE 2011)
Outras funccedilotildees importantes fornecidas pelo SGDB incluem proteccedilatildeo do sis-tema contra falhas de hardware ou software atraveacutes do seu subsistema de backup e restoreO subsistema de recuperaccedilatildeo eacute responsaacutevel por garantir que o banco de dados seja res-taurado ao estado em que estava antes da transaccedilatildeo ser executada O backup ou coacutepiade seguranccedila de disco tambeacutem eacute necessaacuterio no caso de uma falha catastroacutefica de discoInclui tambeacutem proteccedilatildeo de seguranccedila contra acesso natildeo autorizado ou malicioso umavez que diversos tipos de usuaacuterios ou grupo de usuaacuterios compartilham a mesma base dedados O SGBD deve oferecer vaacuterios niacuteveis de acesso atraveacutes de uma conta de usuaacuterioprotegida por senha O subsistema de seguranccedila eacute responsaacutevel pelas restriccedilotildees de cadaconta de usuaacuterio responsaacutevel pela administraccedilatildeo do sistema teraacute privileacutegios que um usuaacuteriocomum natildeo tem pois deve apenas manipular os dados ou ateacute mesmo somente consultaralgumas informaccedilotildees sem permissatildeo para realizar qualquer tipo de alteraccedilatildeo (ELMASRINAVATHE 2011)
Haacute muitos tipos de SGBD desde pequenos sistemas que funcionam em compu-tadores pessoais a sistemas enormes que estatildeo associados a mainframes Um modelo de da-dos para um SGBD define como os dados seratildeo armazenados no banco de dados(AbrahamSilberschatz Henry Korth 1999)
O maior benefiacutecio de um banco de dados eacute proporcionar ao usuaacuterio umavisatildeo abstrata dos dados (Abraham Silberschatz Henry Korth 1999) O sistema ocultadeterminados detalhes sobre a forma de armazenamento e manutenccedilatildeo desses dados OSGBD age como interface entre os programas de aplicaccedilatildeo e os ficheiros de dados fiacutesicose separa as visotildees loacutegica e de concepccedilatildeo dos dados Assim sendo satildeo basicamente trecircs oscomponentes de um SGBD
bull Linguagem de definiccedilatildeo de dados (especiacutefica conteuacutedos estrutura a base de dados edefine os elementos de dados)
bull Linguagem de manipulaccedilatildeo de dados (para poder alterar os dados na base)
bull Dicionaacuterio de dados (guarda definiccedilotildees de elementos de dados e respectivas caracte-riacutesticas e descreve os dados
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 18
Existem muitos tipos de ferramentas completas e com funcionalidades acresci-das que elevam para outros niacuteveis a capacidade operacional de gerar e gerenciar informaccedilatildeode valor para a organizaccedilatildeo segue exemplo de algumas destas ferramentas SGBD Fire-bird HSQLDB IBM DB2 IBM Informix JADE MariaDB Microsoft Visual FoxproMongoDB mSQL MySQL Oracle PostgreSQL SQL-Server Sybase TinySQL ZODB
Para completar a definiccedilatildeo inicial do SGDB eacute uma coleccedilatildeo de arquivos eprogramas inter-relacionados ilustrado na Figura 7
Figura 7 ndash Diagrama simplificado de um ambiente de sistema de banco de dados Fonte(ELMASRI NAVATHE 2011)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 19
231 SGBD - Relacional
Para que se possa usar um sistema ele precisa ser eficiente na recuperaccedilatildeodas informaccedilotildees Esta eficiecircncia estaacute relacionada agrave forma pela qual foram projetadasas complexas estruturas de representaccedilatildeo desses dados no banco de dados (AbrahamSilberschatz Henry Korth 1999)
Assim o projeto do banco de dados deve considerar a interface entre o sistemade banco de dados e o sistema operacional Os componentes funcionais do sistema debanco de dados podem ser divididos pelos componentes de processamento de consultase pelo componentes de administraccedilatildeo de memoacuteria (Abraham Silberschatz Henry Korth1999)
Os componentes de processamento de consultas satildeo
bull Compilador DML traduz comandos DML da linguagem de consultas em instruccedilotildeesde baixo niacutevel DML eacute uma famiacutelia de linguagem de manipulaccedilatildeo de dados dividasem duas categorias procedural e declarativa A procedural especifica como os dadosdevem ser obtidos do banco e a declarativa natildeo necessita especificar o como os dadosseratildeo obtidos do banco Um exemplo de linguagem declarativa mais conhecida eacute oSQL
bull Preacute-compilador para comandos DML inseridos em programas de aplicaccedilatildeo queconvertem comandos DML em chamadas de procedimentos normais da linguagemhospedeira
bull Interpretador DDL interpreta os comandos DLL e registra-os em um conjunto detabelas que contecircm metadados
bull Componentes para o tratamento de consultas executam instruccedilotildees de baixo niacutevelgeradas pelo compilador DML
Os componentes de administraccedilatildeo de armazenamento de dados satildeo
bull Gerenciamento de autorizaccedilotildees e integridade testa o funcionamento das regras deintegridade e a permissatildeo de acesso aos dados pelo usuaacuterio
bull Gerenciamento de transaccedilotildees garante que o banco de dados permaneceraacute em estadoconsistente
bull Administraccedilatildeo de arquivos gerencia a alocaccedilatildeo de espaccedilo no armazenamento emdisco
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 20
bull Administraccedilatildeo de buffer responsaacutevel pela intermediaccedilatildeo de dados do disco para amemoacuteria principal
Aleacutem disso algumas estruturas de dados satildeo exigidas como parte da imple-mentaccedilatildeo fiacutesica do sistema
bull Arquivo de dados armazena o proacuteprio banco de dados
bull Dicionaacuterio de dados armazena os metadados relativos agrave estrutura do banco de dados
bull Iacutendices proporcionam acesso raacutepido aos itens de dados que satildeo associados a valoresdeterminados
bull Estatiacutesticas de dados armazenam informaccedilotildees estatiacutesticas relativas aos dados conti-dos no banco de dados
Os componentes e a conexatildeo entre eles satildeo mostrados conforme Figura 8
Figura 8 ndash Estrutura detalhada do Sistema de Gerenciamento Banco de dados Fonte(Abraham Silberschatz Henry Korth 1999)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 21
Conforme os componentes de processamento de consultas um esquema dedados eacute especificado por um conjunto de definiccedilotildees expressas por uma linguagem especialchamada linguagem de definiccedilatildeo de dados (data-definition language - DDL) O resultado dacompilaccedilatildeo dos paracircmetros DDLs eacute armazenado em um conjunto de tabelas que constituemum arquivo especial chamado dicionaacuterio de dados ou diretoacuterio de dados
Para expressar consulta e atualizaccedilotildees eacute utilizado uma linguagem chamadalinguagem de manipulaccedilatildeo de dados (data-manipulation-language - DML) Ela eacute utilizadapara viabilizar o acesso ou a manipulaccedilatildeo dos dados de forma compatiacutevel ao modelode dados apropriado A DML responsaacutevel pela recuperaccedilatildeo de informaccedilotildees eacute chamadade linguagem de consulta estruturada (Structured Query Language - SQL) (AbrahamSilberschatz Henry Korth 1999)
A versatildeo Original dessa linguagem foi desenvolvida em San Joseacute no laboratoacuteriode pesquisas da IBM nos anos 70 A linguagem SQL proporciona comandos para definiccedilatildeoexclusatildeo e alteraccedilatildeo de esquemas de relaccedilotildees consultas baseadas em aacutelgebra relacional ecalculo relacional de tuplas Ainda possui comandos para definiccedilatildeo de visotildees especificaccedilatildeode direito de acesso especificaccedilatildeo de regras de integridade especificaccedilatildeo de inicializaccedilatildeoe finalizaccedilatildeo de transaccedilotildees(Abraham Silberschatz Henry Korth 1999)
Para garantir essas regras o SGBD relacional utiliza um conceito de controletransacional chamado ACID (Atomicidade Consistecircncia Isolamento e Durabilidade) doinglecircs Atomicity Consistency Isolation Durability(ELMASRI NAVATHE 2003)
bull Atomicidade A transaccedilatildeo deve ter todas as suas operaccedilotildees executadas em caso desucesso ou nenhum resultado em caso de falha ou seja todo o trabalho eacute feito ounada eacute feito Neste caso natildeo existe resultados parciais da transaccedilatildeo
bull Consistecircncia A execuccedilatildeo de uma transaccedilatildeo deve levar o banco de dados de um estadoconsistente a um outro estado consistente ou seja uma transaccedilatildeo deve terminarrespeitando as regras de integridade e restriccedilotildees de integridade loacutegica previamenteassumidas
bull Isolamento Eacute um conjunto de teacutecnicas que tentam evitar que transaccedilotildees concorrentesinterfiram umas nas outras
bull Durabilidade Os efeitos de uma transaccedilatildeo em caso de sucesso devem persistirno banco de dados mesmo em casos de quedas de energia travamentos ou errosGarante que os dados estaratildeo disponiacuteveis em definitivo
Os SGBDs relacionais mais conhecidos e utilizados pelo mercado satildeo OracleMicrosoft SQL Server PostgreSQL MySQL entre outros
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 22
As arquiteturas de SGBD relacional tecircm como possiacutevel dificuldade tornar osbancos de dados convencionais escalaacuteveis e mais baratos aleacutem de manter um esquemariacutegido na modelagem dos dados (SADALAGE FOWLER 2012)
Em 1998 surgiu o termo Banco de Dados Natildeo-Relacional baseado em umasoluccedilatildeo de banco de dados que natildeo oferecia uma interface SQL mas esse sistema ainda erabaseado na arquitetura relacional Posteriormente o termo passou a representar soluccedilotildeesque promoviam uma alternativa ao Modelo Relacional tornando se uma abreviaccedilatildeo de NotOnly SQL (natildeo apenas SQL) (BRITO 2010)
232 SGBD - Natildeo Relacional
Banco de Dados Natildeo-Relacional tem algumas caracteriacutesticas em comum taiscomo serem livres de esquema promoverem alta disponibilidade e maior escalabilidade(BRITO 2010) Os primeiros comeccedilaraacute a surgir como o SGBD orientado a objetos quetem como principais caracteriacutesticas armazenar os dados como objetos linguagem deprogramaccedilatildeo e o esquema do banco de dados usam o mesmo modo de definiccedilatildeo de tipos eos bancos de dados orientados oferecem suporte a versionamento de objetos
O SGBD Natildeo Relacional atualmente mais conhecido como SGBD NoSQLtem como principais caracteriacutesticas primeiro e mais oacutebvio natildeo utilizar a linguagem SQLembora natildeo seja regra mas geralmente satildeo projetos de coacutedigo aberto e oferecem umagama de opccedilotildees para consistecircncia e distribuiccedilatildeo Outra caracteriacutestica eacute operar sem umesquema permitindo-lhe livremente adicionar campos para registros de banco de dadossem ter que definir quaisquer alteraccedilotildees na estrutura em primeiro lugar (SADALAGEFOWLER 2012)
Os SGBDs NoSQL apresentam algumas caracteriacutesticas fundamentais que osdiferenciam dos tradicionais SGBDs relacionais tornando-os adequados para armazena-mento de grandes volumes de dados natildeo estruturados ou semiestruturados Segue algumasdestas caracteriacutesticas
bull Escalabilidade horizontal A ausecircncia de controle de bloqueios eacute uma caracteriacutesticados SGBDs NoSQL que torna esta tecnologia adequada para solucionar problemasde gerenciamento de volumes de dados que crescem exponencialmente
bull Ausecircncia de esquema ou esquema flexiacutevel Uma caracteriacutestica evidente eacute a ausecircnciacompleta ou quase total do esquema que define a estrutura dos dados modeladosEsta ausecircncia facilita tanto a escalabilidade quanto contribui para um maior aumentoda disponibilidade Em contrapartida natildeo haacute garantias da integridade dos dados oque ocorre nos bancos de dados relacionais devido agrave sua estrutura riacutegida
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 23
bull Permite replicaccedilatildeo de forma nativa Diminui o tempo gasto para recuperar informa-ccedilotildees
bull Consistecircncia eventual A consistecircncia nem sempre eacute mantida entre os diversos pontosde distribuiccedilatildeo de dados Esta caracteriacutestica tem como princiacutepio o teorema CAP (Con-
sistency Availability and Partition Tolerence) que diz que em um dado momentosoacute eacute possiacutevel garantir duas de trecircs propriedades entre consistecircncia disponibilidade etoleracircncia agrave particcedilatildeo (LI et al 2012)
Por mais que o SGBD NoSQL natildeo possua esquemas riacutegidos e inflexiacuteveis abase de dados geralmente haacute um esquema impliacutecito presente Esse esquema impliacutecito eacuteum conjunto de suposiccedilotildees sobre a estrutura dos dados no coacutedigo que manipula os dadosPor exemplo uma modelagem usando um armazenamento do tipo ChaveValor conformeFigura 9
Figura 9 ndash Modelagem do Sistema de Gerenciamento Banco de dados NoSQL para consu-midor e seus pedidos Fonte (SADALAGE FOWLER 2012)
Poreacutem essa estrutura de dados usada pelos bancos de dados NoSQL valor-chave coluna larga graacutefico ou documento eacute diferente das usadas por padratildeo em bancos dedados relacionais tornando algumas operaccedilotildees mais raacutepidas no NoSQL Apesar de todas asvantagens de escalabilidade flexibilidade e velocidade o banco de dados NoSQL enfrentagrandes desafios como a consistecircncia dos dados processados em transaccedilotildees distribuiacutedascomo as que existem em banco de dados relacional como PostgreSQL utilizado nessetrabalho
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 24
24 PostgreSQL
Para preparar os dados para realizaccedilatildeo dos estudos de caso foi necessaacuterio autilizaccedilatildeo de um banco de dados relacional e o escolhido por conta de jaacute haver um tipo dedados JSON foi o PostgreSQL
O PostgreSQL eacute um poderoso sistema de banco de dados objeto-relacionalde coacutedigo aberto derivado do pacote POSTGRES escrito na Universidade da Califoacuterniaem Berkeley Com mais de uma deacutecada de desenvolvimento por traacutes o PostgreSQL eacuteatualmente o mais avanccedilado banco de dados de coacutedigo aberto disponiacutevel
O projeto POSTGRES liderado pelo Professor Michael Stonebrakercomeccedilouem 1986 atualmente possui uma arquitetura comprovada que lhe confere uma reputaccedilatildeode confiabilidade integridade de dados e correccedilatildeo Ele eacute executado em todos os principaissistemas operacionais incluindo Linux UNIX Mac OS X Solaris e Windows Incluia maioria dos tipos de dados SQL2008 tambeacutem suporta o armazenamento de objetosbinaacuterios incluindo imagens sons ou viacutedeo Possui interfaces de programaccedilatildeo nativas paraC C ++ Java Net Perl Python Ruby Tcl ODBC entre outros
Um banco de dados de classe empresarial o PostgreSQL possui recursossofisticados como o MVCC (Multi-Version Concurrency Control) tablespaces replicaccedilatildeoassiacutencrona transaccedilotildees aninhadas backups on-line um planejador e otimizador de consultassofisticado Eacute altamente escalaacutevel tanto na grande quantidade de dados que pode gerenciarquanto no nuacutemero de usuaacuterios simultacircneos que pode acomodar Existem sistemas ativosdo PostgreSQL em ambientes de produccedilatildeo que gerenciam mais de 4 terabytes de dados(POSTGRES 2017)
Poreacutem para obter o processamento de Big Data provenientes da Internet dasCoisas seraacute necessaacuterio adotar um banco de dados que suporte aleacutem do grande volume dedados fazer isso de forma paralela e que ofereccedila faacutecil escalabilidade (LI et al 2012)
Para se escolher um banco de dados liacuteder de mercado o Gartner o defineda seguinte forma Os liacutederes demonstram geralmente mais suporte para uma amplagama de aplicaccedilotildees operacionais tipos de dados e vaacuterios casos de uso Esses fornecedoresdemonstraram a satisfaccedilatildeo do cliente consistente com forte apoio ao cliente Por isso osliacutederes geralmente representam o menor risco para clientes nas aacutereas de desempenhoescalabilidade confiabilidade e suporte Como as demandas do mercado mudam com otempo entatildeo os liacutederes demonstram forte visatildeo em apoio natildeo soacute das necessidades atuaisdo mercado mas tambeacutem das tendecircncias emergentes(GARTNER 2015)
Para escolher um banco de dados que atenda a estas caracteriacutesticas de BigData o Gartner considera um SGBD comercial definido como sistemas que tambeacutemsuportam muacuteltiplas estruturas e tipos de dados como XML texto JavaScript Object
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 25
Notation (JSON) aacuteudio imagem e viacutedeo Eles devem incluir mecanismos para isolar osrecursos de carga de trabalho e controlar vaacuterios paracircmetros de acesso do usuaacuterio finaldentro de instacircncias gestatildeo dos dados
Diante das caracteriacutesticas apresentadas foi utilizado o Quadrante Maacutegico daGartner (2015) para selecionar o banco de dados NoSQL para realizar o estudo de caso damodelagem conforme Figura 10
Figura 10 ndash Quadrante de Gartner Fonte(GARTNER 2015)
Por ser um dos bancos de dados melhor ranqueado entre os lideres no Qua-drante Maacutegico da Gartner o MongoDB foi o escolhido
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 26
25 MongoDB
MongoDB eacute uma aplicaccedilatildeo de coacutedigo aberto de alta performance alta dispo-nibilidade e escalonamento automaacutetico O seu desenvolvimento comeccedilou em outubro de2007 pela 10gen A primeira versatildeo puacuteblica foi lanccedilada em fevereiro de 2009 (ELIOT2010)
O MongoDB a partir da versatildeo 30 introduziu novos mecanismos de arma-zenamento que ampliam as capacidades do banco de dados permitindo-lhe escolher astecnologias ideais para as diferentes cargas de trabalho em sua organizaccedilatildeo como porexemplo o mecanismo MMAPv1 padratildeo Uma versatildeo melhorada do motor usado emversotildees anteriores do MongoDB e o novo motor de armazenamento WiredTiger que pro-porciona melhor controle de concorrecircncia compressatildeo nativa dos dados gerando benefiacuteciossignificativos nas aacutereas de menores custos de armazenagem e melhorando o desempenhodo hardware (MONGODB 2015)
Executar vaacuterios mecanismos de armazenamento em uma implantaccedilatildeo e alavan-car a mesma linguagem de consulta escalando meacutetodos e ferramentas operacionais emtodos eles para reduzir representativamente o desenvolvimento e complexidade operacionaltornado ele um dos bancos de dados NoSQL liacuteder de mercado
No MongoDB a menor unidade eacute um documento Os documentos satildeo armaze-nados em uma coleccedilatildeo conforme Figura 11 que por sua vez compotildeem um banco de dadosOs documentos satildeo anaacutelogos a linhas em uma tabela SQL mas haacute uma grande diferenccedilanem todos os documentos precisam ter a mesma estrutura Os documentos de uma coleccedilatildeouacutenica natildeo necessitam ter o mesmo conjunto de campos e tipo de dados de um campo podediferir entre os documentos dentro de uma coleccedilatildeo Outra caracteriacutestica do MongoDB eacuteque os campos em um documento podem conter matrizes e ou sub-documentos (agraves vezeschamados de documentos aninhados ou incorporados) conforme a Figura 12
Figura 11 ndash Exemplo de uma Coleccedilatildeo Fonte Mongo (2016)
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 27
Figura 12 ndash Exemplo de um Documento Fonte (MONGODB 2016)
O MongoDB fornece a capacidade de consulta em qualquer campo dentro deum documento Fornece tambeacutem um rico conjunto de opccedilotildees de indexaccedilatildeo para otimizaruma grande variedade de consultas incluindo iacutendices de texto iacutendices geoespaciais iacutendicescompostos iacutendices dispersos iacutendices de tempo de vida iacutendices exclusivos e outros Aleacutemdisso fornece a capacidade de analisar dados no local sem que precise ser replicado paraanaacutelise dedicada ou motores de busca
Os documentos MongoDB satildeo semelhantes aos objetos JavaScript Object
Notation mais conhecidos como JSON Os valores dos campos podem incluir outrosdocumentos arrays e arrays de documentos
251 JSON
JSON eacute um formato de troca de dados simples de faacutecil escrita pelos humanose de faacutecil interpretaccedilatildeo pelas maacutequinas Desenvolvido a partir de um subconjunto delinguagem de programaccedilatildeo JavaScript (CROCKFORD 2006)
JSON eacute construiacutedo em duas estruturas
bull Uma coleccedilatildeo de pares nomevalor reconhecido como objeto
bull Uma lista ordenada de valores reconhecido como uma matriz vetor lista ou sequecircn-cia
Um objeto eacute um conjunto natildeo ordenado de pares nomevalor Um objetocomeccedila com e termina com Cada nome eacute seguido por e o nomevalor pares satildeoseparados por
Uma matriz eacute uma coleccedilatildeo ordenada de valores Comeccedila com [e terminacom ] Os valores satildeo separados por Exemplo de uma estrutura JSON na Figura 13Este formato natildeo suporta campos binaacuterios para isso o MongoDB utiliza o formato BSON
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 28
Figura 13 ndash Exemplo de um arquivo Json Fonte(CROCKFORD 2006)
252 BSON
BSON eacute uma representaccedilatildeo binaacuteria de documentos JSON BSON eacute um formatode serializaccedilatildeo binaacuteria usado para armazenar documentos e fazer chamadas de procedi-mento remoto no MongoDB O valor de um campo pode ser qualquer um dos tipos dedados BSON incluindo outros documentos matrizes e arrays de documentos conformeFigura 14
O banco de dados MongoDB foi escolhido por possuir aleacutem de todas ascaracteriacutesticas apresentada pela Gartner mas tambeacutem por atender algumas caracteriacutesticasdo Big Data
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 29
Figura 14 ndash Exemplo de um arquivo Bson Fonte(MONGODB 2016)
26 Big Data
Big Data eacute um termo amplamente utilizado para nomear conjuntos de dadosmuito grandes ou complexos Pode-se considerar que o Big Data eacute uma quantidade enormede informaccedilotildees nos servidores de bancos de dados e que funcionam dentro de diversosservidores de rede de computadores utilizando um sistema operacional de rede interligadosentre si
As primeiras noccedilotildees do Big Data foram limitadas a algumas organizaccedilotildeescomo Google Yahoo Microsoft e Organizaccedilatildeo Europeacuteia para Pesquisa Nuclear (CERN)No entanto com os recentes desenvolvimentos em tecnologias como sensores hardware
de computador e da nuvem o aumento de poder de armazenamento e processamento ocusto cai rapidamente (ZASLAVSKY PERERA GEORGAKOPOULOS 2012)
Entretanto os principais desafios incluem anaacutelise captura curadoria de dadospesquisa compartilhamento armazenamento transferecircncia visualizaccedilatildeo e informaccedilotildeessobre privacidade dos dados
Para ajudar no processamento dos dados oriundos do Big Data a Googlecriou um modelo de programaccedilatildeo desenhado para processar grandes volumes de dadosem paralelo chamado MapReduce O MapReduce eacute um modelo que foi proposto para oprocessamento de grandes conjuntos de dados atraveacutes da aplicaccedilatildeo de tarefas capazes derealizar este processamento de forma paralela dividindo o trabalho em um conjunto detarefas independentes (Dean JeffreyGhemawat 2004)
Composto por duas fases esse processo se divide na fase de Map onde ocorresumarizaccedilatildeo dos dados como por exemplo uma contagem de uma determinada palavrapresente em uma palavra menor eacute nesta fase onde os elementos individuais satildeo transfor-mados e quebrados em pares do tipo Chave-Valor Na fase de Reduce a mesma recebe
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 30
como entrada a saiacuteda da fase Map a partir disto satildeo realizados procedimentos de filtrageme ordenamento dos dados que agrupam os pares semelhantes em conjuntos menores
Na utilizaccedilatildeo da plataforma Big Data neste trabalho foi definido a utilizaccedilatildeodos bancos de dados PostgreSQL e MongoDB e se faz necessaacuterio entender algumasterminologias e conceitos
261 PostgreSQL x MongoDB
Como o banco de dados de origem onde foram preparados os dados foi oPostgreSQL um banco de dados relacional utilizando a linguagem SQL e o banco dedados a receber as informaccedilotildees foi o MongoDB utilizando linguagem JavaScript segueabaixo algumas terminologias conforme Figura 15
Figura 15 ndash Terminologias SQL utilizado no PostgreSQL e do MongoDB
Assim como as terminologias os comandos tambeacutem satildeo diferentes Segue umcomparativo dos comandos conforme Figura 16
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 2 Fundamentaccedilatildeo Teoacuterica 31
Figura 16 ndash Comparaccedilatildeo entre os comandos SQL utilizado pelo PostgreSQL e os utilizadospelo MongoDB
27 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito os assuntos que fazem parte dos estudos de caso pro-postos Big Data eacute o assunto principal deste trabalho sendo muito importante compreenderseu funcionamento e suas necessidades que seratildeo sanadas com uma modelagem de bancode dados Natildeo Relacional baseada em arquivo JSON que seraacute armazenado e gerenciandono banco de dados MongoDB Esta modelagem por si soacute ajuda a sanar alguns problemasocasionados pela internet das coisas
A Modelagem de Banco de dados natildeo relacional eacute muito utilizada para tratargrande massa de dados natildeo estruturados O banco de dados MongoDB eacute um banco dedados amplamente utilizado por ser um dos que melhor oferece suporte a modelagem NatildeoRelacional segundo a Gartner Para compreender melhor o banco de dados e modelagemnatildeo relacional foi necessaacuterio descrever com detalhes o banco de dados e os modelosrelacionais
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
CAPIacuteTULO 3
DESENVOLVIMENTO DO TRABALHO
Este capiacutetulo se dedica a apresentar os dados utilizados nos estudos de casode onde eles se originaram como foi a sua preparaccedilatildeo antes de sua importaccedilatildeo para obanco de dados com a modelagem aqui proposta os softwares e hardwares utilizados pararealizaccedilatildeo de cada estudos de caso Tambeacutem sera descrito o passo a passo de cada estudode caso proposto por este trabalho
31 Origem dos Dados
Os dados utilizados neste trabalho foi fornecido por duas fontes diferentessendo elas o INMET (Instituto Nacional de Meteorologia) e do PGFA (Programa de Poacutes-graduaccedilatildeo de Fiacutesica Ambiental) da Universidade Federal de Mato Grosso Os dados foramentregues em planilhas eletrocircnicas Os dados utilizados nos estudos de caso proposto nestetrabalho foram obtidos originalmente de sensores que estatildeo ou estiveram instalados emestaccedilotildees de meteorologia
311 Dados do Instituto Nacional de Meteorologia
A coleta de dados eacute feita atraveacutes de sensores para mediccedilatildeo dos paracircmetros me-teoroloacutegicos a serem observados As medidas tomadas em intervalos de minuto a minutoe integralizadas para no periacuteodo de uma hora para serem transmitidas (INMET 2011)
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 33
satildeo Temperatura Instantacircnea do Ar Temperatura Maacutexima do Ar Temperatura Miacutenima doAr Umidade Relativa Instantacircnea do Ar Umidade Relativa Maacutexima do Ar Umidade Rela-tiva Miacutenima do Ar Temperatura Instantacircnea do Ponto de Orvalho Temperatura Maacuteximado Ponto de Orvalho Temperatura Miacutenima do Ponto de Orvalho Pressatildeo AtmosfeacutericaInstantacircnea do Ar Pressatildeo Atmosfeacuterica Maacutexima do Ar Pressatildeo Atmosfeacuterica Miacutenima doAr Velocidade Instantacircnea do Vento Direccedilatildeo do Vento Intensidade da Rajada do VentoRadiaccedilatildeo Solar e Precipitaccedilatildeo Acumulada no Periacuteodo
Estes dados satildeo armazenados em uma memoacuteria natildeo volaacutetil que os manteacutemmedidos por um periacuteodo especificado Os dados satildeo captados e mantidos temporariamenteem uma rede de estaccedilotildees meteoroloacutegicas que os disponibilizam para serem transmitidosvia sateacutelite ou telefonia celular para a sede do INMET
Os sensores ficam instalados em uma estaccedilatildeo meteoroloacutegica automaacutetica (EMA)que nada mais eacute do que um instrumento de coleta automaacutetica de informaccedilotildees ambientaislocais (meteoroloacutegicas hidroloacutegicas ou oceacircnicas) composta pelos seguintes elementosSub-sistema de coleta de dados Sub-sistema de controle e armazenamento Sub-sistemade energia (painel solar e bateria) e Sub-sistema de comunicaccedilatildeo
Aleacutem dos sub-sistemas mencionados a estaccedilatildeo deve ser instalada em uma basefiacutesica numa aacuterea livre de obstruccedilotildees naturais e prediais situada em aacuterea gramada miacutenimade 14m por 18m cercada por tela metaacutelica (para evitar entrada de animais) Os sensores edemais instrumentos satildeo fixados em um mastro metaacutelico de 10 metros de altura aterradoeletricamente (malha de cobre) e protegido por paacutera-raios Os aparelhos para as mediccedilotildeesde chuva (pluviocircmetro) e de radiaccedilatildeo solar bem como a antena para a comunicaccedilatildeo ficamsituados fora do mastro mas dentro do cercado conforme Figura 17
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 34
Figura 17 ndash Estaccedilatildeo Meteoroloacutegica Automaacutetica Fonte(INMET 2011)
312 Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental daUniversidade Federal de Mato Grosso
Assim como o INMET os dados do Programa de Poacutes-Graduaccedilatildeo da FiacutesicaAmbiental (PGFA) da Universidade Federal de Mato Grosso (UFMT) foram coletadosatraveacutes de sensores que captaram dados micrometeoroloacutegicos da Torre micrometeoroloacutegicaCambarazal conforme Figura 18 Por se tratar de dados micrometeoroloacutegicos os dadosdo PGFA foram coletados na ordem de segundos o que gera uma grande quantidade dedados
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 35
Figura 18 ndash Torre Micrometeoroloacutegica Cambarazal Fonte(FEDERAL et al 2009)
Devido a grande quantidade de dados eacute necessaacuterio realizar um processo delimpeza antes da disponibilizaccedilatildeo dos dados para que se aproveite somente os dados uacuteteis
No PGFA aleacutem do processo de anaacutelise e buscas dos dados mais uacuteteis outroproblema eacute o de armazenamento desses dados Na grande maioria das vezes cada pesqui-sador manteacutem os dados em planilhas eletrocircnicas no computador pessoal dificultando ocompartilhamento da informaccedilatildeo Devido a esta dificuldade as informaccedilotildees foram cedidaspor um dos pesquisadores do PGFA Poreacutem para que os dados pudessem ser armazenadospara realizaccedilatildeo dos estudos de caso fez-se necessaacuterio transformar as informaccedilotildees queestavam em planilha eletrocircnica para o formato de documento JSON
As informaccedilotildees cedidas em formato de planilha eletrocircnica pelo INMET e peloPGFA foram modelados no formato JSON
32 Cenaacuterio
O Cenaacuterio utilizado para realizar os estudos de caso da modelagem eacute umconjunto de dados meteoroloacutegicos que primeiramente foram inseridos em um bancode dados relacional SQL Server 2016 instalado em uma maacutequina virtual com sistema
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 36
operacional Windows Por conta dos poucos recursos e componentes em relaccedilatildeo ao tipo dedados no formato Json foi muito difiacutecil gerar os arquivos na modelagem proposta
Os arquivos que foram possiacuteveis de gerar no SQL Server causou um graveproblema de desempenho fazendo com que fosse necessaacuterio escolher outro banco dedados Apoacutes anaacutelise criteriosa foi utilizado o banco de dados PostgreSQL instalado emuma maacutequina virtual com sistema operacional Windows e posteriormente os dados foramextraiacutedos do banco de dados relacional para arquivos no formato JSON Os arquivos fiacutesicosforam copiados para outra maacutequina virtual com sistema operacional Linux para seremimportados no banco de dados Natildeo Relacional MongoDB Ambas as maacutequinas virtuaisforam instaladas dentro da mesma maacutequina fiacutesica compartilhando o mesmo hardware
Como os dados fornecidos estavam em um banco de dados relacional precisa-vam ser tratados antes de importar para o banco de dados Natildeo Relacionalsendo necessaacuterioa realizaccedilatildeo de uma preparaccedilatildeo dos dados
321 Preparaccedilatildeo dos Dados
Para realizar a preparaccedilatildeo dos dados foi escolhido o banco de dados Post-greSQL que possui compatibilidade com o tipo de dados JSON e aleacutem disso a cre-dibilidade de ser um banco de dados robusto e amplamente utilizado pelo mercadoApoacutes a escolha do banco de dados o primeiro passo eacute criar as tabelas para receberos dados das planilhas eletrocircnicas de cada fonte de dados onde foi incluiacutedo o atri-buto chamado fonte conforme Figuras 19 e 20 para identificar a origem dos dados
Figura 19 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 37
Figura 20 ndash Script para criaccedilatildeo da tabela de dados para receber os dados originais doINMET
Feito isso foi necessaacuterio realizar a importaccedilatildeo dos dados de cada fonte dedados atraveacutes da funcionalidade de importaccedilatildeo da ferramenta de interface graacutefica PgAdminconforme Figura 21
Figura 21 ndash Tela mostrando a funcionalidade de importaccedilatildeo da ferramenta de interfacegraacutefica PgAdmin
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 38
Para que a funcionalidade funcione corretamente eacute preciso realizar algumasverificaccedilotildees como o formato de data campos nulos e linhas quebradas que precisaram sercorrigidas antes da realizaccedilatildeo da importaccedilatildeo para o banco de dados
Apoacutes a importaccedilatildeo dos dados de origem nas tabelas criadas conforme Figura22 foram realizados varias tentativas de exportaccedilatildeo direto das tabelas de origem para osarquivos no formato JSON que resultaram em scripts complexos e de execuccedilatildeo muito lentachegando a gerar um arquivo de 10 mil registros por hora Observando esta dificuldade foinecessaacuterio otimizar o processo e para isso houve a necessidade de criar tabelas auxiliarespara ajudar na transformaccedilatildeo do formato dos dados originais para o formato JSON no proacute-prio banco de dados relacional Sendo assim entatildeo foram criados as tabelas auxiliares paracada fonte de dados incluindo em sua estrutura um atributo chamado idpara identificarcada registro e auxiliar no momento da exportaccedilatildeo destes dados Tambeacutem foi criado um atri-buto do tipo JSON chamado infopara guardar todos os outros atributos de cada registro databela de origem As Figura 23 e 24 representam os scripts de criaccedilatildeo de cada tabela auxiliar
Figura 22 ndash Tela mostrando alguns dados importados no PostgreSQL
Figura 23 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosda PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 39
Figura 24 ndash Script de criaccedilatildeo de tabela auxiliar para transformaccedilatildeo do formato dos dadosdo INMET
Em seguida os dados foram transferidos das tabelas onde estatildeo os dadosoriginais para as tabelas auxiliares e para isso foi desenvolvido um script para cada fontede dados conforme as Figuras 25 e 26
Figura 25 ndash Script de inserccedilatildeo de dados na tabela auxiliar do PGFA
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 40
Figura 26 ndash Script de inserccedilatildeo de dados na tabela auxiliar do INMET
Apoacutes transferir os dados da tabela de origem para a tabela com o formatoJSON os dados se apresentam conforme Figura 27
Figura 27 ndash Tela mostrando alguns dados importados no banco de dados PostgreSQL comformato JSON
Depois dos dados transferidos para as tabelas auxiliares foi possiacutevel gerar osarquivos em formato JSON desta vez gerando aproximadamente 50 mil registros porarquivo no tempo meacutedio de 45 segundos por arquivo conforme Figura 28
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 41
Figura 28 ndash Tela mostrando script de geraccedilatildeo dos arquivos JSON e o tempo de execuccedilatildeodo script
Os arquivos devem ser gerados na modelagem aqui proposta que seraacute deta-lhada neste capiacutetulo e para gerar os arquivos nesta modelagem foram utilizados algunsequipamentos virtuais e fiacutesicos
322 Equipamentos Utilizados
Para realizar a inclusatildeo das planilhas eletrocircnicas na base de dados foram neces-saacuterios a criaccedilatildeo de servidores virtualizados no sistema de virtualizaccedilatildeo Oracle VirtualBoxversatildeo 5110 A maacutequina hospedeira possui processador Intel Core i7-4500U 16GB dememoacuteria RAM com sistema operacional Windows 10
Foram criadas duas maacutequinas virtuais (VM) para o desenvolvimento destetrabalho a fim de que as configuraccedilotildees do SGBD de conversatildeo dos dados natildeo afeteas configuraccedilotildees do SGBD de recepccedilatildeo dos dados por possiacuteveis erros decorrentes deinstalaccedilatildeo ou parametrizaccedilotildees
Todas as maacutequinas virtualizadas tem a mesmas configuraccedilotildees de hardware
sendo elas 1 nuacutecleo de Processador Intel Core i7-4500 Disco Riacutegido 60GB 8GB deMemoacuteria RAM e Placa de Rede em modo NAT
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 42
Na maacutequina que foi construiacuteda para realizar a conversatildeo dos dados foi ins-talado o banco de dados PostgreSQL versatildeo 961 64bits e o SGBD PgAdmin3 versatildeo1230a de coacutedigo aberto e o sistema operacional foi o Windows Server 2012 64bits
Na maacutequina que foi construiacuteda para realizar a recepccedilatildeo dos dados foi instaladoo banco de dados MongoDB versatildeo 328 e a ferramenta de interface graacutefica Robomongo090-RC9 principalmente por ser nativo 1 do MongoDB e o sistema operacional LinuxUbuntu 1604 LTS 64-bit
33 Estudo de Caso
Neste trabalho foram desenvolvidos trecircs estudos de caso uma modelagemdos dados em JSON para extrair os dados do banco de dados relacional em formatode documento para ser utilizado no segundo estudo de caso que eacute popular o banco dedados NoSQL com os documentos gerados pela modelagem e o terceiro estudo de casoeacute realizar consultas para verificaccedilatildeo de performance do banco de dados com massa deaproximadamente 1 milhatildeo de registros
331 Estudo de Caso 1 Modelagem dos dados
Para validar o estudo de caso foi necessaacuterio realizar a modelagem atraveacutes deimplementaccedilatildeo de regras em JavaScript que eacute trabalhado em uma camada anterior aobanco de dados Na verdade a modelagem eacute um documento JSON que posteriormente eacutepersistido no banco de dados
A primeira fonte de dados eacute a do Programa de Poacutes-Graduaccedilatildeo em FiacutesicaAmbiental da Universidade Federal de Mato Grosso que compreende a anaacutelise de solo Asegunda fonte de dados eacute do Instituto Nacional de Meteorologia Utilizando este cenaacuteriofoi desenvolvido uma modelagem natildeo relacional para atender os dados compreendidoscomo dados da Internet das coisas
Os dados disponibilizados em planilhas eletrocircnicas primeiramente foramimportados para o banco de dados relacional PostgreSQL que foi escolhido por possuirfunccedilotildees nativas do banco de dados para tratamento de documentos JSON Utilizandoestas funccedilotildees nativas do PostgreSQL foi desenvolvido um script para gerar os documentosJSON para gerar os documentos de cada fonte de dado conforme Figura 28
Como no cenaacuterio proposto grande parte dos registros estatildeo relacionados ainformaccedilotildees temporais e vem de fontes de dados diferentes a modelagem foi construiacutedaem formato JSON com um conjunto de regras em javascript1 referencia sobre a palavra nativo httpauslandcombrerp-diferenca-entre-software-integrado-
embarcado-e-nativo
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 43
A ideia da modelagem eacute ser o mais flexiacutevel possiacutevel sendo assim natildeo eacutenecessaacuterio a criaccedilatildeo de tabelas ou no caso do MongoDB coleccedilotildees antes da inserccedilatildeo dosdados Caso a coleccedilatildeo natildeo exista o proacuteprio MongoDB se encarrega de criar antes dainserccedilatildeo dos documentos Os dados seratildeo armazenados conforme a modelagem em JSONque constitui em armazenar um documento com dois documentos internos ou tambeacutemchamados de sub-documentos
O primeiro documento interno possui um conjunto de dados denominadosKEYS onde ficam no miacutenimo um campo que seraacute utilizado como chave podendo possuirmais campos chaves Estes campos chaves devem ser campos que existam tambeacutem nosegundo documento interno
O segundo documento interno possui um conjunto de dados denominadoDADOS onde ficam os atributos do documento podendo incluir qualquer tipo de dadosconforme Figura 29
Figura 29 ndash Exemplo da modelagem vazia
Poreacutem para o preenchimento correto da modelagem eacute importante seguir algu-mas regras obrigatoacuterias
Regras
Primeiramente eacute necessaacuterio que o documento possua os dois conjuntos dedados KEYS e DADOS citados acima
No conjunto KEYS eacute necessaacuterio que se informe no miacutenimo um campo quepossa ser utilizado como chave ou um conjunto de campos e que possa facilitar a buscapelo documento
No conjunto DADOS pode possuir qualquer tipo de dados inclusive os dadosincluiacutedos no conjunto KEYS
No cenaacuterio proposto foram criados documentos com o primeiro conjunto dedados possuindo cinco campos iniciais essenciais sendo eles fonte ano mecircs dia e horaNo segundo conjunto de dados foi colocado os dados temporais extraiacutedos dos dados dos
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 44
sensores das estaccedilotildees meteoroloacutegicas disponibilizados pelo INMET e PGFA Dados estesque jaacute foram processados
Os dados foram disponibilizados no formato de documento de texto e pararealizar o estudo de caso foi necessaacuterio transformar do formato texto para o formato JSONFormato este utilizado para atender a modelagem proposta
Utilizando os dados disponibilizados no contexto deste trabalho ambos do-cumentos possuem os mesmos atributos no conjunto KEYS que eacute o campo necessaacuteriopara sua localizaccedilatildeo e identificaccedilatildeo dentro do banco de dados Jaacute o segundo conjunto dedados eacute apresentado com os atributos diferentes Os documentos possuem no conjuntoDADOS cada um os seus atributos disponibilizados por cada fonte fornecedora dos dadosmeteoroloacutegicos Apoacutes a geraccedilatildeo dos documentos eacute possiacutevel realizar a populaccedilatildeo da basede dados no MongoDB
332 Estudo de Caso 2 Popular base de dados
Para realizar a populaccedilatildeo dos dados o importante inicialmente eacute realizar umabusca no banco de dados com os dados do conjunto KEYS do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com exatamenteos mesmos campos e valores do conjunto KEYS do documento a ser inserido a regraatualizaraacute o documento do banco de dados com os dados do documento a ser inserido
No caso da busca encontrar no banco de dados um documento com os mesmoscampos poreacutem qualquer valor diferente do conjunto KEYS do documento a ser inserido aregra cria um novo documento no banco de dados com os atributos contidos no documentoa ser inserido
No caso da busca natildeo encontrar nenhum documento no banco de dados com oconjunto KEYS que contenham os mesmos campos que o conjunto KEYS do documento aser inserido a regra cria um novo documento no banco de dados com os atributos contidosno documento a ser inserido
As regras citadas satildeo representadas pela linha de comando representada naFigura 30
Figura 30 ndash Script para realizar a populaccedilatildeo dos documentos JSON na base de dados
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 45
O trecho do comando dbtesteupdate identifica o banco de dados a coleccedilatildeo aser atualizada ou inserida o comando update em conjunto com outros paracircmetros realizauma busca no banco atualiza ou insere dados na coleccedilatildeo escolhida
O trecho do comando keys inputkeys representa a pesquisa pelos docu-mentos existentes
O trecho do comando $set keys inputkeys dados inputdados alocaos dados a serem atualizados ou inseridos
O trecho do comando upsert true eacute o paracircmetro que permite o comandoupdate inserir um novo documento caso o documento natildeo exista no banco de dados
Apoacutes a realizaccedilatildeo da populaccedilatildeo dos dados na base de dados MongoDB satildeorealizados verificaccedilotildees de performance
333 Estudo de Caso 3 Verificaccedilatildeo de performance
Para realizar a verificaccedilatildeo de performance dos bancos de dados seratildeo utilizados2 tipos de consulta em cada banco de dados uma simples e uma complexa Cada consultaseraacute executada com 4 limites de registros sendo uma com 1 mil registros uma com 10 milregistros uma com 50 mil registros e a uacuteltima com 100 mil registros As consultas seratildeorepetidas 10 vezes cada uma e o resultado seraacute a meacutedia aritmeacutetica simples dos resultadosde cada consulta exclusiva
Exemplo a consulta simples seraacute executada 10 vezes com 1 mil registros seratildeosomados os tempos dos resultados das 10 consultas e posteriormente dividido por 10 oresultado final eacute o tempo meacutedio de execuccedilatildeo da consulta simples com mil registros
Para as operaccedilotildees realizadas no banco de dados PostgreSQL o coacutedigo daconsulta foi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit1000
bull Consulta simples com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit10000
bull Consulta simples com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit50000
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 46
bull Consulta simples com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes limit100000
bull Consulta complexa com 1 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 1000
bull Consulta complexa com 10 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 10000
bull Consulta complexa com 50 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 50000
bull Consulta complexa com 100 mil registros
SELECT FROM publicpgfaa p inner join publicinmet i on pmes = imes wherepano lt 2015 and pano gt 1995 and pmes = 1 and pmes = 12 limit 100000
Para as operaccedilotildees realizadas no banco de dados MongoDB o coacutedigo da consultafoi estruturado da seguinte forma
bull Consulta simples com 1 mil registros
dbgetCollection(rsquotccrsquo)find()limit(1000)
bull Consulta simples com 10 mil registros
dbgetCollection(rsquotccrsquo)find()limit(10000)
bull Consulta simples com 50 mil registros
dbgetCollection(rsquotccrsquo)find()limit(50000)
bull Consulta simples com 100 mil registros
dbgetCollection(rsquotccrsquo)find()limit(100000)
bull Consulta complexa com 1 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(1000)
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 3 Desenvolvimento do Trabalho 47
bull Consulta complexa com 10 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(10000)
bull Consulta complexa com 50 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(50000)
bull Consulta complexa com 100 mil registros
dbgetCollection(rsquotccrsquo)find(keysano$lte2015keysano$lte1995
dadosmes$ne1dadosmes$ne12)limit(100000)
34 Resumo do Capiacutetulo
Neste capiacutetulo foi descrito a origem dos dados a preparaccedilatildeo desses dados emqual cenaacuterio seratildeo realizados cada um dos estudos de caso e foi descrito com detalhes aconfiguraccedilatildeo das maacutequinas sistemas operacionais e banco de dados nelas instalados
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
48
CAPIacuteTULO 4
RESULTADOS E DISCUSSOtildeES
A seguir seratildeo apresentados os resultados de todos os estudos de caso damodelagem dos dados populaccedilatildeo da base de dados e verificaccedilatildeo de performance
41 Resultado do Estudo de Caso 1 Modelagem dos dados
Utilizando a modelagem proposta apoacutes executar o script de geraccedilatildeo dos do-cumentos em formato JSON cada arquivo JSON possui vaacuterios documentos e cada umdeles preenchidos com os dados do contexto que se apresenta conforme os exemplosrepresentados pela Figura 31 com os dados disponibilizados pelo INMET e na figura 32com os dados disponibilizados pelo PGFA Estes satildeo exemplos de como os documentosficam com a modelagem proposta assim os documentos podem ser utilizados para realizara populaccedilatildeo na base de dados MongoDB
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 49
Figura 31 ndash Exemplo da modelagem preenchida com os dados da INMET Fonte codigoJson com os dados do INMET
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 50
Figura 32 ndash Exemplo da modelagem preenchida com os dados da PGFA Fonte codigoJson com os dados do PGFA
42 Resultado do Estudo de Caso 2 Popular base de dados
Apoacutes a populaccedilatildeo dos documentos na coleccedilatildeo eacute possiacutevel verificar se os dadosforam inseridos corretamente executando na interface graacutefica RoboMongo o seguintescript dbgetCollection(rsquonome_coleccedilatildeorsquo)find() conforme a Figura 33 e verificar comoficou cada documento abrindo o registro diretamente no RoboMongo conforme Figuras 34com o resultado da inserccedilatildeo dos dados da PGFA e Figura 35 com o resultado da inserccedilatildeodos dados do INMET
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 51
Figura 33 ndash Exemplos de documentos inseridos no banco de dados MongoDB
Figura 34 ndash Dados da PGFA inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do PGFA
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 52
Figura 35 ndash Dados da INMET inseridos no banco de dados Fontetela com o resultado dainserccedilatildeo dos dados do INMET
43 Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
Apoacutes verificar que os dados foram gravados no banco de dados MongoDBforam realizados os testes de performance Os testes foram realizados conforme o item333 desse trabalho poreacutem o banco de dados MongoDB natildeo conseguiu concluir a apre-sentaccedilatildeo dos dados ao selecionar 100 mil registros tanto para consulta simples como paraconsulta complexa conforme resultados apresentados na Figura36 A quantidade maacuteximade registros apresentadas pelo banco de dados MongoDB foi de 50 mil registros Aoultrapassar a quantidade de 50 mil registros durante as consultas no MongoDB a interfacegraacutefica Robomongo fechava apoacutes alguns segundos de execuccedilatildeo
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 53
Figura 36 ndash Tabela com o resultado dos tempos meacutedios das consultas dos banco de dadosPostgreSQL e MongoDB
Mesmo o banco de dados MongoDB natildeo conseguindo apresentar os resultadosdas consultas de 100 mil registros para as consultas simples alcanccedilando o limite de 50 milregistros o banco de dados MongoDB quase sempre apresentou resultados proacuteximo de0 segundos enquanto o PostgreSQL aumentou o tempo de resposta a cada quantidade deregistros que foi consultada conforme o graacutefico da Figura 37 atingindo uma meacutedia superiora 50 segundos com a consulta de 100 mil registros
Figura 37 ndash Graacutefico com o resultado dos tempos meacutedios das consultas simples realizadosno banco de dados PostgreSQL e MongoDB
Assim como nas consultas simples o banco de dados MongoDB sofreu omesmo problema nas consultas complexas natildeo marcando tempo com a consulta de 100mil registros e registrando novamente a marca limite dos 50 mil registros Repetindo oque aconteceu nas consultas simples o banco de dados MongoDB registrou para todas asconsultas um tempo meacutedio abaixo de 0 segundos jaacute ao contrario das consultas simpleso banco de dados PostgreSQL apresentou uma resposta mais raacutepida para cada consultaque era feita poreacutem sempre mantendo uma meacutedia muito superior ao resultado apresentado
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 4 Resultados e discussotildees 54
pelo MongoDB O resultado mais baixo apresentado pelo banco de dados PostgreSQLfoi a marca de aproximadamente 40 segundos conforme Figura 38 voltando a aumentar otempo de consulta quando consultado 100 mil registros
Figura 38 ndash Graacutefico com o resultado dos tempos meacutedios das consultas complexas realiza-dos no banco de dados PostgreSQL e MongoDB
A fim de entender esse problema nas consultas de 100 mil registros encontradosna execuccedilatildeo realizada na interface graacutefica Robomongo foi realizado uma pesquisa emfoacuterum na internet e atraveacutes do site Stack Overflow que eacute a maior comunidade on-linepara programadores compartilhem seus conhecimentos e promover suas carreiras fundadoem 2008 com mais de 6 milhotildees de programadores registrados e que recebe mais de 40milhotildees de visitantes por mecircs foi encontrado um caso semelhante
Usando Mono 321 no Ubuntu 1204 em um projeto CSharp que se conectaao MongoDB e tenta consultar e atualizar os documentos executando 4 scripts diferentesesperando receber 10 mil documentos de resultado sendo que em um deles natildeo apresentanenhum resultado Caso esse consultado no dia 06022017 e que pode ser verificado atraveacutesdo seguinte link httpstackoverflowcomquestions19067189strange-performance-test-results-with-different-write-concerns-in-mongodb-c-shrq=1
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
55
CAPIacuteTULO 5
CONCLUSOtildeES
Com este trabalho realizou-se a investigaccedilatildeo dos modelos de banco de dadosnatildeo relacional conhecendo seus conceitos e suas diferenccedilas para outros padrotildees atu-almente existentes Dos modelos investigados o modelo orientado a documento foi oescolhido por ser mais flexiacutevel escalaacutevel adaptaacutevel aceitar dados textuais e binaacuterios emvaacuterios formatos diferentes
Apoacutes esta escolha foi possiacutevel investigar e testar o armazenamento de dadosoriundos da Internet das Coisas Os dados foram previamente preparados em um bancode dados relacional e posteriormente foi facilmente armazenado no banco de dados natildeorelacional permitindo dar sequecircncia ao trabalho
Feito os testes de armazenamento foram desenvolvidos os estudos de casoutilizando dados sensoriais meteoroloacutegicos do Instituto Nacional de Meteorologia e doprograma de poacutes-graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grossoque sofreram uma preacutevia preparaccedilatildeo
Com os dados preparados foram realizados a execuccedilatildeo avaliaccedilatildeo e homolo-gaccedilatildeo de cada estudo de caso Estudo de caso 1 - Modelagem dos dados foi realizado amodelagem dos dados atraveacutes do modelo orientado a documentos desenvolvido em lingua-gem JavaScript conforme regras estabelecidas no item 331 deste trabalho e gravados noformato de arquivo JSON
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Capiacutetulo 5 Conclusotildees 56
Estudo de caso 2 - Popular base de dados com os documentos salvos emarquivo foi possiacutevel importar os mesmos para dentro do banco de dados seguindo as regrasestabelecidas no item 332 deste trabalho
Estudo de caso 3 - Verificaccedilatildeo de performance foi realizado testes de perfor-mance atraveacutes de vaacuterias consultas em quantidade diferentes de registros em 2 bancos dedados diferentes sendo eles o PostgreSQL e o MongoDB e o resultado apresentou umproblema de resposta da consulta com limite de 100 mil registros quando realizado noMongoDB atraveacutes de sua interface graacutefica Robomongo poreacutem natildeo foi possiacutevel ateacute o mo-mento identificar se o problema ocorreu no banco de dados ou na interface graacutefica Mesmocom o problema ocorrido na consulta dos 100 mil registros realizada no MongoDB obanco de dados PostgreSQL atraveacutes de sua interface graacutefica PgAdmin apresentou resultadode tempo de resposta muito superior ao tempo de resposta apresentado pelo MongoDBconcluindo que mesmo com os problemas apresentados o banco de dados natildeo relacionalobteve um desempenho melhor nos testes efetuados
O resultado final demonstra que assim como o cenaacuterio utilizado para os testeseacute possiacutevel utilizar o mesmo esquema para diversos tipos de cenaacuterios diferentes ondeao menos um atributo do sub-documento KEYS exista tanto em uma fonte como emoutra fonte de dados envolvidas como no sub-documento DADOS do proacuteprio documentoprincipal
De forma geral atraveacutes dos estudos de caso percebe-se que os objetivos foramalcanccedilados sendo que a modelagem construiacuteda possibilita o armazenamento de grandemassa de dados como as dos sensores meteoroloacutegicos Por natildeo possuir uma coleccedilatildeopreacute-definida possibilita a inserccedilatildeo de qualquer tipo de dados obedecendo as regras damodelagem fazendo com que a modelagem seja escalaacutevel e flexiacutevel Como a modelagemnecessita que ao menos que um atributo seja igual entre todos os sub-documentos KEYSa modelagem permite o cruzamento de dados entre dados de contextos diferentes possibili-tando a inserccedilatildeo na mesma coleccedilatildeo e a recuperaccedilatildeo dos documentos dentro da coleccedilatildeo setorna mais raacutepida poreacutem foi identificado um problema apresentado na interface graacuteficaRobomongo que ao precisar realizar uma consulta que traga de uma soacute vez mais de 50 milregistros a aplicaccedilatildeo acaba fechando
Para trabalhos futuros existe uma grande quantidade de possibilidades como ade resolver o problema aqui encontrado sobre a consulta com mais de 50 mil registros nainterface graacutefica Robomongo aleacutem de dados textuais testar a modelagem com dados binaacute-rios e a realizaccedilatildeo de testes da modelagem em outros bancos de dados NoSQL Construirsistemas para sua utilizaccedilatildeo onde seraacute realizada inserccedilatildeo consultas e alteraccedilotildees podendoassim avaliar melhor sua flexibilidade adaptabilidade escalabilidade e seu desempenho
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
57
REFEREcircNCIAS
Abraham Silberschatz Henry Korth S S Sistema de Banco de Dados Terceira e SatildeoPaulo Makron Books 1999 778 p vii 8 9 10 11 12 13 14 16 17 19 20 21
BOOTON J IBM finally reveals why it bought The Weather Com-pany 2016 Disponiacutevel em lthttpwwwmarketwatchcomstoryibm-finally-reveals-why-it-bought-the-weather-company-2016-06-15gt 4
BRITO R W Bancos de dados NoSQL x SGBDs relacionais anaacutelise comparativaFaculdade Farias Brito e Universidade de Fortaleza 2010 Disponiacutevel emlthttpscholargooglecomscholarhl=enampbtnG=Searchampq=intitleBancos+de+Dados+NoSQL+x+SGBDs+Relacionais++Anlise+Comparatigt 22
CROCKFORD D The applicationjson Media Type for JavaScript Object Notation(JSON) 2006 Disponiacutevel em lthttpwwwietforgrfcrfc4627txtnumber=4627gt vii27 28
Dean JeffreyGhemawat S MapReduce Simplified Data Processing on Large Clusters2004 1 p Disponiacutevel em lthttpresearchgooglecomarchivemapreducehtmlgt 29
ELIOT State of MongoDB 2010 Disponiacutevel em lthttpblogmongodborgpost434865639state-of-mongodb-march-2010gt 26
ELMASRI R NAVATHE S B Fundamentals of Database Systems Database v 28p 1029 2003 ISSN 19406029 21
ELMASRI R NAVATHE S B Sistemas de Banco de Dados - 6a Edi-ccedilatildeopdf [sn] 2011 790 p ISBN 978-85-7936-085-5 Disponiacutevel emlthttpfileshare3590depositfilesorgauth-1426943513b5db19f23dd9b11ebf50d2-18739203223-1997336327-152949425-guestFS359-5SistBD6Edrargt vii 6 7 10 1416 17 18
FEDERAL U et al Simulaccedilatildeo da evapotranspiraccedilatildeo e otimizaccedilatildeo computacional domodelo de ritchie com clusters de bancos de dados 2009 vii 35
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Referecircncias 58
GARTNER Quadrante Maacutegico da Gartner para o DBMS Operacional 2015 Disponiacutevelem lthttpwwwintersystemscombrprodutoscachegartners-gartner-dbmsgt vii 24 25
INMET I N d M Nota Teacutecnina No 0012011SEGERLAIMECSCINMET Rede deestaccedilotildees meteoroloacutegicas automaacuteticas do INMET n 001 p 1ndash11 2011 vii 32 34
LI T et al A Storage Solution for Massive IoT Data Based on NoSQL 2012 IEEEInternational Conference on Green Computing and Communications p 50ndash57 2012Disponiacutevel em lthttpieeexploreieeeorglpdocsepic03wrapperhtmarnumber=6468294gt vii 2 3 23 24
MONGO Databases and Collections 2016 1 p Disponiacutevel em lthttpsdocsmongodbcommanualcoredatabases-and-collectionsgt vii 26
MONGODB Top 5 Considerations When Evaluating NoSQL Databases n June p 1ndash72015 26
MONGODB Documents 2016 Disponiacutevel em lthttpsdocsmongodbcommanualcoredocumentgt vii 27 29
PERNAMBUCO U F D Uma Arquitetura de Cloud Computing para anaacutelise de Big Dataprovenientes da Internet Of Things Uma Arquitetura de Cloud Computing para anaacutelise deBig Data provenientes da Internet Of Things 2014 3 15
PIRES P F et al Plataformas para a Internet das Coisas Anais do Simpoacutesio Brasileiro deRedes de Computadores e Sistemas Distribuiacutedos p 110ndash169 2015 3
POSTGRES PostgreSQL 2017 Disponiacutevel em lthttpswwwpostgresqlorggt 24
SADALAGE P FOWLER M NoSQL Distilled A Brief Guide to the EmergingWorld of Polyglot Persistence [sn] 2012 192 p ISSN 1098- ISBN 9780321826626Disponiacutevel em lthttpmedcontentmetapresscomindexA65RM03P4874243Npdf$delimiter026E30F$nhttpbooksgooglecombookshl=enamplr=ampid=AyY1a6-k3PICampoi=fndamppg=PT23ampdq=NoSQL+Distilled+A+Brief+Guide+to+the+Emerging+World+of+Polyglot+Persistenceampots=6GAoDEGKNiampsig=mz6Pgtvii 15 22 23
SILVERSTON L The Data Model Resource Book [Sl sn] 1997 ISBN 0-471-15364-86 7
SOLDATOS J SERRANO M HAUSWIRTH M Convergence of utility computingwith the Internet-of-things In Proceedings - 6th International Conference on InnovativeMobile and Internet Services in Ubiquitous Computing IMIS 2012 [Sl sn] 2012 p874ndash879 ISBN 9780769546841 1
SOUZA V C O SANTOS M V C Amadurecimento Consolidaccedilatildeo e Performance deSGBDs NoSQL - Estudo Comparativo XI Brazilian Symposium on Information System p235ndash242 2015 3
STROZZI C NoSQL - A Relational Database Management System 2007 Disponiacutevel emlthttpwwwstrozziitcgi-binCSAtw7Ien_USNoSQLHomePgt 14 15
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-
Referecircncias 59
Veronika Abramova Jorge Bernardino and Pedro Furtado EXPERIMENTALEVALUATION OF NOSQL DATABASES International Journal of DatabaseManagement Systems ( IJDMS ) Vol6 No3 June 2014 v 6 n 100 p 1ndash16 2005 3
WHITTEN J BENTLEY L DITTMAN K Systems analysis and designmethods IrwinMcGraw-Hill 1998 ISBN 9780256199062 Disponiacutevel emlthttpsbooksgooglecombrbooksid=0OEJAQAAMAAJgt 8
ZASLAVSKY A PERERA C GEORGAKOPOULOS D Sensing as a Service and BigData Proceedings of the International Conference on Advances in Cloud Computing(ACC-2012) p 21ndash29 2012 ISSN 9788173717789 1 2 29
- Folha de aprovaccedilatildeo
- Dedicatoacuteria
- Agradecimentos
- Resumo
- Abstract
- Sumaacuterio
- Lista de ilustraccedilotildees
- Introduccedilatildeo
- Fundamentaccedilatildeo Teoacuterica
-
- Modelagem de Dados
-
- Modelos Loacutegicos com Base em Objetos
-
- Modelo Entidade-Relacionamento
- Modelo Orientado a Objeto
- Modelo Semacircntico de Dados
- Modelo Funcional de Dados
-
- Modelos Loacutegicos com Base em Registros
-
- Modelo Relacional
- Modelo de Rede
- Modelo Hieraacuterquico
- Modelo Orientado a Objetos
-
- Modelos Fiacutesicos de Dados
- Modelo Natildeo Relacional
-
- ChaveValor
- Orientado a Colunas
- Orientado a Documentos
- Grafos
-
- Banco de Dados
- Sistema Gerenciador de Banco de Dados
-
- SGBD - Relacional
- SGBD - Natildeo Relacional
-
- PostgreSQL
- MongoDB
-
- JSON
- BSON
-
- Big Data
-
- PostgreSQL x MongoDB
-
- Resumo do Capiacutetulo
-
- Desenvolvimento do Trabalho
-
- Origem dos Dados
-
- Dados do Instituto Nacional de Meteorologia
- Dados do Programa de Poacutes-Graduaccedilatildeo da Fiacutesica Ambiental da Universidade Federal de Mato Grosso
-
- Cenaacuterio
-
- Preparaccedilatildeo dos Dados
- Equipamentos Utilizados
-
- Estudo de Caso
-
- Estudo de Caso 1 Modelagem dos dados
- Estudo de Caso 2 Popular base de dados
- Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Resumo do Capiacutetulo
-
- Resultados e discussotildees
-
- Resultado do Estudo de Caso 1 Modelagem dos dados
- Resultado do Estudo de Caso 2 Popular base de dados
- Resultado do Estudo de Caso 3 Verificaccedilatildeo de performance
-
- Conclusotildees
- Referecircncias
-