bases de dados newsql: uma avaliação...

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Bases de Dados NewSQL: uma

avaliação experimental

Débora Abigail Carvalho Ribeiro

Licenciatura em Engenharia Informática – Ramo de Sistemas de Informação

Coimbra, Novembro de 2013

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Licenciatura em Engenharia Informática

Ramo de Sistemas de Informação

Projecto

Relatório Final

Bases de Dados NewSQL: uma

avaliação experimental

Débora Abigail Carvalho Ribeiro

Orientador:

Professor Doutor Jorge Bernardino

DEIS - ISEC

Coimbra, Novembro de 2013

Ao meu namorado e à minha família

Bases de Dados NewSQL Agradecimentos

v

Agradecimentos

Quero agradecer ao Professor Jorge Bernardino, o meu orientador de projecto, por

toda a ajuda e orientação que me deu ao longo deste projecto.

Agradeço também ao Professor Francisco Duarte, anterior presidente do

Departamento de Engenharia Informática e de Sistemas (DEIS), por ter

disponibilizado um computador que permitiu a realização dos testes necessários para

este projecto.

E por fim quero agradecer ao meu namorado e à minha família por todo o apoio que

me deram ao longo deste projecto, e pelo incentivo que me deram a nunca desistir e

continuar mesmo quando as coisas corriam menos bem.

Bases de Dados NewSQL Resumo

vii

Resumo

Com a evolução do mundo das tecnologias a capacidade de armazenamento de

informação e de processamento não consegue acompanhar o ritmo da informação

gerada sendo por isso necessário procurar alternativas para as tradicionais bases de

dados relacionais.

Uma das soluções actualmente existentes para resolver este problema foi o

aparecimento das bases de dados NoSQL. Apesar de terem bastante capacidade de

escalabilidade e processamento estas bases de dados têm duas limitações muito

grandes, não utilizam a linguagem SQL e não dão garantia de consistência dos dados,

isto é, não são ACID. Logo uma transição para sistemas NoSQL pode trazer muitas

dificuldades a qualquer organização, a começar por terem de reescrever todo o código

da base de dados. Assim depressa se chegou à conclusão que esta não é uma solução

viável para a maioria das organizações. Deste modo, surgiram as bases de dados

NewSQL.

As bases de dados NewSQL são um conjunto de novas bases de dados relacionais que

proporcionam melhor desempenho que os sistemas actualmente existentes, mantendo

no entanto a utilização da linguagem SQL. Devido às enormes quantidades de dados

geradas hoje em dia este tipo de bases de dados são adequadas para resolver os

tradicionais problemas no processamento desta informação. Neste projecto mostramos

as vantagens das bases de dados NewSQL através da avaliação sua experimental

utilizando o benchmark TPC-H. Nesta avaliação foram testadas as seguintes bases de

dados NewSQL: Drizzle, TokuDB, NuoDB, VoltDB e StormDB, utilizando como

base de comparação a base de dados MySQL. A avaliação experimental demonstrou a

superioridade das bases de dados NewSQL e como podem responder às actuais

necessidades de capacidade armazenamento de informação e de processamento.

Palavras–chave: Bases de dados, NewSQL, bases de dados open source, RDBMS,

NoSQL

Bases de Dados NewSQL Resumo

viii

Abstract

With the evolution of the world of technologies the capacity to store information and

processing cannot keep up with the pace of information generated and is therefore

necessary search for alternatives to traditional relational databases.

One of the solutions currently exist to solve this problem was the emergence of

NoSQL databases. Although having enought capacity of scalibility and processing

this databases have two limitations too large, do not use SQL language and give no

guarantee of consistency of data, i.e., they are not ACID. So a transiction to NoSQL

systems can bring many difficulties to any organization, start with having to rewrite

all the code of the database. So quickly came to the conclusion that is not a viable

solution for most organizations. Thus, NewSQL databases emerged.

NewSQL databases are a group of new relational databases that provides better

performance than the currently existing systems, maintaining however the use of the

SQL language. Because of the large quantities of data generated nowadays this type

of databases are appropriate to solve the traditional problems in processing this

information. In this project we show the advantages of the NewSQL databases

through its experimental evaluation using the TPC-H benchmark. In this evaluation

the following NewSQL databases were tested: Drizzle, TokuDB, NuoDB, VoltDB

and StormDB, using as a basis of comparison the database MySQL. The experimental

evaluation demonstrated the superiority of NewSQL databases and how they can

respond to the current needs of storage capacity and information processing.

Key-words: Databases, NewSQL, open source databases, RDBMS, NoSQL

ix

Índice

Agradecimentos ............................................................................................................. v

Resumo ........................................................................................................................ vii

Abstract ....................................................................................................................... viii

Índice ............................................................................................................................ ix

Índice de Figuras ........................................................................................................ xii

Índice de Tabelas ........................................................................................................ xv

Notação e Glossário .................................................................................................. xvii

1 Introdução ............................................................................................................. 1

2 O problema do crescimento dos dados ................................................................. 5

3 Evolução do SQL ao NewSQL ............................................................................ 11

3.1 NoSQL ................................................................................................................... 12

3.2 NewSQL ................................................................................................................ 14

3.3 Porquê criar o NewSQL? .................................................................................... 16

3.4 Problemas do SQL ............................................................................................... 16

3.5 Características das soluções NewSQL ................................................................ 17

3.6 Categorias do NewSQL ....................................................................................... 18

3.6.1 Novas Arquitecturas ........................................................................................ 18

3.6.2 Novos motores de armazenamento MySQL .................................................. 19

3.6.3 Sharding Transparente ................................................................................... 19

3.6.4 NewSQL-as-a-Service ...................................................................................... 19

4 Sistemas NewSQL ............................................................................................... 21

4.1 MySQL .................................................................................................................. 22

4.2 Drizzle ................................................................................................................... 23

4.3 TokuDB ................................................................................................................. 24

4.4 NuoDB ................................................................................................................... 26

x

4.5 VoltDB ................................................................................................................... 27

4.6 StormDB ............................................................................................................... 29

5 Ambiente experimental ....................................................................................... 33

5.1 TPC-H Benchmark .............................................................................................. 33

5.2 Características a avaliar ...................................................................................... 36

6 Principais dificuldades ........................................................................................ 37

7 Avaliação Experimental ...................................................................................... 39

7.1 Comparação de características técnicas ............................................................. 39

7.2 Bases de dados com 1GB ..................................................................................... 41

7.2.1 MySQL vs Drizzle vs TokuDB ........................................................................ 45

7.2.2 NuoDB ............................................................................................................... 49

7.2.3 VoltDB .............................................................................................................. 52

7.2.4 StormDB ........................................................................................................... 55

7.3 Bases de dados de com 10GB .............................................................................. 57

7.3.1 MySQL vs Drizzle vs TokuDB ........................................................................ 59

7.3.2 StormDB ........................................................................................................... 62

8 Conclusões e trabalho futuro ............................................................................. 65

Referências .................................................................................................................. 67

Anexo A Tutorial de instalação do Ubuntu 12.04 ................................................. 71

Anexo B Tutorial de instalação do MySQL e dos sistemas NewSQL .................. 75

B.1 MySQL .................................................................................................................. 75

B.2 Drizzle ................................................................................................................... 77

B.3 TokuDB ................................................................................................................. 78

B.4 NuoDB ................................................................................................................... 79

B.5 VoltDB ................................................................................................................... 80

Anexo C Como utilizar o TPC-H ........................................................................... 81

Anexo D Pesquisas do TPC-H ............................................................................... 83

xi

Anexo E Scripts utilizados no VoltDB ................................................................... 96

E.1 Script 1 .................................................................................................................. 96

E.2 Script 2 .................................................................................................................. 98

Anexo F Resultados para a base de dados de 1GB ............................................. 100

Anexo G Resultados da base de dados de 10GB .................................................. 106

Anexo H Artigo Científico .................................................................................... 109

Anexo I Proposta de Projecto ............................................................................. 119

xii

Índice de Figuras

Figura 2.1- Estimativa dos dados gerados em todo mundo entre 2005 e 2011, em exabytes, adaptado

de (Gantz & Reinsel, 2011) ---------------------------------------------------------------------------------------- 6

Figura 2.2 – Crescimento dos 3 Vs (Rouse, 2013) -------------------------------------------------------------- 7

Figura 2.3 - Armazenamento distribuído dos dados (Venkatesh & S, 2012) -------------------------------- 9

Figura 3.1 – Sharding de uma base de dados ------------------------------------------------------------------ 15

Figura 4.1 – Ecossistema NewSQL, (451 Group, 2012) ------------------------------------------------------ 21

Figura 4.2 – Interface do MySQL no Ubuntu ------------------------------------------------------------------ 23

Figura 4.3 – Interface do Drizzle -------------------------------------------------------------------------------- 24

Figura 4.4 – Interface do TokuDB ------------------------------------------------------------------------------- 26

Figura 4.5 – Interface do domain -------------------------------------------------------------------------------- 27

Figura 4.6 – Interface do NuoSQL ------------------------------------------------------------------------------- 27

Figura 4.7 – Interface do servidor do VoltDB------------------------------------------------------------------ 29

Figura 4.8 – Interface do sqlcmd do VoltDB ------------------------------------------------------------------- 29

Figura 4.9 – Interface StormDB --------------------------------------------------------------------------------- 31

Figura 4.10 – Gestão da base de dados no StormDB --------------------------------------------------------- 31

Figura 5.1 – Esquema da base de dados do TPC-H ----------------------------------------------------------- 34

Figura 7.1 – Tempo de criação das tabelas para 1GB -------------------------------------------------------- 42

Figura 7.2 – Erro ao definir uma chave forasteira no StormDB -------------------------------------------- 44

Figura 7.3 – Definição correcta de uma chave forasteira no StormDB ------------------------------------ 44

Figura 7.4 – Média dos tempos de execução para 1GB após executar as três sequências --------------- 46

Figura 7.5 – Tempo total de execução de todas as sequências para 1GB ---------------------------------- 48

Figura 7.6 - Média dos tempos de execução para 1GB após esxecutar as três sequências (NuoDB

MySQL, Drizzle e TokuDB) --------------------------------------------------------------------------------------- 50

Figura 7.7 - Tempo total de execução de todas as sequências para 1GB (NuoDB MySQL, Drizzle e

TokuDB) ------------------------------------------------------------------------------------------------------------- 51

Figura 7.8 - Erro VoltDB, order join ---------------------------------------------------------------------------- 52

Figura 7.9 – Erro VoltDB, condição having -------------------------------------------------------------------- 52

Figura 7.10 – Erro VoltDB, criar vistas e pesquisas com subpesquisas ------------------------------------ 53

Figura 7.11 – Erro VoltDB, espaço para tabela temporária excedido-------------------------------------- 53

xiii

