Gonçalo da Cruz Pereira e Sousarepositorium.sdum.uminho.pt/bitstream/1822/40119/1...a chamar Big...

Gonçalo da Cruz Pereira e Sousa

Document-Based Databases:Estudo Comparativo noÂmbito das Bases de Dados NoSql

Gonç

alo

da C

ruz P

ereir

a e

Sous

a

outubro de 2015UMin

ho |

201

5Do

cum

ent-B

ased

Dat

abas

es:

Estu

do C

ompa

rativ

o no

Âm

bito

das

Bas

es d

e Da

dos

NoS

ql

Universidade do MinhoEscola de Engenharia

outubro de 2015

Dissertação de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia e Gestão de Sistemas de Informação

Trabalho efectuado sob a orientação doProfessor Doutor José Luís Mota Pereira

Gonçalo da Cruz Pereira e Sousa

Document-Based Databases:Estudo Comparativo noÂmbito das Bases de Dados NoSql

Universidade do MinhoEscola de Engenharia

I

O conhecimento é um tesouro, mas a prática é a chave para alcançá-lo.

Thomas Fuller

Agradecimentos _______________________________________________________________________________

III

Agradecimentos

Ao concluir a presente dissertação gostaria de manifestar o meu sincero agradecimento a

todos os que contribuiram para a sua realização, não podendo deixar de salientar algumas

pessoas em particular:

Ao professor Doutor José Luís Mota Pereira, orientador desta dissertação, agradeço a

disponibilidade demonstrada, os esclarecimentos prestados e a partilha de conhecimentos.

Ao Departamento de Sistemas de Informação agradeço pela ajuda sempre prestada ao longo

destes anos.

Aos Amigos que tiveram presentes nesta caminhada, Fábio Teixeira, Diogo Silva, José

Santos, Jaime Oliveira e Diana Aguiar agradeço todo o apoio.

Ao meu grande amigo José Oliveira agradeço o apoio e camaradagem ao longo destes anos.

À Filipa Neiva realço um agradecimento especial por ter estado sempre presente e sempre

me ter apoiado bastante ao longo destes anos.

À minha mãe e ao meu irmão agradeço pela amizade e ajuda pois sem eles nada disto era

possível.

Ao meu irmão pequenino, que apesar de ter nascido há pouco tempo também merece um

agradecimento.

Ao meu falecido pai agradeço e dedico esta dissertação pois era a vontade dele ver-me

formado.

Resumo _______________________________________________________________________________

V

Resumo

Depois de várias décadas de grande sucesso e bons serviços prestados às organizações, a

tecnologia relacional de bases de dados tem vindo a ser desafiada por uma nova classe

de tecnologias de bases de dados a que se deu a designação genérica de NoSql. Para este

facto contribuíram decisivamente os recentes desenvolvimentos na área a que se tem vindo

a chamar Big data, na qual, dada a complexidade e volume dos conjuntos de dados a

gerir, o tradicional modelo relacional começou a apresentar dificuldades.

Dentro desta nova classe de tecnologias de Bases de Dados surgiram diferentes propostas,

com distintas proveniências e áreas de aplicação, vulgarmente classificadas em quatro

grupos, de acordo com o seu modelo de dados: Column, Document, Key/Value e Graph

Based Databases.

Dada a grande diversidade de propostas atualmente existentes em cada um dos modelos de

Bases de Dados NoSql, torna-se pertinente compreender as suas características específicas

e áreas de aplicação mais relevantes, enquanto, simultaneamente se vincam as suas

diferenças relativamente às tradicionais bases de dados relacionais.

Em particular, pretende-se abordar uma das quatro classes de bases de dados em que o

mundo NoSql se divide – as Document-Based databases, de que produtos como o MongoDB

e o CouchDB são alguns dos principais representantes. Como propósito do trabalho em que

esta dissertação se enquadra, pretende-se perceber quais as diferenças, a nível de

desempenho, entre soluções suportadas por estes dois produtos, quando utilizados no

suporte de bases de dados de dimensão crescente, procurando evidenciar também as

diferenças entre estas e soluções construídas recorrendo à bem conhecida tecnologia

relacional.

Palavras chave: Big data, Sql, NoSql, Document databases.

Abstract _______________________________________________________________________________

VII

Abstract

After many decades of great success and good services provided to organizations, relational

databases have been challenged by a new class of database technologies with the generic

designation of NoSql. To this fact contributed, decisively, the recent developments in the

area called BigData, in which, due to its complexity and volume of data to manage, the

traditional relational model has began to present difficulties.

In this new class of database technologies appeared different proposals, with different

origins and application areas, commonly classified into four groups, according to its data

model: Column, Document, Key/Value and Graph Based Databases.

Given the wide variety of currently existing proposals in each of the NoSql Database

families, it is pertinent to understand their most important specific characteristics and

application areas, while, simultaneously, clarifying their differences regarding traditional

relational databases.

In particular, it is intended to explore one of the four database classes in which the NoSql

world is divided – the Document-Based databases, in which products like MongoDB and

CouchDB are some of the main representatives. In this thesis, it’s intended to understand

what are the differences, in performance, between solutions developed using these two

products, when used to support databases of growing dimensions, seeking to highlight the

differences between these and solutions built using the well-known relational technology.

Key words: Big data, Sql, NoSql, Document databases.

Índice _______________________________________________________________________________

IX

Índice Agradecimentos............................................................................................................................. III

Resumo ............................................................................................................................................ V

Abstract ........................................................................................................................................ VII

Índice ............................................................................................................................................. IX

Índice de Figuras ........................................................................................................................... XI

Índice de Tabelas ......................................................................................................................... XIII

Lista de Siglas e Acrónimos ......................................................................................................... XV

Capitulo 1- Introdução .................................................................................................................... 1

1.1 Enquadramento ..................................................................................................................... 1

1.2 Objetivos e Resultados Propostos......................................................................................... 2

1.3 Abordagem Metodológica .................................................................................................... 3

1.4 Estrutura da Dissertação ....................................................................................................... 4

Capitulo 2- Fundamentos Teóricos ................................................................................................. 5

2.1 Big data ................................................................................................................................. 5

2.2 Surgimento do conceito NoSql ............................................................................................. 7

2.3 NoSql .................................................................................................................................... 9

2.3.1 Teorema CAP .............................................................................................................. 12

2.3.2 BASE Vs ACID .......................................................................................................... 14

2.3.3 Caraterização das Bases de dados NoSql .................................................................... 16

2.3.4 Tipos de Bases de Dados NoSql ................................................................................. 25

2.3.5 Comparação entre os tipos de Bases de Dados NoSql ................................................ 38

2.3.6 Considerações Finais ................................................................................................... 43

Capítulo 3 – Análise e Carregamento dos dados ........................................................................... 45

3.1 Dados para Carregamento .................................................................................................. 45

3.2 Carregamento dos dados no MySQL .................................................................................. 46

3.2.1 Modelo conceptual de dados ............................................................................................ 47

3.2.2 Descrição das Entidades ................................................................................................... 47

3.2.3 Carregamento das tabelas filho ........................................................................................ 49

3.2.4 Carregamento das tabelas pai ........................................................................................... 52

3.3 Carregamento de dados no MongoDB ............................................................................... 54

3.3.1 Estrutura dos Documentos .......................................................................................... 54

3.3.2 Carregamento da coleção ............................................................................................ 55

3.4 Carregamento dos dados no CouchDB ............................................................................... 56

Capitulo 4 – Benchmarking .......................................................................................................... 59

4.1 Consultas MySQL ............................................................................................................... 59

4.2 Consultas MongoDB ........................................................................................................... 60

Índice _______________________________________________________________________________

X

4.3 Consultas CouchDB ............................................................................................................ 61

4.4 Criação de Índices ............................................................................................................... 63

4.5 Resultados ........................................................................................................................... 64

4.5.1 Consulta 1 ......................................................................................................................... 64

4.5.2 Consulta 2 ......................................................................................................................... 64

4.5.3 Consulta 3 ......................................................................................................................... 65

4.6 Discussão de Resultados ..................................................................................................... 65

Capítulo 5 – Testes de Carga ........................................................................................................ 67

5.1 Base de Dados BD1............................................................................................................. 67

5.2 Base de dados BD2 ............................................................................................................. 68

5.3 Base de dados BD3 ............................................................................................................. 69

5.4 Base de dados BD4 ............................................................................................................. 70

5.5 Discussão de resultados ....................................................................................................... 71

Capítulo 6 – Conclusões ................................................................................................................ 73

6.1 Contribuições ...................................................................................................................... 73

6.2 Dificuldades ........................................................................................................................ 73

6.3 Trabalho futuro .................................................................................................................... 74

Referências Bibliográficas ............................................................................................................ 75

Anexos .......................................................................................................................................... 81

Anexo A .................................................................................................................................... 83

Anexo B .................................................................................................................................... 97

Anexo C .................................................................................................................................. 101

Anexo D .................................................................................................................................. 105

Anexo E ................................................................................................................................... 107

Índice de Figuras _______________________________________________________________________________

XI

Índice de Figuras Figura 1 - Teorema CAP (Retirado de Indrawan-Santiago, 2012, pag.47) ..................................... 12

Figura 2 - Fluxo do funcionamento do Map Reduce (Retirado de Alexandre & Cavique,

2013,pag.41) ................................................................................................................................... 19

Figura 3 - Exemplo MapReduce (Adaptado de Bonnet et al., 2011,pag.486) ................................ 19

Figura 4 - Fluxo de uma execução MapReduce (Retirado de Bonnet et al., 2011,pag.486) ........... 20

Figura 5 - Exemplo de sharding (Retirado de Cardoso, 2012,pag.25) ............................................ 22

Figura 6 - Exemplo de sharding de um carrinho e compras (Retirado de Tauro et al., 2012,pag.2)23

Figura 7 - Exemplo de uma chave ligada a um valor (Retirado de Sadalage & Fowler,

2012,pag.58) ................................................................................................................................... 26

Figura 8 - Estrutura típica das column-based databases (Retirado de Sadalage & Fowler,

2012,pag.46) ................................................................................................................................... 28

Figura 9 - Exemplo das relações numa graph database (Retirado de Sadalage & Fowler,

2012,pag.52) ................................................................................................................................... 30

Figura 10 - Exemplo de dois Documentos de uma Document database ......................................... 33

Figura 11 - Documento contendo um exemplo de descrição de um livro (Retirado de Silva,

2011,pag.14) ................................................................................................................................... 34

Figura 12 - Exemplo de uma função utilizada para obter o título de todos os livros armazenados na

base de dados (Retirado de Silva, 2011,pag.14) ............................................................................. 35

Figura 13 - Exemplo de um Documento com campos distintos (Retirado de Queiroz et al.,

2013,pag.485) ................................................................................................................................. 36

Figura 14 - Exemplo de uma consulta sobre todos os livros que contêm o título Flatland (Retirado

de Silva, 2011,pag.17) ..................................................................................................................... 37

Figura 15 - Exemplo de duas consultas efetuadas no MongoDB (Retirado de Silva, 2011,pag.17)37

Figura 16 - Consistent hashing (Retirado de Grolinger et al., 2013, pag.13).................................. 40

Figura 17 – Extrato do csv aviões ................................................................................................... 45

Figura 18 – Extrato do csv companhias aéreas ............................................................................... 46

Figura 19 – Extrato do csv aeroportos ............................................................................................ 46

Figura 20 – Extrato do csv contendo voos de 1995 ........................................................................ 46

Figura 21 - Modelo conceptual de dados ........................................................................................ 47

Figura 22 - Import do csv airport .................................................................................................... 50

Figura 23 - Exemplo de um documento criado no MongoDB ........................................................ 56

Figura 24 - Exemplo de um documento criado no CouchDB ......................................................... 57

Figura 25 - Criação de um índice no MySQL ................................................................................. 63

Figura 26 - Comparação de desempenhos na Consulta 1................................................................ 64



Figura 29 - Resultado do Teste de carga utilizando a consulta 1 .................................................... 67








Figura 37 - Download do MongoDB .............................................................................................. 97

Figura 38 - Instalação do MongoDB ............................................................................................... 97

Figura 39 - Setup type da instalação do MongoDB ........................................................................ 98

Figura 40 - Correção do erro hotfix ................................................................................................ 98

Figura 41 - Mudança para a diretoria do MongoDB ....................................................................... 99

Figura 42 - Execução do comando "mongod" ................................................................................ 99

Índice de Figuras _______________________________________________________________________________

XII

Figura 43 - Inicialização do MongoDB ........................................................................................ 100

Figura 44 - Execução do comando "mongo" ................................................................................ 100

Figura 45 - Download do CouchDB ............................................................................................. 101

Figura 46 - Instalação do CouchDB .............................................................................................. 101

Figura 47 - Seleção da diretoria .................................................................................................... 102

Figura 48 - Alteração das credenciais do CouchDB ..................................................................... 102

Figura 49 - Execução do CouchDB através do curl ...................................................................... 103

Figura 50 - Download do Jmeter ................................................................................................... 107

Figura 51 - Inicialização do Jmeter ............................................................................................... 107

Figura 52 - Criação do Thread Group ........................................................................................... 108

Figura 53 - Criação do config element para o MongoDB ............................................................. 108

Figura 54 - Criação da sampler para o MongoDB ........................................................................ 109

Figura 55 - Criação do Listener .................................................................................................... 109

Figura 56 - Criação do Config Element para o MySQL ............................................................... 110

Figura 57 - Criação da Sampler para o MySQL ........................................................................... 111

Índice de Tabelas _______________________________________________________________________________

XIII

Índice de Tabelas Tabela 1- Comparação dos tipos de bases de dados NoSql em termos de segurança (Adaptado de

Grolinger et al., 2013, pag.17) ........................................................................................................ 25 Tabela 2 - Comparação entre os tipos de bases de dados NoSql (Adaptado de Indrawan-Santiago,

2012,pag.47) ................................................................................................................................... 39 Tabela 3 - Comparação dos tipos de bases de dados NoSql em termos de particionamento,

replicação e consistência (Retirado de Grolinger et al., 2013,pag.11) ............................................ 42 Tabela 4 - Descrição dos atributos da entidade airplane ................................................................. 47 Tabela 5 - Descrição dos atributos da entidade Airline .................................................................. 47 Tabela 6 - Descrição dos atributos da entidade airport ................................................................... 48 Tabela 7 - Descrição dos atributos da entidade aircraft type .......................................................... 48 Tabela 8 - Descrição dos atributos da entidade engine type ........................................................... 48 Tabela 9 - Descrição dos atributos da entidade flight ..................................................................... 49 Tabela 10 - Descrição dos atributos da entidade manufacturer ...................................................... 49 Tabela 11 - Descrição dos atributos da entidade model .................................................................. 49 Tabela 12 - Descrição dos atributos da entidade plane type ........................................................... 49

Lista de Siglas e Acrónimos _______________________________________________________________________________

XV

Lista de Siglas e Acrónimos XML- Extensible Markup Language

NoSql- Not Only SQL

SQL- Structured Query Language

CAP- Consistency, Availability e Partition Tolerance

PA- Partition Tolerance e Availability

CA- Consistency e Availability

CP- Consistency e Partition Tolerance

BASE- Basically available, soft state, eventually consistent

ACID- Atomicity, Consistency, Isolation, Durability

JSON- JavaScript Object Notation

API- Application Programming Interface

Introdução _______________________________________________________________________________

1

Capitulo 1- Introdução

Neste capítulo são contextualizadas as bases de dados NoSql no âmbito do Big data, e o

porquê das bases de dados relacionais estarem limitadas nesse contexto. Seguidamente são

referidos os objetivos e resultados propostos, e, por fim, é apresentada a estruturação do

documento.

1.1 Enquadramento

Com o aparecimento do Big data, no qual a complexidade e volume dos dados aumentou, a

tecnologia relacional começou a demonstrar fragilidades principalmente a nível de

desempenho. Isto fez com que uma nova tecnologia de base de dados, a NoSql, emergisse e

começasse a ser opção para as empresas.

O conceito Big data pode ser resumidamente definido como “uma coleção de bases de dados

tão complexa e volumosa que se torna muito difícil fazer algumas operações simples (ex.,

remoção, ordenação, sumarização) de forma eficiente utilizando Sistemas Gestão de Bases

de Dados (SGBD) tradicionais” (Vieira & Figueiredo, 2012).

Nas grandes aplicações web, desktop ou até mesmo móveis está-se a tornar cada vez mais

comum lidar com grande volume de dados, sendo que no futuro a situação será mais

exigente em termos de armazenamento de dados (Toth, 2012).

Em particular, a necessidade de gerir dados cujos formatos são dificilmente acomodáveis

em sistemas relacionais, dispersos por múltiplos servidores, levou ao aparecimento das ditas

Bases de Dados NoSql. Sendo assim, este novo tipo de bases de dados vieram para resolver

os problemas dos sistemas que precisam de escalabilidade e agilidade nas suas inserções,

buscas e alterações (Toth, 2012).

Lidando com tanta quantidade de registos, o desempenho pode diminuir com bases de dados

relacionais, assim, esta nova tecnologia veio para colmatar esta diminuição de desempenho,

focando-se numa abordagem diferente de persistência de dados que se baseia na

disponibilidade, desempenho e escalabilidade das soluções (Toth, 2012).

Dentro desta nova classe de tecnologias de Bases de Dados surgiram diferentes propostas,

com distintas proveniências e áreas de aplicação, vulgarmente classificadas em quatro

grupos, de acordo com o seu modelo de dados: Column, Document, Key/Value e Graph

Based Databases. Em simultâneo, e reconhecendo a relevância desta área, os próprios

construtores tradicionais de tecnologia relacional começaram também a fazer as suas

incursões, como é o caso da Oracle com o Oracle NoSql Database (do tipo Key/Value-

Introdução _______________________________________________________________________________

2

Based Databases), ou da Microsoft com o DocumentDB (do tipo Document-Based

Databases).

Dada a grande diversidade de propostas atualmente existentes em cada um dos modelos de

Bases de Dados NoSql, torna-se pertinente compreender as suas características específicas

e áreas de aplicação mais relevantes, enquanto, simultaneamente se vincam as suas

diferenças relativamente às tradicionais bases de dados relacionais.

Este trabalho vai abordar a tecnologia de Bases de dados NoSql denominada Document

Databases que tem como exemplos o CouchDB e o MongoDB. Este tipo de bases de dados

NoSql são parecidas com a abordagem chave/valor com uma grande exceção. Em vez de

armazenar qualquer arquivo binário como valor de uma chave é requisitado que o valor dos

dados que serão armazenados possuam um formato que a base de dados possa interpretar.

Na maioria das vezes podem ser arquivos de extensão XML, JSON ou qualquer formato

descritivo, variando muito de ferramenta para ferramenta (Toth, 2012).

Guardar novos documentos que contenham qualquer tipo de atributos pode ser tão fácil

como adicionar novos atributos nos Documentos existentes. Estas Document Databases

oferecem API’s mais ricas. Range queries nos valores, secondary indexes, querying nested

documents e operações como "and", "or", "between" são características, que podem ser

utilizadas convenientemente (Hecht & Jablonski, 2011).

Este é um tema atual e interessante de ser abordado pois é uma tecnologia cada vez mais

utilizada e que veio resolver muitos problemas. Nomeadamente as Document Databases

que através de documentos são guardados os dados. Sendo esta um dos principais tipos de

bases de dados NoSql, este trabalho é pertinente e uma mais-valia para aprender mais sobre

esta tecnologia.

1.2 Objetivos e Resultados Propostos

Com este trabalho pretende-se, justamente, explorar este novo domínio da tecnologia de

bases de dados, em particular as designadas Document Databases, de que produtos como

o MongoDB e o CouchDB, são alguns dos principais representantes.

Os objetivos são os seguintes:

Caracterização do contexto Big data e o papel das bases de dados NoSql nesse

contexto;

Caracterização detalhada de alguns dos produtos NoSql mais representativos de

Introdução _______________________________________________________________________________

3

entre as Document-Based Databases;

Análise comparativa desses produtos com base em casos de estudo

representativos das suas áreas de aplicação;

Identificação das vantagens relativamente às bases de dados relacionais.

1.3 Abordagem Metodológica

Estudo Exploratório será a abordagem metodológica a seguir durante a realização da

dissertação. Recorrendo a esta abordagem, pretende-se analisar as bases de dados NoSql,

nomeadamente as vantagens em relação à tecnologia SQL.

Afunilando para as Document Databases, em que se pretende fazer uma análise a esta

tecnologia.

Por fim pegar num caso prático e efetuar uma comparação entre as Document Databases e

a tecnologia Relacional.

Explorar novos fenómenos pode ajudar quem pesquisa a testar a viabilidade de um estudo

mais alargado, da necessidade da compreensão ou determinar o melhor método a utilizar

num estudo posterior.

Piovesan & Temporini (1995) citam Theodorson que refere que é “Um estudo preliminar

em que o objetivo principal é familiarizar-se com um fenômeno de investigação, de modo

que o estudo que se segue possa ser projetado com uma maior compreensão e precisão.

Permite também escolher as técnicas mais adequadas para a pesquisa e decidir sobre as

questões que mais necessitam de atenção e investigação detalhada, e pode alertar para

possíveis dificuldades, sensibilidades, e áreas de resistência. "

Citam também Polit e Hungler que referem que “é um estudo preliminar designado para

desenvolver ou refinar hipóteses, ou para testar e definir métodos de coleção de dados.”

Segundo Richardson (1989) “o estudo exploratório procura conhecer as características de

um fenômeno para procurar explicações das causas e consequências do dito fenômeno”

Já para Mattar (1994) “visa prover quem pesquisa de um maior conhecimento sobre o tema

ou problema de pesquisa em perspetiva. Por isso é apropriada para os primeiros estágios da

investigação, quando a familiaridade, o conhecimento e a compreensão do fenómeno por

parte de quem pesquisa são geralmente insuficientes ou inexistentes”.

Para Sampieri et al. (1991) “os estudos exploratórios servem para aumentar o grau de

familiaridade com fenômenos relativamente desconhecidos, obter informações sobre a

