Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things...

72
UNIVERSIDADE FEDERAL DE MATO GROSSO INSTITUTO DE COMPUTAÇÃO COORDENAÇÃO DE ENSINO DE ESPECIALIZAÇÃO EM BANCO DE DADOS MODELAGEM DE BANCO DE DADOS NÃO RELACIONAL EM PLATAFORMA BIG DATA VISANDO DADOS DE INTERNET DAS COISAS CLEITON VITOR FERNANDES CUIABÁ - MT 2017

Transcript of Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things...

Page 1: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 2: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 3: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 4: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

- 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
Page 5: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 6: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 7: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 8: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 9: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 10: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 11: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 12: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 13: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 14: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 15: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 16: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 17: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 18: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 19: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 20: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 21: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 22: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 23: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 24: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 25: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 26: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 27: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 28: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 29: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 30: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 31: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 32: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 33: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 34: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 35: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 36: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 37: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 38: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 39: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 40: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 41: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 42: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 43: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 44: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 45: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 46: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 47: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 48: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 49: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 50: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 51: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 52: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 53: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 54: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 55: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 56: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 57: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 58: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 59: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 60: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 61: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 62: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 63: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 64: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 65: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 66: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 67: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 68: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 69: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 70: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 71: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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
Page 72: Modelagem de banco de dados Não Relacional em plataforma ... Vitor Fern… · Internet of Things works with a great amount of devices connected to Internet and the constant growth

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