Figura 7.12 – Média do tempo de execução para 1GB após executar as três sequências (VoltDB


Figura 7.13 – Desvio padrão para 1GB (VoltDB MySQL, Drizzle e TokuDB) ---------------------------- 54

Figura 7.14 – Tempo total de execução para 1GB (VoltDB MySQL, Drizzle e TokuDB) ---------------- 54

Figura 7.15 – Erro StormDB ------------------------------------------------------------------------------------- 55

Figura 7.16 – Média do tempo de execução para 1GB após executar as três sequências (StormDB


Figura 7.17 – Desvio padrão para 1GB (StormDB MySQL, Drizzle e TokuDB) -------------------------- 56

Figura 7.18 – Tempo total de execução para 1GB (StormDB MySQL, Drizzle e TokuDB) -------------- 56

Figura 7.19 – Utilização de memória pelo NuoDB e VoltDB ------------------------------------------------ 57

Figura 7.20 – Tempo de criação das tabelas para 10GB ----------------------------------------------------- 57

Figura 7.21 – Média dos tempos de execução para 10GB --------------------------------------------------- 59

Figura 7.22 – Tempo total de execução para 10GB ----------------------------------------------------------- 61

Figura 7.23 - Tempo total de execução para 10GB (StormDB MySQL, Drizzle e TokuDB) ------------- 62

Figura 7.24 – Desvio padrão para 10GB (StormDB MySQL, Drizzle e TokuDB) ------------------------ 62

Figura 7.25 – Tempo total de execução para 10GB (StormDB MySQL, Drizzle e TokuDB) ------------ 63

Figura F.1 – Tempos de execução na sequência 1 para 1GB ---------------------------------------------- 100

Figura F.2 - Tempos de execução na sequência 2 para 1GB ---------------------------------------------- 100

Figura F.3 - Tempos de execução na sequência 3 para 1GB ---------------------------------------------- 100

Figura F.4 – Sequência 1 para 1GB (NuoDB vsMysql,Drizzle e TokuDB) ------------------------------ 101

Figura F.5 - Sequência 2 para 1GB (NuoDB vsMysql,Drizzle e TokuDB) ------------------------------- 101

Figura F.6 - Sequência 3 para 1GB (NuoDB vsMysql,Drizzle e TokuDB) ------------------------------- 102

Figura F.7 - Sequência 1 para 1GB (VoltDB vsMysql,Drizzle e TokuDB) ------------------------------- 103



Figura F.10 – Sequência 1 para 1GB (StormDB vsMysql,Drizzle e TokuDB) --------------------------- 104

Figura F.11 - Sequência 2 para 1GB (StormDB vsMysql,Drizzle e TokuDB) --------------------------- 104

Figura F.12 - Sequência 3 para 1GB (StormDB vsMysql,Drizzle e TokuDB) --------------------------- 105

Figura G.1 - Sequência 1 para 10G --------------------------------------------------------------------------- 106

Figura G.2 - Sequência 2 para 10GB -------------------------------------------------------------------------- 106

Figura G.3 – Sequência 3 para 10GB ------------------------------------------------------------------------- 107

xiv

Figura G.4 - Sequência 1 para 10GB (StormDB MySQL, Drizzle e TokuDB) --------------------------- 108

Figura G.5- Sequência 2 para 10GB (StormDB MySQL, Drizzle e TokuDB) --------------------------- 108

Figura G.6 - Sequência 3 para 10GB (StormDB MySQL, Drizzle e TokuDB) --------------------------- 108

xv

Índice de Tabelas

Tabela 5.1 - Caracterização das tabelas do TPC-H para 1GB e 10GB ------------------------------------ 33

Tabela 7.1 – Comparação das características técnicas dos Sistemas NewSQL --------------------------- 40

Tabela 7.2 – Tempos de carregamento de dados para 1GB em segundos ---------------------------------- 42

Tabela 7.3 – Tempos obtidos para a criação de chaves primárias para 1GB ----------------------------- 43

Tabela 7.4 – Tempos obtidos para a criação de chaves forasteiras para 1GB ---------------------------- 43

Tabela 7.5 – Desvio padrão para 1GB -------------------------------------------------------------------------- 47

Tabela 7.6 – Desvio padrão para 1GB (NuoDB MySQL, Drizzle e TokuDB) ------------------------------ 50

Tabela 7.7 – Tempo de carregamento de dados para 10GB-------------------------------------------------- 58

Tabela 7.8 – Tempos obtidos para a criação de chaves primárias para 10GB ---------------------------- 58

Tabela 7.9 – Tempos obtidos para a criação de chaves forasteiras para 10GB --------------------------- 58

Tabela 7.10 – Desvio padrão para 10GB ----------------------------------------------------------------------- 60

Tabela F.1 – Valores da pesquisa Q14 para 1GB ----------------------------------------------------------- 101

Tabela F.2 - Valores da pesquisa Q15 (NuoDB vsMysql,Drizzle e TokuDB) ---------------------------- 102



Tabela G.1 – Valores da pesquisa Q9 para 10GB ----------------------------------------------------------- 107

Tabela G.2 – Valores da pesquisa Q14 para 10GB --------------------------------------------------------- 107

Bases de Dados NewSQL Notação e Glossário

xvii

Notação e Glossário

ACID – Atomicidade, Consistência, Isolamento e Durabilidade

ANSI – American National Standard Institute

DBMS – Database Management System

FK (Foreign Key) – Chave forasteira

ISO – International Organization for Standards

MVCC – Multiversion concurrency control

NoSQL – Not Only SQL

OLTP – Online Transaction Processing

PK (Primary Key) – Chave primária

RDBMS – Relational Database Management System

Sharding – é um tipo de particionamento de bases de dados que separa bases de

dados de grande de dimensão em particiçoes individuais, rápidas e fáceis de gerir

chamadas dados shard.

Shared-nothing – é uma arquitectura de computação distribuída, em que cada nó é

independente e auto-suficiente. Não há partilha de memória e de armazenamento em

disco entre cada um dos nós existentes.

SGBD – Sistema de Gestão de Bases de Dados

SQL – Structured Query Language

Bases de Dados NewSQL Capítulo 1

1

1 Introdução

Uma base de dados é um sistema que tem como principais finalidades: registar,

actualizar, manter e disponibilizar a informação relevante para a actividade de uma

organização. Os componentes que constituem uma base de dados são: a estrutura

lógica e física, através da qual a informação é organizada e o Sistema de Gestão de

Bases de Dados (SGBD), que assegura a gestão da informação (Carriço, 1996). Hoje

em dia ter a informação armazenada em bases de dados é vital para qualquer

organização.

As bases de dados surgiram no início dos anos 60 mas eram pouco práticas pois a

informação era guardada em ficheiros. Para facilitar a utilização das bases de dados

surgiram no início dos anos 70 os SGBD relacionais. Estes sistemas tornaram-se

bastante populares pois utilizam o modelo relacional, constituído por relações e

também devido ao surgimento da linguagem SQL (Structured Query Language), uma

linguagem de fácil utilização e bastante eficiente (Caldeira, 2006). Com este modelo

não existe redundância dos dados e existe mais flexibilidade, isto é, devido à

independência entre os dados e os programas qualquer alteração a um destes

elementos não obriga a uma mudança drástica no outro elemento.

A linguagem SQL foi criada em 1974 para ser utilizada nos SGBD. Apesar de terem

aparecido outras linguagens esta tornou-se a mais utilizada em todas as bases de dados

relacionais, por isso foi criado um padrão para SQL em 1986 pelo American National

Standard Institute (ANSI) e em 1987 pela International Organization for Standards

(ISO). Apesar de ter sido criado um padrão para SQL existem pequenas diferenças de

sintaxe nos diferentes produtos na utilização do SQL, dependendo de quem está a

vender o produto.

Para além dos vendedores de bases de dados não seguirem o padrão existente para o

SQL quando fabricam os seus produtos existe outro problema cada vez mais evidente

a falta de capacidade de armazenamento e processamento para toda a informação que

existe disponível hoje em dia. Para tentar solucionar esta dificuldade surgiram as

bases de dados NoSQL (Not Only SQL).

O NoSQL foi utilizado pela primeira vez em 1998 por Carlo Strozzi para designar

uma base de dados de código aberto que não tinha um interface SQL. O termo foi


2

reintroduzido em 2009 por Eric Evans num evento onde se pretendia falar de bases de

dados distribuídas de código aberto (NoSQL, 2013). As bases de dados NoSQL não

utilizam o modelo relacional, ou seja, são não relacionais e não têm as garantias

ACID (Atomicidade, Consistência, Isolamento e Durabilidade) que as bases de dados

relacionais têm, o que se torna uma grande desvantagem, pois apesar de terem

capacidade de armazenamento, as bases de dados NoSQL não conseguem garantir que

os dados que armazenam são consistentes. Outra limitação destas bases de dados é

facto de não utilizaram a linguagem SQL, daí o seu nome NoSQL.

Devido a estas grandes limitações das bases de dados NoSQL em 2011 falou-se pela

primeira vez em bases de dados NewSQL (NewSQL, 2013). Estas soluções tal como

o NoSQL oferecem grande capacidade de armazenamento mas além disso oferecem

as vantagens de serem relacionais, utilizarem a linguagem SQL e terem todas as

garantias ACID.

Assim tendo em consideração o desenvolvimento que a Internet e os sistemas de

armazenamento têm tido e o aparecimento de novos sistemas de bases de dados, o

objectivo deste projecto é analisar este novo tipo de bases de dados designadas

NewSQL. Esta análise consistiu em investigar quais as suas vantagens, as suas

características e quais os sistemas de bases de dados NewSQL actualmente existentes.

Após toda a análise teórica das bases de dados NewSQL, foi efectuada uma avaliação

experimental dos principais sistemas NewSQL (Drizzle, TokuDB, NuoDB, VoltDB e

StormDB), utilizando para isso a benchmark TPC-H.

A avaliação dos sistemas NewSQL mostrou que estes sistemas têm realmente uma

grande capacidade de armazenamento e processamento sendo sem dúvida mais

rápidos que as antigas bases de dados relacionais.

Este projecto foi realizado no Laboratório de Investigação e Inovação Tecnológica

(LIIT) localizado nas instalações do Instituto Superior de Engenharia de Coimbra

(ISEC).

A estrutura deste relatório encontra-se dividida em oito capítulos:

1. Introdução – enquadramento do projecto e quais os objectivos deste projecto;

2. O problema do crescimento dos dados – história da Internet e como esta se

desenvolveu até chegar aos dias de hoje e o que levou à necessidade de bases

de dados com maior capacidade de armazenamento e processamento;


3

3. Evolução do SQL ao NewSQL – história do SQL e como este se tem

desenvolvido até à criação dos sistemas NewSQL. Apresentamos também as

motivações que levaram à criação destes novos sistemas;

4. Sistemas NewSQL – descrição dos sistemas NewSQL existentes e a que

categoria pertencem; apresentamos também detalhadamente os sistemas que

foram testados durante a realização deste projecto;

5. Ambiente Experimental – explicamos o ambiente em que os vários sistemas

NewSQL foram testados, a benchmark utilizada para testar os sistemas e quais

as características que era pretendido avaliar nos diversos sistemas;

6. Principais dificuldades – dificuldades que surgiram ao longo da realização

deste projecto e como resolvemos essas mesmas dificuldades;

7. Avaliação Experimental – avaliação de 5 bases de dados NewSQL utilizando

o benchmark TPC-H e a respectiva análise dos resultados.

8. Conclusões e trabalho futuro – principais conclusões retiradas da

investigação realizada durante o projecto assim como dos testes realizados, e

que trabalho se pode fazer futuramente nesta área.


4


5

2 O problema do crescimento dos dados

Em 1958 o Departamento de Defesa dos Estados Unidos da América criou a

Advanced Research Projects Agency (ARPA) para estabelecer a sua liderança em

ciência e tecnologia aplicada aos militares, isto veio a ser a “semente” da Internet. Os

E.U.A criaram esta agência em resposta ao lançamento do satélite Sputnik por parte

da Rússia, em 1957 (Zakon, 2011).

Poucos anos depois começaram a ser discutidos os primeiros planos da ARPANET

(Advanced Research Projects Agency Network), tendo sido criada em 1969. A

ARPANET foi uma das primeiras redes da história da Internet actual e consistia numa

rede de quatro computadores que ligava quatro universidades entre si. Essas quatro

universidades eram:

SRI - Stanford Research Institute's Augmentation Research Center;

UCLA - University of California, Los Angeles;

UCSB - University of California, Santa Barbara;

Utah - University of Utah's Computer Science Department.

Com o passar dos anos esta rede foi aumentando, em 1971 já era constituída por 15

nós com 23 computadores. Em 1973 foi feita a primeira ligação internacional através

da ARPANET à University College of London, Inglaterra.

Em 1983, a ARPANET foi dividida em duas redes: a MILNET, que servia as

necessidades militares, e a ARPANET, que suportava a investigação.

No ano de 1990 o Departamento de Defesa dos E.U.A decidiu acabar com a

ARPANET, substituindo-a pela rede da NSF (National Science Foundation), que mais

tarde passou a ser a NSFNET (National Science Foundation Network). Esta rede

popularizou-se em todo o mundo com a denominação Internet.

Para a expansão da Internet foi muito importante a criação da World Wide Web

(WWW). A WWW foi criada no CERN (Centre Européen por la Recherche

Nucléaire), por Tim Berners-Lee.

A Internet transformou-se num sistema mundial público, de redes de computadores,

ao qual qualquer pessoa ou computador, previamente autorizado, pode conectar-se.


6

Obtida a conexão o sistema permite a transferência de informação entre

computadores. A infra-estrutura utilizada pela Internet é a rede mundial de

telecomunicações.

Com a globalização da Internet o volume de informação gerado mais que duplicou de

dois em dois anos, segundo a Lei de Moore (Moore, 1965). A lei de Moore surgiu em

1965 através de um conceito estabelecido por Gordon Earl Moore e diz que o poder

de processamento dos computadores duplica a cada dois anos. Assim mais poder de

processamento significa mais capacidade para gerar informação.

Segundo o estudo da IDC’s Digital Universe, de Junho de 2011, os dados criados em

2010 foram cerca de 1.200 exabytes, e vão continuar a crescer até aos 8.000 exabytes,

em 2015, sendo a Internet/Web o principal gerador e consumidor de dados, como é

mostrado na figura 2.1. Exabyte é uma unidade de armazenamento de dados em

computador, 260

bytes. O prefixo exa é um termo decimal. 260

são

1,152,921,504,606,846,976 bytes em decimal, um pouco mais que 1018

bytes como é

explicado em (Rouse, 2005).

Figura 2.1- Estimativa dos dados gerados em todo mundo entre 2005 e 2011, em

exabytes, adaptado de (Gantz & Reinsel, 2011)

Toda esta quantidade de informação gerada pela Internet e por todos os meios de

comunicação que nos rodeiam levaram a um conceito designado por Big Data, termo

utilizado para descrever o crescimento, a disponibilidade e o uso exponencial de

informações estruturadas e não estruturadas. Volume, variedade e velocidade são as

três propriedades ou dimensões que definem este termo. Volume refere-se à

quantidade de dados, variedade ao número de tipo de dados e velocidade refere-se à

velocidade de processamento dos dados (Rouse, 2013). Como se pode ver na figura

2.2, estes 3 Vs estão a crescer rapidamente.


7

Figura 2.2 – Crescimento dos 3 Vs (Rouse, 2013)

Nem todos os dados são úteis para fazer a análise de Big Data, no entanto há alguns

tipos de dados que estão particularmente desenvolvidos e que são bastante

interessantes para esta análise, como por exemplo (Big Data in 2020, 2012):

Videovigilância – normalmente são dados genéricos (data, hora, localização)

que são anexados automaticamente a um ficheiro de vídeo. Contudo, como a

utilização das câmaras IP continua a crescer, esta é uma boa oportunidade para

se adicionar mais inteligência à câmara e assim capturar imagens, analisá-las e

classificá-las em tempo real. Logo será possível, por exemplo, agilizar as

investigações criminais, definir um padrão de trânsito para os condutores e,

obviamente, melhorar a inteligência militar;

Dispositivos médicos – no futuro, sensores de todos os tipos (incluindo os que

podem ser implantados no corpo) irão medir a biometria vital e não vital,

acompanhar a eficácia da medicina, relacionar a actividade física com a saúde

e monitorizar possíveis surtos virais, tudo isto em tempo real;

Entretenimento e média social – tendências com base em multidões ou

grandes grupos de pessoas que podem ser uma grande fonte de Big Data para

ajudarem a trazer ao mercado a “próxima grande coisa”. Ajuda também a

definir possíveis vencedores e vencidos nos mercados de acções e até mesmo a


8

prever resultados de eleições. Tudo isto com base na informação publicada

pelos utilizadores em redes sociais e outros tipos de sites de livre acesso.

Imagens do consumidor – podemos dizer muito acerca de nós mesmos

quando publicamos fotografias nossas ou da nossa família ou amigos. A

imagem utilizada vale mais que mil palavras, e o início da Big Data introduziu

um multiplicador significativo. A chave para este tipo de dados é a introdução

de sofisticados algoritmos que permitem a identificação e análise das imagens

em tempo real.

Um exemplo do grande volume de dados gerados na Internet é o YouTube que tem

mais de mil milhões de utilizadores individuais que visitam o seu site todos os meses,

onde são visualizadas mais de 6 mil milhões de horas por mês, o que equivale quase

uma hora por cada pessoa na Terra e mais 50% em relação ao ano anterior e onde são

carregadas 100 horas de vídeo por minuto (YouTube, s.d.).

Desde a sua criação o Twitter demorou 3 anos 2 meses e 1 dia para atingir o

bilionésimo tweet, no entanto em Julho deste ano eram precisos apenas 5 dias para

que isso acontecesse; por segundo são partilhados 9.100 novos tweets e a média de

tweets por dia é de 58 milhões e são feitas 2.1 biliões de pesquisas (Twitter Statistics,

2013).

Em Junho deste ano existiam no Facebook 50.000.000 de páginas e a cada vinte

minutos eram partilhados 1.000.000 de links, enviavam-se 2.000.000 de pedidos de

amizade e eram enviadas 3.000.000 de mensagens, (Facebook Statistics, 2013).

Mas não são só as redes sociais que geram uma enorme quantidade de informação.

Actualmente existem sensores que ligados à Internet permitem monitorizar trânsito,

disponibilidade de estacionamento, poluição do ar, qualidade das estradas e muito

mais, tudo em tempo real gerando por isso enormes quantidades de dados.

O sensor mais comum e poderoso é o telemóvel. Com GPS e acesso à Internet os

smartphones são uma importante fonte de informação para fornecer, por exemplo,

dados acerca do trânsito. O Google Maps, por exemplo, utiliza muito dados recolhidos

através de utilizadores que utilizam telemóvel (Autopia Blog, 2011).


9

A continuidade da disponibilidade dos dados tornou-se mais importante que nunca.

Vivemos num tempo em que esperamos que os dados estejam disponíveis 24h por dia,

7 dias por semana e a partir de qualquer local.

Em (Venkatesh & S, 2012) é referido que este crescimento está a levar a que a

capacidade de armazenamento esteja a esgotar-se, e leva ao aparecimento de novos

sistemas de gestão de informação onde os dados são armazenados de forma

distribuída mas manipulados como se estivessem todos na mesma máquina, tal como

mostra a figura 2.3.

Figura 2.3 - Armazenamento distribuído dos dados (Venkatesh & S, 2012)

Para além de ser necessário resolver o problema do crescente volume de dados

gerados, é necessário ter em conta os requisitos de desempenho para a assegurar que

os dados são processados dentro do tempo pretendido. Infelizmente, o aumento do

poder de processamento não se traduz num acesso mais rápido aos dados, o que acaba

por se reflectir nos sistemas de bases de dados existentes.

Isto conduz à terceira dimensão da alta disponibilidade e durabilidade dos dados, ou

seja, temos de ter em consideração a alta disponibilidade sem qualquer falha, o que

tem sido um ponto forte das telecomunicações. Estes desafios têm gerado uma onda

de novas soluções de processamento de bases de dados, que gerem os dados de

maneira estruturada e não-estruturada.

Michael Stonebraker no seu artigo (Stonebraker, 2012) aborda as possíveis soluções

de processamento:


10

Tradicionais OLTP (Online Transaction Processing) – Estas soluções

registam todas as transacções efectuadas na organização, no entanto não são a

solução ideal para o problema de armazenamento existente por dois motivos.

Primeiro, a quantidade de dados que se pretende carregar para a base de dados

pode exceder as capacidades do velho SQL; segundo, não são capazes de

proporcionar pesquisas e análises aos dados em tempo real;

NoSQL (Not Only SQL) – Os fornecedores deste tipo de solução afirmam

que podem proporcionar uma grande escalabilidade e alto desempenho através

da diminuição ou até mesmo da eliminação do suporte a transacções,

eliminando o SQL. Esta solução tem também dois problemas. Primeiro, a

grande maioria das aplicações pretende bases de dados ACID (Atomicidade,

Consistência, Isolamento e Durabilidade), ou seja, querem maior capacidade

de armazenamento mas também querem garantir a integridade e consistência

dos dados e o NoSQL não garante esta consistência; segundo, a ausência de

SQL torna as pesquisas de dados mais trabalhosas;

NewSQL – Soluções que começam a aparecer e que preservam o SQL e

oferecem também grande escalabilidade e alto desempenho enquanto

preservam a noção de ACID nas transacções.

Tendo em conta a análise de Michael Stonebraker as soluções NewSQL parecem ser

as melhores para o problema de armazenamento e processamento que existe

actualmente.

No capítulo seguinte iremos fazer a análise histórica desde o surgimento do SQL até à

criação das bases de dados NewSQL.


11

3 Evolução do SQL ao NewSQL

Neste capítulo vamos explicar como surgiu o SQL e como os sistemas que utilizam

esta linguagem se foram desenvolvendo até chegarmos ao NewSQL.

A tecnologia de bases de dados relacionais foi inventada em 1970 por Edgar Frank

Codd, quando trabalhava para a IBM, onde demonstrou a utilidade e funcionalidade

trazida por esta nova tecnologia (Codd, 1970). Juntamente com esta proposta foi

desenvolvida a linguagem SQL - Structured Query Language (Chamberlin e Boyce,

1974), que se tornou a linguagem padrão na manipulação de dados armazenados em

bases de dados relacionais (Plew & Stephens, 2002).

Embora as ideias de Codd fossem marcantes, a IBM decidiu não as implementar

imediatamente. No entanto, outros grupos aperceberam-se das publicações de Codd e

começaram a trabalhar para pôr em prática as suas ideias.

Ingres foi a primeira base de dados relacional não-comercial desenvolvida em 1974

por um grupo da Universidade da Califórnia.

A primeira base de dados relacional comercial foi a Oracle V2 desenvolvida em 1979

pela Software Relational, que mais tarde passou a ser a Oracle Corporation. Poucas

semanas depois a IBM também lançou um novo sistema de bases de dados, o System

R, que utilizava uma nova linguagem de pesquisas, o SEQUEL. Em 1981 lançaram o

SQL/DS e em 1983 lançaram o DB2, principal produto RDBMS (Relational Database

Management System) da IBM até aos dias de hoje.

O SQL tornou-se a linguagem mais utilizada em bases de dados relacionais pelas

enormes vantagens que tem para quem utiliza esta linguagem (More Process, 2013):

É possível executar o SQL em computadores, portáteis, servidores e até

mesmo em telemóveis; e é muito fácil mover de um dispositivo para outro,

bases de dados que utilizem SQL;

A maioria dos vendedores de DBMS (Database Management System) utiliza

SQL nos seus produtos;

Existe um padrão para a linguagem SQL criado pela ANSI e ISO;

É a linguagem mais utilizada em bases de dados relacionais;


12

É muito fácil aprender e entender o SQL pois as suas pesquisas consistem

principalmente em declarações em inglês;

É uma linguagem interactiva que pode ser utilizada para comunicar com bases

de dados e obter respostas a questões complexas em pouco tempo;

O SQL pode ser ao mesmo tempo tanto uma linguagem de programação como

uma linguagem interactiva;

É uma linguagem completa, isto é, o SQL é utilizado tanto para criar bases de

dados como gerir a segurança da mesma. Assim como para actualizar,

recuperar ou partilhar informação da base de dados com os utilizadores;

Dependendo das permissões do utilizador que está a utilizar a base de dados é

possível mostrar a cada um informação diferente do conteúdo da base de

dados através da criação de vistas;

É uma linguagem cliente /servidor, que serve para ligar um servidor de bases

de dados a um computador cliente que apenas pretende interagir com a base de

dados;

É também uma linguagem dinâmica pois permite a alteração do conteúdo da

base de dados mesmo quando vários utilizadores estão a aceder à base de

dados;

Desde há algum tempo o SQL suporta também a programação orientada a

objectos.

Apesar de ter todas estas vantagens o SQL tem também muitas limitações que são

abordadas na secção 3.4, no entanto a maior desvantagem do SQL é que apesar do

padrão criado pela ANSI e ISO nem todos os vendedores de bases de dados utilizam

esse padrão, isto é, utilizam o SQL nas suas bases de dados mas não utilizam o padrão

na sua totalidade o que é torna as bases de dados de difícil utilização pois cada vez

que muda de produtos é necessário aprender novos conceitos para aceder à base de

dados.

3.1 NoSQL

O NoSQL foi utilizado pela primeira vez em 1998 por Carlo Strozzi para designar

uma base de dados de código aberto que não tinha um interface SQL. O termo foi


13

reintroduzido em 2009 por Eric Evans num evento onde se pretendia falar de bases de

dados distribuídas de código aberto. Em (NoSQL, s.d.) é definido como sendo a

próxima geração de bases de dados que tem as seguintes características: ser não

relacional, distribuída, open source e escalável horizontalmente. A intenção original

era ter uma base de dados web escalável e moderna. As características que mais vezes

se aplicam são: não ter esquemas de tabelas fixas, fácil suporte de replicação, API

(Application Programming Interface) simples, eventualmente consistente (BASE –

Basically Available, Soft state, Eventual consistency) mas não é ACID.

Muitos sistemas empresariais que tratam dados de grande importância (por exemplo,

sistemas financeiros) também têm necessidade de aumentar o seu tamanho mas são

incapazes de utilizar soluções NoSQL (aplicações que utilizam bases de dados que

seguem a definição anteriormente apresentada para NoSQL), porque as mesmas não

podem oferecer requisitos transaccionais robustos e consistentes. Anteriormente, as

únicas soluções possíveis para estas empresas passava por comprar uma mais máquina

com maior capacidade ou desenvolver um middleware personalizado que distribuísse

as consultas feitas na tradicional DBMS (Database Management System). Estas

soluções são demasiado dispendiosas e por isso não são solução para muitas das

empresas.

Apesar de todos os benefícios que as bases de dados NoSQL podem oferecer têm

também desvantagens e quando pretende fazer a transição de uma base de dados

relacional para uma base de dados NoSQL é necessário analisar muito e planear bem

essa transição porque pode revelar-se uma mudança bastante difícil e trabalhosa uma

vez que as bases de dados NoSQL, como o próprio nome indica, não utilizam

linguagem SQL.

Para além de a transição de bases de dados relacionais para bases de dados NoSQL ser

uma tarefa bastante difícil existem ainda outras desvantagens que nos devem fazer

pensar antes de avançar para uma mudança tão radical (Silva, 2010):

Modelos de integridade fracos;

Eventualmente consistente, ou seja, as bases de dados NOSQL não têm

garantias de que os dados sejam consistentes. O que significa que as bases de

dados NoSQL não são ACID;

Transacções só podem ser feitas através de código;


14

Pesquisas à base de dados são muito complexas;

Não existe uma linguagem padrão;

Controlo de acesso desorganizado.

Por causa de todas as desvantagens que o NoSQL apresenta começaram a surgir

novos sistemas de bases de dados, sistemas NewSQL, que voltam ao original modelo

relacional e ao uso da linguagem padrão SQL mas que pretendem oferecer alguns dos

benefícios das bases de dados NoSQL como a escalabilidade e a capacidade de

processamento.

3.2 NewSQL

O termo NewSQL foi utilizado pela primeira vez pelo analista Matthew Aslett, do 451

Group, em 2011 no seu relatório “NoSQL, NewSQL and Beyond”. Matthew Aslett

utilizou o termo NewSQL para classificar a nova alternativa de sistemas de bases de

dados.

O NewSQL é descrito em (Aslett, 2011) como sendo um atalho para os vários

fornecedores das novas alternativas de sistemas de bases de dados de alta performance

e escaláveis. Antes referiram-se a estes produtos como “ScalableSQL” para os

diferenciar dos outros produtos de bases de dados relacionais. Uma vez que esta

implica uma escalabilidade horizontal, que não é necessariamente uma característica

de todos os produtos, adoptaram o nome “NewSQL”.

Aslett esclarece também, que tal como o NoSQL, o NewSQL não é para ser traduzido

literalmente: o que é novo no NewSQL são os fornecedores, e não o SQL.

O NewSQL é um conjunto de vários fornecedores da nova alternativa de sistemas de

bases de dados SQL, de alto desempenho e escalável. Estes fornecedores têm vindo a

desenhar soluções que tenham os benefícios do modelo relacional da arquitectura

distribuída, e que melhore o desempenho das bases de dados relacionais para que o

aumento de tamanho das bases de dados não seja um problema (Venkatesh & S,

2012).

Em (NewSQL, 2013) é explicado que o NewSQL é também uma classe de gestão de

bases de dados relacionais que visa proporcionar o mesmo desempenho que os

sistemas NoSQL para carregamentos de OLTP e ainda assim manter as garantias


15

ACID das bases de dados tradicionais. Pretende-se ainda eliminar as tarefas que estão

sujeitas a erros de gestão como por exemplo o sharding manual, sem ter de

interromper o funcionamento da base de dados (Mehta, 2013). Sharding é um tipo de

particionamento de bases de dados que separa bases de dados de grande dimensão em

partições individuais, rápidas e fáceis de gerir chamadas dados shard (figura 3.1).

Assim o sharding manual implica fazer o particionamento das bases de dados

manualmente sem recorrer a qualquer aplicação para o fazer.

Figura 3.1 – Sharding de uma base de dados

Na apresentação do relatório do grupo de investigação 451 Group (Aslett 2, 2011),

Matthew Aslett diz que as bases de dados NewSQL foram projectadas para atender os

requisitos de escalabilidade das arquitecturas distribuídas ou para melhorar o

desempenho de tal forma que a escalabilidade horizontal deixe de ser uma

necessidade, incluindo novos mecanismos de armazenamento MySQL, tecnologias de

sharding transparente e bases de dados completamente novas. O NewSQL é assim

utilizado para descrever o desenvolvimento de novas bases de dados relacionais e

serviços desenhados para que as arquitecturas distribuídas tenham todos os benefícios

do modelo relacional, e melhorando o desempenho das bases de dados relacionais

para que já não seja necessário escalabilidade horizontal.

Logo pode dizer-se que o NewSQL pretende preservar o SQL, oferecer alto

desempenho e escalabilidade enquanto preserva a noção de ACID para transacções.


16

3.3 Porquê criar o NewSQL?

O SQL tem muitos problemas quer ao nível de gestão de bases de dados quer ao nível

da linguagem que permite aceder às bases de dados, tais como a escalabilidade, o

desempenho e o tamanho reduzido das bases de dados. Com o aumento do volume de

dados as bases de dados SQL estão a perder poder de processamento e a ficar muito

aquém do desempenho esperado. A capacidade de armazenamento das bases de dados

SQL está a esgotar-se. Para além disso tem também o problema de ter certas coisas

que mudam de produto para produto e fornecedor para fornecedor. Em seguida são

apresentados alguns dos problemas existentes no SQL e que o NewSQL pretende

solucionar (Sourceforge, s.d.)

3.4 Problemas do SQL

Tal como já foi referido antes, o SQL não possui só vantagens também tem limitações

(Sourceforge, s.d.). O principal problema do SQL é a existência de diferenças nas

regras de sintaxe em cada produto, mesmo nas coisas mais simples. Estas diferenças

dificultam quem está a começar a utilizar o SQL pois não consegue detectar

rapidamente estas diferenças.

Quando se utilizam diferentes bases de dados num mesmo trabalho é possível que o

programador se depare com o problema da impossibilidade de importar os diferentes

tipos de dados de uma base de dados para outra. Para além disso não é possível

utilizar dados com um tamanho qualquer pois o SQL tem restrição no tamanho dos

tipos de dados, enquanto, por exemplo no Java não há restrições. Estas restrições

podem levar a perdas de tempo porque os programadores no início definem colunas

varchar com um tamanho pequeno, que podem vir a ser insuficientes e leva a que

mais tarde seja necessário alterar o tamanho.

Outro problema do SQL é não existir um padrão para incremento automático de

colunas/sequências e não ser fácil fazer pesquisas nas bases de dados quando se

pretende procurar por algum campo que esteja a NULL.

Quando se pretende utilizar o SQL para integrar noutra linguagem de programação é

necessário escolher com cuidado a linguagem de programação que se vai utilizar

porque o SQL é difícil de integrar numa linguagem de programação como o Java.


17

Se pretender fazer a distinção entre letras maiúsculas e minúsculas, no SQL, não vai

conseguir fazê-lo pois não é case sensitive, isto é, tanto faz usar letras maiúsculas

como minúsculas que o SQL não as diferencia. E para além disto também permite

espaços nos nomes. Outras linguagens de programação não suportam espaços nos

nomes pois parece não haver uma boa razão para isso.

Outra dificuldade do SQL é que se uma tabela tiver muitas colunas é necessário uma

contagem de colunas, ou seja, é necessário saber todas as colunas existentes.

Exemplo, Insert INTO (muitas colunas) Values (muitos valores), o que pode ser muito

demorado quando se quer inserir muitos dados. Para além de ter se saber todas as

colunas existentes também não é fácil comparar linhas completas, porque é necessário

listar a coluna completa.

Não existe uma maneira padrão de verificar se uma tabela (índice, etc.) já existe, o

que por vezes poderia facilitar a vida do gestor da base de dados. Assim como não

existe sintaxe para gerir a base de dados como um todo e um comando UPSERT

padrão. Insert se a coluna não existir e Update se existir.

Os diferentes produtos que existem no mercado têm diferentes mecanismos de

namespace (esquemas, catálogos, bases de dados). O namespace contém um conjunto

de identificadores (nomes) que permitem a desambiguação de identificadores

homónimos de namespaces diferentes.

3.5 Características das soluções NewSQL

Segundo (Venkatesh & S, 2012) as principais características das soluções NewSQL

são:

O SQL é o principal mecanismo de interacção com as aplicações;

Suporta ACID para as transacções;

Mecanismo de controlo de não-bloqueio simultâneo, para que a leitura em

tempo real não entre em conflito com a escrita, e assim fazê-los parar;

Uma arquitectura que proporcione um desempenho mais alto por nó do que as

tradicionais soluções RDBMS;

Uma arquitectura shared-nothing, expansiva, capaz de funcionar no maior

número de nós sem bloquear. Arquitectura shared-nothing é uma arquitectura


18

de computação distribuída, em que cada nó é independente e auto-suficiente.

Não há partilha de memória e de armazenamento em disco entre cada um dos

nós existentes.

Com estas características espera-se que o NewSQL seja mais rápido que os

tradicionais sistemas RDBMS.

3.6 Categorias do NewSQL

Embora os sistemas NewSQL variem muito na sua arquitectura interna, há duas

características distintas que são comuns a todos eles e que são o suporte ao modelo de

dados relacional e o uso de SQL como principal interface.

Os sistemas NewSQL podem ser agrupados em quatro categorias:

Novas Arquitecturas;

Novos motores de armazenamento MySQL;

Sharding Transparente;

NewSQL-as-a-Service.

3.6.1 Novas Arquitecturas

A primeira categoria sistemas de NewSQL são plataformas de bases de dados

completamente novas. São projectados para funcionar num grupo distribuído de nós

shared-nothing, uma arquitectura em que cada nó é independente e auto-suficiente, ou

seja, nenhum dos nós partilha memória ou espaço em disco. Os nós normalmente

possuem um subconjunto de dados. As consultas SQL são divididas em fragmentos de

consultas e enviadas para os nós que possuem os dados. Estas bases de dados têm a

capacidade de aumentar o seu tamanho linearmente quando são acrescentados nós

adicionais.

Esta categoria está dividida em duas subcategorias, que são:

Bases de dados tradicionais – Mantêm as funcionalidades das tradicionais

bases de dados, manipulando todos os tipos de consultas. As bases de dados

são completamente reformuladas assumindo que assentam num sistema

distribuído e incluem componentes tais como controlo de concorrência


19

distribuída, controlo de fluxo e processador de consultas distribuídas. Google

Spanner e Clustrix são exemplos deste tipo de bases de dados.

Bases de dados em memória – As aplicações alvo destes sistemas NewSQL

são caracterizadas por ter um grande número de transacções que:

o 1 – São de curta duração;

o 2 – Trabalham com um pequeno subconjunto de dados através de

índices (não existe análise à tabela completa);

o 3 – São repetitivas, isto é, fazem sempre as mesmas consultas mas com

dados diferentes.

Estes sistemas NewSQL atingem um alto desempenho e têm grande capacidade de

mudar de tamanho e fazem-no contrariando muita da herança recebida da arquitectura

do sistema System R, que é um sistema de bases de dados construído através de um

projecto de pesquisa no Laboratório San Jose Research, da IBM, no início do ano de

1974. Dois exemplos deste tipo de sistemas são o VoltDB e o SQLFire (NewSQL,

2013)

3.6.2 Novos motores de armazenamento MySQL

A segunda categoria são mecanismos de armazenamento altamente optimizados para

o MySQL. Estes sistemas têm o mesmo interface de programação que o MySQL, mas

aumentam o seu tamanho melhor que os motores incorporados, como o InnoDB.

Exemplos destes novos mecanismos de armazenamento incluem o ScaleDB, TokuDB,

MemSQL e Akiban (NewSQL, 2013).

3.6.3 Sharding Transparente

Este sistema tem uma camada intermédia de sharding (sharding middleware) que

divide automaticamente as bases de dados em múltiplos nós. Exemplos destes tipos de

sistemas são dbShards, Scalearc e ScaleBase (NewSQL, 2013).

3.6.4 NewSQL-as-a-Service

Um software as-a-Service é uma forma de distribuição e comercialização desse

mesmo software. Neste modelo o fornecedor do software responsabiliza-se por toda a

estrutura necessária para a disponibilização do sistema (servidores, conectividade,


20

cuidados com a segurança da informação) e o cliente utiliza o software via internet,

tendo apenas de pagar pela utilização do serviço.

Não é necessariamente a tecnologia utilizada que determina o modelo. O software

utilizado pode ser 100% web (utilizado via browser) ou pode ter alguma instalação

local (como antivírus ou sistemas de backup). As características principais são a não

aquisição das licenças (mas sim pagar pelo seu uso como um "serviço") e a total

responsabilidade do fornecedor pela disponibilização do sistema em produção.

Um exemplo deste tipo de sistemas é o StormDB.

No capítulo seguinte iremos fazer uma breve descrição das características de todos os

sistemas testados durante a realização deste projecto e ainda apresentar o ecossistema

NewSQL.


21

4 Sistemas NewSQL

Neste capítulo mostramos todos os sistemas NewSQL que existem actualmente mas

abordamos principalmente os sistemas que foram testados dando a conhecer cada um

deles. Fazemos a apresentação da base de dados MySQL, que apesar de não ser um

sistema NewSQL, é a base de dados open source mais utilizada no mundo (DB-

Engines Ranking, 2013), sendo por isso utilizada como referência na avaliação das

bases de dados NewSQL.

Na figura 4.1 podemos ver o ecossistema NewSQL, isto é, como estão distribuídos os

vários sistemas pelas categorias NewSQL.

Figura 4.1 – Ecossistema NewSQL, (451 Group, 2012)

Como é possível ver existem quatro grandes categorias por onde se distribuem os

diversos sistemas NewSQL:

Novas bases de dados (New Databases);

Motores de armazenamento (Storage engines);

Clustering/Sharding;

NewSQL-as-a-Service;

Os sistemas testados e que iremos descrever de seguida pertencem às categorias New

Databases (Drizzle, VoltDB, NuoDB), Storage engines (TokuDB) e NewSQL-as-a-

Service (StormDB)


22

4.1 MySQL

O MySQL foi criado em 1995 por David Axmark, Allan Larsson and Michael

"Monty" Widenius da empresa MySQL AB e o seu site é http://www.mysql.com/.

Actualmente o MySQL é propriedade da Oracle Foundation.

Um dos grandes objectivo para o MySQL é que este seja:

A melhor base de dados e a mais utilizado em todo o mundo;

Disponível e acessível para todos;

Rápido, seguro e confiável através de pequenas melhorias;

Fácil de usar;

Livre de erros.

A versão testada do MySQL foi a que estava disponível quando os testes foram

realizados, a 5.6.13. De referir que a partir da versão 5.6 o MySQL foi bastante

melhorado em relação às versões anteriores em aspectos, tais como (Ulin & Young,

2013):

Performance e escalabilidade:

o Aumentou para 48 CPU Threads. Threads são as sequências de

instrução que são executadas num programa;

Em relação à versão 5.5 a performance aumentou 230%;

INNODB, módulo de armazenamento que oferece transacções do tipo ACID:

Melhor rendimento nas transacções e mais disponibilidade;

Optimização:

o Melhor tempo na execução de consultas e melhor ajuste das consultas;

o Melhor desempenho, disponibilidade e integridade dos dados;

Nova Funcionalidade:

o Acesso NoSQL para INNODB.

Com estas melhorias significativas pretendeu-se eliminar os erros existentes nas

versões anteriores e ainda melhorar o desempenho do MySQL.

Na figura 4.2 é mostrado o interface do MySQL.

http://www.mysql.com/


23

Figura 4.2 – Interface do MySQL no Ubuntu

4.2 Drizzle

O Projecto Drizzle teve o seu início em 2008 e está disponível em

http://www.drizzle.org/. O Drizzle é uma base de dados transaccional, relacional e

open source que deriva da base de dados MySQL. A versão utilizada nos testes foi a

7.2.4-alpha.

O Drizzle foi desenhado para ambientes modernos de 64 bits, arquitectura multi-core,

com gigabytes de memória e para executar várias transacções ao mesmo tempo,

(Drizzle Documentation, 2010).

Embora o Drizzle seja uma derivação do MySQL não foi feito para o substituir mas

sim para atrair os utilizadores que querem a confiabilidade, bases de dados ACID e a

fácil utilização que o MySQL proporciona mas não precisam de todos os recursos que

este tem como por exemplos, procedimentos, triggers ou vistas.

As principais diferenças entre Drizzle e o MySQL são as seguintes, (Getting Started

with Drizzle and PHP, 2009):

Motor de armazenamento é o InnoDB em vez do MyISAM;

Suporta menos tipos de dados;

Utiliza um protocolo diferente de comunicação cliente/servidor;

Suporta uma arquitectura de módulos extensível que permite aos

programadores compilar apenas os módulos necessários (muito parecido com

o Apache ou com o PHP).

http://www.drizzle.org/


24

O Drizzle está optimizado para ter várias conexões em simultâneo à base de dados; e

não é possível utilizá-lo em plataformas Windows.

A equipa que programou o Drizzle retirou código que achava desnecessário do

MySQL e converteu o restante código para a linguagem C++ e para bibliotecas mais

modernas.

Em termos técnicos, o Drizzle é baseado num micro-kernel projectado para bases de

dados a que se possam acrescentar novos módulos sempre que necessário. E os seus

objectivos relacionais e de durabilidade estão construídos no kernel como projecto

padrão.

O Drizzle suporta um variado número de interfaces como plugins e assim o kernel faz

o menos possível e é o mais claro possível para os utilizadores. Desta forma é

permitido aos utilizadores aumentar a base de dados escrevendo simples plugins.

Historicamente, os servidores de bases de dados é que definem a infra-estrutura – o

utilizador deve utilizar o sistema de autenticação e de login existentes. O Drizzle tenta

uma abordagem diferente, tem como objectivo a integração com a infra-estrutura

existente tornando-se parte dela e não uma ilha.

Na figura 4.3 é mostrado o interface do Drizzle.

Figura 4.3 – Interface do Drizzle

4.3 TokuDB

O TokuDB pertence à empresa Tokutek e a sua primeira versão open source foi

lançada em Abril de 2013, o seu site é http://www.tokutek.com/. A versão do TokuDB

utilizada para executar os testes foi a 5.5.30-tokudb-7.0.4.

http://www.tokutek.com/


25

O TokuDB é um mecanismo de armazenamento para MySQL que foi especialmente

criado para ter um alto desempenho em carregamentos de escrita intensiva, utilizando

para isso a indexação Fractal Tree, (TokuDB, s.d.).

A indexação Fractal Tree implementa as mesmas operações que a indexação B-Tree,

forma mais comum de indexação. A diferença está na performance, pois a Fractal

Tree substitui I/O (entradas/saídas) aleatórias por I/O sequenciais; isto é feito para que

a largura de banda do disco tenha uma taxa de utilização máxima, mesmo quando a

base de dados cresce. Como resultado é possível ter mais índices sem haver perda de

desempenho; quanto maior for a tabela mais vantagem o TokuDB consegue obter em

relação ao mecanismo de armazenamento B-Tree, ou seja, mesmo em grande tabelas o

TokuDB oferece um bom desempenho sem particionamento ou sharding pois foi

projectado para tabelas muito grandes.

TokuDB é escalável, ACID e tem um mecanismo de armazenamento compatível com

MVCC (Multiversion concurrency control) que proporciona melhorias em consultas

através de índices. MVCC é um método de controlo de concorrência normalmente

utilizado em sistemas de gestão de bases de dados que proporciona simultaneamente

acesso às bases de dados e às linguagens de programação para implementação de

memória transaccional.

As principais vantagens do TokuDB em relação ao motor de armazenamento MySQL

são as seguintes, (TokuDB Documentation, n.d.):

Fazer inserções e pesquisas mais rapidamente em condições reais;

Escalabilidade máxima, isto é, a base de dados pode ter muitos terabytes de

tamanho;

Controlo de concorrência, ou seja, permite a leitura e escrita simultânea na

base de dados sem que esta fique inconsistente;

Melhoramento no backup de falhas.

Com estas características a equipa que desenhou o TokuDB pretende torná-lo numa

base de dados bastante eficiente e capaz de competir com o MySQL.

Na figura 4.4 é mostrado o interface do TokuDB.


26

Figura 4.4 – Interface do TokuDB

4.4 NuoDB

O NuoDB foi fundado em 2008 com o nome de NimbusDB e em 2011 o seu nome foi

mudado para NuoDB. Este sistema foi projectado em 2008 por Jim Starkey e em 2010

juntou-se a ele neste projecto Barry Morris, (NuoDB, 2013). O site do NuoDB é

http://www.nuodb.com/. E a versão utilizada nos testes foi a 1.2.

O NuoDB é solução NewSQL que oferece alto desempenho e escalabilidade, com

inexistência de tempo de inactividade e gestão de bases de dados que podem estar

distribuídas por vários locais, como é explicado em (NuoDB without compromisse,

2013).

É um DBMS que lida com transacções, interacções e observações em qualquer lado. E

suporta linguagens de programação como Java, .NET, PHP e Phyton, entre outras.

O NuoDB é uma base de dados distribuída desenhada com alguns desafios em mente.

Tem todas as propriedades do SQL: tem garantias ACID em todas as suas

transacções, suporta a linguagem SQL e a lógica relacional. Foi desenhado desde o

início como um sistema distribuído que tem escalabilidade tal como um serviço na

Cloud tem, oferecendo alta disponibilidade sem um único ponto de falha.

Ao contrário das tradicionais arquitecturas shared-nothing, o NuoDB oferece uma

arquitectura ponto-a-ponto, onde cada ponto funciona tanto como servidor como

cliente, o que gera alta disponibilidade dos dados.

http://www.nuodb.com/


27

A arquitectura do NuoDB está dividida em três camadas: administrativa, transaccional

e de armazenamento. Esta divisão em camadas é fundamental para que se possa ter

um sistema relacional escalável (The Architecture & Motivation for NuoDB, 2013).

O NuoDB tem duas interfaces na linha de comandos, uma onde se inicia a Storage

Manager e a Transaction Engine, o domain (figura 4.5) e outra interface que é o

NuoSQL (figura 4.6).

Figura 4.5 – Interface do domain

Figura 4.6 – Interface do NuoSQL

4.5 VoltDB

O VoltDB é uma base de dados em memória (in-memory), ou seja, depende da

memória principal para armazenamento de dados. Este sistema foi desenhado por

conhecidos pesquisadores de sistemas de bases de dados, incluindo Michael

Stonebraker, Sam Madden e Daniel Abadi, em 2010. O site deste sistema é

http://voltdb.com/ e a versão utilizada nos testes foi a 3.2.

O VoltDB é uma base de dados relacional ACID e que utiliza uma arquitectura

shared-nothing, (VoltDB, 2013).

O VoltDB tem seis características chave (Technology of VoltDB, 2013):

1. ACID - o VoltDB garante que os dados estão 100% correctos, em 100% das

vezes não sendo por isso necessário trocar a consistência dos dados por

escalabilidade. O VoltDB tem ambos através de:

http://voltdb.com/


28

Dados organizados em partições na memória;

Envio de transacções por clientes conectados à base de dados;

Transacções recebidas são direccionadas para os dados e executadas

em série.

2. Escalabilidade horizontal – a base de dados VoltDB pode aumentar o seu

tamanho em duas dimensões:

Aumentado a capacidade dos nós da base de dados existentes;

Aumentando o número de nós num cluster shared-nothing;

3. Alta disponibilidade – enquanto a maioria dos produtos de bases de dados

oferece alta disponibilidade através de módulos complexos e bastante caros, o

VoltDB foi desenhado para ter alta disponibilidade a partir do zero. É fácil de

utilizar e completamente transparente para as aplicações. As partições são

replicadas de forma transparente por vários servidores, e se um falhar todos os

dados permanecem disponíveis e consistentes para a operação continuar;

4. Desempenho em memória com durabilidade em disco – todos sabemos que

acidentes podem acontecer mas isso não tem de afectar a aplicação ou o

negócio de uma empresa. Com o Command Logging e o Snapshot do VoltDB

é possível recuperar a base de dados de uma forma rápida e fácil;

5. Replicação da base de dados para recuperação de perdas – tempo de

inactividade não é uma opção com o VoltDB. A funcionalidade de replicação

da base de dados do VoltDB faz uma replicação assíncrona na WAN (Wide

Area Network) para a recuperação de perdas. A cópia remota é apenas de

leitura enquanto não for considerada como sendo a base de dados principal,

que armazena os dados em disco se o controlo remoto estiver temporariamente

inacessível;

6. VoltDB export – integrar os dados de transacções com os dados analíticos ou

outro tipo de dados é uma exigência fundamental para aplicações de alto

desempenho. O VoltDB tem incluída uma funcionalidade de extracção

transaccional: o VoltDB export.


29

O VoltDB também tem dois interfaces, um para iniciar o servidor (figura 4.7) e outro

para o sqlcmd (figura 4.8).

Figura 4.7 – Interface do servidor do VoltDB

Figura 4.8 – Interface do sqlcmd do VoltDB

4.6 StormDB

Este sistema pertence à empresa TransLattice que foi fundada em 2007 por Fank

Huerta, Mike Lyle e Robert Geiger.

O StormDB é uma base de dados na Cloud e pode ser encontrado no site

http://www.stormdb.com/. No entanto este não é um sistema open source. Permite um

período experimental de 30 dias mas depois desse período é necessário começar a

pagar o alojamento da base de dados.

O StormDB é um serviço de gestão de base de dados relacionais que proporciona um

desempenho confiável e uma escalabilidade perfeita. Ao contrário das típicas bases de

dados na Cloud, o StormDB tem uma abordagem diferente para armazenar os dados

na Cloud. Em vez de executar a base de dados numa máquina virtual, perdendo

desempenho e confiabilidade, o StormDB é uma Cloud de bases de dados (StormDB

http://www.stormdb.com/


30

overview, 2013). Semelhante às clouds de armazenamento, não existe virtualização

dos dados. É tudo executado directamente a partir de um computador dando ao

utilizador performance, escalabilidade e confiabilidade.

Numa típica base de dados na Cloud existe limitação no aumento do tamanho da

instância virtual que se utiliza, enquanto no StormDB os dados são automaticamente

divididos por clusters de servidores ajustando o seu tamanho à necessidade da base de

dados. Tudo isto sem a necessidade de instalar complexas soluções de replicação de

dados ou aumentar a consistência dos dados para poder ampliar o tamanho da base de

dados na Cloud.

Muitas bases de dados na Cloud desempenham bem algumas das tarefas necessárias

na gestão da base de dados à custa de se tornarem piores noutras tarefas, o StormDB

não faz este tipo de compromisso. Qualquer tipo de base de dados complexa, seja um

exigente sistema transaccional ou uma data warehouse complicada, podem ser

executador no StormDB (StormDB overview, 2013).

Alguns dos benefícios do StormDB são (Why StormDB, 2013):

Não há necessidade de ajustar o desempenho da base de dados para aumentar

o tamanho da aplicação;

A base de dados está pronta para utilização em poucos segundos sem

necessitar de configurar complicadas opções de alta disponibilidade e

replicação de dados;

Tudo o que é necessário para a base de dados está na Cloud. Basta apenas

aceder ao browser para a utilizar;

Sistema baseado no PostgreSQL por isso não é necessário reescrever

pesquisas e aplicações. Apenas tem de se utilizar o SQL ANSI que já

conhecemos;

Não existe a necessidade de sacrificar os recursos para obter escalabilidade e o

desempenho que se pretende para a base de dados. O StormDB permite que se

faça tudo desde a pesquisa mais simples à mais complexa.

O StormDB tem um interface onde é possível ver as bases de dados existentes (figura

4.9) e outro onde é possível gerir a base de dados (figura 4.10).


31

Figura 4.9 – Interface StormDB

Figura 4.10 – Gestão da base de dados no StormDB

No próximo capítulo fazemos a análise do ambiente experimental utilizado para a

avaliação dos sistemas anteriormente descritos, descrevemos a benchmark utilizada e

as características que pretendemos avaliar.


32


33

5 Ambiente experimental

Para avaliar as bases dados NewSQL utilizou-se a benchmark TPC-H (Transaction

Performance Council). Os testes foram realizados num computador com sistema

operativo Ubuntu 12.04 LTS 64-bit, memória (RAM) de 8GB, processador Intel®

Core™ i7 CPU 920 @ 2.67GHz x 8 e disco Samsung HD502HJ 500GB SATA.

5.1 TPC-H Benchmark

O TPC-H é uma benchmark de apoio à decisão que consiste num conjunto de

pesquisas ad-hoc orientadas ao negócio.

Esta benchmark avalia o desempenho de vários sistemas de apoio à decisão através da

execução de um conjunto de pesquisas, em condições controladas, nas bases de dados

em teste. As pesquisas do TPC-H dão respostas para questões de negócio reais e

simulam as tradicionais pesquisas ad-hoc dos sistemas de apoio à decisão. Estas

pesquisas são muito mais complexas que a maioria das transacções OLTP e incluem

um vasto conjunto de operadores e restrições de selectividade. As pesquisas geram

também uma intensa actividade por parte do servidor de base de dados do sistema que

está a ser testado e são executadas numa base de dados de acordo com uma população

específica e requisitos de tamanho (TPC-H Documentation, 2013).

O TPC-H possui oito tabelas, que são apresentadas na tabela 5.1 assim como o

número de registos que cada uma possui para 1GB e 10GB e cujo esquema se

apresenta na figura 5.1.

Tabela 5.1 - Caracterização das tabelas do TPC-H para 1GB e 10GB

1GB 10GB

Nation 25 25

Region 5 5

Part 200 000 2 000 000

Supplier 10 000 100 000

Partsupp 800 000 8 000 000

Customer 150 000 1 500 000


34

Orders 1 500 000 15 000 000

Lineitem 6 001 215 59 986 052

TOTAL 8 661 245 86 586 082

Figura 5.1 – Esquema da base de dados do TPC-H

O TPC-H tem vinte e duas pesquisas que designamos Q1 a Q22, as quais explicamos

de seguida:

Q1 – volume de negócios que foi facturado e enviado;

Q2 – procura que fornecedor deve ser seleccionado para fazer o pedido de

uma determinada peça numa determinada região;

Q3 – retorna as 10 encomendas com o valor mais alto que não foram enviadas;

Q4 – determina se o sistema de ordem de prioridade está a funcionar

correctamente e dá uma avaliação da satisfação do cliente;

Q5 – lista o volume de receitas feito através de fornecedores locais;


35

Q6 – quantifica quanto aumentam as receitas se se eliminar descontos de uma

determinada empresa num determinado intervalo percentual num dado

intervalo de tempo;

Q7 – determina o valor de mercadorias enviadas entre determinadas nações

para ajudar na renegociação de contractos de transporte;

Q8 – determina como o mercado de uma determinada nação dentro de uma

determinada região se alterou em dois anos em relação a uma determinada

peça;

Q9 – determina o lucro feito com determinada linha de peças dividido por

nação fornecedora e ano;

Q10 – identifica clientes que possam ter problemas com as peças que lhes

foram enviadas;

Q11 – procura os fornecedores mais importantes de determinada nação;

Q12 – determina se seleccionar o tipo de envio mais barato afecta

negativamente os pedidos com ordem de prioridade urgente fazendo com que

mais clientes recebam as suas encomendas depois da data definida;

Q13 – faz a relação entre os clientes e o tamanho das suas encomendas;

Q14 – monitoriza a resposta do mercado a promoções como por exemplo

anúncios de televisão ou campanhas especiais;

Q15 – identifica o melhor fornecedor para que este possa ser recompensado

através de mais negócios ou um reconhecimento especial;

Q16 – procura os fornecedores que podem fornecer peças com determinados

atributos. Isto pode ser utilizado, por exemplo, para determinar se um

fornecedor que é muito procurado tem número suficiente de peças disponíveis;

Q17 – calcula a receita média anual que seria perdida se não se pudesse fazer

pequenas encomendas de determinadas peças;

Q18 – classifica os clientes tendo como critério o facto de terem feito grandes

encomendas;


36

Q19 – receita bruta com desconto de peças seleccionadas e tratadas de

maneira particular;

Q20 – identifica fornecedores que tenham peças seleccionadas que possam ser

candidatas a uma oferta promocional;

Q21 – identifica os fornecedores que não seriam capazes de enviar as peças

pretendidas em tempo útil;

Q22 – identifica áreas onde existem clientes propensos a fazer compras.

De referir que a pesquisa Q20 não foi utilizada devido a problemas na sua execução

no TokuDB.

No anexo C apresentamos como gerar os dados para carregar as tabelas com o DBgen

e como gerar as pesquisas com o Qgen e no anexo D o código de todas as pesquisas.

5.2 Características a avaliar

Para se poder comparar os diversos sistemas é necessário definir as características que

se pretende avaliar.

As características que se pretende avaliar são:

O tempo que cada sistema demora a carregar dados para a base dados;

O tempo que demora a executar uma consulta à base de dados;

O interface, isto é, se é de fácil utilização;

Existência de manuais de utilização;

Existência de fóruns onde se possam esclarecer eventuais dúvidas;

A análise ao resultado da avaliação destas características será feita no capítulo de

avaliação experimental.

No capítulo seguinte descrevemos as dificuldades encontradas ao longo da execução

deste projecto e as soluções encontradas para ultrapassar essas mesmas dificuldades.


37

6 Principais dificuldades

No início deste projecto foi decidido utilizar uma máquina virtual com o sistema

operativo Ubuntu 12.04 LTS mas à medida que fomos desenvolvendo o projecto

apercebemo-nos que não seria possível executá-lo numa máquina virtual devido aos

requisitos de memória do VoltDB e do NuoDB, por isso tivemos que solicitar ao

presidente do DEIS que disponibilizasse um computador com mais memória RAM

para podermos testar um maior número de sistemas, o qual nos foi cedido

prontamente.

O Ubuntu 12.04 LTS já tem no seu repositório de aplicações o MySQL pronto a ser

instalado, no entanto não é a versão mais recente. Após fazermos o download da

versão mais recente que existia no site do MySQL procedemos à sua instalação mas

aparecia sempre o aviso de que existia uma versão no repositório do Ubuntu e que era

essa que devia ser instalada. Percebemos com isso que não bastava fazer uma

instalação simples para conseguir utilizar a versão mais recente do MySQL. Após

alguma pesquisa encontramos a resolução do problema em

http://www.peterchen.net/2013/02/20/en-how-to-install-mysql-5-6-on-ubuntu-12-04-

precise/ que consistia em remover completamente a versão do MySQL que o Ubuntu

tem no seu repositório, mover a pasta my.cnf da localização utilizada por defeito pelo

MySQL para uma nova localização e colocar o novo scrip de inicialização do MySQL

que está incluído na versão recente, que fizemos download do site, na directoria

correcta para que o MySQL funcionasse correctamente.

Outro sistema testado foi o Drizzle e para procedermos à sua instalação recorremos à

documentação disponibilizada no site deste sistema. Mas de cada vez que seguíamos

os passos indicados não obtinhamos uma instalação correcta, chegando por isso à

conclusão de que esta documentação é pouco clara. Conseguimos instalar

correctamente o Drizzle através dos passos disponibilizados em

http://devzone.zend.com/1504/getting-started-with-drizzle-and-php/ e através da

instalação de pacotes extras que foram sendo pedidos ao longo da instalação.

No VoltDB foram várias as dificuldades encontradas:

Os dados para carregar as tabelas estão armazenados em vários ficheiros,

sendo que a separação de cada campo é feita através do caracter “|”. No

http://www.peterchen.net/2013/02/20/en-how-to-install-mysql-5-6-on-ubuntu-12-04-precise/

http://www.peterchen.net/2013/02/20/en-how-to-install-mysql-5-6-on-ubuntu-12-04-precise/

http://devzone.zend.com/1504/getting-started-with-drizzle-and-php/


38

VoltDB esse caracter só é utilizado para separar os campos de cada linha da

tabela e para saber que chegou ao final de uma linha e se vai iniciar outra basta

que seja carregada a tecla “Enter” (\n na programação). No entanto os

ficheiros gerados pelo DBgen do TPC-H têm o caracter “|” também para

separar uma linha da outra, por isso foi necessário criar um script que retirasse

esse caracter do fim da cada linha, para se fazer o carregamento dos dados

correctamente no VoltDB, uma vez que não é possível retirar o caracter

manualmente pois existem tabelas que contêm milhões de registos. O script

utilizado é apresentado no anexo E.1.

O VoltDB não suporta o tipo de dados date, apenas o tipo de dados timestamp.

Não tem no entanto uma função que permita a transformação do formato date

em timestamp e por isso foi necessário criar um script que fizesse essa

transformação desses dados contidos nas tabelas Orders e Lineitem. O script é

apresentado no anexo E.2.

O principal problema encontrado no VoltDB foram as diversas limitações ao

nível da linguagem SQL tendo sido necessário reescrever algumas pesquisas e

não tendo sido possível sequer executar todas as pesquisas.

Alguns dos sistemas não indicam em quanto tempo foi executada cada pesquisa o que

se tornou complicado para registar os tempos de execução de cada pesquisa. A

solução encontrada para este problema foi criar uma tabela temporária com os campos

query (onde se colocava o número da pesquisa), data (colocava-se a data e hora do

sistema) e obs (onde se colocava se estava a iniciar ou terminar a execução da

pesquisa). E antes de cada pesquisa e após cada pesquisa inseria-se um registo nesta

tabela sendo possível determinar a que hora iniciou e terminou a execução das

pesquisas.

No próximo capítulo será feita a análise das características técnicas de cada base de

dados bem como a análise dos resultados obtidos após testarmos as bases de dados.


39

7 Avaliação Experimental

Nesta secção apresentamos os resultados experimentais obtidos nos testes realizados

no MySQL e nos sistemas NewSQL (Drizzle, TokuDB, NuoDB, VoltDB e StormDB)

e uma fazemos a análise desses mesmos resultados. A avaliação experimental foi

realizada para dois conjuntos de dados, isto é, bases de dados com tamanho de 1GB e

10GB.

Os testes foram realizados para cada uma das bases de dados através da execução de

três sequências de pesquisas (S1 a S3) geradas no random.org:

S1 – Q9, Q18, Q8, Q5, Q21, Q2, Q14, Q16, Q13, Q12, Q15, Q19, Q3, Q7,

Q22, Q10, Q11, Q1, Q6, Q17, Q4;

S2 – Q18, Q15, Q21, Q8, Q6, Q14, Q2, Q22, Q10, Q12, Q17, Q1, Q13, Q16,

Q3, Q11, Q19, Q9, Q7, Q5, Q4;

S3 – Q14, Q8, Q13, Q5, Q11, Q22, Q4, Q10, Q1, Q9, Q6, Q3, Q15, Q12, Q2,

Q21, Q18, Q16, Q7, Q17, Q19;

Deste modo pretendemos evitar possíveis efeitos de armazenamento em cache dos

resultados das pesquisas, executando três vezes cada pesquisa de forma aleatória e

obtendo depois o valor médio da execução de cada uma. De referir que foram

utilizadas todas as vinte e duas pesquisas do TPC-H com excepção da pesquisa Q20

que foi retirada dos testes devido a alguns problemas na sua execução no TokuDB

pois para uma base de dados de 1GB passados dois dias a executar a pesquisa, ainda

não tínhamos obtido qualquer resultado.

Todos os valores aqui apresentados estão em segundos.

7.1 Comparação de características técnicas

Para além de fazermos a avaliação experimental de cada sistema NewSQL fizemos

também uma comparação de algumas características técnicas desses sistemas que

apresentamos na tabela 7.1. As características pretendidas foram escolhidas do site

http://vschart.com/compare/drizzle-database/vs/mysql.

http://vschart.com/compare/drizzle-database/vs/mysql


40

Tabela 7.1 – Comparação das características técnicas dos Sistemas NewSQL

Drizzle TokuDB NuoDB VoltDB StormDB

Modelo da

Base de Dados Relacional Relacional Relacional Relacional Relacional

Linguagem

para

pesquisas

SQL SQL SQL SQL/Rest SQL

Modelo de

Integridade MVCC

ACID /

MVCC

ACID /

MVCC ACID MVCC

ACID Sim Sim Sim Sim Sim

Transacções Sim Sim Sim Sim Sim

Escalabilidade

Horizontal Sim Sim Sim Sim Sim

Sharding Sim Não Não Sim Sim

Arquitectura

Shared-

nothing

Sim Desconhecido Não Sim Sim

Memória

mínima 2GB 1GB 4GB 4GB Cloud

Open source Sim Sim Sim Sim Não

Fácil de

utilizar Sim Sim Sim +/- Sim

Manual de

utilização

Sim mas

pouco

esclarecedor

Sim Sim Sim Sim

Fóruns de

dúvidas Não Não Sim Sim Não


41

Nesta tabela é possível ver algumas das características técnicas que se pretende que os

sistemas testados tenham.

A escalabilidade horizontal é a capacidade de ligar várias unidades de hardware ou

software entre si, tais como servidores, para que funcionem como uma única unidade

lógica.

Sharding é a possibilidade de dividir a base de dados por vários computadores sem

afectar no entanto a consistência dos dados.

Arquitectura shared-nothing é uma arquitectura de computação distribuída, em que

cada nó é independente e auto-suficiente. Não há partilha de memória e de

armazenamento em disco entre cada um dos nós existentes.

MVCC é um método de controlo de concorrência normalmente utilizado em sistemas

de gestão de bases de dados que proporciona simultaneamente acesso às bases de

dados e às linguagens de programação para implementação de memória transaccional.

A linguagem REST (Representational State Transfer) é uma técnica de engenharia de

software para sistemas hipermédia distribuídos como a World Wide Web. O termo

começou a ser utilizado em 2000, na tese de doutoramento de Roy Fielding. Este

termo originalmente referia-se a um conjunto de princípios de arquitectura, na

actualidade utiliza-se num sentido mais amplo para descrever qualquer interface web

simples que utiliza XML e HTTP (ou YAML, JSON, ou texto puro), sem as

abstracções adicionais dos protocolos baseados em padrões de trocas de mensagem

como o protocolo de serviços web SOAP.

Através da análise desta tabela é possível verificar que todos os sistemas cumprem

quanto ao facto de serem uma base de dados relacional e terem todas as garantias

ACID e têm também a escalabilidade horizontal tal como as bases de dados NoSQL,

que era o que se pretendia ao introduzir estes novos sistemas de bases de dados no

mercado. Na avaliação experimental analisamos se realmente os sistemas NewSQL

têm maior capacidade de processamento em relação às tradicionais bases de dados

relacionais.

7.2 Bases de dados com 1GB

Nesta secção apresentamos todos os gráficos com os resultados da avaliação

experimental para uma base de dados com 1GB.

http://pt.wikipedia.org/wiki/Hiperm%C3%ADdia

http://pt.wikipedia.org/wiki/Internet

http://pt.wikipedia.org/wiki/2000

http://pt.wikipedia.org/wiki/Roy_Fielding


42

Figura 7.1 – Tempo de criação das tabelas para 1GB

Neste gráfico não é apresentado o VoltDB porque para criar as tabelas é necessário

criar um ficheiro .sql que depois é compilado e utilizado para iniciar o servidor do

VoltDB, assim não foi possivel contabilizar o tempo que demora a criar cada tabela

pois são todas criadas ao mesmo tempo.

É possível verificar que quando não é necessário muita capacidade de processamento,

o que acontece a criar tabelas, o MySQL e o TokuDB são os que demoram mais a

fazê-lo por serem os dois sistemas mais semelhantes entre si.

Tabela 7.2 – Tempos de carregamento de dados para 1GB em segundos

Nation Region Part Supplier Partsupp Customer Orders Lineitem

MySQL 0.19 0.06 7.74 2.07 32.39 8.16 49.85 248.54

Drizzle 0.05 0.05 4.98 0.2 33.84 6.25 58.21 312.34

TokuDB 0.05 0.22 2.11 0.32 8.34 2.04 13.01 66.08

NuoDB 1.5 0.34 5.4 0.63 18.44 4.06 44.12 238.94

VoltDB 0.16 0.19 58.7 2.99 256.34 50.71 506.89 2148.07

StormDB 0.65 0.62 21.42 1.89 90 13.54 128.78 523.6


43

Tabela 7.3 – Tempos obtidos para a criação de chaves primárias para 1GB


MySQL 0.95 0.78 11.09 4.3 76.55 13.41 87.27 718.49

Drizzle 1.11 1.36 19.05 3.68 191.97 27.07 276.64 1178.75

TokuDB 1.21 0.89 7.31 1.6 52.95 9.39 79.11 366.01

NuoDB 0.01 0.02 0.79 0.04 3.36 0.59 6.07 25.61

StormDB 0.63 0.66 0.57 0.57 0.77 0.5 1.28 3.2

Tabela 7.4 – Tempos obtidos para a criação de chaves forasteiras para 1GB

Nation Supplier Partsupp Customer Orders Lineitem

MySQL 1.48 5.30 59.82 15.86 192.98 3732.32

Drizzle 0.21 0.55 56.58 4.48 75.86 2534.74

TokuDB 1.42 1.95 53.4 9.51 80.34 367.86

Os valores anteriores estão apresentados na forma de tabela porque têm tanto valores

muito pequenos como valores muito grandes e isso dificulta a visualização desses

mesmos valores na forma de gráfico.

Como é possível ver as operações que demoram mais tempo a ser realizadas são as

que são efectuadas nas tabelas Partsupp, Orders e Lineitem. Isto deve-se ao facto de

serem as tabelas que contêm mais registos.

Na tabela das chaves primárias (PK) não consta o VoltDB porque estas são definidas

ao mesmo tempo que se criam as tabelas na compilação do ficheiro .sql que é

necessário compilar para obter um ficheiro .jar para se poder iniciar o servidor do

VoltDB.

Em relação às chaves forasteiras (FK) só possível defini-las para o MySQL, Drizzle e

TokuDB. Ao analisar a documentação disponibilizada tanto pelo NuoDB como pelo

VoltDB é possível verificar que estes dois sistemas não suportam a utilização de FK,

o que é uma limitação destes sistemas.


44

Em relação ao StormDB não foi possível definir as FK porque os campos têm nomes

diferentes, isto é, o nome do campo que pretendemos que seja FK é diferente do

campo da tabela que estamos a referenciar. Por exemplo para a tabela Nation, o

campo n_regionkey é FK, fazendo referência ao campo r_regionkey da tabela Region.

Ao fazermos o comando necessário para definir a FK:

ALTER TABLE nation ADD CONSTRAINT nation_fk FOREIGN KEY

(n_regionkey) REFERENCES region (r_regionkey) MATCH FULL;

Obtivemos o erro que é mostrado na figura 7.2.

Figura 7.2 – Erro ao definir uma chave forasteira no StormDB

Assim fizemos a experiência de criar uma tabela que continha apenas um campo

designado r_regionkey, inserimos alguns valores e definimos FK e já foi possível

defini-la como mostra a figura 7.3.

Figura 7.3 – Definição correcta de uma chave forasteira no StormDB


45

Com esta experiência verificamos que o StormDB tem também uma limitação ao

nível da definição de FK, ou seja, se o nome do campo não for igual nas duas tabelas

não é possível definir FK.

Analisando as tabelas anteriores é possível ver que a inserir dados o sistema que

demora mais tempo é o VoltDB devido a ser um sistema in-memory, ou seja, faz

muita utilização da memória do computador o que faz com que à medida que o

tamanho da base de dados vai aumento o sistema começa a utilizar mais memória e

torna-se mais lento e pode levar mesmo à utilização total da memória disponível

fazendo com que o computador deixe de responder e seja necessário reiniciá-lo.

Para definir as PK o sistema que demorou mais foi o Drizzle devido a ter sido

desenhado para privilegiar a escalabilidade, executando várias tarefas em simultâneo.

Esta base de dados apesar de ter 1GB não é um tamanho muito grande e definir

chaves primárias em cada tabela não necessita de várias transacções feitas em

simultâneo.

Já na definição das FK o sistema que demorou mais tempo foi o MySQL devido a ser

preciso uma maior capacidade processamento já que para definir FK é necessário

comparar as tabelas linha a linha para verificar se os valores inseridos na tabela onde

se quer definir a FK estão correctos.

7.2.1 MySQL vs Drizzle vs TokuDB

Nestes sistemas foi possível executar a totalidade das pesquisas permitindo uma

comparação mais detalhada entre eles. Em seguida apresentamos os gráficos com os

tempos de execução para cada sequência, o total do tempo de execução após executar

as três sequências e ainda a média do tempo de execução e o desvio padrão. O desvio

padrão mostra-nos a variação que existe em relação à média, sendo que um desvio

padrão com um valor baixo significa que todos os valores estão próximos do valor da

média e um valor alto significa valores dispersos que variam muito entre si.


46

Figura 7.4 – Média dos tempos de execução para 1GB após executar as três

sequências

A pesquisa Q14 para o MySQL e para o Drizzle apresenta valores muito grandes o

que dificulta a correcta visualização do gráfico por haver também valores muito

pequenos assim não foram colocados no gráfico os resultados desta pesquisa. A média

obtida foi de 219, 271 e 3 segundos para o MySQL, Drizzle e TokuDB,

respectivamente.

Analisando o gráfico anterior é possível verificar que as pesquisas mais demoradas

são as pesquisas Q9, Q10, Q13, Q14, Q18 e Q21, pois são aquelas que pesquisam

informação em mais tabelas e que necessitam de fazer cálculos para chegar a um

resultado final. As restantes pesquisas vão pesquisar num menor número de tabelas e

algumas têm de fazer a pesquisa apenas num determinado intervalo de tempo, o que

leva a que a quantidade de informação a pesquisar seja menor.

Os valores do desvio padrão são apresentados em tabela porque alguns valores são tão

pequenos que no gráfico apareciam com o valor zero não sendo possível ver o

verdadeiro valor do desvio padrão para determinadas pesquisas.


47

Tabela 7.5 – Desvio padrão para 1GB

MySQL Drizzle TokuDB

Q1 0.08 0.88 0.23

Q2 0.74 0.04 0.33

Q3 0.68 0.03 0.18

Q4 0.10 0.10 1.42

Q5 0.96 0.05 1.53

Q6 0.03 0.02 0.01

Q7 0.28 0.03 1.25

Q8 1.00 0.15 0.53

Q9 41.72 9.43 1.22

Q10 6.19 0.11 1.64

Q11 0.06 0.01 0.22

Q12 0.05 0.06 0.21

Q13 4.54 0.64 0.58

Q14 5.32 0.37 0.20

Q15 0.06 0.24 0.21

Q16 0.11 0.44 0.11

Q17 0.02 0.06 0.33

Q18 4.48 2.00 0.30

Q19 0.06 0.10 0.26

Q21 4.80 0.03 0.47

Q22 0.01 0.03 0.26

Ao observarmos a tabela anterior é possível constatar que a pesquisa cujo resultado se

desvia mais do seu valor médio é a Q9 no MySQL e Drizzle e a Q10 no TokuDB. Na


48

primeira sequência a pesquisa a ser executada primeiro é a Q9 e isso influenciou o

valor do desvio padrão desta pesquisa no MySQL e no Drizzle pois é o valor obtido

nesta execução que influencia o valor de desvio padrão obtido. Apesar das pesquisas

terem sido executadas aleatoriamente para diminuir os efeitos dos dados que ficam em

cache acabam sempre por ficar dados em cache que podem ser úteis para as pesquisas

seguintes e é o que acontece com a pesquisa Q10 no TokuDB. Na primeira e segunda

sequência a pesquisa Q10 é executada após a pesquisa Q22 que utiliza apenas uma

das tabelas que são utilizadas na Q10 tendo por isso demorado mais alguns segundos

a ser executada que na terceira sequência, pois é executada logo após a pesquisa Q4,

sendo que esta pesquisa utiliza duas das tabelas utilizadas na Q10. Nesta pesquisa é

possível ver que se houver dados em cache que possam ser utilizados na pesquisa

seguinte isso afecta o tempo de execução ainda que seja só por um ou dois segundos

de diferença.

Figura 7.5 – Tempo total de execução de todas as sequências para 1GB

Considerando o tempo total de execução para o conjunto das três sequências é

possível verificar que o Drizzle é o que demora mais a executar todas as pesquisas,

seguido do MySQL com uma diferença de 187.52 segundos (3min 7.52seg) de

execução.

O mais rápido dos três é o TokuDB demorando apenas 904.98 segundos (15min

4.98seg) a executar todas as pesquisas. Assim tendo em consideração os resultados


49

experimentais é possível concluir que o TokuDB é mais rápido 47% que o MySQL e

52% mais rápido que o Drizzle a executar as sequências de pesquisas. Por outro lado

o Drizzle é 10% mais lento que o MySQL.

O Drizzle torna-se mais lento que o MySQL nas bases de dados de 1GB devido a ter

sido desenhado para privilegiar a escalabilidade, executando várias transacções em

simultâneo, o que não acontece neste conjunto de experiências. Nesta avaliação

experimental não se executaram várias transacções em simultâneo e um tamanho de

1GB ainda não é uma base de dados que se possa considerar de grande dimensão e

por isso o Drizzle acaba por ser mais lento.

Como foi referido na definição do TokuDB, este foi desenhado para conseguir

efectuar pesquisas mais rapidamente e para trabalhar com tabelas muito grandes.

Apesar de na base de dados de 1GB não haver tabelas muito grandes nota-se

claramente que mesmo assim o TokuDB conseguiu atingir o objectivo de ter uma

velocidade de execução superior aos restantes.

7.2.2 NuoDB

Nesta subsecção apresentamos os resultados do NuoDB. Estes não são apresentados

em conjunto com os sistemas anteriores porque não foi possível testar todas as

pesquisas. No NuoDB não foi possível obter resultados para as pesquisas Q1, Q2,

Q11, Q13, Q17 e Q19.

O NuoDB por ser um sistema novo ainda não tem implementado todas as

optimizações do MySQL na análise de subpesquisas. O que fez com que nas referidas

pesquisas não retornassem resultados pois todas elas, com excepção da pesquisa Q1,

têm subpesquisas, vão procurar a sua informação a várias tabelas e não limitam essa

informação a um intervalo de tempo, o que faz com que seja necessário procurar em

toda a tabela a informação pretendida. A pesquisa Q1 apesar de não ter subpesquisas

faz muitas operações aritméticas e vais procurar a informação pretendida na tabela

Lineitem, que é a tabela que contém mais registos.

Como não possível executar todas as pesquisas fazemos a comparação do NuoDB em

relação aos anteriores sistemas (MySQL, Drizzle, TokuDB) mas apenas com as

pesquisas que foram executadas no NuoDB.


50

Figura 7.6 - Média dos tempos de execução para 1GB após esxecutar as três

sequências (NuoDB MySQL, Drizzle e TokuDB)

Por termos obtido resultados muito elevados para as pesquisas Q14, Q15, Q18 e Q22

não foi possível colocar os seus valores no gráfico. A pesquisa Q14 foi devido ao

valor alcançado no MySQL e no Drizzle, as restantes foi devido aos valores no

NuoDB.

A Q14 teve de média 219, 271, 3 e 19 segundos; Q15 obteve uma média de 7, 11, 5 e

83792 segundos; Q18 tem uma média de 46, 35, 96 e 16085 segundos; por fim a Q22

tem uma média de 0.31, 0.35, 0.45 e 6794 segundos para o MySQL, Drizzle, TokuDB

e NuoDB respectivamente.

Tabela 7.6 – Desvio padrão para 1GB (NuoDB MySQL, Drizzle e TokuDB)

MySQL Drizzle TokuDB NuoDB

Q3 0.68 0.03 0.18 9.76

Q4 0.10 0.10 1.42 33.42

Q5 0.96 0.05 1.53 0.52

Q6 0.03 0.02 0.01 0.43

Q7 0.28 0.03 1.25 35.30

Q8 1.00 0.15 0.53 17.10

Q9 41.72 9.43 1.22 24.01


51

Q10 6.19 0.11 1.64 26.80

Q12 0.05 0.06 0.21 16.84

Q14 5.32 0.37 0.20 25.84

Q15 0.06 0.24 0.21 15741.37

Q16 0.11 0.44 0.11 26.65

Q18 4.48 2.00 0.30 538.03

Q21 4.80 0.03 0.47 32.33

Q22 0.01 0.03 0.26 470.17

Olhando para a tabela 7.6 é possível verificar que os valores do desvio padrão do

NuoDB são bastante altos para a maioria das pesquisas, o que significa que existe uma

grande variação entre os valores de execução das pesquisas em cada sequência. Isto

pode ser explicado em parte porque o NuoDB faz uma grande utilização da memória

do computador e quanto mais dados precisa pesquisar e tem em cache começa a

utilizar cada vez mais memória do computador o que torna a execução das pesquisas

mais lentas.

Figura 7.7 - Tempo total de execução de todas as sequências para 1GB (NuoDB

MySQL, Drizzle e TokuDB)

Devido ao elevado tempo de execução das pesquisas Q15, Q18 e Q22 o tempo total

de execução do NuoDB é também bastante elevado sendo mais lento 31344, 27439 e

64898 vezes que o MySQL, Drizzle e TokuDB, respectivamente, nas pesquisas

executadas.


52

Com estes resultados é possível concluir que o NuoDB ainda precisa ser melhorado a

nível de performance pois apenas executou as pesquisas mais simples e dessas

demorou bastante tempo em três pesquisas por serem talvez as mais complicadas que

conseguiu executar. Outro ponto que torna o NuoDB mais lento em relação aos outros

três sistemas é o significativo uso de memória, o que começa a tornar o computador

mais lento nas operações que tem de executar.

7.2.3 VoltDB

À semelhança do que aconteceu com o NuoDB também no VoltDB não foi possível

executar todas as pesquisas, embora por motivos diferentes. A linguagem SQL

utilizada pelo VoltDB está ainda muito longe de ser o SQL padrão e por isso tem

inúmeras limitações.

Em pesquisas que utilizassem mais de 6 tabelas dava erro e informava que era

necessário indicar um order join, figura 7.8. Essa indicação só pode ser feita através

de um procedimento em java. Na documentação do VoltDB explica como fazer esses

procedimentos e por isso decidimos fazer os procedimentos de maneira a ser possível

executar o maior número de pesquisas no VoltDB. No entanto sempre que

compilávamos o procedimento dava erro pois a ordem indicada não estava correcta e

assim não possível executar pesquisas com mais de 6 tabelas.

Figura 7.8 - Erro VoltDB, order join

Outra limitação é o facto de não suportar a condição having, figura 7.9.

Figura 7.9 – Erro VoltDB, condição having


53

Também se observou outra dificuldade tanto a criar vistas como com pesquisas que

contêm subpesquisas. Ao criar vistas, mesmo seguindo a documentação do VoltDB

dava erro e o mesmo acontecia com as pesquisas com subpesquisas, figura 7.10.

Figura 7.10 – Erro VoltDB, criar vistas e pesquisas com subpesquisas

Outra situação é facto de quando está a efectuar uma pesquisa só ter espaço de

100MB para criar uma tabela temporária, sendo que se esse espaço for excedido dá

erro, figura 7.11.

Figura 7.11 – Erro VoltDB, espaço para tabela temporária excedido

Assim com todas estas limitações só foi possível executar as pesquisas Q1, Q4, Q6,

Q12, Q14 e Q16.

Figura 7.12 – Média do tempo de execução para 1GB após executar as três

sequências (VoltDB MySQL, Drizzle e TokuDB)

Por termos obtido resultados muito elevados para as pesquisas Q14 no MySQL e no

Drizzle, este não foram colocados no gráfico. A pesquisa Q14 teve de média 219, 271,

3 e 1 segundos para o MySQL, Drizzle, TokuDB e VoltDB respectivamente.


54

Figura 7.13 – Desvio padrão para 1GB (VoltDB MySQL, Drizzle e TokuDB)

Figura 7.14 – Tempo total de execução para 1GB (VoltDB MySQL, Drizzle e

TokuDB)

Fazendo a análise dos gráficos anteriores é possível verificar que se o VoltDB

melhorar a utilização do SQL, isto é, se se aproximar mais do SQL padrão será um

bom sistema NewSQL pois tendo em conta as poucas pesquisas que foi possível

executar mesmo assim obteve melhores resultados que os restantes sistemas, sendo

93%, 95% e 45% mas rápido que o MySQL, Drizzle e TokuDB, respectivamente, nas

pesquisas executadas. E também se nota que os tempos obtidos para cada sequência

andam sempre próximos da média pois os valores de desvio padrão são muito baixos,

isto significa que seja qual for a ordem de execução das pesquisas demora quase

sempre o mesmo tempo a executar as pesquisas.


55

7.2.4 StormDB

O StormDB é uma base de dados na Cloud mas como foi a única na Cloud que

testámos iremos compará-la com o MySQL, Drizzle e TokuDB até por uma questão

de perceber se é mais eficiente ter uma base de dados na Cloud ou no nosso

computador.

À primeira vista o StormDB começa logo a perder em relação aos outros sistemas

porque só executou pesquisas simples, que fossem limitadas a um intervalo de tempo

e que procurassem a informação necessária, no máximo em quatro tabelas das oito

existentes. Sendo que sempre que tentámos executar uma das restantes pesquisas deu

erro, figura 7.15.

Figura 7.15 – Erro StormDB

Devido a este erro só foi possível executar as pesquisas Q1, Q4, Q6, Q11, Q12, Q13,

Q14, Q15, Q16, Q18 e Q22.

Figura 7.16 – Média do tempo de execução para 1GB após executar as três

sequências (StormDB MySQL, Drizzle e TokuDB)


56

Por termos obtido resultados muito elevados para as pesquisas Q14 no MySQL e no

Drizzle, este não foram colocados no gráfico. A pesquisa Q14 teve de média 219, 271,

3 e 26 segundos para o MySQL, Drizzle, TokuDB e StormDB respectivamente.

Figura 7.17 – Desvio padrão para 1GB (StormDB MySQL, Drizzle e TokuDB)

Figura 7.18 – Tempo total de execução para 1GB (StormDB MySQL, Drizzle e

TokuDB)

Também neste sistema, mesmo não tendo executado todas as pesquisas, obteve-se

melhores resultados, tendo sido 77%, 79% e 43% mais rápido que o MySQL, Drizzle

e TokuDB, respectivamente. Assim se o sistema for melhorado por forma a permitir a

execução de pesquisas mais complicados seria uma possível solução para quem


57

pretende grande escalabilidade e ao mesmo tempo capacidade de processamento, no

entanto é preciso ter em conta que a utilização deste sistema tem custos associados.

7.3 Bases de dados de com 10GB

Para a base de dados de 10GB só foi possível testar o MySQL, Drizzle, TokuDB e

StormDB devido a limitações de memória do computador utilizado. O NuoDB e o

VoltDB são dois sistemas que utilizam muito a memória do computador e verificou-se

que quanto maior a base de dados mais memória do computador era utilizada.

Estávamos ainda na fase de carregamento de dados para estes dois sistemas e a

utilização de memória já estava praticamente no máximo, como se pode ver na figura

7.19, não sendo sequer possível terminar o carregamento dos dados tanto para um

sistema como para outro pois o computador acabou por deixar de responder e teve de

ser reiniciado para funcionar novamente.

Figura 7.19 – Utilização de memória pelo NuoDB e VoltDB

Figura 7.20 – Tempo de criação das tabelas para 10GB


58

Tabela 7.7 – Tempo de carregamento de dados para 10GB


MySQL 0.27 0.07 54.30 5.21 275.56 54.44 411.46 1935.52

Drizzle 0.07 0.04 55.27 1.92 293.70 58.69 501.62 2349.74

TokuDB 0.18 0.20 11.32 0.81 52.79 10.15 82.86 413.44

StormDB 0.68 0.67 690.36 23.30 4321.41 1087.75 4264.00 8947.41

Tabela 7.8 – Tempos obtidos para a criação de chaves primárias para 10GB


MySQL 1.37 3.16 162.46 9.49 878.57 134.04 1243.90 6656.58

Drizzle 0.17 0.58 63.08 5.00 1217.49 63.09 2834.16 28787.11

TokuDB 1.02 0.92 41.94 5.04 358.44 56.87 515.75 2842.49

StormDB 0.61 0.54 1.09 0.77 4.06 0.84 5.55 20.64

Tabela 7.9 – Tempos obtidos para a criação de chaves forasteiras para 10GB

Nation Supplier Partsupp Customer Orders Lineitem

MySQL 4.53 9.51 1267.18 132.37 7521.12 83253.01

Drizzle 1.80 1601.00 60.89 1332.07 9068.99 154731.66

TokuDB 2.78 4.88 341.66 57.84 520.77 2895.35

Para as tabelas de 10GB os tempos de execução aumentam consideravelmente mas

mantêm-se a situação das operações demorarem mais tempo a executar nas tabelas

Partsupp, Orders e Lineitem porque mais uma vez são as tabelas que têm mais

registos.


59

7.3.1 MySQL vs Drizzle vs TokuDB

Figura 7.21 – Média dos tempos de execução para 10GB

A média da pesquisa Q9 é de 35276, 25500 e de 590; já a média da pesquisa Q14 é de

159103, 75704 e de 65 para MySQL, Drizzle e TokuDB, respectivamente. Estes

valores não são apresentados no gráfico porque os resultados para MySQL e Drizzle

são muito elevados e iam tornar o gráfico pouco perceptível.

Nesta base de dados, por já ter uma dimensão considerável, a pesquisa Q3 que apesar

de ir procurar a sua informação a apenas três das oito tabelas mas que tem de fazer

cálculos para chegar ao resultado final já demora um tempo considerável a executar. E

o mesmo acontece com a Q7 e Q8 que apesar de pesquisarem num dado intervalo de

datas, ainda é um intervalo considerável (dois anos), pesquisam informação em cinco

e sete tabelas respectivamente e necessitam de fazer cálculos complexos para obter o

resultado final.

As pesquisas Q9, Q10, Q13, Q14 e Q18 mantêm nesta base de dados os seus valores

elevados devido ao aumento da quantidade de informação e porque são pesquisas que

não limitam a sua procura a um intervalo de tempo, utilizando toda a informação

contida nas tabelas.


60

Tabela 7.10 – Desvio padrão para 10GB

MySQL Drizzle TokuDB

Q1 4 18 8

Q2 55 31 8

Q3 2165 2209 19

Q4 21 18 18

Q5 360 263 144

Q6 4 46 6

Q7 1207 3385 15

Q8 265 738 177

Q9 11788 290 27

Q10 435 1987 134

Q11 1 59 9

Q12 4 44 14

Q13 228 197 18

Q14 14182 6163 11

Q15 12 8 7

Q16 65 6 1

Q17 63 32 33

Q18 43 99 11

Q19 179 145 14

Q21 10 53 2

Q22 5 19 4

Ao contrário do que que acontece com as bases de dados de 1GB que não são as

pesquisas mais demoradas que apresentam um maior desvio padrão, nas bases de

10GB é isso que acontece. Tanto para o MySQL como para o Drizzle a pesquisa que


61

mais tempo demora a ser executada é a Q14, já no TokuDB a pesquisa que demora

mais tempo na sua execução é a Q8. Por serem pesquisas demoradas e por nesta base

de dados as tabelas já conterem bastante informação, o tempo que estas pesquisas

demoram executar varia um pouco de sequência para sequência, sendo também

influenciadas pelos dados que possam estar em cache das pesquisas executadas

anteriormente.

Figura 7.22 – Tempo total de execução para 10GB

Com base nos resultados experimentais é possível concluir que quando se aumenta a

capacidade de armazenamento das bases de dados de 1GB para 10GB o MySQL

torna-se mais lento em relação às bases de dados NewSQL testadas, o que significa

que o MySQL apesar de ter capacidade de armazenamento perde capacidade de

desempenho em bases de dados de grande dimensão.

Tal como já foi referido anteriormente, o Drizzle privilegia escalabilidade e esse é um

factor que se mostra decisivo numa base de dados com um tamanho de 10GB, que se

pode considerar de dimensão considerável, fazendo com que o Drizzle em relação ao

MySQL tenha uma melhoria de 39%.

Na base de dados de 10GB é possível ver ainda melhor a capacidade do TokuDB

fazer as suas pesquisas mais rapidamente. Pois nesta base de dados já temos tabelas

com um tamanho considerável e é possível verificar que o TokuDB foi realmente

projectado para ser mais rápido que os outros sistemas uma vez que nestas bases de


62

dados o TokuDB destaca-se ainda mais, com uma melhoria de 95% em relação ao

MySQL e 92% em relação ao Drizzle.

Também é possível concluir que o aumento da dimensão da base de dados leva a que

demore muito mais tempo a execução das pesquisas. Apesar da dimensão destas bases

de dados ser dez vezes maior que as anteriores, o aumento do tempo de execução não

é proporcional pois aumenta 391 vezes, 213 vezes e 35 vezes para o MySQL, Drizzle

e TokuDB respectivamente. Assim verifica-se que a base de dados menos afectada

pelo aumento da dimensão foi o TokuDB que continuou a ter um melhor desempenho

em relação às outras bases de dados.

7.3.2 StormDB

Figura 7.23 - Tempo total de execução para 10GB (StormDB MySQL, Drizzle e

TokuDB)

A média da pesquisa Q14 é de 159103, 75704, 65 e de251 para MySQL, Drizzle,

TokuDB e StormDB, respectivamente.

Figura 7.24 – Desvio padrão para 10GB (StormDB MySQL, Drizzle e TokuDB)


63

Figura 7.25 – Tempo total de execução para 10GB (StormDB MySQL, Drizzle e

TokuDB)

Apesar de não ter executado as pesquisas todas quando comparado com outros

sistemas relativamente às pesquisas que executou nota-se que este sistema é mais

rápido na execução das mesmas. Sendo assim basta que melhore o problema de não

executar determinadas pesquisas e é um bom sistema para utilizar em qualquer

organização.

No capítulo seguinte mostramos as conclusões retiradas com a avaliação feita a cada

sistema e também abordamos um possível trabalhar para desenvolver no futuro.


64


65

8 Conclusões e trabalho futuro

Este trabalho permitiu concluir que as bases de dados NewSQL são as mais indicadas

para solucionar o problema de falta de capacidade de armazenamento e

processamento, pois seguem o modelo relacional, utilizam linguagem SQL e têm

todas as garantias ACID para que os dados contidos nas bases de dados estejam

consistentes.

Foram testados os sistemas NewSQL: Drizzle, TokuDB, NuoDB, VoltDB e

StormDB. Os resultados dos testes mostram que existem situações em que alguns

sistemas obtêm melhores resultados.

Se não se pode gastar dinheiro num bom computador que tenha bastante memória

RAM, o VoltDB e o NuoDB não são os sistemas indicados para esta situação. Pois,

ambos necessitam de muita memória e quanto maior for a base de dados mais

memória consomem. No caso de não terem muita memória disponível poderão levar a

que o computador deixe de funcionar.

O StormDB é uma base de dados na Cloud e por isso não é open source, é necessário

pagar pela sua utilização. Não conseguimos neste sistema testar todas as pesquisas

possíveis mas acreditamos que se o sistema for melhorado e começar a ser possível

testar todas as pesquisas é um bom sistema. Pois nas pesquisas que executou foi

melhor que os restantes sistemas tanto na base de dados de 1GB como na base de

dados de 10GB.

No entanto se pretendemos ter um sistema completamente open source em que os

dados fiquem armazenados no nosso próprio computador, temos duas opções o

Drizzle e o TokuDB. No entanto, o TokuDB é bastante melhor que o Drizzle pois

obteve resultados melhores tanto na base de dados de 1GB como na de 10GB. O

Drizzle nos testes executados demonstrou ser um sistema preparado para bases de

dados de grande dimensão, pois para as bases de dados de 1GB não teve tão bom

desempenho como nas bases de dados de 10GB.

Também foi possível concluir que mesmo executando as pesquisas aleatoriamente

acabam por ficar dados em cache que influenciam a execução da pesquisa seguinte,

no entanto os efeitos observados são mínimos.


66

Assim é possível concluir que dos sistemas utilizados o que tem melhor performance

e reage melhor ao aumento do tamanho da base de dados é o TokuDB. Pois, neste

sistema é possível executar todas as pesquisas. Nas bases de dados de 1GB o TokuDB

é mais rápido 47% que o MySQL e 52% mais rápido que o Drizzle, e nas bases de

dados de 10GB o TokuDB destaca-se ainda mais, com uma melhoria de 95% em

relação ao MySQL e 92% em relação ao Drizzle.

Neste projecto abordámos apenas as bases de dados NewSQL mas, como foi escrito

ao longo deste relatório, existem também os novos sistemas NoSQL que pretendem

dar escalabilidade às bases de dados e capacidade de processamento, não garantindo

no entanto que os dados que a base de dados contém sejam consistentes. Deste modo

propomos para um trabalho futuro testar as bases de dados NoSQL e fazer a

comparação dos resultados com as bases de dados NewSQL para avaliarmos qual

fornece melhor resposta à falta de capacidade de armazenamento e processamento.

Bases de Dados NewSQL Referências

67

Referências

451 Group (2012) NoSQL, NewSQL, Big Data… Total Data – The Future of

Entreprise Data Management. Consultado em 24-03-2013, no site

http://nosqlroadshow.com/dl/NoSQL-Road-Show/slides/NoSQL-

Basel/mattNosqlRoadshowBasel.pdf

Aslett, Matthew (2011) What we talk about whe we talk about NewSQL. Consultado

em 25 de Fevereiro de 2013, no site

http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-

about-when-we-talk-about-newsql/

Aslett, Matthew (2011) NoSQL, NewSQL and Beyond: The answer to SPRAINed

relational databases. Consultado em 24 de Março de 2013, no site

http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-

and-beyond/

Autopia Blog (2011) Cellphone Networks and the Future of Traffic. Consultado em

10 de Novembro de 2013, no site http://www.wired.com/autopia/2011/03/cell-phone-

networks-and-the-future-of-traffic/

Big Data in 2020 (2012) Consultado em 22 de Novembro de 2013, no site

http://www.emc.com/leadership/digital-universe/iview/big-data-2020.htm

Caldeira, Teresa (2006). Bases de Dados. Consultado em 8 de Novembro de 2013, no

site http://docentes.esa.ipcb.pt/tmlc/PGSIG-BD.pdf

Carriço, José António (1996) Desenho de Bases de Dados – CTI (Centro de

Tecnologias de Informação, Lda)

Chamberlin, Donald D. and Boyce Raymond F.. 1974. SEQUEL: A structured

English query language. In Proceedings of the 1974 ACM SIGFIDET workshop on

Data description, access and control (now SIGMOD)). ACM, New York, NY, USA,

249-264.

Codd, E. F. (Junho de 1970) A Relational Model of Data for Large Shared Banks.

Communications of ACM13, 6 (June 1970), 377-387. Doi=10.1145/362384.362685.

DB-Engines Ranking (2013) Consultado em 11 de Novembro de 2013, no site

http://db-engines.com/en/ranking

Drizzle Documentation (2010). Consultado em 3 de Outubro de 2013, no site

http://docs.drizzle.org/index.html

http://nosqlroadshow.com/dl/NoSQL-Road-Show/slides/NoSQL-Basel/mattNosqlRoadshowBasel.pdf

http://nosqlroadshow.com/dl/NoSQL-Road-Show/slides/NoSQL-Basel/mattNosqlRoadshowBasel.pdf

http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/


http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/


http://www.wired.com/autopia/2011/03/cell-phone-networks-and-the-future-of-traffic/

http://www.wired.com/autopia/2011/03/cell-phone-networks-and-the-future-of-traffic/

http://www.emc.com/leadership/digital-universe/iview/big-data-2020.htm

http://docentes.esa.ipcb.pt/tmlc/PGSIG-BD.pdf




68

Facebook Statistics (2013) Consultado em 10 de Novembro de 2013, no site

http://www.statisticbrain.com/facebook-statistics/

Gantz, John & Reinsel, David (2011). Extracting value from chaos. Consultado em

06-03-2012, no site http://www.emc.com/collateral/analyst-reports/idc-extracting-

value-from-chaos-ar.pdf

Getting Started with Drizzle and PHP (2009). Consultado em 3 de Outubro de 2013,

no site http://devzone.zend.com/1504/getting-started-with-drizzle-and-php/

Mehta, Chirag (2013). A Journey from SQL to NoSQL to NewSQL. Consultado em

28 de Fevereiro de 2013, no site http://www.cloudave.com/25272/a-journey-from-sql-

to-nosql-to-newsql/

More Process (2013) Pros, advantages of SQL (Structured Query Language).

Consultado em 11 de Novembro de 2013, no site

http://www.moreprocess.com/sql/pros-advantages-of-sql-structured-query-language

Moore, Gordon E., “Cramming More Components onto Integrated Circuits,”

Electronics, Volume 38, Number 8, April 19, 1965

NewSQL - Wikipédia (2013). Consultado em 25 de Fevereiro de 2013, no site

http://en.wikipedia.org/wiki/NewSQL

NoSQL (s.d.). Consultado em 24 de Março de 2013, no site http://nosql-

databases.org/

NoSQL – Wikipédia (2013). Consultado em 20 de Novembro de 2013, no site

http://pt.wikipedia.org/wiki/NoSQL

NuoDB - Wikipédia (2013). Consultado em 7 de Agosto de 2013, no site

http://en.wikipedia.org/wiki/NuoDB

NuoDB without compromisse (2013) Consultado em 7 de Agosto de 2013, no site

http://go.nuodb.com/rs/nuodb/images/NuoDB_Product_Brochure_Final.pdf

Plew, Ron & Stephens, Ryan (2002) What is SQL? Consultado em 12 de Setembro de

2013, no site

http://www.informit.com/library/content.aspx?b=STY_Sql_24hours&seqNum=9

Rouse, Margaret (2005). Exabyte (EB). Consultado em 6 de Março de 2013, no site

http://searchstorage.techtarget.com/definition/exabyte

Rouse, Margaret (2013). 3 Vs (Volume, variety and velocity). Consultado em 10 de

Novembro de 2013, no site http://whatis.techtarget.com/definition/3Vs

http://www.statisticbrain.com/facebook-statistics/

http://www.emc.com/collateral/analyst-reports/idc-extracting-value-from-chaos-ar.pdf

http://www.emc.com/collateral/analyst-reports/idc-extracting-value-from-chaos-ar.pdf


http://www.cloudave.com/25272/a-journey-from-sql-to-nosql-to-newsql/


http://www.moreprocess.com/sql/pros-advantages-of-sql-structured-query-language

http://en.wikipedia.org/wiki/NewSQL

http://nosql-databases.org/

http://nosql-databases.org/

http://pt.wikipedia.org/wiki/NoSQL

http://en.wikipedia.org/wiki/NuoDB

http://go.nuodb.com/rs/nuodb/images/NuoDB_Product_Brochure_Final.pdf


http://searchstorage.techtarget.com/definition/exabyte

http://whatis.techtarget.com/definition/3Vs


69

Silva, José da (2013) Moving from SQL to NoSQL. Consultado em 11 de Novembro

de 2013, no site http://blog.josedasilva.net/moving-from-sql-to-nosql/

Stonebraker, Michael (Novembro de 2012). New Opportunities for NewSQL.

Communications of the ACM, Vol. 55 No. 11, Pages 10-11

10.1145/2366316.2366319

Sourceforge (s.d.). NewSQL. Consultado em 25 de Fevereiro de 2013, no site

http://newsql.sourceforge.net/

StormDB overview (2012) Consultado em 22 de Novembro de 2013, no site

http://www.stormdb.com/sites/default/files/downloads/StormDB_Datasheet.pdf

Technology of VoltDB (2013) Consultado em 26 de Novembro de 2013, no site

http://voltdb.com/products/technology

The Architecture & Motivation for NuoDB (2013). Consultado em 11 de Novembro

de 2013, no site

http://go.nuodb.com/rs/nuodb/images/TechnicalWhitepaper.pdf?mkt_tok=3RkMMJW

WfF9wsRonvqvBZKXonjHpfsX56OwtX6K%2BlMI%2F0ER3fOvrPUfGjI4JSMp0a

PyQAgobGp5I5FEJSbnYRbBrt6EFXg%3D%3D

TokuDB Documentation (s.d.). Consultado em 2 de Outubro de 2013 no site

http://www.tokutek.com/2011/02/1773/

TPC-H Documentation (2013). Consultado em 11 de Novembro de 2013, no site

http://www.tpc.org/tpch/spec/tpch2.15.0.pdf

Twitter Statistics (2013) Consultado em 10 de Novembro de 2013, no site

http://www.statisticbrain.com/twitter-statistics/

Ulin, Tomas & Young, Rob (2013). Developer and DBA Guide to What´s New in

MySQL 5.6. Consultado em 3 de Abril de 2013, no site http://www.mysql.com/why-

mysql/white-papers/whats-new-mysql-5-6/

Venkatesh, Prasanna & S, Nirmala (2012). NewSQL – The new way to handle big

data. Consultado em 1 de Março de 2013, no site

http://www.linuxforu.com/2012/01/newsql-handle-big-data/

VoltDB - Wikipedia (2013). Consultado em 04-04-2013, no site

http://en.wikipedia.org/wiki/VoltDB

Why StormDB (2013) Consultado em 22 de Novembro de 2013, no site


http://blog.josedasilva.net/moving-from-sql-to-nosql/

http://newsql.sourceforge.net/

http://www.stormdb.com/sites/default/files/downloads/StormDB_Datasheet.pdf

http://voltdb.com/products/technology

http://go.nuodb.com/rs/nuodb/images/TechnicalWhitepaper.pdf?mkt_tok=3RkMMJWWfF9wsRonvqvBZKXonjHpfsX56OwtX6K%2BlMI%2F0ER3fOvrPUfGjI4JSMp0aPyQAgobGp5I5FEJSbnYRbBrt6EFXg%3D%3D





http://www.statisticbrain.com/twitter-statistics/

http://www.mysql.com/why-mysql/white-papers/whats-new-mysql-5-6/


http://www.linuxforu.com/2012/01/newsql-handle-big-data/

http://en.wikipedia.org/wiki/VoltDB



70

YouTube (s.d.) Estatísticas. Consultado em 10 de Novembro de 2013, no site

http://www.youtube.com/yt/press/pt-PT/statistics.html

Zakon, Robert H’obbes’ (2011) Hobbes’ Internet TimeLine 10.2. Consultado em 8 de

Novembro de 2013, no site http://www.zakon.org/robert/Internet/timeline/

http://www.youtube.com/yt/press/pt-PT/statistics.html

http://www.zakon.org/robert/internet/timeline/

Bases de Dados NewSQL Anexos

71

Anexo A Tutorial de instalação do

Ubuntu 12.04

Alguns dos sistemas utilizados só funcionam em sistemas operativos Linux e como tal

poderá ser necessário fazer a instalação do mesmo. Neste anexo mostramos o tutorial

de como instalar o Ubuntu 12.04, o sistema operativo utilizado para fazer os testes aos

vários sistemas. Pode fazer o download da versão desejada do sistema operativo

Ubuntu no site http://www.ubuntu.com/

Se já tem o Windows instalado no seu computador poderá querer fazer um dual boot e

para tal poderá seguir os tutoriais disponibilizados em

http://linuxelement.blogspot.pt/.

Mas poderá também utilizar uma máquina virtual ou instalar apenas o Ubuntu 12.04

no seu computador. Como a primeira opção para testar os sistemas foi a utilização de

uma máquina virtual, o tutorial que se apresenta em seguida é instalação do Ubuntu

12.04 na máquina virtual. No entanto a instalação de raiz no seu computador não será

diferente.

Escolher o idioma pretendido, no caso foi English e seleccionar Install Ubuntu.

http://www.ubuntu.com/

http://linuxelement.blogspot.pt/


72

Se pretender fazer o download de novas actualizações enquanto instala o Ubuntu deve

seleccionar a opção “Download updates while installing”. Neste caso não

seleccionamos nenhuma opção e clicamos em Continue.

Clique em Continue.

Cliquem em Install Now.


73

Escolha o fuso horário do local onde se encontra e clique em Continue.

Clique em Detect Keyboard Layout, prima uma das teclas pedidas e em seguida

clique em Continue.

Em seguida defina o seu nome de utilizador e a password pretendida e clique em

Continue.


74

Aguarde até que a instalação esteja concluída e lhe seja pedido para reiniciar o

computador. Após isto o computador está pronto a ser utilizado.


75

Anexo B Tutorial de instalação do

MySQL e dos sistemas NewSQL

Neste anexo apresentamos um tutorial de como instalar cada um dos sistemas testados

durante a realização deste projecto.

B.1 MySQL

O Ubuntu tem uma versão do MySQL pronta a instalar mas nem sempre é a versão

mais actual.

Se pretender instalar a versão que vem no Ubuntu basta seguir os passos seguintes:

shell> sudo apt-get install mysql-server

shell> mysql –u root –p


76

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 15

Server version: 5.6.13 MySQL Community Server (GPL)

Copyright © 2000, 2013, Oracle and/or its affiliates. All rights

reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names by trademarks of their respective owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input

statement.

mysql>

Se pretender instalar a versão mais actual do MySQL que pode ser encontrada no site

http://dev.mysql.com/downloads/mysql/ terá de seguir os seguintes passos:

shell> sudo su

shell> dpkg – i mysql-5.6.13-debian6.0-x86_64.deb

shell> rm mysql-5.6.13-debian6.0-x86_64.deb

shell> service mysql stop && cp -rp /var/lib/mysql /var/lib/mysql.old

shell> apt-get remove mysql-server mysql-server-5.5 mysql-server-

core-5.5

shell> mv /etc/mysql/my.cnf /etc/my.cnf

shell> cp /opt/mysql/server-5.6/support-files/mysql.server

/etc/init.d/mysql.server && update-rc.d mysql.server defaults

shell> apt-get install libaio1

shell> chown -R mysql /opt/mysql/server-5.6/

shell> chgrp -R mysql /opt/mysql/server-5.6/

shell> nano /etc/my.cnf

E deve alterar as seguintes linhas no ficheiro my.cnf:

basedir = /opt/mysql/server-5.6

lc-messages-dir = /opt/mysql/server-5.6/share

Guarde as alterações feitas ao ficheiro.

shell> /opt/mysql/server-5.6/scripts/mysql_install_db --user=mysql --

datadir=/var/lib/mysql

shell> rm /opt/mysql/server-5.6/my.cnf

shell> service mysql.server start

shell> mysql –u root –p

Enter password:


http://dev.mysql.com/downloads/mysql/


77


Server version: 5.6.13 MySQL Community Server (GPL)


reserved.




statement.

mysql>

B.2 Drizzle

Para instalar o Drizzle é necessário fazer o download do libdrizzle

(https://launchpad.net/libdrizzle/5.1) e do Drizzle (https://launchpad.net/drizzle/7.2).

Depois de fazer o download destes dois pacotes é necessário descompactar e fazer a

instalação é também necessário fazer a instalação de alguns pacotes do Linux que

serão necessários para que a instalação seja feita correctamente.

shell> sudo su

shell> apt-get install libpcre3-dev libevent-dev autoconf automake

bison ncurses-dev \ libtool librealine-dev libz-dev g++ libssl-dev

uuid-de libpam0g libpam0g-dev gperf \ libboost-all-dev libcloog-ppl0

libprotobuf-dev

shell> tar -xzvf libdrizzle-5.1.4.tar.gz

shell> cd libdrizzle-0.3

shell> ./configure

shell> make

shell> make install

shell> tar -xzvf drizzle-7.2.4-alpha.tar.gz

shell> cd drizzle-7.2.4-alpha

shell> ./configure --with-libprotobuf-prefix=/usr/local

shell> make

shell> make install

shell> groupadd drizzle

shell> useradd -g drizzle drizzle

shell> mkdir /usr/local/drizzle

shell> mkdir /usr/local/drizzle/data

shell> cd /usr/local/drizzle

https://launchpad.net/libdrizzle/5.1

https://launchpad.net/drizzle/7.2


78

shell> chown -R drizzle .

shell> chgrp -R drizzle .

shell> /home/debora/drizzle-7.2.4-alpha/drizzled/drizzled \

--user=drizzle --basedir=/usr/local/drizzle/ \

--datadir=/usr/local/drizzle/data/ &

shell> /usr/local/bin/drizzle

Welcome to the Drizzle client.. Commands end with ; or \g.

Your Drizzle connection id is 3

Server version: 7.2.4-alpha Source distribution (Trunk)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

drizzle>

/home/debora/drizzle-7.2.4-alpha/drizzled/drizzled é a dirctoria para onde foi

descompactada a pasta do Drizzle e onde está o servidor que se deve executar após a

instalação para ser possivel executar o cliente Drizzle para se utilizar a base de dados.

B.3 TokuDB

O download do TokuDB pode ser feito através do link

http://www.tokutek.com/products/downloads/enterprise-edition-downloads/.

Se nunca tiver criado nenhum grupo utuilizador designado mysql o primeiro passo é a

sua criação.

shell> sudo su

shell> groupadd -g mysql

shell> useradd -r -u -g mysql mysql

Se já tiver tanto o grupo como o utiluzador mysql criados pode passar este passo à

frente.

shell> mkdir -pv /opt/tokutek

shell> cd /opt/tokutek

shell> tar xvzf /path/to/mysql-5.5.30-tokudb-7.0.4-linux-

x86_64.tar.gz

shell> ln -sv mysql-5.5.30-tokudb-7.1.0-linux-x86_64 mysql

shell> cd mysql

shell> chown -Rv mysql:mysql .

shell> cp -v support-files/my-small.cnf /etc/my.cnf

shell> nano /etc/my.cnf

http://www.tokutek.com/products/downloads/enterprise-edition-downloads/


79

No ficheiro my.cnf vai acrescentar as seguintes linhas na secção [mysqld]:

datadir = /var/lib/mysql

basedir = /opt/tokutek/mysql

user = mysql

Guarde as alterações efectuadas ao ficheiro e feche-o.

shell> scripts/mysql_install_db --user=mysql

shell> ln -sv /opt/tokutek/mysql/support-files/mysql.server

/etc/init.d/mysql

shell> service mysql start

shell> mysql –u mysql



Server version: 5.5.30-tokudb-7.0.4 MySQL Community Server (GPL)


reserved.




statement.

mysql>

B.4 NuoDB

O download do NuoDB pode ser feito no link

http://www.nuodb.com/register/request/developer. Sendo que é necessário efectuar

primeiro o registo e só depois terá acesso ao download.

Faça download do ficheiro .deb que é para o Ubuntu. Após o download é só proceder

à instalação.

shell> sudo dpkg –i nuodb-1.2.linux.x64.deb

E após este simples comando o NuoDb está pronto a ser utilizado.

shell> java -jar /opt/nuodb/jar/nuoagent.jar --broker & (cada vez que

se liga o computador é necessário iniciar o broker)

shell> java -jar /opt/nuodb/jar/nuodbmanager.jar --broker localhost -

-password bird

nuodb [domain] > start process sm host localhost database 10gb

Process command-line options:

http://www.nuodb.com/register/request/developer


80

Archive directory: /opt/nuodb/samples/10gb (é necessário dar

privilégios de escrita para esta pasta senão a inicialização falha)

Initialize archive: true (primeira vez) false (restantes vezes)

Started process: ....... [ pid = 9950 ]

nuodb [domain] > start process te host localhost database 10gb

Process command-line options: --dba-user dba --dba-password dba

(quando se inicia pela primeira vez, depois já não é necessário)

Started process: ...... [ pid = 9961 ]

shell> /opt/nuodb/bin/nuosql 10gb@localhost --user dba --password dba

SQL>

B.5 VoltDB

O download pode ser feito em http://go.voltdb.com/software-downloads. Terá

de se registar e após isso irá receber um e-mail com o link para fazer o seu download.

Deverá clicar no link do Open Source Linux. Após isso é só fazer a instalação.

shell> sudo tar -zxvf voltdb-3.2.tar.gz -C /opt

shell> cd /opt

shell> sudo mv voltdb-3.2 voltdb

shell> export PATH="$PATH:$/opt/voltdb/bin

http://go.voltdb.com/software-downloads


81

Anexo C Como utilizar o TPC-H

O TPC-H pode ser encontrado em http://www.tpc.org/tpch/.

Após fazer o download é necessário descompactar a pasta obtida e depois fazer

algumas alterações no ficheiro makefile.suite nas linhas CC, DATABASE, MACHINE,

WORKLOAD.

shell> cd tpch_2_15_0/dbgen

shell> nano makefile.suite

################

## CHANGE NAME OF ANSI COMPILER HERE

################

CC = gcc

# Current values for DATABASE are: INFORMIX, DB2, TDAT (Teradata)

# SQLSERVER, SYBASE, ORACLE,

VECTORWISE

# Current values for MACHINE are: ATT, DOS, HP, IBM, ICL, MVS,

# SGI, SUN, U2200, VMS, LINUX, WIN32

# Current values for WORKLOAD are: TPCH

DATABASE= SQLSERVER

MACHINE = LINUX

WORKLOAD = TPCH

shell> cp makefile.suite makefile

shell> make

shell> ./dbgen –vf –s 1 (-s dá-nos o tamanho da base de dados, neste

caso é de 1GB)

TPC-H Population Generator (Version 2.15.0)

Copyright Transaction Processing Performance Council 1994 - 2010

Generating data for suppliers table/

Preloading text ... 100%

done.

Generating data for customers tabledone.

Generating data for orders/lineitem tablesdone.

Generating data for part/partsupplier tablesdone.

Generating data for nation tabledone.

Generating data for region tabledone.

http://www.tpc.org/tpch/


82

Para gerar as pesquisas é necessário copiar o qgen e o ficheiro dists.dss para dentro da

pasta queries e depois é só executar o qgen para obter o código de cada pesquisa.

shell> ./qgen [numero da pesquisa]


83

Anexo D Pesquisas do TPC-H

Aqui são apresentadas as pesquisas do TPC-H utilizadas para testar os vários

sistemas.

Q1 - Pricing Summary Report Query

select

l_returnflag,

l_linestatus,

sum(l_quantity) as sum_qty,

sum(l_extendedprice) as sum_base_price,

sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,

sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as

sum_charge,

avg(l_quantity) as avg_qty,

avg(l_extendedprice) as avg_price,

avg(l_discount) as avg_disc,

count(*) as count_order

from

lineitem

where

l_shipdate <= date '1998-12-01' - interval '64' day

group by

l_returnflag,

l_linestatus

order by

l_returnflag,

l_linestatus;

Q2 - Minimum Cost Supplier Query

select

s_acctbal,

s_name,

n_name,

p_partkey,

p_mfgr,

s_address,

s_phone,

s_comment

from

part,

supplier,

partsupp,

nation,

region

where

p_partkey = ps_partkey

and s_suppkey = ps_suppkey

and p_size = 13

and p_type like '%BRASS'

and s_nationkey = n_nationkey

and n_regionkey = r_regionkey


84

and r_name = 'AMERICA'

and ps_supplycost = (

select

min(ps_supplycost)

from

partsupp,

supplier,

nation,

region

where


and s_suppkey = ps_suppkey



and r_name = 'AMERICA'

)

order by

s_acctbal desc,

n_name,

s_name,

p_partkey

limit 100;

Q3 - Shipping Priority Query

select

l_orderkey,

sum(l_extendedprice * (1 - l_discount)) as revenue,

o_orderdate,

o_shippriority

from

customer,

orders,

lineitem

where

c_mktsegment = 'MACHINERY'

and c_custkey = o_custkey

and l_orderkey = o_orderkey

and o_orderdate < date '1995-03-10'

and l_shipdate > date '1995-03-10'

group by

l_orderkey,

o_orderdate,

o_shippriority

order by

revenue desc,

o_orderdate

limit 10;

Q4 - Order Priority Checking Query

select

o_orderpriority,

count(*) as order_count

from

orders

where

o_orderdate >= date '1995-10-01'

and o_orderdate < date '1995-10-01' + interval '3' month


85

and exists (

select

*

from

lineitem

where

l_orderkey = o_orderkey

and l_commitdate < l_receiptdate

)

group by

o_orderpriority

order by

o_orderpriority;

Q5 - Local Supplier Volume Query

select

n_name,

sum(l_extendedprice * (1 - l_discount)) as revenue

from

customer,

orders,

lineitem,

supplier,

nation,

region

where

c_custkey = o_custkey


and l_suppkey = s_suppkey

and c_nationkey = s_nationkey



and r_name = 'AFRICA'

and o_orderdate >= date '1993-01-01'

and o_orderdate < date '1993-01-01' + interval '1' year

group by

n_name

order by

revenue desc;

Q6 - Forecasting Revenue Change Query

select

sum(l_extendedprice * l_discount) as revenue

from

lineitem

where

l_shipdate >= date '1997-01-01'

and l_shipdate < date '1997-01-01' + interval '1' year

and l_discount between 0.06 - 0.01 and 0.06 + 0.01

and l_quantity < 24;


86

Q7 - Volume Shipping Query

select

supp_nation,

cust_nation,

l_year,

sum(volume) as revenue

from

(

select

n1.n_name as supp_nation,

n2.n_name as cust_nation,

extract(year from l_shipdate) as l_year,

l_extendedprice * (1 - l_discount) as volume

from

supplier,

lineitem,

orders,

customer,

nation n1,

nation n2

where

s_suppkey = l_suppkey

and o_orderkey = l_orderkey


and s_nationkey = n1.n_nationkey

and c_nationkey = n2.n_nationkey

and (

(n1.n_name = 'VIETNAM' and n2.n_name

= 'IRAQ')

or (n1.n_name = 'IRAQ' and n2.n_name

= 'VIETNAM'

)

)

and l_shipdate between date '1995-01-01' and

date '1996-12-31'

) as shipping

group by

supp_nation,

cust_nation,

l_year

order by

supp_nation,

cust_nation,

l_year;

Q8 - National Market Share Query

select o_year,

sum(case

when nation = 'CHINA' then volume

else 0

end) / sum(volume) as mkt_share

from

(

select

extract(year from o_orderdate) as o_year,

l_extendedprice * (1 - l_discount) as volume,

n2.n_name as nation

from


87

part,

supplier,

lineitem,

orders,

customer,

nation n1,

nation n2,

region

where

p_partkey = l_partkey

and s_suppkey = l_suppkey


and o_custkey = c_custkey

and c_nationkey = n1.n_nationkey

and n1.n_regionkey = r_regionkey

and r_name = 'ASIA'

and s_nationkey = n2.n_nationkey

and o_orderdate between date '1995-01-01' and

date '1996-12-31'

and p_type = 'LARGE BURNISHED STEEL'

) as all_nations

group by

o_year

order by

o_year;

Q9 - Product Type Profit Measure Query

select

nation,

o_year,

sum(amount) as sum_profit

from

(

select

n_name as nation,

extract(year from o_orderdate) as o_year,

l_extendedprice * (1 - l_discount) -

ps_supplycost * l_quantity as amount

from

part,

supplier,

lineitem,

partsupp,

orders,

nation

where

s_suppkey = l_suppkey

and ps_suppkey = l_suppkey

and ps_partkey = l_partkey

and p_partkey = l_partkey



and p_name like '%maroon%'

) as profit

group by

nation,


88

o_year

order by

nation,

o_year desc;

Q10 - Returned Item Reporting Query

select

c_custkey,

c_name,

sum(l_extendedprice * (1 - l_discount)) as revenue,

c_acctbal,

n_name,

c_address,

c_phone,

c_comment

from

customer,

orders,

lineitem,

nation

where



and o_orderdate >= date '1993-02-01'

and o_orderdate < date '1993-02-01' + interval '3' month

and l_returnflag = 'R'

and c_nationkey = n_nationkey

group by

c_custkey,

c_name,

c_acctbal,

c_phone,

n_name,

c_address,

c_comment

order by

revenue desc

limit 20;

Q11 - Important Stock Identification Query

select

ps_partkey,

sum(ps_supplycost * ps_availqty) as value

from

partsupp,

supplier,

nation

where

ps_suppkey = s_suppkey


and n_name = 'UNITED KINGDOM'

group by

ps_partkey having

sum(ps_supplycost * ps_availqty) > (

select


89

sum(ps_supplycost * ps_availqty) *

0.0000100000

from

partsupp,

supplier,

nation

where

ps_suppkey = s_suppkey



)

order by

value desc;

Q12 - Shipping Modes and Order Priority Query

select

l_shipmode,

sum(case

when o_orderpriority = '1-URGENT'

or o_orderpriority = '2-HIGH'

then 1

else 0

end) as high_line_count,

sum(case

when o_orderpriority <> '1-URGENT'

and o_orderpriority <> '2-HIGH'

then 1

else 0

end) as low_line_count

from

orders,

lineitem

where

o_orderkey = l_orderkey

and l_shipmode in ('REG AIR', 'SHIP')

and l_commitdate < l_receiptdate

and l_shipdate < l_commitdate

and l_receiptdate >= date '1997-01-01'

and l_receiptdate < date '1997-01-01' + interval '1' year

group by

l_shipmode

order by

l_shipmode;

Q13 - Customer Distribution Query

select

c_orders.c_count,

count(*) as custdist

from

(


90

select

c_custkey,

count(o_orderkey) as c_count

from

customer left outer join orders on


and o_comment not like

'%pending%accounts%'

group by

c_custkey

) as c_orders

group by

c_count

order by

custdist desc,

c_count desc;

Q14 - Promotion Effect Query

select

100.00 * sum(case

when p_type like 'PROMO%'

then l_extendedprice * (1 - l_discount)

else 0

end) / sum(l_extendedprice * (1 - l_discount)) as

promo_revenue

from

lineitem,

part

where

l_partkey = p_partkey

and l_shipdate >= date '1996-10-01'

and l_shipdate < date '1996-10-01' + interval '1' month;

Q15 - Top Supplier Query

create view revenue0 (supplier_no, total_revenue) as

select

l_suppkey,

sum(l_extendedprice * (1 - l_discount))

from

lineitem

where

l_shipdate >= date '1996-04-01'

and l_shipdate < date '1996-04-01' + interval '3'

month

group by

l_suppkey;

select

s_suppkey,

s_name,

s_address,

s_phone,

total_revenue

from


91

supplier,

revenue0

where

s_suppkey = supplier_no

and total_revenue = (

select

max(total_revenue)

from

revenue0

)

order by

s_suppkey;

drop view revenue0;

Q16 - Parts/Supplier Relationship Query

select

p_brand,

p_type,

p_size,

count(distinct ps_suppkey) as supplier_cnt

from

partsupp,

part

where


and p_brand <> 'Brand#51'

and p_type not like 'SMALL BRUSHED%'

and p_size in (33, 43, 46, 20, 9, 40, 45, 1)

and ps_suppkey not in (

select

s_suppkey

from

supplier

where

s_comment like '%Customer%Complaints%'

)

group by

p_brand,

p_type,

p_size

order by

supplier_cnt desc,

p_brand,

p_type,

p_size;

Q17 - Small-Quantity-Order Revenue Query

select

sum(l_extendedprice) / 7.0 as avg_yearly

from

lineitem,


92

part

where


and p_brand = 'Brand#24'

and p_container = 'SM PACK'

and l_quantity < (

select

0.2 * avg(l_quantity)

from

lineitem

where

l_partkey = p_partkey

);

Q18 - Large Volume Customer Query

select

c_name,

c_custkey,

o_orderkey,

o_orderdate,

o_totalprice,

sum(l_quantity)

from

customer,

orders,

lineitem

where

o_orderkey in (

select

l_orderkey

from

lineitem

group by

l_orderkey having

sum(l_quantity) > 313

)



group by

c_name,

c_custkey,

o_orderkey,

o_orderdate,

o_totalprice

order by

o_totalprice desc,

o_orderdate

limit 100;

Q19 - Discounted Revenue Query

select

sum(l_extendedprice* (1 - l_discount)) as revenue

from

lineitem,

part

where

(


93



and p_container in ('SM CASE', 'SM BOX', 'SM PACK',

'SM PKG')

and l_quantity >= 5 and l_quantity <= 5 + 10

and p_size between 1 and 5

and l_shipmode in ('AIR', 'AIR REG')

and l_shipinstruct = 'DELIVER IN PERSON'

)

or

(



and p_container in ('MED BAG', 'MED BOX', 'MED PKG',

'MED PACK')





)

or

(



and p_container in ('LG CASE', 'LG BOX', 'LG PACK',

'LG PKG')





);

Q20 - Potential Part Promotion Query

select

s_name,

s_address

from

supplier,

nation

where

s_suppkey in (

select

ps_suppkey

from

partsupp

where

ps_partkey in (

select

p_partkey

from

part

where

p_name like 'coral%'

)

and ps_availqty > (


94

select

0.5 * sum(l_quantity)

from

lineitem

where

l_partkey = ps_partkey

and l_suppkey = ps_suppkey

and l_shipdate >= date '1995-

01-01'

and l_shipdate < date '1995-

01-01' + interval '1' year

)

)


and n_name = 'IRAN'

order by

s_name;

Q21 - Suppliers Who Kept Orders Waiting Query

select

s_name,

count(*) as numwait

from

supplier,

lineitem l1,

orders,

nation

where

s_suppkey = l1.l_suppkey

and o_orderkey = l1.l_orderkey

and o_orderstatus = 'F'

and l1.l_receiptdate > l1.l_commitdate

and exists (

select

*

from

lineitem l2

where

l2.l_orderkey = l1.l_orderkey

and l2.l_suppkey <> l1.l_suppkey

)

and not exists (

select

*

from

lineitem l3

where

l3.l_orderkey = l1.l_orderkey

and l3.l_suppkey <> l1.l_suppkey

and l3.l_receiptdate > l3.l_commitdate

)



group by

s_name

order by

numwait desc,

s_name

limit 100;


95

Q22 - Global Sales Opportunity Query

select

cntrycode,

count(*) as numcust,

sum(c_acctbal) as totacctbal

from

(select

substring(c_phone from 1 for 2) as cntrycode,

c_acctbal

from

customer

where

substring(c_phone from 1 for 2) in

('35', '37', '25', '21', '39', '41',

'22')

and c_acctbal > (select

avg(c_acctbal)

from

customer

where

c_acctbal > 0.00

and substring(c_phone from 1

for 2) in

('35', '37', '25',

'21', '39', '41', '22')

)

and not exists (

select

*

from

orders

where

o_custkey = c_custkey

)

) as custsale

group by

cntrycode

order by

cntrycode;


96

Anexo E Scripts utilizados no VoltDB

Neste anexo apresentamos os scripts que foram necessários criar para uma correcta

utilização do VoltDB.

E.1 Script 1

package script;

import java.io.BufferedWriter;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.FileWriter;

import java.io.IOException;

import java.util.Scanner;

public class Script {

public static void main(String[] args) throws FileNotFoundException, IOException {

Scanner ler1 = new Scanner(new FileInputStream("partsupp.tbl"));

Scanner ler2 = new Scanner(new FileInputStream("orders.tbl"));

Scanner ler3 = new Scanner(new FileInputStream("lineitem.tbl"));

Scanner ler4 = new Scanner(new FileInputStream("nation.tbl"));

Scanner ler5 = new Scanner(new FileInputStream("region.tbl"));

Scanner ler6 = new Scanner(new FileInputStream("part.tbl"));

Scanner ler7 = new Scanner(new FileInputStream("supplier.tbl"));

Scanner ler8 = new Scanner(new FileInputStream("customer.tbl"));

BufferedWriter novo1 = new BufferedWriter(new FileWriter("partsupp2.tbl"));

BufferedWriter novo2 = new BufferedWriter(new FileWriter("orders2.tbl"));

BufferedWriter novo3 = new BufferedWriter(new FileWriter("lineitem2.tbl"));

BufferedWriter novo4 = new BufferedWriter(new FileWriter("nation2.tbl"));

BufferedWriter novo5 = new BufferedWriter(new FileWriter("region2.tbl"));

BufferedWriter novo6 = new BufferedWriter(new FileWriter("part2.tbl"));

BufferedWriter novo7 = new BufferedWriter(new FileWriter("supplier2.tbl"));

BufferedWriter novo8 = new BufferedWriter(new FileWriter("customer2.tbl"));

String linha;

String []campos;

int i=0;

while(ler1.hasNextLine())

{

linha = ler1.nextLine();

campos=linha.split("\\|");

novo1.write(campos[0]+"|");




novo1.write(campos[4]+"\n");

}


{












}


{










97











}


{







}


{






}


{












}


{










}


{











}

ler1.close();

ler2.close();

ler3.close();

ler4.close();

ler5.close();


98

ler6.close();

ler7.close();

ler8.close();

novo1.close();

novo2.close();

novo3.close();

novo4.close();

novo5.close();

novo6.close();

novo7.close();

novo8.close();

}

}

E.2 Script 2

package datetotimestamp;

import java.io.BufferedWriter;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.FileWriter;

import java.io.IOException;

import java.util.*;

import java.text.*;

public class DateToTimestamp {

public static void main(String[] args) throws ParseException,

FileNotFoundException, IOException {

Scanner ler = new Scanner(new FileInputStream("lineitem.tbl"));

Scanner ler2 = new Scanner(new FileInputStream("orders.tbl"));

BufferedWriter novo = new BufferedWriter(new FileWriter("lineitem2.tbl"));

BufferedWriter novo2 = new BufferedWriter(new FileWriter("orders2.tbl"));

String linha;

String []campos;

while(ler.hasNextLine())

{

linha = ler.nextLine();


String str_date=campos[10];

DateFormat formatter ;

Date date ;

formatter = new SimpleDateFormat("yyyy-MM-dd");

date = (Date)formatter.parse(str_date);

Calendar c = Calendar.getInstance();

c.setTime(date);

String str_date2=campos[11];

Date date2 ;

date2 = (Date)formatter.parse(str_date2);

Calendar c2 = Calendar.getInstance();

c2.setTime(date2);

String str_date3=campos[12];

Date date3 ;

date3 = (Date)formatter.parse(str_date3);

Calendar c3 = Calendar.getInstance();

c3.setTime(date3);

novo.write(campos[0]+"|");










novo.write((c.getTimeInMillis()+3600000)*1000+"|");

novo.write((c2.getTimeInMillis()+3600000)*1000+"|");

novo.write((c3.getTimeInMillis()+3600000)*1000+"|");



novo.write(campos[15]);

novo.write("\n");

}


{



99


String str_date=campos[4];

DateFormat formatter ;

Date date ;

formatter = new SimpleDateFormat("yyyy-MM-dd");

date = (Date)formatter.parse(str_date);

Calendar c = Calendar.getInstance();

c.setTime(date);





novo2.write((c.getTimeInMillis()+3600000)*1000+"|");




novo2.write(campos[8]);

novo2.write("\n");

}

ler.close();

ler2.close();

novo.close();

novo2.close();

}

}


100

Anexo F Resultados para a base de

dados de 1GB

Por uma questão de não colocarmos resultados repetidos no capítulo da avaliação

experimental decidimos colocar em anexo estes resultados.

Figura F.1 – Tempos de execução na sequência 1 para 1GB

Figura F.2 - Tempos de execução na sequência 2 para 1GB

Figura F.3 - Tempos de execução na sequência 3 para 1GB


101

Tabela F.1 – Valores da pesquisa Q14 para 1GB

S1 S2 S3

MySQL 222.44 212.76 221.42

Drizzle 270.72 270.84 270.15

TokuDB 3.03 2.65 2.75

NuoDB 3.71 3.71 48.47

VoltDB 0.8 1.49 1.38

StormDB 26.25 25.57 26.07

Figura F.4 – Sequência 1 para 1GB (NuoDB vsMysql,Drizzle e TokuDB)

Figura F.5 - Sequência 2 para 1GB (NuoDB vsMysql,Drizzle e TokuDB)


102

Figura F.6 - Sequência 3 para 1GB (NuoDB vsMysql,Drizzle e TokuDB)

Tabela F.2 - Valores da pesquisa Q15 (NuoDB vsMysql,Drizzle e TokuDB)

S1 S2 S3

MySQL 6.95 7 6.89

Drizzle 11.36 11.07 10.89

TokuDB 5.54 5.15 5.23

NuoDB 78387.48 101523.5 71464.52


S1 S2 S3

MySQL 50.15 47.14 41.33

Drizzle 37.45 34.03 33.96

TokuDB 96.16 95.56 95.77

NuoDB 16347.82 16441.85 15466.51


103


S1 S2 S3

MySQL 0.31 0.31 0.32

Drizzle 0.33 0.35 0.38

TokuDB 0.29 0.75 0.3

NuoDB 7336.45 6550.7 6496.23

Figura F.7 - Sequência 1 para 1GB (VoltDB vsMysql,Drizzle e TokuDB)



104


Figura F.10 – Sequência 1 para 1GB (StormDB vsMysql,Drizzle e TokuDB)

Figura F.11 - Sequência 2 para 1GB (StormDB vsMysql,Drizzle e TokuDB)


105

Figura F.12 - Sequência 3 para 1GB (StormDB vsMysql,Drizzle e TokuDB)


106

Anexo G Resultados da base de dados

de 10GB

Conforme o que foi feita para as bases de dados de 1GB também para 10GB

colocámos em anexo os resultados obtidos em cada sequência dos vários sistemas de

forma a não colocarmos informação repetida na avaliação experimental

Figura G.1 - Sequência 1 para 10GB

Figura G.2 - Sequência 2 para 10GB


107

Figura G.3 – Sequência 3 para 10GB

Tabela G.1 – Valores da pesquisa Q9 para 10GB

S1 S2 S3

MySQL 48886.18 28602.72 28337.84

Drizzle 27763.26 27560.68 27190.87

TokuDB 578.32 571.30 621.12

Tabela G.2 – Valores da pesquisa Q14 para 10GB

S1 S2 S3

MySQL 164050.16 143110.42 170149.63

Drizzle 70212.9 74529.20 82370.12

TokuDB 73.38 52.89 70.05

StormDB 253.25 250.22 248.81


108

Figura G.4 - Sequência 1 para 10GB (StormDB vsMysql,Drizzle e TokuDB)

Figura G.5- Sequência 2 para 10GB (StormDB vsMysql,Drizzle e TokuDB)

.

Figura G.6 - Sequência 3 para 10GB (StormDB vsMysql,Drizzle e TokuDB)


109

Anexo H Artigo Científico

Artigo submetido à Revista RISTI (Revista Ibérica de Sistemas e Tecnologias de

Informação). Até ao momento presente não sabemos o resultado desta submissão.

Avaliação Experimental de Bases de Dados NewSQL para Organizações Virtuais

Débora Ribeiro 1, Jorge Bernardino 1

[email protected], [email protected]

1 Instituto Politécnico de Coimbra – Instituto Superior de Engenharia de Coimbra, Rua Pedro Nunes, 3030-199, Coimbra, Portugal

DOI: 10.4304/risti.n.pi-pf

Resumo: As bases de dados NewSQL são um conjunto de novas bases de dados relacionais que proporcionam melhor desempenho que os sistemas actualmente existentes, mantendo no entanto a utilização da linguagem SQL. Devido às enormes quantidades de dados armazenadas pelas organizações virtuais este tipo de bases de dados são adequadas para resolver os tradicionais problemas no processamento desta informação. Neste artigo mostramos as vantagens das bases de dados NewSQL para as organizações virtuais, através da avaliação experimental utilizando o benchmark TPC-H. Nesta avaliação foram utilizadas duas das mais conhecidas bases de dados NewSQL, Drizzle e TokuDB, utilizando como base de comparação a base de dados MySQL. A avaliação experimental demonstrou a superioridade das bases de dados NewSQL e como podem responder às necessidades das organizações virtuais.

Palavras-chave: Bases de dados, NewSQL, Organizações virtuais

Abstract: NewSQL databases are a group of new relational databases that provides better performance than the currently existing system, maintaining however the use of SQL language. Because of the large quantities of data stored by virtual organizations this type of databases are appropriate to solve the traditional problems in processing this information. In this article we show the advantages of NewSQL databases for the virtual organizations, through experimental evaluation using the benchmark TPC-H. In this evaluation were used two of the most know NewSQL databases, Drizzle and TokuDB, using as basis of comparison the database MySQL. The experimental evaluation has demonstrated the superiority of NewSQL databases and how they can meet the needs of virtual organizations.

Key-words: Databases, NewSQL, Virtual organizations

1. Introdução

Hoje em dia a Internet é o principal meio de comunicação utilizado em todo o mundo e por isso muitas empresas tendem a transformar os seus serviços localizados em espaços físicos em lojas e espaços virtuais.


110

Desta transformação das empresas, de espaços físicos em espaços virtuais resulta a criação de Organizações Virtuais. Estas organizações recorrem a redes para ligar pessoas e ideias, de modo a criar e distribuir serviços e produtos sem as tradicionais limitações físicas das organizações.

No entanto estas organizações têm como grande desafio conseguir processar e armazenar toda a informação que necessitam para que a organização funcione correctamente.

Com a Internet disponível para todos, a quantidade de informação transmitida começou a aumentar a cada ano que passa. Este aumento causa problemas no processamento e armazenamento de toda essa informação, o que fez com que procurassem novas soluções de bases de dados. Uma das soluções mais recentes foi proposta com a designação de bases de dados NewSQL (Stonebraker, 2012). Este novo tipo de bases de dados oferece grande escalabilidade e alto desempenho com a vantagem de continuarem a preservar a utilização da linguagem SQL. E para esclarecer, o NewSQL não deve ser tomado à letra, o que existe de novo sobre os fornecedores NewSQL é o vendedor, e não o SQL. O NewSQL é assim utilizado para descrever o desenvolvimento de novas bases de dados relacionais e serviços desenhados para que as arquitecturas distribuídas tenham todos os benefícios do modelo relacional, e melhorando o desempenho das bases de dados relacionais para que já não seja necessário escalabilidade horizontal, (Aslett 2, 2011)

De acordo com (Stonebraker, 2012) as soluções NewSQL são as mais viáveis para resolver o problema de processamento e armazenamento de grandes quantidades de dados como aquelas que existem nas organizações virtuais.

Assim, neste artigo, pretende-se avaliar bases de dados NewSQL para organizações virtuais comparando experimentalmente estes sistemas com as soluções actualmente existentes. Para a avaliação experimental foram consideradas duas das mais utilizadas bases de dados NewSQL: Drizzle e TokuDB. De salientar que neste trabalho apenas estamos interessados em analisar soluções NewSQL open-source, por forma a diminuir os gastos de software nas empresas. A avaliação experimental utilizando o TPC-H benchmark mostrou ganhos significativos das bases de dados NewSQL quando comparadas com o desempenho da tradicionalmente mais utilizada base de dados open-source MySQL.

Este artigo está estruturado da seguinte forma: na secção 2 será efectuada uma descrição do que é o NewSQL e como surgiu. Serão também descritas as principais características das soluções NewSQL e as respectivas categorias. A secção 3 descreve as bases de dados NewSQL analisadas: Drizzle e TokuDB, comparando com a bem conhecida MySQL. A secção 4 descreve sucintamente o ambiente experimental e o TPC-H que foi a benchmark utilizada na avaliação das várias bases de dados. A secção 5 apresenta os resultados da avaliação experimental. Finalmente, as conclusões e trabalho futuro são apresentadas na secção 6.

2. Evolução do SQL ao NewSQL

A tecnologia de bases de dados relacionais foi inventada em 1970 por Edgar Frank Codd, quando trabalhava para a IBM, onde demonstrou a utilidade e funcionalidade trazida por esta nova tecnologia (Codd, 1970). Juntamente com esta proposta, foi desenvolvida a linguagem SQL - Structured Query Language (Chamberlin e Boyce, 1974), que se tornou a linguagem padrão na manipulação de dados armazenados em bases de dados relacionais, (Plew & Stephens, 2002).

O NewSQL surge assim para designar o conjunto de novas bases de dados relacionais que visam proporcionar o mesmo desempenho que os sistemas NoSQL para carregamentos de OLTP e ainda assim manter as garantias ACID (Atomicity, Consistency, Isolation, Durability) para as bases de dados tradicionais. O NewSQL pretende ainda eliminar as tarefas pesadas que estão sujeitas a erros de gestão como por exemplo o sharding manual, sem ter de interromper o funcionamento da base de dados, como é referido em (Mehta, 2013). Sharding é um tipo de particionamento de bases de dados que separa bases de dados muito grandes em partes mais pequenas, rápidas e fáceis de gerir chamadas dados shard. A palavra shard significa uma pequena parte de um todo. Assim o sharding manual implicaria fazer este particionamento das bases de dados manualmente sem recorrer a qualquer aplicação para o fazer.


111

Em (Aslett, 2011), é ainda referido que as bases de dados NewSQL foram projectadas para atender os requisitos de escalabilidade das arquitecturas distribuídas e para melhorar o desempenho de tal forma que a escalabilidade horizontal deixe de ser uma necessidade, incluindo novos mecanismos de armazenamento MySQL, tecnologias de sharding transparente, isto é, dividir os dados horizontalmente, dividir as tabelas por várias máquinas diminuindo assim o número de registos em cada tabela.

Assim pode dizer-se que o NewSQL pretende preservar o SQL, oferecendo alto desempenho e escalabilidade enquanto preserva a noção de ACID para transacções.

Segundo (Venkatesh & S, 2012) as principais características das soluções NewSQL são:

O SQL é o principal mecanismo de interacção com as aplicações;

Suporta ACID para as transacções;

Mecanismo de controlo de não-bloqueio simultâneo, para que a leitura em tempo real não entre em conflito com a escrita;

Uma arquitectura que proporcione um maior desempenho por nó do que as tradicionais soluções RDBMS (Relational DataBase Management System);

Uma arquitectura shared-nothing, expansiva, capaz de funcionar com o maior número de nós sem bloquear. Arquitectura shared-nothing é uma arquitectura de computação distribuída, em que cada nó é independente e auto-suficiente. Não há partilha de memória e de armazenamento em disco entre cada um dos nós existentes.

Com estas características espera-se que o NewSQL seja mais rápido que os tradicionais sistemas RDBMS.

Embora os sistemas NewSQL variem muito na sua arquitectura interna, há duas características distintas que são comuns a todos eles e que são o suporte ao modelo de dados relacional e o uso de SQL como principal interface. Ainda, segundo (Venkatesh & S, 2012) os sistemas NewSQL podem ser agrupados em três categorias:

Novas Arquitecturas;

Novos motores de armazenamento MySQL;

Sharding Transparente.

As bases de dados testadas, Drizzle e TokuDB, pertencem à categoria Novas Arquitecturas e Novo motores de armazenamento MySQL, respectivamente.

3. Bases de Dados avaliadas

Para avaliar as bases dados NewSQL e perceber quais as mais-valias que estas podem trazer às organizações virtuais testámos as bases de dados Drizzle e TokuDB e como base de comparação utilizámos o MySQL. Nesta secção descrevemos de forma sucinta estas três bases de dados testadas.

3.1. MySQL

Avaliou-se a base de dados MySQL, como já foi referido anteriormente, para termos uma base de comparação com uma base de dados que não seja NewSQL. Escolhemos o MySQL por ser considerado o sistema de base de dados open-source mais utilizado no mundo, (DBEngines Ranking, 2013).

A versão testada do MySQL foi a última actualmente disponibilizada, a 5.6.13. De referir que a partir da versão 5.6 o MySQL foi bastante melhorado em relação às versões anteriores em aspectos, tais como (Ulin & Young, 2013):

Performance e escalabilidade:


112

o Aumentou para 48 CPU Threads. Threads são as sequências de instrução que são executadas num programa;

o Em relação à versão 5.5 a performance aumentou 230%;

INNODB, módulo de armazenamento que oferece transacções do tipo ACID:

o Melhor rendimento nas transacções e mais disponibilidade;

Optimização:

o Melhor tempo na execução de consultas e melhor ajuste das consultas;

Melhor desempenho, disponibilidade e integridade dos dados;

Nova Funcionalidade:

o Acesso NoSQL para INNODB.

Com estas melhorias significativas pretendeu-se eliminar os erros existentes nas versões anteriores e ainda melhorar o desempenho do MySQL.

3.2.Drizzle

O Projecto Drizzle teve o seu início em 2008. O Drizzle é uma base de dados transaccional, relacional e open-source que deriva da base de dados MySQL.

O Drizzle foi desenhado para ambientes modernos de 64 bits, arquitectura multi-core, com gigabytes de memória e para executar várias transacções ao mesmo tempo, (Drizzle Documentation, 2010).

Embora o Drizzle seja uma derivação do MySQL não foi feito para o substituir mas sim para atrair os utilizadores que querem a confiabilidade, bases de dados ACID e a fácil utilização que o MySQL proporciona mas não precisa de todos os recursos que este tem como por exemplos, procedimentos, triggers ou vistas.

As principais diferenças entre Drizzle e o MySQL são as seguintes, (Getting Started with Drizzle and PHP, 2009):

Motor de armazenamento é o InnoDB em vez do MyISAM;

Suporta menos tipos de dados;

Utiliza um protocolo diferente de comunicação cliente/servidor;

Suporta uma arquitectura de módulos extensível que permite aos programadores compilar apenas os módulos necessários (muito parecido com o Apache ou com o PHP).

O Drizzle está optimizado para ter várias conexões em simultâneo à base de dados; e não é possível utilizá-lo em plataformas Windows.

A equipa que programou o Drizzle retirou código que achava desnecessário do MySQL e converteu o restante código para a linguagem C++ e para bibliotecas mais modernas.

Em termos técnicos, o Drizzle é baseado num micro-kernel projectado para bases de dados a que se possam acrescentar novos módulos sempre que necessário. E os seus objectivos relacionais e de durabilidade estão construídos no kernel como projecto padrão.

O Drizzle suporta um número de interfaces como pluggins e assim o kernel faz o menos possível e é o mais claro possível para os utilizadores. Desta forma é permitido aos utilizadores aumentar a base de dados escrevendo simples plugins.

Historicamente, os servidores de bases de dados é que definem a infra-estrutura – o utilizador deve utilizar o sistema de autenticação e de login existentes. O Drizzle tenta uma abordagem diferente; tem como objectivo a integração com a infra-estrutura existente tornando-se parte dela e não uma ilha.


113

3.3.TokuDB

O TokuDB é um mecanismo de armazenamento para MySQL que foi especialmente criado para ter um alto desempenho em carregamentos de escrita intensiva, utilizando para isso a indexação Fractal Tree, (TokuDB Documentation, s.d.).

A indexação Fractal Tree implementa as mesmas operações que a indexação B-Tree, forma mais comum de indexação. A diferença está na performance, pois a Fractal Tree substitui I/O (entradas/saídas) aleatórias por I/O sequenciais; isto é feito para que a largura de banda do disco tenha uma taxa de utilização máxima, mesmo quando a base de dados cresce. Como resultado é possível ter mais índices sem haver perda de desempenho; quanto maior for a tabela mais vantagem o TokuDB consegue obter em relação ao mecanismo de armazenamento B-Tree, ou seja, mesmo em grande tabelas o TokuDB oferece um bom desempenho sem particionamento ou sharding pois foi projectado para tabelas muito grandes.

TokuDB é escalável, ACID e tem um mecanismo de armazenamento compatível com MVCC (Multiversion concurrency control) que proporciona melhorias em consultas através de índices. MVCC é um método de controlo de concorrência normalmente utilizado em sistemas de gestão de bases de dados que proporciona simultaneamente acesso às bases de dados e às linguagens de programação para implementação de memória transaccional.

As principais vantagens do TokuDb em relação ao motor de armazenamento MySQL são as seguintes, (TokuDB Documentation, s.d.):

Fazer inserções e pesquisas mais rapidamente em condições reais;

Escalabilidade máxima, isto é, a base de dados podem ter muitos terabytes de tamanho;

Controlo de concorrência, ou seja, permite que a leitura e escrita simultânea na base de dados sem que esta fique inconsistente;

Melhoramento no backup de falhas.

Com estas características a equipa que desenhou o TokuDb pretende torná-lo numa base de dados bastante eficiente e capaz de competir com o MySQL.

4. Ambiente experimental

Para avaliar as bases dados NewSQL open source Drizzle e TokuDB utilizou-se a benchmark TPC-H (Transaction Performance Council). Os testes foram realizados num computador com sistema operativo Ubuntu 12.04 64-bit, memória (RAM) de 8GB e um processador Intel® Core™ i7 CPU 920 @ 2.67GHz x 8.

4.1 TPC-H Benchmark

O TPC-H é uma benckmark de apoio à decisão que consiste num conjunto de pesquisas ad-hoc orientadas ao negócio.

Esta benchmark avalia o desempenho de vários sistemas de apoio à decisão através da execução de um conjunto de pesquisas, em condições controladas, nas bases de dados em teste. As pesquisas do TPC-H dão respostas para questões de negócio reais e simulam as tradicionais pesquisas ad-hoc dos sistemas de apoio à decisão. Estas pesquisas são muito mais complexas que a maioria das transacções OLTP e incluem um vasto conjunto de operadores e restrições de selectividade. As pesquisas geram também uma intensa actividade por parte do servidor de base de dados do sistema que está a ser testado e são executadas numa base de dados de acordo com uma população específica e requisitos de tamanho.

O código das pesquisas assim como todas as informações sobre a benchmark e sobre as tabelas encontra-se em (TPC-H Documentation, 2013).


114

O TPC-H possui oito tabelas, que são apresentadas na tabela 2, e tem também vinte e duas pesquisas que designamos Q1 a Q22.

Tabela 1 – Caracterização do número de registos das tabelas do TPC-H para 1GB e 10GB

Nº de registos

Tabelas 1GB 10GB

Nation 25 25

Region 5 5

Part 200 000 2 000 000

Supplier 10 000 100 000

Partsupp 800 000 8 000 000

Customer 150 000 1 500 000

Orders 1 500 000 15 000 000

Lineitem 6 001 215 59 986 052

TOTAL 8 661 245 86 586 082

5. Avaliação Experimental

Nesta secção apresentamos os resultados experimentais obtidos nos testes realizados no MySQL, Drizzle e TokuDB e uma fazemos a análise desses mesmos resultados. A avaliação experimental foi realizada para dois conjuntos de dados, isto é, bases de dados com tamanho de 1GB e 10GB.

Os testes foram realizados para cada uma das bases de dados através da execução de três sequências de pesquisas (S1 a S3) geradas no random.org:

S1 – Q9, Q18, Q8, Q5, Q21, Q2, Q14, Q16, Q13, Q12, Q15, Q19, Q3, Q7, Q22, Q10, Q11, Q1, Q6, Q17, Q4;



Deste modo pretendemos evitar possíveis efeitos de armazenamento em cache dos resultados das pesquisas, executando três vezes cada pesquisa de forma aleatória e obtendo depois o valor médio da execução de cada uma. De referir que foram utilizadas todas as vinte e duas pesquisas do TPC-H com excepção da pesquisa Q20 que foi retirada dos testes devido a alguns problemas na sua execução.

5.1. Bases de Dados com 1GB

Nestas experiências são avaliados os motores MySQL, Drizzle e TokuDB utilizando a base de dados do TPC-H com 1GB. A figura 1 mostra os valores médios obtidos pelas pesquisas do TPC-H na execução das três sequências (S1,S2 e S3).


115

Figura 1 - Média dos tempos de execução para 1GB

Analisando as pesquisas utilizadas, que podem ser consultadas em (TPC-H Documentation, 2013), é possível verificar que as pesquisas mais demoradas são as pesquisas Q9, Q10, Q13, Q14, Q18 e Q21, pois são aquelas que pesquisam informação em mais tabelas e que necessitam de fazer cálculos para chegar a um resultado final. As restantes pesquisas vão pesquisar num menor número de tabelas e algumas têm de fazer a pesquisa apenas num determinado intervalo de tempo, o que leva a que a quantidade de informação a pesquisar seja menor.

Como a pesquisa Q14 obtém valores bastante elevados relativamente às restantes, optámos por não a incluir para não prejudicar a legibilidade da Figura 1. Os resultados médios obtidos foram de 331.89, 398.54 e 5.11 segundos usando MySQL, Drizzle e TokuDB, respectivamente.

Na figura 2 é mostrado o tempo total de execução para as três sequências S1, S2 e S3, utilizando cada um dos motores de base de dados em análise.

Figura 2 - Tempo total de execução de todas as sequências para 1GB

Considerando o tempo total de execução para o conjunto das três sequências é possível verificar que o Drizzle é o que demora mais a executar todas as pesquisas, seguido do MySQL com uma diferença de 187.52 segundos (3min 7.52seg) de execução.


116

O mais rápido dos três é o TokuDB demorando apenas 904.98 segundos (15min 4.98seg) a executar todas as pesquisas. Assim tendo em consideração os resultados experimentais é possível concluir que o TokuDB é mais rápido 47% que o MySQL e 52% mais rápido que o Drizzle a executar as sequências de pesquisas. Por outro lado o Drizzle é 10% mais lento que o MySQL.

O Drizzle torna-se mais lento que o MySQL nas bases de dados de 1GB devido a ter sido desenhado para privilegiar a escalabilidade, executando várias transacções em simultâneo, o que não acontece neste conjunto de experiências. Nesta avaliação experimental não se executaram várias transacções em simultâneo e um tamanho de 1Gb ainda não é uma base de dados que se possa considerar de grande dimensão e por isso o Drizzle acaba por ser mais lento.

Como foi referido na definição do TokuDB, este foi desenhado para conseguir efectuar pesquisas mais rapidamente e para trabalhar com tabelas muito grandes. Apesar de na base de dados de 1Gb não haver tabelas muito grandes nota-se claramente que mesmo assim o TokuDB conseguiu atingir o objectivo de ter uma velocidade de execução superior aos restantes.

5.2. Bases de Dados com 10GB

A figura 3 mostra os valores médios obtidos pelas pesquisas do TPC-H na execução das três sequências (S1, S2 e S3), utilizando uma base de dados de 10GB.

Figura 3 - Média dos tempos de execução para 10GB

As pesquisas Q9 e Q14 têm valores elevados no MySQL e no Drizzle e por isso para simplificar, não foram incluídas nos gráficos. Para a pesquisa Q9 os resultados médios obtidos foram 35275.58, 27893.58 e 590.25 segundo; e para pesquisa Q14 foram 159103.40, 75704.07 e 64.44 segundo utilizando o MySQL, Drizzle e TokuDB, respectivamente.

Nesta base de dados, por já ter uma dimensão considerável, a pesquisa Q3 que apesar de ir procurar a sua informação a apenas três das oito tabelas mas que tem de fazer cálculos para chegar ao resultado final já demora um tempo considerável a executar. E o mesmo acontece com a Q7 e Q8 que apesar de pesquisarem num dado intervalo de datas, ainda é um intervalo considerável (dois anos) e pesquisam informação em cinco e sete tabelas respectivamente, necessitam de fazer cálculos complexos para obter o resultado final.

As pesquisas Q9, Q10, Q13, Q14 e Q18 mantêm nesta base de dados os seus valores elevados devido ao aumento da quantidade de informação e porque são pesquisas que não limitam a sua procura a um intervalo de tempo, utilizando toda a informação contida nas tabelas.


117

Figura 4 - Tempo total de execução de todas as sequências para 10GB

Com base nos resultados experimentais é possível concluir que quando se aumenta a capacidade de armazenamento das bases de dados de 1GB para 10GB o MySQL torna-se mais lento em relação às bases de dados NewSQL testadas, o que significa que o MySQL apesar de ter capacidade de armazenamento perde capacidade de desempenho em bases de dados com tamanho elevado.

Tal como já foi referido anteriormente o Drizzle privilegia escalabilidade e esse é um factor que se mostra decisivo numa base de dados com um tamanho, que se pode considerar de dimensão considerável, como a que se utilizou de 10 GB, fazendo com que o Drizzle em relação ao MySQL tenha uma melhoria de 39%.

Na base de dados de 10Gb é possível ver ainda melhor a capacidade do TokuDb fazer as suas pesquisas mais rapidamente, pois nesta base de dados já temos tabelas com um tamanho considerável e é possível verificar que o TokuDb foi realmente projectado para ser mais rápido que os outros sistemas pois nestas bases de dados o TokuDB destaca-se ainda mais, com uma melhoria de 95% em relação ao MySQL e 92% em relação ao Drizzle.

Também é possível concluir que o aumento da dimensão da base de dados leva a que demore muito mais tempo a execução das pesquisas. Apesar da dimensão destas bases de dados ser dez vezes maior que as anteriores, o aumento do tempo de execução não é proporcional pois aumenta 391 vezes, 213 vezes e 35 vezes para o MySQL, Drizzle e TokuDB respectivamente. Assim verifica-se que a base de dados menos afectada pelo aumento da dimensão foi o ToKuDB que continuou a ter um melhor desempenho em relação às outras bases de dados.

6. Conclusões e Trabalho Futuro

As bases de dados NewSQL foram criadas a pensar na melhoria de desempenho e no problema da falta de armazenamento que existe actualmente nas organizações, mas também para corrigir algumas das falhas que existem noutros sistemas de bases de dados. Por isso as bases de dados NewSQL como o TokuDB e o Drizzle foram projectadas para ter escalabilidade, isto é, suportarem bases de dados com grande dimensão e ainda serem mais eficazes a executar pesquisas.

Com esta avaliação experimental foi possível verificar que quando se trata de bases de dados relativamente pequenas, 1GB, o MySQL ainda tem um desempenho que se pode considerar positivo mesmo perdendo para o TokuDB. Mas quando aumentamos o tamanho das bases de


118

dados para 10GB nota-se que o MySQL não está preparado para a escalabilidade que as organizações virtuais poderão vir a necessitar nas suas bases de dados. Quando se trata de armazenar uma grande quantidade de dados e efectuar pesquisas nessas bases de dados, as organizações virtuais com certeza que irão ganhar muito quer em escalabilidade quer em desempenho com os sistemas NewSQL. Assim, estas bases de dados são excelentes opções para as organizações virtuais que contêm muitos dados.

Como trabalho futuro pretendemos avaliar outros motores de bases de dados NewSQL e efectuar também a avaliação experimental em organizações virtuais.

Referências

(Aslett , 2011) Aslett, Matthew (2011) NoSQL, NewSQL and Beyond: The answer to SPRAINed relational databases. Consultado em 24-03-2013, no site http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/

(Aslett 2, 2011) Aslett, Matthew (2011) What we talk about when we talk about NewSQL. Consultado em 20-09-2013, no site http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/

(Chamberlin & Boyce, 1974) Chamberlin, Donald D. and Boyce Raymond F.. 1974. SEQUEL: A structured English query language. In Proceedings of the 1974 ACM SIGFIDET workshop on Data description, access and control (now SIGMOD)). ACM, New York, NY, USA, 249-264.

(Codd, 1970) Codd, E. F. (Junho de 1970) A Relational Model of Data for Large Shared Banks. Communications of ACM13, 6 (June 1970), 377-387. Doi=10.1145/362384.362685.

(DBEngines Ranking, 2013) DBEngines Ranking, (2013) Consultado em 07-10-2013, no site http://db-engines.com/en/ranking

(Drizzle Documentation, 2010) Drizzle Documentation (2010). Consultado em 03-10-2013, no site http://docs.drizzle.org/index.html

(Getting Started with Drizzle and PHP, 2009) Getting Started with Drizzle and PHP (2009). Consultado em 03-10-2013, no site http://devzone.zend.com/1504/getting-started-with-drizzle-and-php/

(Mehta, 2013) Mehta, Chirag (2013). A Journey from SQL to NoSQL to NewSQL. Consultado em 28-02-2013, no site http://www.cloudave.com/25272/a-journey-from-sql-to-nosql-to-newsql/

(Plew & Stephens, 2002) Plew, Ron & Stephens, Ryan (2002) What is SQL? Consultado em 12-09-2013, no site http://www.informit.com/library/content.aspx?b=STY_Sql_24hours&seqNum=9

(Stonebraker, 2012) Stonebraker, Michael (Novembro de 2012). New Opportunities for NewSQL. Communications of the ACM, Vol. 55 No. 11, Pages 10-11 10.1145/2366316.2366319

(TokuDB Documentation, s.d.) TokuDB Documentation (s.d.). Consultado em 02-10-2013 no site http://www.tokutek.com/2011/02/1773/

(TPCH-H Documentation, 2013) TPC-H Documentation (Junho de 2013). Consultado em 24-09-2013, no site http://www.tpc.org/tpch/spec/tpch2.15.0.pdf

(Ulin & Young, 2013) Ulin, Tomas & Young, Rob (2013). Developer and DBA Guide to What´s New in MySQL 5.6. Consultado em 03-04-2013, no site http://www.mysql.com/why-mysql/white-papers/whats-new-mysql-5-6/

(Venkatesh & S, 2012) Venkatesh, Prasanna & S, Nirmala (2012). NewSQL – The new way to handle big data. Consultado em 01-03-2013, no site http://www.linuxforu.com/2012/01/newsql-handle-big-data/

















119

Anexo I Proposta de Projecto


120

bases de dados newsql: uma avaliação...

Documents