possibilidade de levar adiante uma investigação mais completa sobre um contexto particular

Introdução _______________________________________________________________________________

4

da vida real e estabelecer prioridades para investigações posteriores, entre outras utilizações.

Porém, os estudos exploratórios em poucas ocasiões constituem um fim em si mesmos. Eles

caracterizam-se por serem mais flexíveis na sua metodologia em comparação com os

estudos descritivos ou explicativos, e são mais amplos e dispersos que estes dois últimos

tipos (por exemplo, procuram observar tantas manifestações do fenômeno estudado quanto

for possível) ” (Révillion, 2001).

Segundo Rodrigues (2007) tem como objetivo inteirar quem pesquisa no problema, através

de pesquisa bibliográfica ou estudo de caso.

Já Révillion (2001) refere que o objetivo do estudo exploratório é procurar perceber as

razões e motivações que estão subjacentes a determinadas atitudes e comportamentos das

pessoas.

Sendo assim esta metodologia tem um foco amplo e raramente responde a questões de

investigação específicas.

1.4 Estrutura da Dissertação

O presente documento está estruturado em seis capítulos. No Primeiro capítulo é

apresentada uma contextualização da origem e necessidade da realização da dissertação.

Além disso, os principais objetivos e resultados esperados da dissertação são descritos, bem

como a metodologia seguida na presente dissertação.

No Segundo capítulo é apresentado o estado de arte sobre as bases de dados NoSql e todos

os termos adjacentes, contextualizando no âmbito da Big data.

No Terceiro capítulo é apresentada a análise e carregamento dos dados, é referido qual o

dataset escolhido e como este foi tratado e carregado para as bases de dados em estudo.

No Quarto capítulo é apresentado o benchmarking, em que escolhidas as consultas a serem

efetuadas irá realizar-se um estudo comparativo entre as tecnologias selecionadas.

No Quinto capítulo são apresentados os testes de carga, que para as consultas estudadas no

benchmarking, irá ser analisado o desempenho com utilizadores a aceder concorrentemente

à base de dados e verificar como estas se comportam.

No sexto e último capítulo são apresentadas as conclusões finais, onde é falado da

contribuíção desta dissertação, bem como as dificuldades sentidas e trabalho futuro.

5

Fundamentos Teóricos _______________________________________________________________________________

Capitulo 2- Fundamentos Teóricos O crescimento exponencial da web 2.0 resultou na geração de cada vez maiores quantidades

de dados, caracterizados por uma grande diversidade de formatos, de que é necessário tirar

partido. O armazenamento, a gestão e o processamento destes novos dados veio evidenciar

as limitações das bases de dados relacionais, tanto em termos de capacidade de lidar com os

grandes volumes de dados, como dos tipos de dados a suportar. Neste contexto, uma nova

tecnologia emergiu e está a tornar-se cada vez mais importante no mercado – as bases de

dados NoSql.

2.1 Big data

Atualmente o armazenamento e processamento de grandes quantidades de dados na área da

computação é um grande desafio. O mundo digital está a crescer a olhos vistos e a tornar-

se cada vez mais complexo, quer relativamente ao volume de dados (do Terabyte ao

Petabyte), à sua variedade (dados estruturados, semiestruturados e não estruturados) e à

velocidade a que têm de ser processados (ritmos cada vez mais rápidos).

A este fenómeno chama-se Big data, que pode ser definido como uma grande coleção de

dados que cresceu tanto e de forma tão diversificada que não pode ser gerido ou explorado

eficientemente com as tradicionais ferramentas da tecnologia relacional (Moniruzzaman &

Hossain, 2013).

O termo Big data surgiu como referência a um conjunto de problemas derivados das

enormes quantidades de dados produzidos por empresas, organizações e pessoas

particulares. Posteriormente, passou a descrever “o conjunto de soluções que visam tratar

esses dados, desde o seu armazenamento até à transformação destes em informações

relevantes para auxiliarem os gestores nas tomadas de decisões” (Basso & Padua, 2014).

Purcell (2013) cita Manyiak et al. (2011) que referem que o nome Big data deriva do facto

dos datasets serem maiores que as tradicionais bases de dados, que não têm capacidade para

capturar, guardar, e analisar estes.

Segundo Vieira et al. (2012), Big data pode ser resumidamente definido como “uma coleção

de bases de dados tão complexa e volumosa que se torna muito difícil e complexo fazer

algumas operações simples (ex: remoção, ordenação, sumarização) de forma eficiente

utilizando Sistemas de Gestão de Bases de Dados tradicionais.” Também acrescenta que

engloba o processamento, de forma eficiente e escalável, de grandes volumes de dados

complexos produzidos por diversas aplicações.


6

Segundo Alexandre e Cavique (2013), o fenómeno Big data assenta nos chamados 3V’s:

Volume: A necessidade de lidar, de forma sustentada, com o crescimento

exponencial de dados gerados;

Velocidade: A necessidade de processar os dados em tempo real, devido à

importância que isso tem para as organizações atuais;

Variedade: O facto dos dados se apresentarem nos mais variados formatos, alguns

deles dificilmente acomodáveis em estruturas rígidas como as disponibilizadas pelo

modelo relacional.

Segundo Vieira et al. (2012), pode-se resumir as características de Big data em quatro

propriedades:

Volume de dados na ordem de dezenas ou centenas de Terabytes;

Necessidade de escalabilidade horizontal;

Fácil distribuição dos dados e/ou processamento;

Vários tipos de dados, desde complexos e/ou semiestruturados.

Big data inclui três tipos de dados, sendo eles, dados estruturados, semi-estruturados e não

estruturados.

Purcell (2013) cita Morris & Rob (2013) que referem que dados estruturados são dados

formatados para utilizar nos sistemas de gestão de bases de dados. Já em relação aos dados

semi-estruturados refere que são uma forma de dados estruturados mas que não estão

formatados para os modelos relacionais. Em relação aos dados não estruturados, refere que

são dados que estão no formato com que são coletados, não estando formatados.

Purcell (2013) cita também Baltzan e Phillips (2012) que referem alguns exemplos destes

tipos de dados. Para os dados semi- estruturados aponta XML. Já para os dados não

estruturados refere pdf’s, email’s e documentos.

A quantidade de dados gerada diariamente está-se a tornar abismal, desde redes sociais,

web, entre outros. Isto leva a problemas ao nível do processamento, armazenamento e

manipulação de dados, que faz com que os sistemas relacionais não sejam os mais indicados

para lidar com o problema do Big data. Por essa razão foram então criados os Sistemas

NoSql, que dispõem de melhorias ao nível do armazenamento e processamento de grandes

quantidades de dados, quer estruturados quer não estruturados (Vieira et al., 2012).

O NoSql veio resolver o problema da grande quantidade de dados que são gerados e têm de

ser tratados. Para além disso deve-se levar em consideração a necessidade das organizações

manterem esses dados durante longos períodos de tempo (Alexandre & Cavique, 2013).

7


2.2 Surgimento do conceito NoSql

Para entender melhor este novo conceito é importante perceber em que consiste uma base

de dados. Esta pode ser definida, muito simplesmente, como um repositório onde se

armazenam dados de vários tipos, interligados através de algum mecanismo que permita

manter as referências entre si.

Castro & Batista (2013) citam Korth et al. (1999) que refere que “é uma coleção de dados

inter-relacionados, representando informações sobre um domínio específico, ou seja,

sempre que for possível agrupar informações que se relacionam e tratam de um mesmo

assunto pode-se dizer que se possui uma base de dados.”

Castro & Batista (2013) citam também Date (2004) que acrescenta que o propósito principal

que era pretendido pelas bases de dados desde o seu aparecimento era oferecer recursos que

mantivessem os dados organizados e torná-los disponíveis, quando solicitados.

E.F.Codd propôs o modelo relacional em 1970. Na altura, este veio simplificar o

armazenamento de dados e o seu processamento, ao migrar os dados para tabelas

relacionadas entre si por campos comuns, manipulados por uma linguagem de alto-nível –

a SQL. O que o autor não previu foi que a quantidade de dados que se teria de armazenar no

futuro se tornaria gigantesca como é atualmente (Cardoso, 2012).

Em relação ao conceito de NoSql, este foi inicialmente usado em 1998 por Carlo Strozzi

para referir uma base de dados open source que não utilizava a referida interface SQL

(Abramova et al., 2014; Strauch, 2010).

Pozzani (2013) refere que esta tecnologia foi desenvolvida inicialmente na Google, com o

Bigtable, sendo que o primeiro research paper foi publicado em 2003.

Um dos primeiros movimentos de mudança em direção ao NoSql ocorreu em 2007, quando

a Amazon apresentou o NoSql Dynamo. Esta foi das primeiras empresas a guardar os seus

dados numa base dados de características não-relacionais (Leavitt, 2010).

A utilização do NoSql que reconhecemos atualmente remonta a um encontro no dia 11 de

junho de 2009, em San Francisco, organizado por Johan Oskarsson. O exemplo do Bigtable

e Dynamo inspirou muitos projetos com um armazenamento de dados alternativo. Sendo

assim, na sua passagem por San Francisco ele queria conseguir visitar todas as empresas

que introduziram este novo conceito, mas chegou à conclusão que era impossível, então

organizou uma conferência onde todas pudessem estar presentes. Ele pretendia que o nome

da conferência fosse curto e memorável e facilmente encontrado no Google, então foi-lhe

sugerido o nome “NoSql” (Grolinger et al., 2013; Sadalage & Fowler, 2012).

Este termo é utilizado como um acrónimo para “Not only Sql”, que realça que o estilo de


8

consultas SQL, não é o objetivo crucial destas bases de dados (Grolinger et al., 2013).

Ainda neste ano começaram as primeiras conferências sobre NoSql e originou que as

pessoas começassem a falar mais deste tema (Stonebraker, 2010).

Atualmente são gerados enormes volumes de dados a todo o instante e por todo o tipo

dispositivos, desde eletrodomésticos inteligentes, até ao comércio online. Existem cada vez

mais sistemas ligados à internet que comunicam entre si. Nos últimos anos, os avanços nas

tecnologias da Web, o incremento na utilização das redes sociais e a proliferação de sensores

e dispositivos móveis conectados à internet, resultou na geração de imensos dados que

necessitam de ser armazenados e posteriormente processados.

Toth (2011) concorda, referindo que o crescimento da quantidade de dados e informação na

web é indiscutível e percetível de dia para dia. Entretanto, se as aplicações possuem um

grande volume de dados poderão vir a existir problemas em relação à infra-estrutura.

Strauch (2010) acrescenta que, com o aparecimento da web 2.0, empresas famosas como

Google, Amazon, entre outras, começaram a largar as tradicionais bases de dados relacionais

como a Oracle para começarem a construir os seus próprios sistemas, isto para armazenar

e processar grandes quantidades de dados.

Tomando como exemplo uma das maiores redes sociais do momento, o Facebook, só nesta

rede, 2.4 biliões de conteúdos são partilhados entre amigos todos os dias. (Grolinger et al.,

2013; Parikh, 2013) Neste tipo de contextos a tecnologia relacional começou a apresentar

limitações especialmente relacionadas com a escalabilidade e desempenho.

As novas exigências fizeram com que a indústria das TIC surgisse com novas propostas

para estes problemas, resultantes das limitações dos sistemas de armazenamento relacional.

Empresas como o Facebook e Google concluíram que seria impossível gerir grandes

quantidades de dados com as bases de dados relacionais e começaram então a procurar

soluções alternativas aos sistemas relacionais. A alternativa que surgiu denominou-se NoSql

(Cardoso, 2012; Guimarães et al., 2013; Hecht & Jablonski, 2011).

Alexandre & Cavique (2013) citam McCreary & Kelly (2013) que concordam e referem

também que com o surgimento de tantas fontes de dados e a necessidade de processar toda

esta informação surgiu o conceito NoSql.

No entanto, ainda muita gente refere que existe uma carência de estudos que comprovem a

real eficácia do modelo NoSql perante o paradigma relacional. Já Rob, Coronel e Crockett

(2013) discordam e referem a tecnologia não relacional como o maior avanço para o

utilizador comparado com o modelo tradicional de armazenamento.

9


Frozza et al. (2011) citam Tiwari (2011) que descreve o conceito da seguinte forma, o

modelo NoSql “é uma tendência que tende a superar o homólogo modelo relacional no que

se refere a escalabilidade horizontal e disponibilidade.”

Guimarães et al. (2013) citam Redmond e Wilson (2012) que referem que as bases de dados

NoSql foram criadas para ir de encontro às necessidades que surgiram com o aumento da

quantidade e diversidade de dados das aplicações atuais, que não são completamente

resolvidas pelas bases de dados relacionais, uma vez que estas aplicações exigem cada vez

mais espaço de armazenamento.

As organizações estão cada vez mais dependentes dos dados para competirem no mercado,

sendo assim, capturar e analisar dados, tornaram-se as chaves para o sucesso no negócio em

vez de ser um custo a minimizar (Indrawan-Santiago, 2012). Esta nova tecnologia veio

fornecer escalabilidade e agilidade aos sistemas, pois já careciam bastante destas

propriedades.

Para Pozzani (2013), NoSql representa uma nova encarnação, e justifica referindo que é

devido à grande escalabilidade das aplicações da internet e por estas se basearem em

computação distribuída e paralela.

Mas o desempenho não é importante por si só, a disponibilidade também é um requisito

considerado importante. Por isso, a Amazon oferecia disponibilidade de serviço de 99,9%

durante um ano (DeCandia et al., 2007; Hecht & Jablonski, 2011).

O fator vital para a mudança no armazenamento de dados era a necessidade de suportar

grandes volumes de dados em clusters, sendo que, bases de dados relacionais não foram

concebidas para correr eficientemente nestes (Sadalage & Fowler, 2012).

Diferentemente das bases de dados relacionais que, de uma forma ou outra, são todas

relativamente semelhantes, a área das bases de dados NoSql caracteriza-se por possuir

diferentes tipos que variam muito entre si, tendo cada uma as suas próprias caraterísticas e

finalidades (Vieira et al., 2012).

A tecnologia NoSql não foi criada com o intuito de substituir o modelo relacional mas sim

preencher uma necessidade do mercado que este não servia adequadamente.

2.3 NoSql

NoSql é um termo utilizado para descrever uma classe de tecnologias que fornecem uma

alternativa para o armazenamento de dados em comparação com os sistemas de gestão de

bases de dados relacionais. Caracterizam-se por fornecer soluções efetivas de baixo custo

para os problemas de disponibilidade e escalabilidade (Schram & Anderson, 2012).


10

Segundo Cardoso (2012), “NoSql é uma coleção de produtos e conceitos sobre a

manipulação de grandes volumes de dados sem usar unicamente SQL”. Já para Pozzani

(2013) “é um termo para todas as bases de dados e armazenamentos de dados que não

seguem os princípios dos sistemas de gestão de bases de dados relacionais”.

Inicialmente, o termo NoSql era suposto significar “No Sql”, mas devido a poucos sistemas

eliminarem completamente a tecnologia relacional, foi então atualizado para “not only Sql”

(Schram & Anderson, 2012). Esta tecnologia é uma alternativa viável relativamente às bases

de dados relacionais, pois garante melhor desempenho nas consultas enquanto mantêm um

certo grau de escalabilidade e flexibilidade (Lee et al., 2013).

A internet e a cloud computing evoluíram bastante e, assim, várias aplicações emergiram, o

que forçou uma evolução ao nível das tecnologias de bases de dados, para responder aos

novos desafios:

Grandes níveis de concorrência na leitura e escrita de dados;

Para não defraudar as expectativas dos utilizadores, as bases de dados têm de

fornecer tempos de resposta suficientemente baixos;

Armazenamento de grandes volumes de dados (Big data) eficiente e com

determinados requisitos de acesso;

Aplicações muito exigentes em termos de processamento, como motores de pesquisa

e plataformas para redes sociais, têm de responder em tempo útil às solicitações de

milhões de utilizadores;

Para além da escalabilidade é fundamental uma alta disponibilidade;

Cada vez mais o volume de dados e os pedidos concorrentes aumentam, pelo que as

bases de dados necessitam de ser facilmente expandidas sem interrupções;

A juntar a tudo isto, exigem-se baixos custos de gestão e operação das soluções.

Já Stonebraker (2009) aponta as seguintes razões que levaram à adoção das bases dados não

relacionais:

Flexibilidade: Podem existir dados que não se adaptam aos rígidos modelos

relacionais e neste caso deveria existir mais flexibilidade.

Desempenho: Dados em vários sites têm dado problemas na gestão de dados

distribuídos nas aplicações (Stonebraker, 2009; Strauch, 2010).

Mesmo que não exista um consenso no que exatamente constitui uma solução NoSql, o

seguinte conjunto de caraterísticas é normalmente atribuído a estas: (Grolinger et al., 2013)

São completamente livres de esquemas, de modo a lidarem com uma grande

11


variedade de tipos de dados;

Possibilitam escalar horizontalmente as soluções através da adição incremental de

novos nodos (commodity servers);

Focadas na disponibilidade e na tolerância ao particionamento. Sendo assim, estão

apontadas para cenários de alta distribuição. Portanto, escolhem comprometer a

consistência em favor da disponibilidade;

Normalmente, não suportam transações ACID como são fornecidas pelas

relacionais, sendo assim são muitas vezes referidas como sistemas BASE (Pritchett,

2008). No entanto, algumas bases de dados NoSql como o CouchDB fornecem

ACID.

Este tipo de tecnologia possui uma caraterística chave que é o facto de conseguirem escalar

horizontalmente, isto é, replicando e particionando dados através de vários servidores. Isto

permite que esta tecnologia suporte um grande número de operações simples de leitura e

escrita por segundo (Cattell, 2011).

Como já foi referido anteriormente, estas bases de dados vieram responder a várias

necessidades, mas um dos maiores desafios que enfrentam é a consistência. Quando se

abordar num próximo tópico o teorema CAP e Eventually Consistency, irá perceber-se o

tipo de consistência que é necessária no sistema.

Estas bases de dados NoSql, em comparação à tecnologia relacional, diferem na medida em

que não são construídas em tabelas e não utilizam a linguagem Sql para a manipulação de

dados. Os sistemas de gestão de bases de dados NoSql são ótimos quando se trabalha com

uma grande quantidade de dados, em que estes, devido à sua natureza não necessitam de um

modelo relacional (Moniruzzaman & Hossain, 2013). Sendo assim, a sua principal

vantagem é conseguirem lidar com dados não estruturados. Como são distribuídas, pode-se

aumentar o desempenho distribuindo a carga por várias máquinas que não custam tanto

como comprar uma máquina mais poderosa. Portanto, são ideais para lidar com grandes

volumes de dados (Cardoso, 2012; Moniruzzaman & Hossain, 2013).

Este tipo de tecnologia começa a encontrar-se em operação em grandes centros de dados,

onde as falhas são uma ocorrência constante, tanto devido a problemas de disco como

comunicação de rede. Esta tecnologia torna-se apropriada nesses contextos já que possui

recursos para permitir a replicação de dados em várias máquinas, o que se traduz num

aumento da disponibilidade dos sistemas (Queiroz et al., 2013).

Estão também desenhados para escalar para milhares ou até milhões de utilizadores em

simultâneo (Moniruzzaman & Hossain, 2013).


12

2.3.1 Teorema CAP

O CAP (Consistency, Availability, Partition tolerance) foi introduzido em 2000 pelo

cientista de computação Eric Brewer (2000) como uma conjetura e foi formalmente provado

em 2002 por Seth Gilbert e Nancy Lynch (2002), sendo assim, estabelecida como teorema

(Cardoso, 2012; Silva, 2011).

Toth (2011), Sousa (2010), Brewer (2000) e Lynch (2002) referem que o teorema CAP,

enquadrando-se na área da computação distribuída, assenta em três requisitos que

descrevem da seguinte forma:

Consistência: Todos os nós de um sistema distribuído necessitam que a versão dos

dados que armazenam seja a mesma;

Disponibilidade: Ainda que um nó da rede esteja desligado, todos os clientes podem

encontrar, sempre que pretenderem, pelo menos uma cópia dos dados que

necessitam;

Tolerância ao particionamento: Caso o sistema seja implementado em servidores

diferentes, continua com os seus dados, propriedades e caraterísticas, sempre

transparentes para o cliente.

Já de acordo com Ferreira (2012), para um sistema distribuído ser consistente, todos os

clientes devem visualizar dados consistentes, independentemente de atualizações e

remoções. Para fornecer disponibilidade, todos os clientes devem sempre ser capazes de ler

e escrever dados mesmo que um nodo falhe. Para ser tolerante ao particionamento deve

continuar a funcionar como planeado, independentemente da rede ou perda de mensagens.

Na figura seguinte estão representadas as combinações possíveis.

Figura 1 - Teorema CAP (Retirado de Indrawan-Santiago, 2012, pag.47)

13


Segundo Cardoso (2012), Toth (2011), Pozzani (2013) e Vieira et al. (2012), de acordo com

este teorema, num sistema de dados distribuído, é impossível ter ao mesmo tempo estes três

requisitos, sendo que apenas é possível ter dois deles ao mesmo tempo, o que leva a escolher

qual dos três requisitos é o menos necessário.

Pozzani (2013) refere as três combinações possíveis da seguinte forma, isto quando uma

caraterística é comprometida.

Comprometer a disponibilidade:

Escolha habitual para bases de dados relacionais com escalabilidade horizontal;

Disponibilidade é afetada por vários fatores entre os quais:

o Atrasos devidos a lag na rede;

o Escassez de recursos;

o Falha de Hardware que leva a fragmentações.

Comprometer a Tolerância ao particionamento:

Uma moderna interpretação deste teorema é, por exemplo, durante uma falha de

rede, um sistema distribuído ter de escolher entre disponibilidade e consistência;

Um sistema que não tiver tolerância ao particionamento é forçado a desistir da

consistência ou disponibilidade durante uma falha.

Comprometer a Consistência:

Sendo assim vamos ter fraca consistência, mas é possível aceitar Eventual Consistency, que

pode ser interpretada de duas formas:

Dado um período de tempo suficiente, onde nenhuma atualização foi enviada, pode-

se esperar que todas as atualizações vão, eventualmente, propagar-se pelo sistema e

todas as réplicas serão consistentes;

Na presença de contínuas atualizações, uma atualização aceite, eventualmente atinge

a réplica ou esta retira-se do serviço.

Eventual Consistency leva-nos para o conceito BASE que irá ser abordado no seguinte

ponto. Segundo Dimitrov (2010), as combinações possíveis dos três requisitos processa-se

da seguinte forma:

CA - Consistência e Disponibilidade

o Clusters únicos, fácil de assegurar devido a todos os nodos estarem sempre

em contacto;

o Exemplo: 2 PC;

o Quando um particionamento ocorre o sistema bloqueia.

CP - Consistência e Tolerância ao particionamento


14

o Alguns dados podem ser inacessíveis (disponibilidade sacrificada), mas o

resto é consistente;

o Exemplo: sharded database.

PA - Disponibilidade e Tolerância ao particionamento

o Sistema está disponível mesmo durante o particionamento, mas alguns

dados podem-se revelar inconsistentes;

o Exemplo: DNS, caches, Master/Slave replication;

o Necessita de alguma estratégia de resolução de conflitos.

Sadalage e Fowler (2012) descrevem de uma maneira bastante simples e percetiva os

sistemas que utilizam a combinação da consistência com a disponibilidade. É fácil quando

se está perante máquinas individuais, pois elas não podem ter particionamentos, sendo

assim, não é necessário haver preocupações com o requisito tolerância ao particionamento,

pois só existe um nodo. Este é o conjunto de requisitos da maioria das bases de dados

relacionais.

Tipicamente as bases de dados NoSql são PA (Partition tolerance/Availability) enquanto a

maioria das relacionais são CA (Consistency/Availability).

2.3.2 BASE Vs ACID

Enquanto o ACID fornece um conjunto de propriedades que garantem que as transações das

bases de dados são processadas com confiança, o oposto modelo BASE, que é derivado

diretamente do teorema CAP, aponta para fornecer um diferente conjunto de propriedades

das que o ACID fornece (Silva, 2011).

2.3.2.1 Modelo ACID

O acrónimo ACID significa, Atomicity, Consistency, Isolation e Durability, é usado pela

generalidade dos sistemas de gestão de base de dados para assegurar a integridade na base

de dados. As suas caraterísticas constituintes significam o seguinte:

Atomicity: Caso exista uma falha na transação, o efeito das suas operações não é

aplicado na base de dados;

Consistency: A integridade da base de dados é garantida no final da execução de

uma transação;

Isolation: O resultado de uma execução de uma transação concorrente é o mesmo

do que uma transação isolada;

Durability: Após a confirmação de uma transação, mesmo que ocorram falhas os

15


resultados são refletidos na base de dados.

ACID fornece um conjunto de propriedades que garantem que as transações das bases de

dados são processadas com confiança e que a base de dados é consistente em acessos

concorrentes e falhas do sistema (Silva, 2011).

2.3.2.2 BASE

Em relação ao modelo BASE, Toth (2011) refere que para que seja possível trabalhar com

um sistema distribuído foi proposto enfraquecer ou relaxar o requisito de consistência

permanente de dados, focando antes na disponibilidade e na tolerância ao particionamento.

Deste modo surge o conceito BASE (Basically Available, Soft state, Eventual consistency)

com propriedades e filosofia oposta.

O mundo NoSql aponta este teorema, referindo a razão pela qual se deve relaxar na

consistência.

Neste sistema não existem transações e são introduzidas ligações no modelo de dados para

permitir melhores esquemas de particionamentos (Moniruzzaman & Hossain, 2013).

Toth (2011) refere ainda que é considerado um cenário que lida bem com transações

distribuídas, tolerância a falhas de consistência e replicação otimista num sistema

distribuído.

Vieira et al. (2012) assim como Toth (2011), referem que o paradigma BASE foi criado a

partir do teorema CAP. O primeiro autor ainda refere que o facto de não se controlar a

consistência, faz com que exista uma sensível diminuição no custo computacional para a

garantia de consistência dos dados em relação às bases de dados relacionais. Já o segundo

autor refere que este modelo de consistência está normalmente associado a sistemas

distribuídos. Refere também, que todas as atualizações pendentes serão propagadas por

todos os nós do sistema, caso durante um determinado tempo não existam atualizações,

ficando assim no fim, todo o sistema consistente. A partir deste conceito vários tipos de

bases de dados NoSql foram criadas, que, como já foi referido não garantem

temporariamente consistência dos dados de uma aplicação. Toth (2011) refere grandes

empresas como a Google e a Amazon, que aproveitaram a vantagem deste paradigma, isto

porque utilizaram um modelo NoSql, aplicado ao conceito de distribuição horizontal. Como

não existe garantia de consistência, as configurações de fragmentação no modelo são mais

fáceis de efetuar e, por conseguinte, o modelo torna-se mais escalável e com custos mais

reduzidos.

Por exemplo, a maioria dos sistemas são chamados “Eventually consistent”, que significa


16

que as atualizações são eventualmente propagadas em todos os nodos (Cattell, 2011).

Eventual Consistency é uma forma específica de fraca consistência (Vogels, 2009). Um

sistema distribuído que forneça Eventual Consistency garante que, quando nenhuma

atualização seja feita num registo, eventualmente o sistema será consistente (exemplo: todos

os nodos do sistema aguentarão eventualmente os mesmos valores, embora possa não ser

necessário, e todos os acessos de leitura serão retornados ao ultimo valor atualizado (Silva,

2011). Agora considerando um exemplo real, considerando duas pessoas que querem

atualizar um número de telefone ao mesmo tempo. Um atualiza e outro atualiza logo a

seguir, senão existisse controlo de concorrência um era atualizado e o outro era atualizado

por cima do primeiro.

As maneiras para manter consistência nestes casos chamam-se otimista e pessimista. A

maneira pessimista trabalha para prevenir que conflitos ocorram, já a otimista deixa os

ocorrer, deteta-os e depois toma medidas para os tratar (Sadalage & Fowler, 2012).

Resumindo, “Basically Available” significa que as bases de dados estão disponíveis sempre

que são acedidas, mesmo que uma parte esteja indisponível. “Soft State” diz que não

precisam sempre de ser consistentes e podem tolerar inconsistência por um certo período de

tempo; e “Eventual Consistency” enfatiza que, depois de um certo período de tempo, a base

de dados vem para um estado de consistência.

2.3.3 Caraterização das Bases de dados NoSql

2.3.3.1 Schema-Free

Segundo Rybinski (1987) e Imielinski & Lipski (1982), schema é um conjunto de fórmulas

que descrevem a base de dados e as relações de acordo com a sua sintaxe. Esta estrutura

provém da normalização que, segundo Codd (1970) citado por Cardoso (2012), é “o

processo de simplificação e organização dos campos e das tabelas de uma base de dados de

forma a reduzir a redundância dos dados”.

Cardoso (2012) refere que a normalização é importante numa base de dados, pois garante

que nas tabelas possam ser inseridos dados sem anomalias (inconsistência de dados,

redundância, etc). Jacobs (2009) também salienta que à medida que a quantidade de dados

aumenta numa tabela, a base de dados tende a ficar mais lenta. Sendo assim, Schrage (2002)

refere que para ganhar rapidez de leitura/obtenção de dados, abdica-se da normalização.

Segundo Cardoso (2012), ao ganhar esta rapidez também se ganha redundância nos dados

e uma maior interdependência entre os mesmos. No entanto, ainda existem alguns

17


problemas inerentes à normalização ou à obrigação de possuir um schema, que é o caso de

todos os dados terem de obedecer àquela estrutura e caso necessite de modificações por

mais pequenas que sejam, podem obrigar a uma restruturação tão grande que pode vir a

obrigar a uma restruturação da aplicação que utiliza a base de dados.

Em relação ao Schema-Free pode-se referir como uma base de dados sem estrutura fixa, ou

seja, os dados não necessitam de obedecer a uma estrutura previamente definida. Sendo

assim, já é permitido um armazenamento de dados não estruturados em qualquer formato,

o que garante um bom desempenho para os desafios do Big data (Almeida & Brito, 2012).

Cardoso (2012) cita Stainer (2010) que refere que o facto de não possuir um schema também

traz desvantagens, como é o caso da possibilidade de possuir dados redundantes e até

incoerentes. Cardoso (2012) refere que a garantia das propriedades ACID deixa de ser válida

devido à inexistência de um schema, o que leva a um modelo diferente chamado BASE, o

qual foi abordado anteriormente.

Cardoso (2012) cita Brewer (2000) que refere que isto é necessário, pois abrindo mão da

consistência dos dados ganha na tolerância a falhas e na disponibilidade, que são bastante

importantes para lidar com grandes volumes de dados.

Por exemplo, Tweets e atualizações de estado nas redes sociais podem ser inconsistentes,

mas o sistema deve ter sempre alto desempenho e alta disponibilidade. Já nas aplicações

que lidam com finanças a consistência é a caraterística mais importante, portanto os sistemas

BASE não são os mais indicados para instituições bancárias (Hecht & Jablonski, 2011).

Os sistemas NoSql não assentam completamente em ACID ou BASE, isto porque, a maioria

das bases de dados permite personalizar a consistência e a disponibilidade de acordo com

as necessidades de cada um (Hecht & Jablonski, 2011).

2.3.3.2 MapReduce

MapReduce é uma tecnologia criada pela Google para dar resposta ao tratamento do enorme

volume de dados com que esta tem de lidar diariamente. Segundo Dean & Ghemawat

(2004), “é um modelo de programação e uma implementação associada ao processamento

e gestão de grandes datasets”. Refere também que é uma framework de programação que

processa datasets de grande porte com hardware regular.

Cardoso (2012) cita White (2012) que refere que é um modelo de dados para processamento

paralelo.

Esta tecnologia foi proposta inicialmente para tornar mais simples o processamento de

grandes volumes de dados em arquiteturas paralelas e distribuídas, como é o caso dos


18

clusters. Sendo assim, é utilizado nestes e os dados são distribuídos e armazenados

utilizando pares <key, value>, onde, para a mesma chave, vários valores podem ser

armazenados. Portanto, a tecnologia MapReduce é ideal para lidar com o processamento

intensivo de grandes quantidades de dados pois é uma abordagem bastante escalável. Isto

porque a alocação dos dados no mesmo nó confere alto desempenho a esta tecnologia

(Vieira et al., 2012).

Segundo Alexandre e Cavique (2013), é um conjunto de processos que permite tratar um

grande volume de dados de forma distribuída. Refere que duas operações estão subjacentes

a esta tecnologia, o Map e o Reduce.

Em relação ao Map trata-se de dividir o problema em subconjuntos mais pequenos que

possam ser distribuídos por outros nós do cluster. Já o Reduce pega em todos os

subconjuntos de dados, agrega e trata a informação e responde ao problema original.

Cardoso (2012) concorda e refere que o MapReduce assenta em dois grandes conceitos:

Uma função de Map, que tem como objetivo separar os grandes volumes de dados

em pedaços mais pequenos;

Uma função de Reduce, que tem como objetivo processar e agrupar todos os

pequenos fragmentos dos dados.

Segundo Vieira et al. (2012), em relação ao aspeto do processamento dos dados, a tecnologia

utilizada pelos produtos NoSql é o MapReduce. Segundo o autor também se divide em dois

grandes conceitos, sendo eles:

Map, que tem como objetivo mapear e distribuir os dados pelos diversos nós de

processamento e armazenamento;

Reduce, que tem como objetivo agregar e processar os resultados parciais para gerar

um resultado final.

Como é possível verificar-se na imagem abaixo, os dados são divididos em pequenos

pedaços e, com a função reduce, são processados e agrupados.

19


Figura 2 - Fluxo do funcionamento do Map Reduce (Retirado de Alexandre & Cavique, 2013,pag.41)

Cardoso (2012) cita Dean & Ghemawat (2004) que referem que o que aconteceu na

implementação do Google foi pegar num cluster típico e escolher um nó que seria o Master

e que iria receber o dataset gigantesco. Posto isto, divide os dados por algumas máquinas

que tomaram o papel de map workers e executaram a função de map aos dados que lhe

foram atribuídos. De seguida, os map workers notificaram o Master de que a função de map

estava concluída, o Master pôde delegar num ou mais reduce workers o trabalho de obter

os dados previamente mapeados pelo map worker e lhes aplicar a função de reduce. Por

fim, os dados estão processados

Caso de aplicação Map/Reduce

Figura 3 - Exemplo MapReduce (Adaptado de Bonnet et al., 2011,pag.486)

Em relação aos pontos (3), (4) e (5) pode-se visualizar na imagem seguinte como são

processados (Bonnet et al., 2011).


20

Pode-se considerar que está relacionado com o poder de processamento existente em

ambientes Cloud. Ambientes MapReduce têm maior facilidade no carregamento de

informações quando comparados com ambientes das bases de dados relacionais, pois os

dados são armazenados no seu estado original, enquanto na tecnologia relacional a

transformação dos dados é feita no momento do processamento das consultas (Vieira et al.,

2012).

Outro exemplo é o caso do Hadoop, que para processar dados semi-estruturados e não

estruturados, utiliza este paradigma, em que localiza todos os dados relevantes e depois

seleciona apenas os dados que respondem à consulta (Purcell, 2013).

2.3.3.3 Escalabilidade

Clarck (2009) define escalabilidade como “alterar o tamanho enquanto mantém

proporções”.

Já Forbes (2010) refere que escalabilidade é “Pragmaticamente a medida da capacidade de

uma solução de crescer para o mais alto nível de uso realista de um modo possível, mantendo

ao mesmo tempo os níveis de serviço aceitáveis”.

Strauch (2010) cita.Clarck (2009) que acrescenta que escalar não está relacionado com ser

rápido mas sim com tamanho. Algum sistema que tenha alto desempenho não necessita de

escalar.

Existem duas formas de escalar sendo elas:

Escalar verticalmente: aumentar a capacidade do servidor, é limitada e tem custos

elevados. Esta está relacionada, segundo Vieira et al. (2012) com o uso de vários

núcleos/ CPU que compartilham memória e discos.

Figura 4 - Fluxo de uma execução MapReduce (Retirado de Bonnet et al.,

2011,pag.486)

21


Escalar horizontalmente: aumentar o número de servidores tendo como beneficio

a facilidade na distribuição dos dados e existe distribuição de dados e carga por

vários servidores mas, contrariamente à escalabilidade vertical, sem haver partilha

de memória ou disco. Permite também o uso de hardware mais barato e comum

(Castro & Batista, 2013).

Opostamente às bases dados relacionais, as bases dados NoSql escalam melhor

horizontalmente e não necessitam de grande disponibilidade de hardware. Pode-se

simplesmente adicionar ou retirar mais máquinas sem comprometer o cluster (Strauch,

2010).

Esta capacidade de escalar horizontalmente é uma das principais caraterísticas do NoSql.

Segundo Vieira et al. (2012), isto permite que um grande volume de operações de

leitura/escrita sejam executadas muito mais eficientemente.

Como já foi abordado anteriormente, as bases de dados relacionais têm problemas com

escalabilidade, nomeadamente escalabilidade dinâmica que é uma propriedade fundamental

no ambiente Cloud. Para estas bases de dados apenas escalabilidade vertical é fácil de ser

atingida, sendo assim, os custos associados chegam a ser exorbitantes.

Vieira et al. (2012) refere então que o facto de um modelo único de SGBD contemplar todos

os modelos de dados, vai contra o contexto de Big data. Isto porque, por um lado, os

produtos relacionais oferecem diversas funcionalidades de extensão, mas, por outro lado, os

custos de manutenção tornam-se inviáveis, pois a maioria das soluções são caras.

Frequentemente, uma base de dados está ocupada porque várias pessoas estão a aceder a

diferentes partes do conjunto de dados. Nestas circunstâncias podemos suportar

escalabilidade horizontal pondo diferentes partes dos dados em diferentes servidores

(Sadalage & Fowler, 2012).

2.3.3.4 Sharding

Segundo Bell et al. (2010), sharding consiste em dividir os dados em fragmentos

independentes pelos nós existentes, o que faz que quando um cliente necessite dos dados

seja redirecionado para o nó que os contém.

Para Shawrtz et al. (2012) é o processo em que se divide os dados em pequenos bocados e

se armazenam posteriormente em diferentes nós.

Já Cardoso (2012) cita Warden (2011) que defende que é o esquema usado para decidir em

que máquina (nó) os pedaços de informação de uma base de dados vão residir.

E segundo Vieira et al. (2012) é uma técnica de partição horizontal dos dados numa


22

arquitetura, mas sem compartilhamento de recursos. Nesta técnica refere que os dados são

divididos por registos em vez de serem divididos por colunas.

Como é possível visualizar na imagem seguinte, a informação é dividida por outros nós.

Bell et al. (2010) refere algumas razões para se efetuar sharding à base de dados, sendo elas:

Os dados serem colocados geograficamente mais perto do utilizador;

Facilitar a pesquisa através da redução do tamanho do Dataset;

Dividir ainda mais os fragmentos que estejam a ser muito utilizados de forma a

equilibrar a carga do sistema.

Existem inúmeras vantagens usando esta técnica. Uma delas é em cada tabela do servidor,

o número total de linhas é reduzido, isto porque as tabelas estão divididas e distribuídas em

vários servidores. Sendo assim, também o tamanho dos índices são reduzidos, o que

geralmente melhora o desempenho de consultas. Outra vantagem é que a base de dados pode

ser separada por diferentes máquinas, isto onde o shard foi implementado, e vários shards

podem ser alocados em diferentes máquinas (Vieira et al., 2012). Portanto, o desempenho

aumenta pois a base de dados está distribuída por várias máquinas.

Existem também algumas desvantagens. Cardoso (2012) refere uma que ele considera a

mais evidente que “é a mudança de um dataset que vem de uma base de dados não

distribuída para um que venha de uma base de dados distribuída em shards.” Segundo

Shawrtz et al. (2012), existem também algumas questões na mudança dos fragmentos de um

nó para o outro.

Para Vieira et al. (2012) o problema do sistema Master Slave é caso existam mais pedidos

de escrita do que uma máquina pode lidar, o que leva à necessidade de efetuar sharding.

Figura 5 - Exemplo de sharding (Retirado de Cardoso, 2012,pag.25)

23


Nesta, estruturas completamente isoladas são postas num servidor por ordem alfabética. Na

figura 5 é mostrado um exemplo de todos os nomes dos clientes começados por A-M são

postos num único servidor e N-Z são postos noutro servidor. Isto certamente pode lidar com

o dobro da carga de trabalho. Similarmente pode haver “n” números de máquinas

adicionadas para facilitar a carga de trabalho (Tauro et al., 2012).

Figura 6 - Exemplo de sharding de um carrinho e compras (Retirado de Tauro et al., 2012,pag.2)

2.3.3.5 Segurança

Segurança é um aspeto importante das bases de dados que é valorizado pela maioria destas.

Sendo assim, irão ser avaliados os vários tipos de bases de dados nos seguintes aspetos de

segurança:

Autenticação: São mecanismos que identificam utilizadores que acedem aos dados.

São associadas passwords a logins, mas também são possíveis mecanismos mais

sofisticados, como certificados. Segundo Grolinger et al. (2013), para muitas

empresas um requisito importante para a autenticação é a capacidade de integração

com o sistema de diretório de utilizadores da empresa como o Lightweight Directory

Access Control (LDAP)/Active Directory and Kerberos servers.”;

Autorização: É a capacidade de assegurar um controlo de acessos aos recursos das

bases de dados. O objetivo é associar a cada utilizador um conjunto de permissões.

Por exemplo, em algumas bases de dados pode-se atribuir permissões específicas

para pedidos de leitura e escrita nas tabelas, execução de funções de administração

e criação de utilizadores;

Encriptação: É um mecanismo que tem como objetivo encriptar dados, para assim

não poderem ser lidos por “attackers” e outras pessoas não autorizadas. De acordo

com Grolinger et al. (2013), “uma solução de uma completa encriptação deve estar


24

presente em pelo menos três diferentes níveis:

o Data at rest: Dados armazenados em disco podem ser lidos se um “attacker”

tiver acesso ao sistema de ficheiros dos servidores. Um mecanismo de

encriptação Data at rest garante que os dados dos utilizadores são

automaticamente encriptados quando escritos nesses ficheiros e

desencriptados quando recuperados;

o Client-to-server communication: A maioria das bases de dados permite

conexões remotas de utilizadores e aplicações para que os dados

armazenados possam ser obtidos. Este fluxo de dados deve também ser

encriptado para garantir uma comunicação privada e segura;

o Server-to-server connections: Porque muitas bases de dados NoSql incluem

algum tipo de replicações e funcionalidades de processamento distribuído,

comunicações através dos nodos do servidor podem também ser um fator

para obter acesso não autorizado aos dados. Um mecanismo de encriptação

servidor- servidor garante que estes fluxos não possam ser lidos;”

Auditoria: Funcionalidades de auditoria estão relacionadas com a criação de um

caminho de auditoria que tem como objetivo analisar registos de eventos que

ocorreram numa base de dados. Esta caraterística tem bastante importância, por

exemplo, numa análise forense de eventos de segurança.

Na tabela seguinte é apresentado o conjunto de caraterísticas de segurança encontradas nas

diversas soluções NoSql. Segundo Grolinger et al. (2013), “é possível afirmar que as

caraterísticas de segurança das soluções NoSql não são tão maduras como as incluídas nas

bases de dados relacionais”. Bases de dados NoSql como o Redis, Memcached, Voldemort,

e Riak, estão apontados para a sua utilização ser apenas em ambientes em rede. Sendo assim,

é assumido que o administrador de rede tem de assegurar que apenas aplicações autorizadas

têm acesso à base de dados, utilizando mecanismos como firewalls ou a adoção de virtual

private networks (VPN).

É de salientar que nem todas as bases de dados possuem caraterísticas de auditorias e,

quando possuem, são muito simples e não podem ser customizadas.

Bases de dados NoSql como o MongoDB e o Cassandra oferecem funcionalidades de

segurança adicionais nas suas edições empresariais, isto revela que a segurança é uma

preocupação relevante para as grandes empresas. Por exemplo, apenas no Cassandra

enterprise edition estão presentes mecanismos de encriptação data at rest e funcionalidades

25


de auditoria.

NoSql

Databases

Encriptação Data at Rest Client/Server Server/Server

Autenticação Autorização Auditoria

Redis Não Não Não Apenas para

o

administrador

Não Não

Memcached Não Não Não Sim Não Não

Voldemort Sim Não Não Não Não Não

Riak Não Sim Sim Não Não Não

Cassandra Sim, na

enterpris

e edition

Sim Sim Sim Sim Sim, na

enterprise

edition

HBase Não Sim Sim Sim Sim Não

DynamoDB Não Sim Não Sim Sim Sim

SimpleDB Não Sim Não Sim Sim Não

MongoDB Não Sim Sim Sim Sim Não

CouchDB Não Sim Sim Sim Sim Não

Couchbase

Server

Não Não Não Sim Não Não

Neo4J Não Sim Não Não Não Não

Hyper

graphDB

Não Não Não Não Não Não

Allegro

Graph

Não Sim Não Sim Sim Sim

Tabela 1- Comparação dos tipos de bases de dados NoSql em termos de segurança (Adaptado de Grolinger et al., 2013,

pag.17)

2.3.4 Tipos de Bases de Dados NoSql

Segundo Toth (2011), Bonnet et al. (2011) e Guimarães et al. (2013), os principais tipos de

bases de dados NoSql são:

Document Databases, que têm como finalidade armazenar documentos em coleções,

coleções estas que contêm objetos idênticos. Não possuem esquema e campos

podem ser dinamicamente adicionados a um documento. (ex. CouchDB e

MongoDB);

Key Values Databases, que têm como finalidade armazenar os dados como chaves

e valores (ex. Riak, Redis e DynamoDB);

Graph Databases, que têm como finalidade armazenar relacionamentos entre os

dados (ex. Neo4J e OrientDB);

Column-based Databases, que têm como finalidade armazenar os dados como

triplas contendo linha, coluna e rótulo de tempo (ex. Cassandra, HBase).

2.3.4.1 Key Value Databases

As Key value databases são as que menos se assemelham com as bases de dados relacionais,


26

isto porque não possuem esquemas nem coleções (Atzeni et al., 2013).

Almeida & Brito (2012) citam Lóscio et al. (2011) que referem que é uma “base de dados

composta por um conjunto de chaves, às quais estão associadas um único valor, que pode

ser uma string ou um binário”.

Toda a base de dados assemelha-se com um mapa ou dicionário que contém objetos

chamados valores, cada um identificado por uma chave única (Atzeni et al., 2013; Hecht &

Jablonski, 2011). Estes valores são isolados e independentes uns dos outros e, por isso, as

relações devem ser tratadas pela lógica da aplicação. Em relação às chaves, estas são a única

maneira para recuperar dados guardados. Possuem uma simples estrutura de dados, sendo

assim são livres de esquemas. Também permitem que novos valores de qualquer tipo

possam ser acrescentados em tempo real, sem que qualquer tipo de conflito com outros

dados armazenados aconteça e sem influenciar a disponibilidade do sistema.

Para ser possível adicionar algum tipo de estrutura no modelo de dados é necessário utilizar

o grupo de pares de chave-valor (Hecht & Jablonski, 2011).

O modelo de dados das Key Value Databases significa que um valor corresponde a uma

chave. Embora a estrutura seja simples, a velocidade de consulta é maior que nas bases de

dados relacionais, suporta grande armazenamento e alta concorrência. Fornece suporte para

consultas e operações de modificação através da chave primária (Han et al., 2011).

Estas bases de dados representam um “balde de dados”. Por exemplo, num caso de um

carrinho de compras mencionado na figura seguinte, onde se pode visualizar uma chave

ligado a um valor que contém dados de encomendas (Tauro et al., 2012).

Figura 7 - Exemplo de uma chave ligada a um valor (Retirado de Sadalage & Fowler, 2012,pag.58)

27


Estas bases de dados são úteis quando se lida com operações simples, que são baseadas

apenas em atributos chave. (Hecht & Jablonski, 2011) É inviável neste modelo de dados

efetuar consultas ad-hoc, isto porque todas as consultas são efetuadas sobre as chaves e não

sobre os valores. (Carniel et al., 2012)

2.3.4.2 Column-Based Databases

São também conhecidas como column oriented databases. Este tipo de base de dados possui

um formato tabela e por isso tem uma representação gráfica semelhante às bases de dados

relacionais. Semelhante mas não igual, pois lida com valores nulos de maneira distinta e

não suporta associações entre tabelas (Han et al., 2011; Hecht & Jablonski, 2011).

Tomando como exemplo “um caso em que se use muitos tipos de atributos, as bases de

dados relacionais iriam guardar um valor nulo em cada coluna no qual o dataset não tem

valor. Já as column-based databases apenas armazenam um par chave-valor num único

registo, se o dataset precisar. É por isto que a Google as refere como “sparse” e torna as

column-based databases bastante eficientes em dominar grandes quantidades de dados.”

Este modelo opõe-se ao das bases de dados relacionais, isto porque as relacionais

armazenam os dados em linhas e nas column-based databases “os dados são indexados por

uma tripla (linha, coluna e timestamp), onde linhas e colunas são identificadas por chaves e

o timestamp permite diferenciar múltiplas versões de um mesmo dado” (Lóscio et al., 2011).

Já para Cattell (2011), o seu modelo de dados básico são registos e colunas, e o seu modelo

básico de escalabilidade está separado entre registos e colunas através de múltiplos nodos:

Registos estão separados ao longo dos nodos através de sharding na chave primária.

Normalmente, separam-se por range em vez de uma função hash. Isto significa que

consultas em intervalos de valores não têm de ir para todos os nodos;

Colunas de uma tabela são distribuídas através de múltiplos nodos utilizando

“column groups”. Estes podem parecer muito complexos, mas grupos de colunas

são uma simples maneira para o utilizador indicar quais colunas são melhor

armazenadas juntas.

Existem duas maneiras de estruturar os dados, sendo elas:

Orientado à linha: cada registo é uma agregação, por exemplo, um cliente com o

Id 1234 e com a família de colunas representando pedaços de dados como perfil,

histórico de encomendas dentro da agregação;

Orientado a colunas: Cada família de colunas define um tipo de registos, por

exemplo perfis de clientes com linhas associadas a registos. Podemos pensar na linha

como um conjunto de registos em todas as famílias de colunas (Sadalage & Fowler,


28

2012).

Na imagem seguinte podemos visualizar a estrutura típica destas bases de dados.

Figura 8 - Estrutura típica das column-based databases (Retirado de Sadalage & Fowler, 2012,pag.46)

De acordo com Abadi & Madden (2008), quando se pretende aceder aos dados sobre a

granularidade de uma entidade, o modelo baseado em linhas é o mais indicado, isto tendo

em conta que todos os dados estão armazenados em conjunto. Mas caso se pretenda ter

acesso apenas a alguns atributos de diversos registos, então o modelo baseado em colunas

é o mais indicado. Sendo assim, quando se pretende pesquisar um cargo, adicionar um cargo

ou eliminá- lo usamos o modelo baseado em linhas, caso usemos uma consulta para verificar

o género mais comum no curso de MIEGSI, é preferível utilizar o modelo baseado em

colunas.

Os dados são armazenados de acordo com as suas colunas de forma independente (Liu et

al., 2011). Cada coluna é exclusivamente armazenada em cada tabela, não existindo

relacionamentos (Carniel et al., 2012).

Concluindo, o modelo de dados das column-based databases é mais indicado para

aplicações que trabalhem com grandes quantidades de dados que estejam armazenados em

grandes clusters, como, por exemplo, data warehouses, pois o modelo de dados permite

particionamento eficiente (Han et al., 2011; Hecht & Jablonski, 2011).

2.3.4.3 Graph Databases

Contrariamente às bases de dados relacionais e às key oriented databases, as graph

29


databases têm uma excelente gestão de dados fortemente ligados. Deste modo, as aplicações

que têm dados com muitos relacionamentos são ótimas para este tipo de base de dados.

Segundo Hecht & Jablonski (2011), são mais indicadas para “serviços baseados em

localização, representação de conhecimento e problemas de encontrar caminhos nos

sistemas de navegação, sistemas recomendados e todo o tipo de casos que envolva relações

complexas.”

O modelo deste tipo de base de dados baseia-se no conceito de grafo. Tem a sua estrutura

composta por: “nós (são os vértices do grafo), relacionamentos (são as arestas) e

propriedades (ou atributos) dos nós e relacionamentos” (Lóscio et al., 2011).

Toth (2011) ainda destaca que “pode-se armazenar qualquer tipo de dados dentro do

conteúdo”. As principais vantagens deste tipo de base de dados são:

O facto de “não existir tanta replicação de dados como nos outros modelos, facto

que acontece por se aproveitar do relacionamento entre os registros” (Toth, 2011);

“A vantagem de utilização do modelo baseado em grafos fica bastante clara quando

consultas complexas são exigidas pelo utilizador. Comparado ao modelo relacional,

que para estas situações pode ser muito custoso” (Lóscio et al., 2011). Isto porque

quando se percorre um grafo, algoritmos heurísticos são aplicados para otimizar a

busca por valores, identificando qual o melhor caminho entre dois nós, isto sem

haver necessidade de verificar outros nós. Já no modelo relacional estas consultas

obrigavam a construir joins, que caso fossem muito complexos afetavam o

desempenho da consulta;

“Esse modelo também dá suporte ao uso de restrições sobre os dados, como

restrições de identidade e de integridade referencial (Diana & Gerosa, 2010), ao

contrário da maioria dos modelos NoSql que são mais flexíveis;”

“Esse modelo pode tornar consultas rápidas, devido à possibilidade da utilização de

propriedades de grafos, medidas de centralidade (pagerank) e algoritmos de menor

caminho” (Toth, 2011).

Na seguinte figura é possível visualizar um exemplo destas bases de dados, onde várias

pessoas têm relacionamentos entre si, quer de amizade, quer de empregado/patrão.


30

Figura 9 - Exemplo das relações numa graph database (Retirado de Sadalage & Fowler, 2012,pag.52)

Sendo assim, as graph databases são indicadas para situações de contexto complexo em

que se conhece a semântica entre os objetos armazenados (Almeida & Brito, 2012).

2.3.4.4 Document-based Databases

Estas bases de dados são organizadas em coleções de documentos, ao contrário das bases

de dados relacionais em que se usam tabelas estruturadas com campos para cada registo.

Também é permitido ao utilizador adicionar vários campos de diferentes tamanhos a um

documento (Leavitt, 2010).

Nestas bases de dados o objetivo é gerir e armazenar documentos. Estes documentos podem

assumir os formatos XML, JSON (Javascript Object Notation) ou BSON (Binary JSON) que

são formatos padrão na troca de dados (Moniruzzaman & Hossain, 2013).

Uma vez que estas bases de dados não possuem um esquema definido para lidar com os

dados faz com que sejam uma boa solução para as típicas aplicações da web 2.0, assim como

para gerir conteúdos associados às redes sociais (Queiroz et al., 2013).

Este tipo de base de dados armazena coleções de documentos, em que um documento

representa “um objeto com um identificador único e um conjunto de campos, que podem

ser strings, listas ou documentos embutidos” (Lóscio et al., 2011).

Diana & Gerosa (2010) referem que este tipo de base de dados “não possui esquema, ou

seja, os documentos armazenados não precisam possuir estrutura em comum”, assim novos

campos podem ser acrescentados a um documento, sem que traga problemas à base de

dados.

O modelo orientado a documentos estende o modelo chave-valor, associando a uma chave

31


um documento, por exemplo, documentos JSON (Carniel et al., 2012).

As Document Databases agrupam pares de chave-valor em documentos. A cada documento

é atribuída uma chave especial “ID”, sendo que esta é atribuída a cada um destes

separadamente. Desta forma, é possível tratar dados estruturados complexos como Nested

objects mais convenientemente (Hecht & Jablonski, 2011).

Diversos atributos podem estar contidos dentro de uma única coluna, e, por sua vez, o

número e tipo de atributos armazenados podem variar de registo para registo.

Contrariamente às key-value databases, este tipo de base de dados permite a pesquisa por

chave ou valor, sendo ideais para armazenar e gerir Big data-Size collections de documentos

como:

Documentos de texto;

Mensagens de correio eletrónico;

Documentos XML;

Representações de entidades da base de dados como produto ou consumidor;

Sparse Data (Moniruzzaman & Hossain, 2013).

Como as key value databases, estas não possuem restrições ao nível de esquema, o que

permite guardar novos documentos, com qualquer tipo de atributos, tão facilmente como

adicionar novos atributos aos documentos existentes em tempo real.

É possível efetuar pesquisas por multi atributo em registos que podem ter diferentes tipos

de pares chave-valor, o que as leva a serem uma ótima escolha para a integração de dados,

assim como para tarefas de migração de esquemas (Hecht & Jablonski, 2011).

Dentro de uma coleção, os documentos podem ser vistos de forma sequencial, podem ser

recuperados individualmente utilizando o seu identificador ou efetuar uma consulta

respeitando a sua estrutura de campos. É igualmente possível introduzir um novo

documento a qualquer altura numa coleção (Atzeni et al., 2013).

Cada coleção possui um nome, e as operações individuais referem-se a esta usando o seu

nome. Desta forma inserem objetos para uma coleção específica. De certo modo, as coleções

possuem uma forma ligeira de esquema, isto porque são visíveis tal como as tabelas nas

bases de dados relacionais. Uma forma pode dizer-se ligeira pois por um lado as coleções

não necessitam de ser explícitas, ao contrário do que acontece nas bases de dados

relacionais, onde uma create table é precisa antes de um select. Por outro lado, nas NoSql,

uma nova coleção é iniciada quando um comando refere uma coleção inexistente. E é

igualmente ligeira, pois a sua estrutura interna não é pré-definida (Atzeni et al., 2013).

Cada objeto possui uma chave que é única, os atributos são elementos básicos do modelo,


32

correspondendo a valores simples como strings ou inteiros (Han et al., 2011).

O facto de as relações estarem integradas dentro do próprio documento pode originar dados

duplicados, mas isto possibilita uma consulta direta. Desta forma, tendo como base uma

estrutura que tenha uma relação Cliente com Encomendas (um cliente pode ter várias

encomendas), se uma consulta fosse criada para retornar as encomendas do Cliente “X”,

neste tipo de base de dados bastaria obter o documento correspondente ao Cliente “X”, que

este por sua vez já traria os documentos correspondentes às suas encomendas. Já nas bases

de dados relacionais seria necessário fazer uma junção das tabelas Clientes e Encomendas,

o que levaria a uma diminuição de desempenho na sua execução, mais sentida caso as

tabelas tenham alguma dimensão (Almeida & Brito, 2012). Uma outra vantagem de possuir

dados duplicados é que “facilita a distribuição do sistema, já que a quantidade de nós a

serem consultados numa busca envolvendo várias entidades relacionadas é menor caso elas

estejam próximas” (Diana & Gerosa, 2010). Sendo assim, dependendo do contexto, Diana

& Gerosa (2010), referem que “pode criar problemas de consistência no banco de dados,

causados por anomalias de atualização e remoção”, isto pode ser sentido quando um

documento duplicado é atualizado num só documento.

A principal diferença entre as Key value databases e as Document é o facto de nas Key value

as agregações serem opacas para os sistemas e nas Document a estrutura das agregações é

transparente, ou seja, pode ser vista.

Nas key value databases apenas podemos aceder a uma agregação por via de uma chave.

Nas Document Databases podemos submeter consultas à base de dados baseadas nos

campos da agregação, podemos retirar parte de uma agregação em vez de tudo, e a base de

dados pode criar índices baseadas no conteúdo da agregação (Sadalage & Fowler, 2012).

De acordo com Strauch (2010), as bases de dados CouchDB e MongoDB são os principais

representantes desta classe de banco de dados baseada em documentos. (Almeida & Brito,

2012)

33


Figura 10 - Exemplo de dois Documentos de uma Document database

Relativamente aos documentos acima apresentados pode-se verificar que são similares mas

têm diferenças no conteúdo. Isto é permitido nas Document Databases. Ainda que a

estrutura de dados possa diferir entre os documentos, estes podem na mesma pertencer à

mesma coleção, ao contrário das bases de dados relacionais em que cada linha na tabela tem

de seguir a mesma estrutura (Sadalage & Fowler, 2012).

2.3.4.4.1 CouchDB

Apache CouchDB é uma Document database open-source (CouchDB, 2011), criada pela

Fundação Apache e está desenvolvida em Erlang, que é uma linguagem de programação

utilizada para aplicações concorrentes e distribuídas. As propriedades ACID são cumpridas

nesta base de dados, fornecendo atualizações serializadas (CouchDB, 2011). É já da sua

natureza distribuído e suporta vários tipos de esquemas de replicação e resolução de

conflitos.

Data Model

CouchDB utiliza uma base de dados formada por uma coleção independente de documentos

em JSON. Estes documentos são compostos por pares de chave/valor. Valores podem ser

do tipo: números, string, boleanos e listas. Estes documentos não possuem qualquer tipo de

esquema e, sendo assim, não têm de seguir nenhuma estrutura, exceto claro, a estrutura

inerente a JSON. Na seguinte imagem pode-se visualizar um exemplo que modela a

informação necessária para descrever um livro.


34

Figura 11 - Documento contendo um exemplo de descrição de um livro (Retirado de Silva, 2011,pag.14)

Segundo Queiroz et al. (2013), são atribuídos a cada documento pelo menos dois atributos:

um número de revisão para resolução de conflitos durante atualizações e um identificador

único.

Silva (2011) cita Anderson et al. (2010).que referem que esta base de dados “é um simples

contentor de uma coleção de documentos e não estabelece nenhuma relação obrigatória

entre eles”

Embora o CouchDB não imponha nenhum tipo de relação entre os documentos, é importante

possuir algum tipo de estrutura que retrate como os documentos são organizados. Sendo

assim, o CouchDB fornece um view model.

Segundo Silva (2011), views são métodos de agregar documentos existentes na base de

dados. Já para Queiroz et al. (2013) permitem a filtragem de partes específicas ou criar

índices para acelerar a procura de um documento. Estas não afetam os dados de uma base

de dados, simplesmente mudam a maneira de como os dados são representados, definindo

assim o design da aplicação.

Silva (2011) também refere que “para definir uma view o utilizador deve fornecer uma

função javascript que atua como uma função map da operação mapreduce. Esta função leva

um documento como um argumento e é permitido manipular os dados do documento da

maneira que se desejar. A view resultante é um documento que pode ter múltiplas linhas.”

Na figura anterior foi apresentado um caso de uma coleção de documentos de livros.

Partindo do princípio que é pretendido obter o título de todos os livros que estão

armazenados na base de dados, criamos uma função map correspondente para ser usada na

view como é mostrado na imagem seguinte.

35


Figura 12 - Exemplo de uma função utilizada para obter o título de todos os livros armazenados na base de dados

(Retirado de Silva, 2011,pag.14)

Query Model

O CouchDB utiliza uma RESTful HTTP API para efetuar operações CRUD básicas em todos

os dados armazenados e utiliza métodos como, http POST, GET, PUT e DELETE as realizar.

Consultas mais complexas podem ser como views, como se viu anteriormente e o resultado

pode ser lido utilizando esta REST API (Anderson et al., 2010; Silva, 2011).

Replication Model

O CouchDB é um sistema de base de dados distribuído peer-based (CouchDB, 2011),

permite peers para atualização e alteração de dados, sincronizando bidireccionalmente as

mudanças. Portanto, utilizando o master-slave setup, em que as sincronizações são feitas

unilateralmente, ou o master-master setup, em que as mudanças podem acontecer em

qualquer um dos nodos, estes devem ser sincronizados bidireccionalmente.

Para isto acontecer, o CouchDB utiliza uma replicação otimista e tem a capacidade de lidar

com conflitos, que podem acontecer derivado a replicações de alterações. Como já foi

referido anteriormente, um id de revisão é atribuído, isto porque sempre que um documento

é atualizado, a versão antiga é mantida e atribuído à versão atualizada um id de revisão

diferente. Portanto, quando um conflito é detetado, a versão que prevalecer é gravada como

a mais recente e a versão que não prevalecer é também gravada na história do documento.

Isto é realizado de forma consistente em todos os nós. Existe a possibilidade da aplicação

poder escolher lidar com o conflito por ela própria, ignorando uma versão (Anderson et al.,

2010).

Consistency Model

Relativamente à consistência, o CouchDB fornece Eventual Consistency. Como vários

masters são permitidos, as alterações têm a necessidade de serem propagadas aos nodos

restantes, sendo assim não existem bloqueios de escrita. Portanto, até estas alterações se

propagarem de nodo para nodo, a base de dados permanece num estado de inconsistência.

Como são suportados master setups únicos com múltiplos slaves, Strong Consistency pode


36

ser alcançada (Anderson et al., 2010).

2.3.4.4.2 MongoDB

O MongoDB é uma Document database open-source escrita na linguagem C++ (10gen,

2011). A companhia 10gen também fornece suporte a esta base de dados. Não possui

qualquer tipo de esquema e gere documentos JSON como o CouchDB. Foca-se no alto

desempenho e desenvolvimento ágil, fornecendo ao programador um conjunto de

caraterísticas para facilmente consultar dados, ao mesmo tempo que escala o sistema.

Data Model

O MongoDB utiliza uma base de dados composta por coleções de documentos no formato

BSON, que é uma versão dos documentos JSON mas binária. Segundo Queiroz et al. (2013),

estas coleções e documentos relembram os conceitos de tabelas e linhas da tecnologia

relacional, mas com a particularidade dos documentos não necessitarem de ter o mesmo

esquema. Sendo assim, os documentos podem conter campos que são diferentes uns dos

outros. Na figura seguinte podemos então visualizar a diferença existente entre os campos.

Figura 13 - Exemplo de um Documento com campos distintos (Retirado de Queiroz et al., 2013,pag.485)

Os documentos contemplados pela base de dados MongoDB estão num “formato chamado

BSON que é muito semelhante ao JSON mas numa representação binária, por razões de

eficiência e por causa de tipos de dados adicionais em comparação com JSON” (Strauch,

2010).

A principal vantagem em utilizar BSON é a eficiência, tanto no espaço como no tempo de

37


computação, uma vez que é formato binário (MongoDB, 2011a).

Cada documento possui um identificador único Id, que pode ser dado pelo utilizador quando

um documento é criado ou automaticamente gerado pela base de dados (MongoDB, 2011c).

No campo Id um índice é automaticamente criado, embora outros índices possam ser criados

manualmente com o objetivo das consultas se tornarem mais rápidas (MongoDB, 2011b).

Query Model

O MongoDB suporta consultas dinâmicas sobre todos os documentos existentes numa

coleção. Segundo Silva (2011), “as consultas são expressas como objetos JSON e são

enviadas para o MongoDB por database drivers (normalmente usando o método “find”)”

(MongoDB, 2011e).

Na imagem seguinte pode-se visualizar um exemplo onde uma base de dados é consultada

por todos os livros contendo o título “Flatland”.

Figura 14 - Exemplo de uma consulta sobre todos os livros que contêm o título Flatland (Retirado de Silva, 2011,pag.17)

Como se pode constatar na imagem seguinte, também é possível sorting e contagem de

caraterísticas. Na primeira consulta todos os livros que estão escritos em inglês são

recuperados, ordenando-os pelo seu título. Já na segunda consulta o número de livros

escritos em inglês é recuperado.

Figura 15 - Exemplo de duas consultas efetuadas no MongoDB (Retirado de Silva, 2011,pag.17)

Replication Model

O MongoDB fornece replicação master-slave e replica sets, sendo que os dados são

replicados assincronamente entre servidores. Em ambos os casos, para operações de escrita,

apenas um servidor é usado, enquanto as operações de leitura podem ser redirecionadas para

os servidores slave (MongoDB, 2011d).

Segundo Silva (2011), “uma replica set é um grupo de servidores em que em qualquer ponto

do tempo existe apenas um servidor master, mas o conjunto é capaz de eleger um novo

master, se o master corrente for abaixo.” Dados são replicados através dos servidores do

conjunto.

Consistency Model

O facto de o MongoDB possuir apenas um master ativo, Strong Consistency é possível se


38

todas as operações de leitura forem realizadas no master (MongoDB, 2011d).

Se a replicação para os servidores slave for feita assincronamente e o MongoDB não

necessitar de fornecer version concurrency control, a leitura nos servidores escravos será de

Eventual Consistency. O facto de poder existir leitura nos servidores slaves é bom pois assim

pode-se alcançar o balanceamento de carga e, sendo assim, o cliente também pode fazer

com que a escrita seja replicada para servidores slaves. Isto ajuda a lidar com escritas

importantes, em que a Eventual Consistency possa não ser adequada, porque assim

consegue-se flexibilidade de leitura para ler através dos servidores escravos.

2.3.5 Comparação entre os tipos de Bases de Dados NoSql

Nesta secção as bases de dados NoSql são comparadas em diversos aspetos, para perceber

o que cada uma fornece.

2.3.5.1Comparação Geral

De modo a entender melhor os vários tipos de bases de dados, estes irão ser comparados

nos seguintes pontos:

Modelo de Dados: O modelo suportado pelos vários tipos de bases de dados;

Modelo de Transação: Prioridade da base de dados na seleção das trocas baseadas

no teorema CAP;

Licença: O tipo de licença do software;

Índices: Que bases dados suportam índices;

Sharding: Indica que bases de dados possuem sharding automático. Isto é, a

capacidade de automaticamente redistribuir os dados e replicações através dos

servidores quando há mudanças de recursos, como adicionar ou remover servidores

(Indrawan- Santiago, 2012).

39


Base de

dados

Modelo de

Dados

Modelo de

Transação

Licença Índice? Sharding?

Cassandra Column-

family

PA Open source Não Sim

CouchDB Document PA Open source Sim Não

DynamoDB Key-value PA Comercial Sim Sim

HBase Column-

family

PC Open source Não Sim

MongoDB Document PA Open source Sim Sim

Neo4j Graph CA Open source Não Não

Riak Key-value PA Open source Sim Sim

Voldemort Key-value PA Open source Sim Sim

Tabela 2 - Comparação entre os tipos de bases de dados NoSql (Adaptado de Indrawan-Santiago, 2012,pag.47)

2.3.5.2 Particionamento, Replicação e Consistência

Particionamento

Como já foi referido anteriormente, a maioria das bases de dados NoSql implementam

algum tipo de particionamento horizontal ou sharding, em que se armazenam conjuntos de

registos em diferentes segmentos que podem estar alocados em diferentes servidores.

Segundo Grolinger et al. (2013), “o modelo de dados é um fator significativo para definir

estratégias para particionamento em bases de dados.”

Existem várias estratégias de particionamento horizontal, mas as mais utilizadas são Range

Partitioning e Consistent Hashing.

Em relação à Range Partitioning, o objetivo é atribuir os dados a partições, localizadas em

diferentes servidores baseados em conjuntos de uma chave de partição. Um servidor tem

como função armazenar e lidar com a leitura/escrita de um específico conjunto de chaves.

Esta estratégia tem como vantagem o processamento efetivo de range queries, isto porque

chaves adjacentes residem no mesmo nodo. No entanto, pode ter desvantagens como hot

spots e load- balancing issues. Por exemplo, se os dados são processados de acordo com as

suas chaves valores, a carga de processamento será bastante concentrada num único servidor

ou em poucos servidores.

Em relação ao Consistent Hashing, o conjunto de dados é representado como um círculo. O

círculo é dividido em conjuntos, igual ao número de nodos disponíveis e cada nodo é

mapeado para um ponto do círculo. Na figura seguinte é possível visualizar o Consistent

Hashing num exemplo com 4 nodos, N1 para N4. Para se determinar o nodo onde um objeto

deve ser alocado o sistema faz hash à chave do objeto e descobre a sua localização no

círculo. Na imagem seguinte pode-se verificar que o objeto “a” está localizado entre o nodo

N4 e N1. De seguida o círculo é percorrido no sentido horário, até que o primeiro nodo seja


40

encontrado e, assim, atribui-se o objeto a esse nodo. O objeto “a” presente na seguinte figura

é atribuído ao nodo N1. De acordo com Grolinger et al. (2013), “cada nodo é responsável

pela região do anel entre ele e o seu predecessor, e referem um exemplo onde o nodo N1 é

responsável pelo data range 1, N2 pelo data range 2 e assim sucessivamente.” A localização

de um objeto no Consistent Hashing pode ser calculada rapidamente, não sendo necessário

um serviço de mapeamento como é necessário no Range Partitioning.

Figura 16 - Consistent hashing (Retirado de Grolinger et al., 2013, pag.13)

O Redis e o Memcache não possuem nenhuma estratégia de particionamento, sendo o cliente

que escolhe uma.

Replicação

Além da escalabilidade de leitura/escrita ser aumentada, a replicação também aumenta a

confiança no sistema, na tolerância a falhas e na durabilidade. Existem duas estratégias de

replicação que ressaltam à vista, sendo elas a replicação master–slave e multi-master.

Como já foi referido anteriormente, na replicação master-slave, um único nodo é designado

como master e é o único nodo que pode processar pedidos de escrita. As alterações

realizadas são propagadas do master para os nodos slaves. Bases de dados que utilizam este

tipo de replicação são o Redis, BerkeleyDB, e o HBase.

Já na replicação multi-master, existe a possibilidade de vários nodos processarem pedidos

de escrita, que depois são propagados para os nodos seguintes. Neste tipo de replicação a

direção de propagação pode ocorrer em diferentes direções, ao contrário da replicação

mater/slave. Bases de dados que utilizam este tipo de replicação são o CouchDB e o

Couchbase Server.

As bases de dados, Voldemort, Riak, e Cassandra, utilizam a replicação masterless que é

41


similar à replicação multi-master, pois tal como nesta vários nodos aceitam pedidos de

escrita. No sistema de replicação todos os nodos possuem o mesmo papel.

Outro fator importante na replicação e que causa grande impacto nas bases de dados é o

modo como as operações de escrita são propagadas entre os nodos. A sincronização de

réplicas pode ser síncrona ou assíncrona. De acordo com Grolinger et al. (2013), na síncrona

“as alterações são propagadas antes que o sucesso da operação de escrita seja reconhecido

pelo cliente. Isto significa que a replicação síncrona introduz atrasos porque a operação de

escrita é completada apenas depois da alteração da propagação.” Este tipo de replicação é

raramente usada pelas bases de dados NoSql, isto porque pode levar a grandes atrasos no

caso de perda temporária ou degradação da conexão. Já em relação à assíncrona referem

que “o sucesso de uma operação de escrita é reconhecida antes das alterações serem

propagadas para a réplica do nodo”. É uma vantagem porque permite a replicação para

longas distâncias mas pode ser uma desvantagem, pois pode resultar em nodos com cópias

de dados inconsistentes.

A escolha do modelo de replicação é de extrema importância porque tem impacto na

capacidade da base de dados escalar pedidos de leitura e escrita (Grolinger et al., 2013).

Consistência

Esta consistência diz respeito à utilizada no teorema CAP, que está relacionada com a

maneira como os dados são vistos nos nodos do servidor, isto depois das operações de

atualização.

Existem dois modelos de consistência, sendo eles a Strong Consistency e a Eventual

Consistency. Na Strong Consistency é assegurado que quando se confirma pedidos de

escrita, os dados atualizados são visíveis nos pedidos seguintes de leitura.

Já no modelo de Eventual Consistency, que já foi referido anteriormente, as alterações são

eventualmente propagadas através do sistema levando o tempo necessário. Sendo assim,

alguns nodos servidor podem conter dados inconsistentes durante um certo período de

tempo.

A maioria das bases de dados NoSql fornecem Eventual Consistency.

De salientar que o MongoDB pode alcançar Strong Consistency usando duas técnicas

diferentes. Primeiro uma conexão é estabelecida pelo master, mas apenas de leitura. A

segunda opção é estabelecer um parâmetro denominado “Replica Acknowledged”, o qual

tem foco na escrita, este assegura que uma escrita é bem-sucedida em todas as réplicas antes

de ser confirmado. No entanto, a base de dados torna-se num sistema de replicação síncrona


42

e o seu desempenho é afetado negativamente.

Tabela 3 - Comparação dos tipos de bases de dados NoSql em termos de particionamento, replicação e consistência

(Retirado de Grolinger et al., 2013,pag.11)

43


2.3.6 Considerações Finais

2.3.6.1 Mitos do NoSql

Segundo Toth (2011), foram criados muitos mitos em redor deste tema, e o autor refere

alguns deles:

NoSql é escalável

É bastante referido que a tecnologia NoSql é bastante escalável, mas esta não escala

automaticamente, simplesmente é mais fácil de ser escalada quando comparado com o

modelo de base de dados relacional.

Não precisamos mais de Administradores de base de dados

Possuir um modelo que proporciona um cenário no qual temos escalabilidade facilitada,

então faz sentido dizer que o profissional com o perfil de administrador de base de dados

não seja mais necessário. Falso. É claro que serão sempre necessários administradores pois

existe sempre a necessidade de fazer backups e lidar com a tecnologia.

Económico

É referido por bastantes autores o custo mais reduzido em comparação à tecnologia SQL

devido às licenças envolvidas e ao preço da escalabilidade. Muitas vezes a tecnologia

relacional cumpre todas as necessidades do cliente e pode ter custos ainda menores, isto

porque também existem bases de dados relacionais open source. Como refere o autor, é tudo

uma questão de analisar o tamanho, licenças e necessidade.

2.3.6.2Dificuldades do NoSql no Ambiente Empresarial

Michael Stonebreaker (2011) refere no Blog CACM que de acordo com um recente post no

blog ReadWriteWeb por Audrey Watters, 44% dos utilizadores corporativos interrogados

nunca tinham ouvido falar de NoSql e uns adicionais 17% não tinham interesse. Pela

experiência dialogando com amigos que possuem empresas chegou a algumas conclusões

do porquê das empresas não estarem interessadas no NoSql, que são as seguintes:

Uma delas é não existindo ACID é igual a perda de interesse: ACID é o padrão

utilizado para alterações de conjuntos de dados partilhados. Um sistema que não

suporte transações reais não dá para adaptar a OLTP. O ponto-chave que o autor

concluiu foi que “um conjunto de dados pode ser feito através de transações de um

único registo, caraterística típica da tecnologia NoSql, mas nada garante que no

futuro não irá ser necessário efetuar operações multi registo o que se tornará um

problema.”


44

Outra é que a linguagem de consultas de baixo nível está morta: A linguagem

de alto nível SQL mostrou que oferece facilidade de programação para consultas ad

hoc de data warehouse. Já na maioria dos produtos NoSql possuem um interface

algorítmico de record-at-a-time que não interessa às empresas.

E por fim NoSql significa “no Standard”: Caso as empresas possuam bastantes

bases de dados, começam preocupações relativamente à quantidade de interfaces

diferentes que os programadores têm de aprender. Como já foi referido existem

vários produtos NoSql, cada um com um interface diferente, já o Sql oferece um

ambiente padrão, que sendo assim, facilita o seu uso em empresas de grande

dimensão.

2.3.6.3 Criticas sobre a Tecnologia NoSql

Scofield (2009) resolveu responder a algumas críticas sobre a tecnologia NoSql:

“NoSql trata-se apenas de Document Databases, ou key-value stores, ou ...”:

Scofield notou que a maioria dos artigos sobre NoSql apenas referem as Document-

based databases ou as key-value stores, e, às vezes, as column-stores. Ele refere que

bons argumentos podem ser feitos, mas que apenas se referem a um tipo específico

de sistema de armazenamento. Scofield critica esta abordagem de só se referirem a

apenas alguns tipos de bases de dados NoSql pois permite aos “tradicionalistas”

argumentar facilmente contra o movimento NoSql ou contra as diferentes

abordagens desta tecnologia.

“Podemos lidar com NoSql também nas Bases de dados relacionais.”: O autor

refere que diferentes aplicações são boas para coisas diferentes, e faz a seguinte

pergunta “Bases de dados relacionais são ótimas com dados relacionais, então

porque haveríamos de as querer usar para dados NoSql?” É evidente salientar que

cada tecnologia tem o seu propósito.

“NoSql é uma rejeição total das bases de dados relacionais”: Esta frase era

bastante referida há algum tempo atrás na comunidade NoSql, mas cada vez menos

tem sido referida, o que agrada a Scofield (2009) citado por Strauch (2010) que diz

que estamos a avançar para uma abordagem pluralista para guardar os nossos dados,

o que é bom.

45

Análise e Carregamento dos Dados _____________________________________________________________________________

Capítulo 3 – Análise e Carregamento dos

dados

Neste capítulo serão descritos os dados que vão servir como exemplo para testar as bases

de dados e onde foram conseguidos. De seguida, apresenta-se a forma como foram

carregados e referido qualquer tratamento que tenham sofrido.

3.1 Dados para Carregamento

O dataset escolhido envolveu dados sobre aviação comercial fornecidos pela American

Statistical Association 1 baseado nos dados fornecidos pela United Sates Department of

Transportation 2.

O que levou à preferência por este dataset foi o facto de ser bastante extenso, o que é ótimo

para a análise do desempenho das bases de dados.

Os dados provenientes do United States Department of Transportation estão no tipo csv e

são constituidos pelos seguintes dados:

Csv com dados dos aviões

Figura 17 – Extrato do csv aviões

1 http://stat-computing.org/dataexpo/2009/the-data.html 2 http://www.transtats.bts.gov/Fields.asp?Table_ID=236

Análise e carregamentos dos dados _______________________________________________________________________________

46

Csv com dados das companhias aéreas

Csv com dados dos aeroportos

Figura 19 – Extrato do csv aeroportos

Csv com os dados gerais de voos por ano (desde 1995 a 2008)

Figura 20 – Extrato do csv contendo voos de 1995

Será com estes dados que iremos instanciar as bases de dados NoSql e Relacional em análise

nesta dissertação.

Relativamente à Tecnologia Relacional, optou-se por utilizar o SGBD MySQL dado ser o

principal representante desta tecnologia em termos de open-source.

3.2 Carregamento dos dados no MySQL

Para efetuar o estudo comparativo da tecnologia relacional com a não relacional optou-se

pela criação de quatro bases de dados cada uma com número de registos diferentes. A

primeira com cerca de 1 milhão e 500 mil registos dizendo respeito ao csv do ano de 1995,

a segunda com cerca de 5 milhões de registos dizendo respeito aos csv dos anos de 1995,

1996 e 1997, a terceira com cerca de 15 milhões de registos dizendo respeito aos csv de

1995 a 2003 e por último uma base de dados com cerca de 41 milhões de registos com todos

os csv existentes, ou seja, de 1995 a 2008.

Cada base de dados tem o nome tese com o número correspondente da mesma como por

Figura 18 – Extrato do csv companhias aéreas

47


exemplo tese1, tese2, tese3 e tese4. Estas foram carregadas da mesma maneira sendo

descrito nos sub-capítulos seguintes o conjunto de passos que foi seguido.

3.2.1 Modelo conceptual de dados

Depois da análise dos dados e conforme os csv disponibilizados pela United State

Department of Transportation foi desenhado o modelo que iria receber o carregamento dos

dados. Este foi pensado de forma a normalizar o máximo de tabelas de modo a seguir as

linhas da tecnologia relacional, permitindo consultas em múltiplas tabelas. Na imagem

seguinte é demonstrado o modelo criado.

Figura 21 - Modelo conceptual de dados

3.2.2 Descrição das Entidades

Relativamente à entidade Airplane, os dados dizem respeito aos dados principais do avião,

sendo descritos na seguinte tabela.

Campo Descrição

Tailnum Chave primária da tabela Avião, com

auto incremento.

Issuedata Data de registo da matrícula.

Status Estado do avião, se está pronto para

viagens ou aguarda registo.

Year Ano do avião. Tabela 4 - Descrição dos atributos da entidade airplane

Relativamente à tabela Airline, os dados dizem respeito às companhias aéreas.

Campo Descrição

idAirline Chave primária da tabela Airplane, com

auto incremento.

Description Sigla da companhia aérea. Tabela 5 - Descrição dos atributos da entidade Airline


48

Relativamente à tabela Airport, os dados dizem respeito aos aeroportos tanto de origem

como de destino.

Campo Descrição

Idairport Chave primária da tabela Airport, chave

já fornecida no csv com o código do

aeroporto.

airport Nome do aeroporto.

city Cidade.

state Estado.

country País.

latitude Latitude.

longitude Longitude. Tabela 6 - Descrição dos atributos da entidade airport

Relativamente à tabela Aircraft_type, esta foi partida do csv avião e os dados dizem respeito

ao tipo de aeronave.

Campo Descrição

idAircraft_type Chave primária da tabela Aircraft_type,

com auto incremento.

type Tipo de aeronave. Tabela 7 - Descrição dos atributos da entidade aircraft type

Relativamente à tabela Engine_type, esta for partida do csv avião e os dados dizem respeito

aos tipos de motores de avião existentes.

Campo Descrição

idEngine_type Chave primária da tabela Engine_type,


type Tipo do motor. Tabela 8 - Descrição dos atributos da entidade engine type

Relativamente à tabela Flight, os dados dizem respeito à informação dos voos realizados.

Campo Descrição

idFlight Chave primária da tabela Flight, com

auto incremento.

Year Ano em questão.

Month Mês em questão.

Dayofmonth Dia do mês em questão, com valores de 1

a 31.

Dayofweek Dia da semana em questão, com valores

de 1 a 7.

Deptime Tempo de partida atual, no formato

hhmm.

CRSDeptime Tempo de partida previsto, no formato

hhmm.

Arrtime Tempo de chegada atual, no formato

49


hhmm.

CRSArrtime Tempo de chegada previsto, no formato

hhmm.

Flightnum Número de voo.

ActualElapsedTime Tempo atual de voo em minutos.

CRSElapsedTime Tempo previsto de voo em minutos.

Airtime Tempo de voo em minutos.

ArrDelay Atraso de chegada em minutos.

DepDelay Atraso de partida em minutos.

Distance Distância entre aeroportos em milhas.

TaxiIn Tempo de Taxi in (pronto para o avião

aterrar) em minutos.

TaxiOut Tempo de Taxi out (pronto para o avião

descolar) em minutos.

Cancelled Booleano de cancelamento, 1-sim 0-não.

Diverted Booleano de desvio, 1-sim 0-não. Tabela 9 - Descrição dos atributos da entidade flight

Relativamente à tabela Manufacturer, esta foi partida do csv avião e os dados dizem

respeito aos fabricantes dos modelos de aviões.

Campo Descrição

idManufacturer Chave primária da tabela Manufacturer,


Name Nome do fabricante. Tabela 10 - Descrição dos atributos da entidade manufacturer

Relativamente à tabela Model, esta foi partida do csv avião e os dados dizem respeito aos

modelos de avião existentes.

Campo Descrição

idModel Chave primária da tabela Model, com

auto incremento.

Name Nome do modelo. Tabela 11 - Descrição dos atributos da entidade model

Por fim, relativamente à tabela Plane_type, esta foi partida do csv avião e os dados dizem

respeito aos tipos de aviões existentes.

Campo Descrição

idPlane_type Chave primária da tabela Plane_type com

auto incremento.

type Tipo de avião. Tabela 12 - Descrição dos atributos da entidade plane type

3.2.3 Carregamento das tabelas filho

Relativamente às tabelas filho, estas podem ser carregadas diretamente através da


50

ferramenta import no workbench. Sendo mais rápido o seu carregamento do que nas que

serão apresentadas no tópico seguinte (tabelas pai). As tabelas que foram carregadas desta

maneira foram a Airport e Airline. Na imagem seguinte pode-se verificar um exemplo de

carregamento usando a tabela Airport.

Figura 22 - Import do csv airport

Efetuou-se o mapping com as colunas do csv e estas foram carregadas automaticamente

para os campos pretendidos.

Como estas tabelas já tinham um campo com possibilidade de chave primária a ferramenta

import era suficiente para o carregamento, mas nas restantes como é necessário a criação de

uma chave primária de auto incremento foram carregadas através de consultas. Como estes

campos estão contidos na tabela avião foram selecionados os pretendidos e inseridos nas

tabelas correspondentes, como é possível visualizar no seguinte código.

CREATE TABLE àircraft_type` (

ìdAircraft_type` int(11) NOT NULL AUTO_INCREMENT,

`type` varchar(45) DEFAULT NULL,

PRIMARY KEY (ìdAircraft_type`),

UNIQUE KEY `type_UNIQUE` (`type`)

) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

51


insert into aircraft_type (type)

select distinct aircraft_type from aviao;

CREATE TABLE èngine_type` (

ìdengine_type` int(11) NOT NULL AUTO_INCREMENT,


PRIMARY KEY (ìdengine_type`),



insert into engine_type (type)

Select distinct engine_type from aviao;

CREATE TABLE `plane_type` (

ìdplane_type` int(11) NOT NULL AUTO_INCREMENT,


PRIMARY KEY (ìdplane_type`),



Insert into plane_type (type)

Select distinct type from aviao;

CREATE TABLE `manufacturer` (

ìdManufacturer` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(45) DEFAULT NULL,

PRIMARY KEY (ìdManufacturer`),

UNIQUE KEY `name_UNIQUE` (`name`)


Insert into manufacturer (name)

Select distinct manufacturer from aviao;

CREATE TABLE `model` (

ìd_model` int(11) NOT NULL AUTO_INCREMENT,

`model` varchar(45) DEFAULT NULL,

PRIMARY KEY (ìd_model`)


Insert into model (model)

Select distinct model from aviao;

De salientar que também podiam ser carregadas através da ferramenta import do

Workbench, mas neste caso os id’s ficavam com números aleatórios e, sendo assim, optou-


52

se por utilizar estas queries para ficarem os id’s todos organizados.

3.2.4 Carregamento das tabelas pai

Para garantir que os dados em todas as tabelas condiziam, efetuou-se o carregamento por

inner joins, eliminando assim todos os dados não correspondentes entre si.

Através de vários testes foram construídos uma série de passos para um carregamento

eficiente de todos os dados.

Primeiro criou-se uma tabela avião e uma tabela csv_1995 para carregar os dados de ambos

os csv. Para isso, utilizou-se o load infiles do MySQL conforme está presente no seguinte

código.

“ LOAD DATA LOCAL INFILE 'C:\\1995.csv'

INTO TABLE tese1.csv_1995

FIELDS TERMINATED BY ',' ENCLOSED BY '"'

LINES TERMINATED BY '\n'

IGNORE 1 LINES “

De seguida, efetuou-se uma consulta em que o objetivo era retornar todos os aviões que

tinham voos correspondentes na tabela csv_1995 através do tailnum que está contido em

ambas as tabelas, avião e csv_1995, criando-se assim a tabela aviao1.

“ Use tese1;

create table aviao1

(select distinct a.tailnum, a.type, a.manufacturer,

a.issue_data, a.model, a.status, a.aircraft_type,

a.engine_type, a.year, c.uniquecarrier

From aviao a

INNER JOIN csv_1995 c

ON a.tailnum = c.tailnum ) “

Com as tabelas Engine_type, Plane_type, Airline, Manufacturer, Aircraft_type e Model

previamente carregadas, é necessário agora fazer um inner join da tabela aviao1 com estas

conforme o código seguinte, isto também para garantir que todos os aviões têm ligações

com estas tabelas.

“ Use tese1;

create table airplane

(select distinct a.tailnum, a.issue_data, a.status, a.year,

53


c.idplane_type, d.idengine_type, e.id_model,

b.idAircraft_type, f.idAirline, g.idManufacturer

From aviao1 a

INNER JOIN aircraft_type b

ON a.aircraft_type = b.type

INNER JOIN plane_type c

ON a.type = c.type

INNER JOIN engine_type d

ON a.engine_type = d.type

INNER JOIN manufacturer g

ON a.manufacturer = g.name

INNER JOIN model e

ON a.model = e.model

INNER JOIN airline f

ON a.uniquecarrier = f.idAirline ) “

Airplane é então a tabela final de avião, definindo-lhe assim uma chave primária, neste caso

o tailnum. Sendo assim, já é possível carregar a tabela de voos final mas, para isso, é

necessário que esta tenha correspondência com o aeroporto de origem e destino e com os

aviões. Para tal efetuou-se um inner join do id_airport com os campos origin e dest na tabela

csv_1995 e do tailnum na tabela Airplane, conforme está presente no seguinte código. Foi

definida também uma chave primária de auto incremento denominada id_flight.

Use tese1;

create table flight (id_voo int auto_increment, primary key

(id_flight))

(select v.year, v.month, v.dayofmonth, v.dayofweek,

v.deptime, v.crsdeptime, v.arrtime, v.crsarrtime,

v.flightnum, v.tailnum, v.actualelapsedtime,

v.crselapsedtime, v.airtime, v.arrdelay, v.depdelay,

v.origin, v.dest, v.distance, v.taxiin, v.taxiout,

v.cancelled, v.cancellation_code, v.diverted,

v.carrierdelay, v.weatherdelay, v.nasdelay, v.securitydelay,

v.lateaircraftdelay

From csv_1995 v

INNER JOIN airport a

ON v.origin = a.idairport

INNER JOIN airport b

ON v.dest = b.idairport

INNER JOIN airplane c

ON v.tailnum = c.tailnum )


54

3.3 Carregamento de dados no MongoDB

O carregamento dos dados no MongoDB pode ser efetuado de duas formas, ou por

documentos embutidos ou referenciados, cada um tem as suas vantagens e será sempre

privilegiado o melhor desempenho da base de dados.

Os dados foram exportados do MySQL em formato JSON para assim ambas as bases de

dados possuírem o mesmo número de registos.

3.3.1 Estrutura dos Documentos

Foram exportados do MySQL documentos JSON das quatro bases de dados criadas. Foram

então agrupados os dados em três JSON, contendo os dados do Airport, Airplane e Flight.

Posto isto, existem duas maneiras de os carregar para o MongoDB: ou por documentos

embutidos ou referenciados.

Para os referenciados bastava criar três coleções no MongoDB e carregar os respetivos JSON

ficando referenciados pelo id que contém cada documento. O problema é que esta

abordagem é mais indicada para modelos que possuíssem relacionamentos de muitos para

muitos, o que não acontece no modelo que foi criado no MySQL. De referir também que

haveria a necessidade da criação de duas ou mais consultas para retornar o que uma consulta

em Sql consegue realizar.

Sendo assim, foram preferidos os documentos embutidos, nestes com apenas uma consulta

consegue-se ir buscar o que é pretendido e no mesmo documento estarão contidos os dados

de um voo, nomeadamente o aeroporto de origem e destino, bem como o avião associado.

Irá existir uma certa redundância de dados mas um melhor desempenho nas consultas.

Embutir documentos pode-se tornar muito mais complicado do que referenciar, sendo que

na referenciação era apenas necessário criar as coleções e carregar os documentos JSON

através do mongoimport, no outro caso já foi necessário a criação de um programa em java

para embutir o aeroporto de origem e destino e o avião no voo correspondente. No anexo A

é possível consultar o código desenvolvido separado por extratos conforme o seu propósito.

No programa desenvolvido primeiro definiram-se as classes principais que estão presentes

no MongoDB, que fazem correspondência às coleções e cada atributo declarado é um campo

no MongoDB.

Cada classe tem declarado um método, nomeadamente o “toString” que permite retornar

uma string no formato JSON, isto para ser permitido visualizar se os dados estavam a ser

bem carregados. O código correspondente está no anexo A no Extrato de código 1.

55


De seguida, foi criada uma classe denominada mongoconnection cujo objetivo era criar uma

conexão válida com o servidor MongoDB e com a base de dados pretendida. O código

correspondente está no anexo A no Extrato de código 2.

Posteriormente foram criadas três classes cujo objetivo é aceder ao MongoDB e recolher os

dados de uma coleção. Através destes dados podemos converter registo a registo os dados

para o tipo de classe respetiva, (Airplane, Airport ou Flight), guardando cada objeto numa

lista. O código correspondente está no anexo A no Extrato de código 3.

Para converter cada registo das coleções recolhidas do MongoDB foi criada uma classe que

possui três métodos, que é responsável por fazer a conversão para cada um dos três tipos de

classes definidas, (Airplane, Airport e Flight). O código correspondente está no anexo A no

Extrato de código 4.

De seguida, criou-se uma classe denominada Flighfinal cujo objetivo era agregar os dados

recolhidos das coleções do MongoDB de modo a ser possível imprimir para o txt o JSON

embutido. O código correspondente está no anexo A no Extrato de código 5.

Por último, criou-se a classe principal que é responsável por executar esta aplicação.

Começou-se por declarar as variáveis do tipo airplanedao, airportdao e flightdao.

Posteriormente recolheram-se todos os elementos da coleção flight, pois é a esta a que se

pretende agrupar o airplane e os airports. Para tal, fez-se uma consulta à coleção flight sem

argumentos, de forma a obter todos os voos. Para cada elemento da lista foi feita uma

consulta à coleção airplane onde se pretendia obter o avião cujo tailnum fosse igual ao

tailnum presente no voo. O mesmo foi feito para o aeroporto de destino e de origem.

Obtendo estes, o sistema está preparado para criar o objeto do tipo flightfinal, guardando-o

numa lista. Percorrendo todos os voos recolhidos o sistema começa a escrever para um txt

previamente criado. O código correspondente está no anexo A no Extrato de código 6.

3.3.2 Carregamento da coleção

Para aceder ao MongoDB é necessário seguir um conjunto de passos. Primeiro temos de

abrir uma conexão à base de dados através da linha de comandos e de seguida noutro

terminal, executar o comando “mongo” na diretoria onde este está alojado. No anexo B está

explicada detalhadamente a instalação e a inicialização desta base de dados.

Depois, através do mongoimport é possível carregar facilmente os dados em JSON para uma

coleção específica.

Na figura seguinte está então um exemplo de um documento constituinte da base de dados

criada.


56

3.4 Carregamento dos dados no CouchDB

O carregamento nesta base de dados foi efetuado da mesma maneira que no MongoDB,

através de documentos embutidos. E os documentos têm a mesma estrutura que os

documentos inseridos no MongoDB. No anexo C está explicada detalhadamente a instalação

e a inicialização desta base de dados.

Primeiramente foi tentado o carregamento através do bulk_docs mas como os ficheiros a

carregar eram demasiado grandes foi necessário encontrar uma alternativa, alternativa essa

que foi um código em python. Neste código faz-se a conexão à base de dados e lê-se o JSON

linha a linha, inserindo-o na base de dados pretendida. O código utilizado está presente no

anexo D.

Na imagem seguinte é apresentado um exemplo de um documento carregado no couchDB.

Figura 23 - Exemplo de um documento criado no MongoDB

57


Figura 24 - Exemplo de um documento criado no CouchDB

De salientar a diferença para o documento no MongoDB, este contém um número de revisão

que em caso de alteração do Document o _id é mantido e é apenas alterado o id de revisão.

59

Benchmarking _____________________________________________________________________________

Capitulo 4 – Benchmarking

Neste capítulo, o objetivo é obter conclusões sobre qual tecnologia de base de dados é mais

indicada para determinada dimensão da base de dados, ou seja, a que tenha melhor

desempenho no que respeita a consultas. A análise será realizada através de consultas nas

várias bases de dados e de gráficos para efetuar comparações.

Para a realização deste benchmark foi utilizado um computador com as seguintes

características:

Processador: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40 GHz;

Memória RAM: 8 gigabytes;

Sistema Operativo: Windows 8.1 x64.

4.1 Consultas MySQL

As consultas foram pensadas e realizadas primeiro no MySQL. O objetivo foi desenvolver

três consultas que fossem aumentando de complexidade.

A primeira, que se pretendia que fosse a mais simples, foi “Selecionar o avião envolvido no

voo com maior atraso no tempo de chegada”. No código seguinte é então apresentada a

consulta 1.

Consulta 1:

select tailnum

from flight

where arrdelay = (Select max(arrdelay) from flight)

Como segunda consulta foi adicionada complexidade juntando algumas tabelas. Nesta

pretende-se “Listar os aviões que têm como fabricante a BOEING e que tenham voos

desviados”. No código seguinte é então apresentada a consulta 2.

Consulta 2:

SELECT distinct a.Tailnum

From airplane a

INNER JOIN manufacturer m

ON a.idManufacturer = m.idManufacturer

INNER JOIN flight v ON a.Tailnum = v.tailnum

Where m.name = 'BOEING' and diverted= “1”

Na terceira consulta o objetivo foi utilizar o maior caminho entre as tabelas, desde o modelo

de avião até ao aeroporto, incluindo também a ida ao aeroporto de origem e destino. Nesta

pretende-se saber “Qual o modelo de avião utilizado nas travessias entre os aeroportos San

Benchmarking _______________________________________________________________________________

60

Francisco International e Philadelphia Intl e que não tenha voos cancelados”

Consulta 3:

Select distinct model

From model as m

INNER JOIN airplane as a

ON M.id_model = a.id_model

INNER JOIN flight as f

ON a.tailnum = f.tailnum

INNER JOIN airport as b

ON f.origin = b.idAirport

INNER JOIN airport as c

ON f.dest = c.idAirport

Where b.airport = 'San Francisco International' and

c.airport = 'Philadelphia Intl’ and cancelled = “0”

4.2 Consultas MongoDB

Pelo facto de terem sido embutidos os documentos, apenas será necessária uma consulta.

Em relação à primeira consulta, ordena-se o arrdelay por ordem descendente e seleciona-se

o primeiro registo.

No seguinte código é possivel então visualizar a consulta efetuada.

db.teste.find({}, {

"tailnum.tailnum": 1}).sort({"arrdelay":-1}).limit(1)

Relativamente à segunda consulta, como os dados do manufacturer e do tailnum estão num

sub-documento e se pretende que não haja repetições dos aviões, é necessário efetuar a

consulta desta forma que é equivalente ao distinct em Sql.

db.runCommand({

"distinct": "teste",

"query": {

"tailnum.manufacturer": "BOEING",

"diverted": "1"

},

"key": "tailnum.tailnum"

});

Relativamente à última consulta também é necessário consultar sub-documentos e retornar

valores únicos, então o código foi realizado da seguinte forma.

db.runCommand({

"distinct": "teste",

"query": {

61

Benchmarking _____________________________________________________________________________

"origin.airport": "San Francisco International",

"dest.airport": "Philadelphia Intl",

“cancelled”: “0”

},

"key": "tailnum.model"

});

4.3 Consultas CouchDB

Para efetuar as consultas no CouchDB é necessária, em primeiro lugar, a criação de uma

view em javascript sobre aquilo que é pretendido consultar e, de seguida, através de um url

consultar a view pretendida.

Na primeira consulta foi criada uma view com os parâmetros tailnum e arrdelay que vão ser

retornados na consulta.

function(doc){

emit([doc.tailnum.tailnum, doc.arrdelay], 1);

}

De seguida, foi criada uma função reduce, isto para retornar o maior valor de arrdelay.

function(keys, values, rereduce) {

var max = 0,

ks = rereduce ? values : keys;

for (var i = 1, l = ks.length; i < l; ++i) {

if (ks[max][0][1] < ks[i][0][1]) max = i;

}

return ks[max];

}

Agora efetua-se uma consulta à view criada e é retornado o maior valor de arrdelay, bem

como o avião associado.

127.0.0.1:5984/tese1/_design/teste1/_view/tese16

O campo tese1 diz respeito à base de dados, o campo teste1 diz respeito ao nome do conjunto

das views e o campo tese 16 diz respeito à view que foi explicada anteriormente.

Na segunda consulta foi criada uma view com os parâmetros manufacturer = “BOEING” e

diverted = “1” que é o que se pretende consultar e como retorno o tailnum.

A view criada foi a seguinte:

function(doc) {

if(doc.tailnum.manufacturer == "BOEING" && doc.diverted ==

1) {

Benchmarking _______________________________________________________________________________

62

emit(doc.tailnum.tailnum, null);

}

}

Como se pretendia que não existissem tailnum repetidos, foi criada a função reduce para

permitir retornar valores únicos.

function(key, values) {

return null;

}

De seguida, fez-se uma querie à view para obter o resultado da consulta.

127.0.0.1:5984/tese1/_design/teste1/_view/tese14?group=true

O valor tese1 é o nome da base de dados, o nome teste1 é o nome do conjunto das views e

o nome tese14 é o nome da view apresentada anteriormente.

Em relação ao group=true, este separa o valor reduce para cada chave única no map, e todos

os valores que partilham a mesma chave são agrupados e reduzidos para um único valor,

eliminando assim os repetidos.

Na terceira consulta a view foi criada com os aeroportos de origem = “San Francisco

International” e destino = “Philadelphia Intl” e com o cancelled = “0” e como retorno o

modelo de avião.

function(doc) {

if(doc.origin.airport == "San Francisco International" &&

doc.dest.airport == "Philadelphia Intl" && doc.cancelled ==

"0") {

emit(doc.tailnum.model, null);

}

}

Como também era pretendido que não houvesse repetição de modelos a mesma função

reduce foi utilizada.

function(key, values) {

return null;

}

A querie feita à view foi a seguinte.

127.0.0.1:5984/tese1/_design/teste1/_view/tese15?group=true

63

Benchmarking _____________________________________________________________________________

4.4 Criação de Índices

Com vista a aumentar o desempenho nas consultas foram criados índices nos campos

utilizados por estas. Relativamente ao MySQL foram criados índices nos campos utilizados

nas três consultas, nomeadamente, cancelled, arrdelay, airport, diverted, model, tailnum e

manufacturer. Na seguinte figura está representado um exemplo da criação de um índice no

MySQL relativamente ao campo airport.

Figura 25 - Criação de um índice no MySQL

Já em relação ao CouchDB, as views criadas já fazem o papel de um índice.

Relativamente ao MongoDB os índices utilizados foram na primeira consulta, simples, e nas

consultas dois e três compound indexes, em que todos os campos são indexados no mesmo

índice.

Para a primeira consulta, foi criado um índice sobre o arrdelay por ordem descendente visto

que na consulta é pretendido o valor maior.

db.teste.createIndex({"arrdelay": -1})

Na segunda consulta foi criado um compound index em todos os campos utilizados nas

consultas.

db.teste.createIndex({"tailnum.tailnum": 1, "tailnum.manufacturer": 1, "diverted":

1})

Na terceira consulta foi criado também um compound index em todos os campos.

db.teste.createIndex({"origin.airport": 1, "dest.airport": 1, "tailnum.model":1,

"cancelled": 1})

Benchmarking _______________________________________________________________________________

64

4.5 Resultados

Agora será analisado o desempenho das duas bases de NoSql (MongoDB e CouchDB) e

Relacional (MySQL). Para tal foram usados vários tamanhos de bases de dados. A BD1

possui um milhão e meio de registos, a BD2 possui quarto milhões e setecentos mil registos,

a BD3 possui cerca de quinze milhões de registos e, por fim, a BD4 possui cerca de quarenta

e um milhões de registos. Posteriormente, por cada consulta será avaliado o desempenho

das três bases de dados em estudo (MongoDB, CouchDB e MySQL).

4.5.1 Consulta 1

No seguinte gráfico estão representados os resultados de desempenho nas três bases de

dados relativamente à consulta 1.

Figura 26 - Comparação de desempenhos na Consulta 1

4.5.2 Consulta 2

No seguinte gráfico estão representados os resultados de desempenho das três bases de


65

Benchmarking _____________________________________________________________________________


4.5.3 Consulta 3

No seguinte gráfico estão representados os resultados de desempenho nas três bases de



4.6 Discussão de Resultados

Relativamente à consulta um, não existem diferenças substanciais entre as três bases de

dados em estudo. Com o aumento da quantidade de registos nota-se um ligeiro aumento de

Benchmarking _______________________________________________________________________________

66

tempo, mas mesmo assim os tempos são bastantes semelhantes entre os vários tamanhos de

base de dados, o que revela um bom desempenho com funções de agregação. De referir

apenas que o CouchDB na base de dados maior demorou quase o dobro do tempo na

consulta comparado com as restantes, mas ainda assim o tempo é bastante reduzido.

Relativamente à consulta dois, os resultados de tempos são ótimos mas o facto de recorrer

a mais de uma tabela começa a afetar o desempenho no MySQL, aumentando o tempo de

consulta conforme o tamanho de dados aumenta. Começa-se a notar também a diferença

para o MongoDB e o CouchDB principalmente na BD4 que aponta para um melhor

desempenho das bases de dados NoSql em estudo, conforme o volume de dados aumenta.

Contudo, os resultados quase que são apresentados instantaneamente nos quatro tamanhos

de bases de dados, o que revela um bom desempenho. Entre o MongoDB e o CouchDB,

nestas consultas, não existem muitas diferenças a nível de desempenho sendo até bastante

semelhantes. A única diferença significativa entre estes foi o facto de no CouchDB ser

necessária a criação de views antes da consulta, sendo este um processo moroso uma vez

que as bases de dados possuíam milhões de registos, mas que se refletiu num bom

desempenho após a criação da view. Relativamente ao MySQL, a diferença chega a ser

notória nas tabelas do gráfico da consulta dois comparativamente às duas bases de dados

NoSQL, notando-se uma perda de desempenho ao nível que o volume de dados aumenta,

enquanto que no MongoDB e no CouchDB os tempos permanecem semelhantes.

De referir que na terceira consulta a mais complexa notou-se uma diferença, pois o facto de

recorrer a bastantes tabelas resultou em tempos muito distintos para a realização da consulta,

principalmente a partir da BD3, a qual possui cerca de quinze milhões de registos.

Com a análise efetuada é possível concluir que a utilização de documentos embutidos no

MongoDB e no CouchDB, onde todos os dados se encontram no mesmo sítio, ao contrário

do MySQL que possui os dados em várias tabelas, leva a um aumento de desempenho.

Também é possível concluir que quanto maior a quantidade de dados, maior é a diferença

de tempos entre o MongoDB e o CouchDB em relação ao MySQL, o que revela que as bases

de dados NoSql são uma boa aposta no que diz respeito a enormes volumes de dados e que

o MySQL para responder ao Big data em que o volume de dados é gigantesco,

provavelmente perderia desempenho comparado com as bases de dados NoSql em estudo.

Relativamente às duas bases de dados NoSql, é de salientar que no MongoDB apenas se

criaram índices que em comparação às views criadas no CouchDB foi um processo mais

rápido, o que revela uma superioridade do MongoDB em relação ao CouchDB.

67

Testes de Carga _____________________________________________________________________________

Capítulo 5 – Testes de Carga

Neste capítulo será comparado o desempenho entre o MySQL e o MongoDB através das

consultas um e três mas com utilizadores a acederem concorrentemente à base de dados,

tendo por base a ferramenta Jmeter. O CouchDB ficou fora desta comparação visto que o

MongoDB possui mais notoriedade e o desempenho nas consultas anteriores foi equivalente,

pelo que seria mais importante analisá-lo neste aspeto. No anexo E está presente o modo

como foram conectadas as bases de dados ao Jmeter e quais os componentes utilizados.

5.1 Base de Dados BD1

Na figura seguinte estão representados os valores de tempos obtidos na consulta 1 com

utilizadores a aceder concorrentemente à base de dados, nomeadamente, dez, vinte e

cinquenta utilizadores.

Figura 29 - Resultado do Teste de carga utilizando a consulta 1




Testes de Carga _______________________________________________________________________________

68


5.2 Base de dados BD2








69

Testes de Carga _____________________________________________________________________________










Testes de Carga _______________________________________________________________________________

70










71

Testes de Carga _____________________________________________________________________________


5.5 Discussão de resultados

Relativamente à consulta um não existem muitas diferenças entre os vários tamanhos de

bases de dados, apenas de salientar que o MongoDB na BD4, que é a base de dados maior,

obteve melhor desempenho que nas restantes que possuem menos dados, apesar da

diferença ser mínima sugere um melhor desempenho com maiores quantidades de dados.

Em comparação com o MySQL notam-se diferenças substanciais nas barras dos gráficos

mas que em relação ao tempo de execução, a diferença entre estas não é muito relevante,

sendo apenas diferenças de décimas.

No que diz respeito à consulta três, que era a consulta mais “pesada”, o MySQL tem um

desempenho bastante inferior ao MongoDB, chegando mesmo a diferenças de dezenas de

segundos. O facto desta consulta ir a múltiplas tabelas prejudica bastante o desempenho do

MySQL em acessos concorrentes à base de dados. A diferença mais substancial é na BD4,

na qual o MongoDB tem um ótimo desempenho com quantidades elevadas de dados e com

o máximo de utilizadores em teste, obtendo mesmo uma diferença de cerca de duzentos

segundos de diferença relativamente ao MySQL. Onde o MySQL se aproximou mais do

MongoDB foi na BD2 e BD3, mas ainda assim com diferenças de alguns segundos.

Concluindo, com operações de agregação e com consultas que não necessitem de recorrer a

muitas tabelas o MySQL revela um bom desempenho, que apesar de ter sido o melhor

desempenho as diferenças para o MongoDB não foram muito elevadas o que revela o

MongoDB como uma boa alternativa. Já na consulta três o MySQL, com o aumento do

volume de dados, vai perdendo cada vez mais desempenho e distancia-se bastante do

Testes de Carga _______________________________________________________________________________

72

MongoDB. Este por sua vez com a BD4, que é a maior base de dados, possui um ótimo

desempenho, mesmo com o máximo de utilizadores testados a acederem concorrentemente

à base de dados, o que o torna bastante atrativo para situações em que com a tecnologia

relacional exista a necessidade de consultar um número elevado de tabelas.

73

Conclusões _____________________________________________________________________________

Capítulo 6 – Conclusões

Neste capítulo são apresentadas as conclusões do trabalho efetuado. Este está dividido em

três secções, nomeadamente, as contribuições do trabalho para o setor em estudo, as

limitações que foram sentidas e o trabalho futuro a ser realizado.

6.1 Contribuições

As bases de dados NoSql estão cada vez mais presentes nas empresas, sendo vistas como

uma alternativa viável para armazenamento de grandes volumes de dados quando a

disponibilidade e a tolerância ao particionamento são as características mais importantes.

Os objetivos propostos para esta dissertação foram atingidos, tendo-se obtido uma

comparação entre as tecnologias relacional e não relacional, bem como entre duas Document

Databases (MongoDB e CouchDB).

É evidenciado que a tecnologia não relacional, nomeadamente as Document Databases,

possui vantagens significativas nas consultas que não utilizam funções de agregação bem

como o facto de serem livres de esquemas, o que as torna numa potente alternativa a ser

utilizada pelas empresas.

Relativamente aos testes de carga, o MongoDB obteve melhor desempenho

comparativamente ao MySQL na consulta que necessitava de percorrer mais tabelas, sendo

que assim, conforme a complexidade dos dados aumenta e mais tabelas, por ventura,

necessitarem de ser criadas e posteriormente consultadas, o desempenho do MySQL irá

agravar-se, contrariamente ao MongoDB, onde o facto de não necessitar de esquemas se

torna bastante vantajoso comparativamente ao MySQL.

A situação de migração da tecnologia relacional para a não relacional deve ser devidamente

analisada, pois quanto maior o volume de dados maiores são os custos de migração e, sendo

assim, as vantagens devem compensar o investimento.

Importa ainda referir que um excerto da presente dissertação foi aprovado em artigo e

apresentado na CAPSI 2015 no ISCTE, contribuindo desta forma para a evidenciação das

diferenças entre as Document Databases e o MySQL.

6.2 Dificuldades

Em todos os trabalhos existem limitações e sendo assim este não foi exceção. A primeira

limitação foi verificada em termos de carregamento de dados, no qual o dataset possuía

bastantes dados inconsistentes pelo que teve de ser devidamente tratado. Era pretendido um

dataset com grande volume de dados e com vários tipos de dados mas foi verificado que era

Conclusões _______________________________________________________________________________

74

algo bastante difícil de ser encontrado.

A segunda limitação identificada foi o facto de se lidar com milhões de registos, o que

requeria um servidor potente, pelo que o carregamento foi um processo bastante moroso.

A terceira e última limitação identificada foi que para embutir documentos, o facto de estes

serem complexos e com bastantes campos, a sua criação através do programa em java foi

bastante lenta, sendo que foram gerados documentos de seiscentos mil em seiscentos mil,

para este não crashar e parar.

6.3 Trabalho futuro

No desenvolvimento desta dissertação vários caminhos podiam ter sido tomados, os quais

identificam possibilidades que ficaram por investigar. Estas oportunidades complementam

o trabalho realizado pelo que devem ser ponderadas.

No que diz respeito à escalabilidade, pode ser analisado o desempenho das bases de dados

relacionais e não relacionais com os servidores distribuídos por várias máquinas e assim

efetuar comparações e verificar se são compensatórias as vantagens das bases de dados

NoSql neste ponto. Nessa comparação podem também ser incluídos testes de carga com

vários utilizadores a aceder simultaneamente à base de dados, quer para consultar ou inserir

dados, e verificar como esta se comporta. Também se poderia incluir a análise de

desempenho relativamente a updates com os testes de carga referidos anteriormente.

75

Referências Bibliográficas _____________________________________________________________________________

Referências Bibliográficas

10gen. (2011). MongoDB. Retrieved from http://www.MongoDB.org/

Abadi, D. J., & Madden, S. (2008). Query Execution in Column-Oriented Database

Systems.

Massachusetts Institute of Technology.

Abramova, V., Bernardino, J., & Pedro, F. (2014). Experimental Evaluation of NoSql

Databases.

International Journal of Database Management Systems (IJDMS), 6(3), 1–16.

Alexandre, J., & Cavique, L. (2013). NoSql no suporte à análise de grande volume de dados.

Revista de Ciencias de Computação, 8, 37 – 48. Retrieved from

http://repositorioaberto.uab.pt/handle/10400.2/3091

Almeida, R. C. De, & Brito, P. F. De. (2012). Utilização da Classe de Banco de Dados

NOSQL como Solução para Manipulação de Diversas Estruturas de Dados. Palmas.

Anderson, J. C., Lehnardt, J., & Slater, N. (2010). CouchDB: The Definitive Guide. (O. M.

Inc., Ed.).

Apache CouchDB. (2011). Retrieved from http://CouchDB.apache.org/

Atzeni, P., Bugiotti, F., & Rossi, L. (2013). Uniform access to NoSql systems. Information

Systems, 43, 117–133. doi:10.1016/j.is.2013.05.002

Baltzan, P., & Phillips, A. (2012). Business driven information systems (3a edição.). Basso,

C., & Padua, R. de. (2014). O Uso de Big Data nas Universidades. Seminário de Iniciação

Científica, 94. Retrieved from

http://editora.unoesc.edu.br/index.php/siepe/article/view/5567

Bell, C., Kindahl, M., & Thalmann, L. (2010). MySQL High Availability. (A. Oram, Ed.)

(1o edition.). O’Reilly Media, Inc.

Bock, D. B., & Schrage, J. F. (2002). Denormalization guidelines for base and transaction

tables.

ACM SIGCSE Bulletin, 34, 129. doi:10.1145/820127.820184

Bonnet, L., Laurent, A., Sala, M., Laurent, B., & Sicard, N. (2011). Reduce, you say: What

NoSql can do for data aggregation and BI in large repositories. Proceedings - International

Workshop on Database and Expert Systems Applications, DEXA, 483–488.

doi:10.1109/DEXA.2011.71

Brewer, E. (2000). Towards Robust Distributed Systems. In Proceedings of the nineteenth

annual ACM symposium on Principles of distributed computing (Vol. 19, pp. 1–12).

doi:10.1145/343477.343502

Cardoso, R. (2012). Bases de Dados NoSql. Instituto Superior de Engenharia do Porto.

Referências Bibliográficas _______________________________________________________________________________

76

Carniel, A. C., Sá, A. D. A., Henrique, V., Brisighello, P., Ribeiro, M. X., Bueno, R., Ciferri,

R. R. (2012). Análise Experimental de Bases de Dados Relacionais e NoSql no

Processamento de Consultas sobre Data Warehouse. Brazilian Symposium on Databases -

Short Paper, d, 113–120. Retrieved from

http://data.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_shp_15.pdf

Castro, J., & Batista, E. (2013). Comparação entre Banco de Dados Relacionais e Não-

Relacionais – MySQL x NoSql. Revista Network Technologies Faculdades Network –

Revista Da Faculdade de Sistema de Informação, Ano 7, No, 111.

Cattell, R. (2011). Scalable SQL and NoSql data stores. ACM SIGMOD Record, 39(4), 12.

doi:10.1145/1978915.1978919

Clarck, B. (2009). NoSql: If Only It Was That Easy. Retrieved February 11, 2015, from

https://markedaspertinent.wordpress.com/2009/08/04/NoSql-if-only-it-was-that-easy/

Coronel, C., Morris, S., & Rob, P. (2013). Database Systems: Design, Implementation and

Management. Management (p. 692).

D., M., & Kelly, A. (2013). Making Sense of NoSql: A guide for managers and the rest of

us.

Date, C. J. (2004). Introdução a Sistemas de Bancos de Dados. (E. Campus, Ed.) (8a

edição.).

Dean, J., & Ghemawat, S. (2004). MapReduce: Simplied Data Processing on Large

Clusters.

Proceedings of 6th Symposium on Operating Systems Design and Implementation, 137–

149. doi:10.1145/1327452.1327492

DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A.,

Vogels, W. (2007). Dynamo : Amazon’s Highly Available Key-value Store. ACM SIGOPS

Operating Systems Review, 41, 205–220. doi:10.1145/1323293.1294281

Diana, M. De, & Gerosa, M. A. (2010). NoSql na Web 2.0: Um estudo comparativo de

bancos Não-Relacionais para Armazenamento de Dados na Web 2.0. WTDBD 2010-IX

Workshop de Teses E Dissertações em Bancos de Dados. Retrieved from

http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf

Dimitrov, M. (2010). NoSql Databases. Ontotext. Retrieved from

http://pt.slideshare.net/marin_dimitrov/NoSql-databases-3584443

Ferreira, L. (2012). Bridging the gap between SQL and NoSql. Universidade do Minho.

Forbes, D. (2010). Getting Real about NoSql and the SQL-Isn’t-Scalable Lie. Retrieved from

https://dennisforbes.ca/index.php/2010/03/02/getting-real-about-NoSql-and-the-Sql-isnt-

scalable-lie/

Frozza, A. A., Schuch, E. M., Ohana, G., & Catarina, B. (2011). POSTGRESQL X

MONGODB: Comparação dos Recursos para Manipulação de Dados Geográficos.

77


Gilbert, S., & Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent,

available, partition-tolerant web services. ACM SIGACT News, 33, 51.

doi:10.1145/564585.564601

Grolinger, K., Higashino, W. a, Tiwari, A., & Capretz, M. A. (2013). Data management in

cloud environments: NoSql and NewSQL data stores. Journal of Cloud Computing:

Advances, Systems and Applications, 2, 22. doi:10.1186/2192-113X-2-22

Guimarães, T., Nakai, A., & Vieira, L. (2013). Banco de dados NoSql para integração de

bases de dados de gases de efeito estufa. Mostra de Estagiários e Bolsistas da Embrapa

Informática Agropecuária, 9., 2013, Campinas. Brasília, DF: Embrapa, 2013. Retrieved

from http://www.alice.cnptia.embrapa.br/bitstream/doc/981973/1/NoSql.pdf

Han, J., Haihong, E., Le, G., & Du, J. (2011). Survey on NoSql database. Proceedings - 2011

6th International Conference on Pervasive Computing and Applications, ICPCA 2011, 363–

366. doi:10.1109/ICPCA.2011.6106531

Hecht, R., & Jablonski, S. (2011). NoSql evaluation: A use case oriented survey. 2011

International Conference on Cloud and Service Computing, 336–341.

doi:10.1109/CSC.2011.6138544

Imielinski, T., & Lipski, W. (1982). A systematic approach to relational database. In ACM

SIGMOD international conference on Management of data (pp. 8–14). Retrieved from

http://dl.acm.org/citation.cfm?id=582356&dl=ACM&coll=DL&CFID=478886163&CFT

OKE N=69157666

Indrawan-Santiago, M. (2012). Database research: Are we at a crossroad? Reflection on

NoSql. Proceedings of the 2012 15th International Conference on Network-Based

Information Systems, NBIS 2012, 45–51. doi:10.1109/NBiS.2012.95

Jacobs, A. (2009). The Pathologies of Big data. ACM Queue, 7(6). Retrieved from

http://queue.acm.org/detail.cfm?id=1563874

James Manyika, Michael Chui, Brad Brown, Jacques Bughin, Richard Dobbs, Charles

Roxburgh, A. H. B. (2011). Big data: The next frontier for innovation, competition, and

productivity. McKinsey Global Institute, (June), 156. doi:10.1080/01443610903114527

Leavitt, N. (2010). Will NoSql Databases Live Up to Their Promise? Computer, 43(2), 12–

14. doi:10.1109/MC.2010.58

Lee, K. K. Y., Tang, W. C., & Choi, K. S. (2013). Alternatives to relational database:

Comparison of NoSql and XML approaches for clinical data storage. Computer Methods

and Programs in Biomedicine, 110(1), 99–109. doi:10.1016/j.cmpb.2012.10.018

Liu, Z., He, B., Hsiao, H., & Chen, Y. (2011). Efficient and scalable data evolution with

column oriented databases. … Conference on Extending Database, 105 – 116.

doi:10.1145/1951365.1951380

Lóscio, B. F., Oliveira, H. R. De, & Pontes, J. C. D. S. (2011). NoSql no desenvolvimento

de aplicações Web colaborativas, 1 – 17. Retrieved from


78

http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSql.pdf

Mattar, F. N. (1994). Pesquisa de Marketing.

MongoDB. (2011a). BSON. Retrieved February 11, 2015, from

http://blog.MongoDB.org/post/114440717/bson

MongoDB. (2011b). Data Models. Retrieved February 11, 2015, from

http://docs.MongoDB.org/manual/data-modeling/

MongoDB. (2011c). ObjectId. Retrieved February 11, 2015, from

http://docs.MongoDB.org/manual/reference/object-id/

MongoDB. (2011d). Replication. Retrieved February 11, 2015, from

http://docs.MongoDB.org/manual/replication/

MongoDB. (2011e). SQL to MongoDB Mapping Chart. Retrieved February 11, 2015, from

http://docs.MongoDB.org/manual/reference/Sql-comparison/

Moniruzzaman, A., & Hossain, S. (2013). NoSql database: New era of databases for Big

data analytics-classification, characteristics and comparison. arXiv Preprint

arXiv:1307.0191, 6(4), 1–14. Retrieved from http://arxiv.org/abs/1307.0191

Parikh, J. (2013). Facebook Newsroom : A new Datacenter for Iowa. Retrieved February

11, 2015, from http://newsroom.fb.com/

Piovesan, A., & Temporini, E. R. (1995). Pesquisa exploratória: procedimento

metodológico para o estudo de fatores humanos no campo da saúde pública. Revista de

Saúde Pública, 29 (011), 318 – 325. doi:10.1590/S0034-89101995000400010

Pozzani, G. (2013). Introduction to NOSQL. NoSql Seminar. NoSql Seminar. Retrieved

from http://www.cs.tut.fi/~tjm/seminars/NoSql2012/NoSql-Intro.pdf

Pritchett, D. (2008). Base: an Acid Alternative. Queue, 6(June 2008), 48–55.

doi:10.1145/1394127.1394128

Purcell, B. (2013). The emergence of “Big data” technology and analytics. Journal of

Technology Research, 1 – 7.

Queiroz, G. R. De, Miguel, A., Monteiro, V., & Câmara, G. (2013). Bancos de Dados

Geográficos e Sistemas NoSql : Onde Estamos e para Onde vamos, Geographic Databases

and NoSql : Accomplishments and Future Directions. Revista Brasileira de Cartografia,

479–492.

Redmond, E., & Wilson, J. R. (2012). Seven Databases in Seven Weeks. North (p. 347).

Révillion, A. S. P. (2001). A Utilização de Pesquisas Exploratórias na Área de Marketing.

XXV

Encontro Da ANPAD, 1 – 15.

Richardson. (1989). Pesquisa social: métodos e técnicas. São Paulo. Rodrigues, W. (2007).

79


Metodologia científica. doi:10.1038/140260c0

Rybiński, H. (1987). On First-Order-Logic Databases. ACM Transactions on Database

Systems.

Retrieved from http://dl.acm.org/citation.cfm?id=27630 Sadalage, P. J., & Fowler, M.

(2012). NoSql Distilled (p. 192).

Sampieri, Collado, & Lucio. (1991). Metodología de la investigación. Mexico.

Schram, A., & Anderson, K. M. (2012). MySQL to NoSql. Proceedings of the 3rd Annual

Conference on Systems, Programming, and Applications: Software for Humanity -

SPLASH ’12, 191. doi:10.1145/2384716.2384773

Scofield, B. (2009). NoSql Misconceptions. Retrieved from http://viget.com/extend/NoSql-

misconceptions

Shawrtz, B., Zaitsev, P., & Tkachenco, V. (2012). High Performance MySQL. (A. Oram,

Ed.) (3ord Editi.). O’Reilly Media, Inc.

Silberschartz, A., Korth, H., & Sudarshan, S. (1999). Sistemas de Banco de Dados.

Silva, C. A. R. F. O. Da. (2011). Data modeling with NoSql : how, when and why. Faculdade

de Engenharia da Universidade do Porto. Retrieved from http://hdl.handle.net/10216/61586

Sousa, P. (2010). O teorema CAP. Retrieved February 26, 2015, from

https://unrealps.wordpress.com/2010/12/28/o-teorema-cap/

Stonebraker, M. (2009). The “NoSql” Discussion has Nothing to Do With SQL. Retrieved

from http://cacm.acm.org/blogs/blog-cacm/50678-the-NoSql-discussion-has-nothing-to-

do-with- Sql/fulltext

Stonebraker, M. (2010). SQL databases v. NoSql databases. Communications of the ACM,

53(4), 10. doi:10.1145/1721654.1721659

Stonebraker, M. (2011). Stonebraker on NoSql and enterprises. Communications of the

ACM, 54(8), 10. doi:10.1145/1978542.1978546

Strauch, C. (2010). NoSql Databases (p. 120). Stuttgart. Tiwari, S. (2011). Professional

NoSql.

Tauro, J. M., Aravindh, S., Shreeharsha, A. B. (2012). Comparative Study of the New

Generation, Agile, Scalable, High Performance NOSQL Databases. International Journal of

Computer Applications, 48(20), 1–4. doi:10.5120/7461-0336

Toth, R. (2012). Abordagem NoSql – uma real alternativa. Dcomp.sor.ufscar.br, 1–6.

Retrieved from http://www.dcomp.sor.ufscar.br/verdi/topicosCloud/NoSql_artigo.pdf

Toth, R. M. (2011). Abordagem NoSql- Uma real Alternativa (pp. 1 – 6). Sorocaba.

Retrieved from http://www2.sor.ufscar.br/verdi/topicosCloud/NoSql_artigo.pdf

Vieira, M., Figueiredo, J., Liberatti, G., & Viebrantz, A. (2012). Bancos de Dados NoSql:


80

conceitos, ferramentas, linguagens e estudos de casos no contexto de Big data. Simpósio

Brasileiro DE Banco de Dados, (1), 1 – 30. Retrieved from

http://data.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_min_01.pdf

Vogels, W. (2009). Eventually Consistent. Communications of the Acm, 52, 14.

doi:10.1145/1466443.1466448

Warden, P. (2011). Big data Glossary. (M. Loukides, Ed.) (p. 56). O’Reilly Media, Inc.

White, T. (2012). Hadoop: The definitive guide. Online (Vol. 54, p. 258). doi:citeulike-

article- id:4882841

81

Anexos _____________________________________________________________________________

Anexos

83

Anexos _____________________________________________________________________________

Anexo A

Extrato de Código 1 package dissertacao.Classes;

import java.io.Serializable;

import java.util.ArrayList;

import java.util.List;

/**

*

* @author Gon

*/

public class Airplane {

public String tailnum;

public String issue_data;

public String year;

public String status;

public String airline;

public String engine_type;

public String type;

public String aircraft_type;

public String model;

public String manufacturer;

public Object id;

// get & set

@Override

public String toString()

{

String s = "{" +

"'tailnum':'" + tailnum + "'" +

", 'issue_data':'" + issue_data + "'" +

", 'year_airplane':" + year +

", 'status':'" + status + "'" +

", 'airline':'" + airline + "'" +

", 'engine_type':'" + engine_type + "'" +

", 'type':'" + type + "'" +

", 'aircraft_type':'" + aircraft_type + "'"

+

", 'model':'" + model + "'" +

", 'manufacturer':'" + manufacturer + "'" +

"}";

return s;

}

package dissertacao.Classes;

/**

Anexos _______________________________________________________________________________

84

*

* @author Gon

*/

public class Airport {

public Object idAirport;

public String airport;

public Object city;

public Object state;

public Object country;

public Object latitude;

public Object longitude;

public Object id;

// get & set

@Override


{

String s = "{" +

"'idAirport':'" + idAirport + "'" +

", 'airport':'" + airport + "'" +

", 'city':'" + city + "'" +

", 'state':'" + state + "'" +

", 'country':'" + country + "'" +

", 'latitude':'" + latitude + "'" +

", 'longitude':'" + longitude + "'" +

"}";

return s;

}

}


/**

*

* @author Gon

*/

public class Flight {

public Object id_flight;

public Object month;

public Object year;

public Object dayofmonth;

public Object dayofweek;

public Object deptime;

public Object crsdeptime;

public Object arrtime;

public Object crsarrtime;

85

Anexos _____________________________________________________________________________

public Object flightnum;

public Object id;

public Object tailnum;

public Object actualelapsedtime;

public Object crselapsedtime;

public Object airtime;

public Object arrdelay;

public Object depdeplay;

public Object origin;

public Object dest;

public Object distance;

public Object taxiin;

public Object taxiout;

public Object cancelled;

public Object diverted;

public Airplane airplane;

public Airport airport;

// get & set

@Override


{

return "Flight{" +

" _id='" + id + "'" +

", id_flight='" + id_flight.toString() + "'"

+

", month='" + month.toString() + "'" +

", year='" + year + "'" +

", dayofmonth='" + dayofmonth + "'" +

", dayofweek='" + dayofweek + "'" +

", deptime='" + deptime + "'" +

", crsdeptime='" + crsdeptime + "'" +

", arrtime='" + arrtime + "'" +

", crsarrtime='" + crsarrtime + "'" +

", arrdelay='" + arrdelay + "'" +

", depdeplay='" + depdeplay + "'" +

", airtime='" + airtime + "'" +

", actualelapsedtime='" + actualelapsedtime

+ "'" +

", crselapsedtime='" + crselapsedtime + "'"

+

", flightnum='" + flightnum + "'" +

", tailnum='" + tailnum + "'" +

", origin='" + origin + "'" +

", dest='" + dest + "'" +

", distance='" + distance + "'" +

", taxiin='" + taxiin + "'" +

", taxiout='" + taxiout.toString() + "'" +

", cancelled='" + cancelled + "'" +

", diverted='" + diverted + "'" +

", airport=" + airport.toString() +

", airplane=" + airplane.toString() +

Anexos _______________________________________________________________________________

86

'}';

}

}

Extrato de código 2

package dissertacao;

import com.MongoDB.DB;

import com.MongoDB.MongoClient;

import java.net.UnknownHostException;

/**

*

* @author Gon

*/

class MongoConnection {

private static final String HOST = "127.0.0.1";

private static final int PORT = 27017;

private static final String db_name = "tese4";

private static MongoConnection uniqInstance;

private static int mongoInstance = 1;

private MongoClient mongo;

private DB db;

private MongoConnection(){

// contrutor private para ser usado pela variavel

criada acima

}

public static synchronized MongoConnection getInstance()

{

if(uniqInstance == null)

{

uniqInstance = new MongoConnection();

}

return uniqInstance;

}

// garante um unico objeto mongo

public DB getDB()

{

if(mongo == null)

{

try{

mongo = new MongoClient(HOST, PORT);

db = mongo.getDB(db_name);

System.out.println("Mongo: " +

87

Anexos _____________________________________________________________________________

mongoInstance++);

}

catch(UnknownError e)

{

e.printStackTrace();

}

}

return db;

}

}



import com.MongoDB.DBCollection;

import com.MongoDB.DBCursor;

import com.MongoDB.DBObject;

import dissertacao.Classes.AirplaneConverter;

import dissertacao.Classes.Flight;



/**

*

* @author Gon

*/

public class FlightDao {

private DBCollection db;

public FlightDao()

{

this.db =

MongoConnection.getInstance().getDB().getCollection("Flight"

);

System.out.println(db);

}

public List<Flight> findFlight(DBObject dbo) {

ArrayList<Flight> avioes = new ArrayList<Flight>();

DBCursor cursor = db.find(dbo);

long i = 0;

while (cursor.hasNext()){

if(i > 40800000 && i < 41400001)

{

avioes.add(AirplaneConverter.converterParaFlight(cursor.next

()));

}

else if(i > 41400001)

Anexos _______________________________________________________________________________

88

{

System.out.println("brekou");

break;

}

else

{

cursor.next();

}

i += 1;

}

return avioes;

}

}



import com.MongoDB.connection.Connection;



import com.MongoDB.Mongo;

import dissertacao.Classes.Airplane;


import java.io.Serializable;



/**

*

* @author Gon

*/

public class AirplaneDao implements IAirplaneDao<Airplane>{


public AirplaneDao()

{

this.db =

MongoConnection.getInstance().getDB().getCollection("Airplan

e");


}

public List<Airplane> findAirplanes(DBObject dbo) {

ArrayList<Airplane> avioes = new

ArrayList<Airplane>();



89

Anexos _____________________________________________________________________________

avioes.add(AirplaneConverter.converterParaAirplane(cursor.ne

xt()));

}

return avioes;

}

}







import dissertacao.Classes.Airport;



/**

*

* @author Gon

*/

public class AirportDao {


public AirportDao()

{

this.db =

MongoConnection.getInstance().getDB().getCollection("Airport

");


}

public List<Airport> findAirport(DBObject dbo) {

ArrayList<Airport> avioes = new

ArrayList<Airport>();



avioes.add(AirplaneConverter.converterParaAirport(cursor.nex

t()));

}

return avioes;

}

}

Anexos _______________________________________________________________________________

90




/**

*

* @author Gon

*/

public class AirplaneConverter {

public static Airplane converterParaAirplane(DBObject

dbo)

{

Airplane aviao = new Airplane();

aviao.id = dbo.get("_id");

aviao.year = (String) dbo.get("year");

aviao.year = aviao.year.replace("\r", "");

aviao.status = (String) dbo.get("status");

aviao.aircraft_type = (String)

dbo.get("aircraft_type");

aviao.airline = (String) dbo.get("airline");

aviao.engine_type = (String)dbo.get("engine_type");

aviao.issue_data = (String)dbo.get("issue_data");

aviao.manufacturer =

(String)dbo.get("manufacturer");

aviao.model = (String)dbo.get("model");

aviao.tailnum = (String)dbo.get("tailnum");

aviao.type =(String)dbo.get("type");

return aviao;

}

public static Airport converterParaAirport(DBObject dbo)

{

Airport aviao = new Airport();


aviao.idAirport = dbo.get("idairport");

String x = "" + dbo.get("airport");

aviao.airport = x.replace("'", "");

aviao.city = dbo.get("city");

aviao.country = dbo.get("country");

aviao.latitude = dbo.get("latitude");

aviao.longitude = dbo.get("longitude");

aviao.state = dbo.get("state");

return aviao;

}

public static Flight converterParaFlight(DBObject dbo)

{

Flight aviao = new Flight();


aviao.year = dbo.get("year");

91

Anexos _____________________________________________________________________________

aviao.actualelapsedtime =

dbo.get("actualelapsedtime");

aviao.airtime = dbo.get("airtime");

aviao.arrdelay = dbo.get("arrdelay");

aviao.cancelled = (String)dbo.get("cancelled");

aviao.arrtime = dbo.get("arrtime");

aviao.crsarrtime = dbo.get("crsarrtime");

aviao.crsdeptime = dbo.get("crsdeptime");

aviao.crselapsedtime =dbo.get("crselapsedtime");

aviao.dayofmonth =dbo.get("dayofmonth");

aviao.dayofweek =dbo.get("dayofweek");

aviao.depdeplay =dbo.get("depdelay");

aviao.deptime =dbo.get("deptime");

aviao.dest =dbo.get("dest");

aviao.origin =dbo.get("origin");

aviao.taxiin =dbo.get("taxiin");

aviao.taxiout =dbo.get("taxiout");

aviao.distance =dbo.get("distance");

aviao.diverted =dbo.get("diverted");

aviao.flightnum =dbo.get("flightnum");

aviao.tailnum =dbo.get("tailnum");

aviao.id_flight = dbo.get("id_flight");

aviao.month = dbo.get("month");

return aviao;

}

}




import dissertacao.Classes.Airport;

/**

*

* @author Gon

*/

class FlightFinal {

public Object id_flight;

public Object month;

public Object year;

public Object dayofmonth;

public Object dayofweek;

public Object deptime;

public Object crsdeptime;

public Object arrtime;

public Object crsarrtime;

public Object flightnum;

public Object id;

public Airplane tailnum;

Anexos _______________________________________________________________________________

92

public Object actualelapsedtime;

public Object crselapsedtime;

public Object airtime;

public Object arrdelay;

public Object depdeplay;

public Airport origin;

public Airport dest;

public Object distance;

public Object taxiin;

public Object taxiout;

public Object cancelled;

public Object diverted;

// get & set

@Override


{

String s = "{" +

" '_id':'" + id + "'" +

", 'id_flight':" + id_flight.toString() +

", 'month':" + month.toString() +

", 'year':" + year +

", 'dayofmonth':" + dayofmonth +

", 'dayofweek':" + dayofweek +

", 'deptime':" + deptime +

", 'crsdeptime':" + crsdeptime +

", 'arrtime':" + arrtime +

", 'crsarrtime':" + crsarrtime +

", 'arrdelay':" + arrdelay +

", 'depdeplay':" + depdeplay +

", 'airtime':" + airtime +

", 'actualelapsedtime':" + actualelapsedtime

+

", 'crselapsedtime':" + crselapsedtime +

", 'flightnum':'" + flightnum + "'" +

", 'origin':" + origin.toString() +

", 'dest':" + dest.toString()+

", 'distance':" + distance +

", 'taxiin':" + taxiin +

", 'taxiout':" + taxiout +

", 'cancelled':'" + cancelled + "'" +

", 'diverted':'" + diverted + "'" +

", 'tailnum':" + tailnum.toString() +

"}";

return s;

}

}

93

Anexos _____________________________________________________________________________




import com.MongoDB.QueryBuilder;

import java.io.BufferedWriter;

import java.io.FileWriter;

import java.io.IOException;



/**

*

* @author Gon

*/

public class Dissertacao {

private AirplaneDao dao = new AirplaneDao();

private AirportDao dao1 = new AirportDao();

private AirportDao dao3 = new AirportDao();

private FlightDao dao2 = new FlightDao();

/**

* @param args the command line arguments

*/

public static void main(String[] args) throws

IOException {

AirplaneDao dao = new AirplaneDao();

AirportDao dao1 = new AirportDao();

AirportDao dao3 = new AirportDao();

FlightDao dao2 = new FlightDao();

long count = 40800001;

DBObject query = QueryBuilder

.start()

.get();

List<dissertacao.Classes.Flight> voos =

dao2.findFlight(query);

List<FlightFinal> lista = new

ArrayList<FlightFinal>();

String s = "";

try

{

for(dissertacao.Classes.Flight voo : voos)

{

DBObject query1 = QueryBuilder

.start("tailnum")

.is(voo.tailnum)

Anexos _______________________________________________________________________________

94

.get();

List<dissertacao.Classes.Airplane> aviao =

dao.findAirplanes(query1);


.start("idairport")

.is(voo.origin)

.get();

List<dissertacao.Classes.Airport> aeroporto

= dao1.findAirport(query2);


.start("idairport")

.is(voo.dest)

.get();

List<dissertacao.Classes.Airport> aeroporto1

= dao3.findAirport(query3);

FlightFinal vooFinal;

vooFinal = new FlightFinal();

vooFinal.id = count;

vooFinal.id_flight = voo.id_flight;

vooFinal.year = voo.year;

vooFinal.month = voo.month;

vooFinal.actualelapsedtime =

voo.actualelapsedtime;

vooFinal.airtime = voo.airtime;

vooFinal.arrdelay = voo.arrdelay;

vooFinal.cancelled = voo.cancelled;

vooFinal.arrtime = voo.arrtime;

vooFinal.crsarrtime = voo.crsarrtime;

vooFinal.crsdeptime = voo.crsdeptime;

vooFinal.crselapsedtime =

voo.crselapsedtime;

vooFinal.dayofmonth = voo.dayofmonth;

vooFinal.dayofweek = voo.dayofweek;

vooFinal.depdeplay = voo.depdeplay;

vooFinal.deptime = voo.deptime;

vooFinal.taxiin = voo.taxiin;

vooFinal.taxiout = voo.taxiout;

vooFinal.origin = aeroporto.get(0);

vooFinal.dest = aeroporto1.get(0);

vooFinal.distance = voo.distance;

vooFinal.diverted = voo.diverted;

vooFinal.flightnum = voo.flightnum;

vooFinal.tailnum = aviao.get(0);

lista.add(vooFinal);

System.out.println(vooFinal.toString());

count+=1;

}

95

Anexos _____________________________________________________________________________

}catch(Exception e)

{

System.out.println(e.toString());

}

BufferedWriter out = new BufferedWriter(new

FileWriter("C:\\teste6\\teste46.txt"));

for(FlightFinal fs : lista)

{

out.write(fs.toString());

}

out.close();

}

}

97

Anexos _____________________________________________________________________________

Anexo B

No site oficial do MongoDB, selecionar download e escolher a versão indicada na imagem

abaixo, isto porque é a mais completa.

Figura 37 - Download do MongoDB

De seguida clica-se no instalador e a instalação começa.

Figura 38 - Instalação do MongoDB

Escolhe-se a opção complete para instalar todas as caraterísticas que a base de dados possui.

Anexos _______________________________________________________________________________

98

Figura 39 - Setup type da instalação do MongoDB

De seguida cria-se uma pasta na diretoria C: com o nome data e uma pasta dentro desta com

o nome db, isto para corrigir o erro hotfix que não deixaria a base de dados arrancar.

Figura 40 - Correção do erro hotfix

De seguida abrir o terminal da linha de comandos e mudar a diretoria para a que contém a

base de dados MongoDB.

99

Anexos _____________________________________________________________________________

Figura 41 - Mudança para a diretoria do MongoDB

De seguida executa-se o comando mongod para dar início à aplicação.

Figura 42 - Execução do comando "mongod"

A base de dados irá correr, e deixa-se esta janela aberta para não encerrar a aplicação.

Anexos _______________________________________________________________________________

100

Figura 43 - Inicialização do MongoDB

De seguida noutro terminal da linha de comandos, muda-se a diretoria para a base de dados

MongoDB e corre-se o comando “mongo” e está pronta a utilizar.

Figura 44 - Execução do comando "mongo"

101

Anexos _____________________________________________________________________________

Anexo C

Acede-se ao site CouchDB.apache.org e efetua-se o download para a versão Windows.

Figura 45 - Download do CouchDB

Executa-se o instalador.

Figura 46 - Instalação do CouchDB

E seleciona-se a diretoria onde será instalado.

Anexos _______________________________________________________________________________

102

Figura 47 - Seleção da diretoria

De seguida localiza-se o ficheiro local.ini e altera-se a password e o user para os

pretendidos, neste caso foi alterado para gon = 1234.

Figura 48 - Alteração das credenciais do CouchDB

Posto isto, inicia-se o CouchDB clicando no ficheiro Start CouchDB e este encontra-se

iniciado.

Neste trabalho é pretendido o acesso às bases de dados através da linha de comandos, sendo

assim houve a necessidade da instalação do Curl que é uma ferramenta da linha de

comandos para transferir dados através de URL´s.

Para pôr a funcionar o curl, basta efetuar o download3, de seguida copiar o executável para

a diretoria C:\Windows\System32.

Agora executa-se o comando “curl http://127.0.0.1:5984/” e fica-se ligado ao CouchDB.

3http://curl.haxx.se/download.html

103

Anexos _____________________________________________________________________________

Figura 49 - Execução do CouchDB através do curl

Como o CouchDB não retornava os tempos de consulta automaticamente como o MySQl e

o MongoDB foi necessário arranjar uma alternativa pois saber o tempo com exatidão era

uma prioridade. Sendo assim uma opção viável era através do curl, saber o tempo que

demorava a retornar o url da consulta à view.

Primeiro foi necessário a criação de um txt com o seguinte código4.

\n

time_namelookup: %{time_namelookup}\n

time_connect: %{time_connect}\n

time_appconnect: %{time_appconnect}\n

time_pretransfer: %{time_pretransfer}\n

time_redirect: %{time_redirect}\n

time_starttransfer: %{time_starttransfer}\n

----------\n

time_total: %{time_total}\n

\n

De seguida executava-se o seguinte comando na linha de comandos apenas alterando o url

conforme a consulta pretendida.

curl -w "@curl-format.txt" -o /dev/null -s

http://127.0.0.1:5984/tese4/_design/teste4/_view/tese44?grou

p=true

4 https://josephscott.org/archives/2011/10/timing-details-with-curl/

105

Anexos _____________________________________________________________________________

Anexo D

import sys

import glob

import errno,time,os

import CouchDB,simplejson

import json

from pprint import pprint

couch = CouchDB.Server() # Assuming localhost:5984

couch.resource.credentials = ("gon", "1234")

# If your CouchDB server is running elsewhere, set it up

like this:

# couch = CouchDB.Server('http://localhost:5984/')

db = couch['tese3']

path = "C:\gon\*.json"

#dirPath = 'C:/Users/VijayKumar/Desktop/CouchDB_Python'

files = glob.glob(path)

for file1 in files:

#dirs = os.listdir( dirPath )

file2 = glob.glob(file1)

for name in file2:

try:

with open(name) as f:

for line in f:

data = json.loads(line)

db.save(data)

pprint(data)

json_data.close()

except IOError as exc:

if exc.errno != errno.EISDIR:

raise

107

Anexos _____________________________________________________________________________

Anexo E Primeiro efetua-se o download do jmeter no site official

http://jmeter.apache.org/download_jmeter.cgi. A versão instalada foi a mais recente que é a

2.13. Tem como requisito o java6 ou superior.

Figura 50 - Download do Jmeter

Posto isto basta instalar o programa e para corre-lo vai-se à diretoria bin do jmeter e executa-

se o batch jmeter em modo administrador.

Figura 51 - Inicialização do Jmeter

Com tudo já instalado e a funcionar corretamente procede-se então à configuração.

MongoDB

Relativamente ao MongoDB, primeiro cria-se um thread group onde o objetivo é gerar a

carga pretendida. No campo number of threads define-se o número de utilizadores a testar

nomeadamente 10, 20, 50. No campo Ramp-Up period define-se o período em segundos

para inicializar um novo utilizador. E no loop count define-se o número de iterações.

Anexos _______________________________________________________________________________

108

Figura 52 - Criação do Thread Group

De seguida cria-se um config element do tipo MongoDB Source Config, é aqui que se faz a

configuração à base de dados através do servidor, neste caso o localhost.

Figura 53 - Criação do config element para o MongoDB

De seguida cria-se uma sampler do tipo MongoDB script e é neste que se define a base de

dados a efetuar o teste, neste caso a tese4 com cerca de 41 milhões de registos, e a consulta

109

Anexos _____________________________________________________________________________

a ser efetuada.

Figura 54 - Criação da sampler para o MongoDB

Por fim cria-se um listener para ser possível visualizar os resultados do teste. O escolhido

foi o summary report, onde é possível visualizar o tempo médio, máximo e mínimo e a

percentagem de erro caso ocorra.

Figura 55 - Criação do Listener

Anexos _______________________________________________________________________________

110

Mysql

Relativamente ao MySQL é utilizado o mesmo thread group e listener que o MongoDB.

Apenas muda a forma de conexão à base de dados e a consulta efetuada.

Relativamente ao config element foi selecionado o jdbc connection, e para configurar a

conexão à base de dados MySQL é necessário o preenchimento dos campos de uma forma

especifica. Nomeadamente no database url em que se define o servidor da base de dados e

a base de dados a utilizar. De seguida o JDBC driver class que é o valor que o jmeter

disponibiliza nos tutoriais para conetar ao MySQL. Por fim basta definir o utilizador e

password.

Figura 56 - Criação do Config Element para o MySQL

Por fim o último ponto distinto do MongoDB é a sampler que foi escolhido o tipo JDBC

request. Nesta é definida a consulta a testar.

111

Anexos _____________________________________________________________________________

Figura 57 - Criação da Sampler para o MySQL

Tendo tudo definido basta correr e esperar os resultados no listener.

Date post:	18-Jan-2019
Category:	Documents
Upload:	hoangque
View:	215 times
Download:	0 times

Gonçalo da Cruz Pereira e Sousarepositorium.sdum.uminho.pt/bitstream/1822/40119/1...a chamar Big...

Documents