Bases de Dados NewSQL: uma avaliação experimental

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
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.
v
Bases de Dados NewSQL
Resumo
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
vii
Bases de Dados NewSQL
Resumo
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
viii
Í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
4
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
Sistemas NewSQL ............................................................................................... 21
4.1
MySQL .................................................................................................................. 22
4.2
Drizzle ................................................................................................................... 23
4.3
TokuDB ................................................................................................................. 24
4.4
NuoDB ................................................................................................................... 26
ix
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
8
Bases de dados de com 10GB .............................................................................. 57
7.3.1
MySQL vs Drizzle vs TokuDB ........................................................................ 59
7.3.2
StormDB ........................................................................................................... 62
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
x
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
xi
Í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
xii
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) --------------------------------------------------------------------------------------- 53
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
MySQL, Drizzle e TokuDB) --------------------------------------------------------------------------------------- 55
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.8 - Sequência 2 para 1GB (VoltDB vsMysql,Drizzle e TokuDB) ------------------------------- 103
Figura F.9 - Sequência 3 para 1GB (VoltDB vsMysql,Drizzle e TokuDB) ------------------------------- 104
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
xiii
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
xiv
Í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 F.3 - Valores da pesquisa Q18 (NuoDB vsMysql,Drizzle e TokuDB) ---------------------------- 102
Tabela F.4 - Valores da pesquisa Q22 (NuoDB vsMysql,Drizzle e TokuDB) ---------------------------- 103
Tabela G.1 – Valores da pesquisa Q9 para 10GB ----------------------------------------------------------- 107
Tabela G.2 – Valores da pesquisa Q14 para 10GB --------------------------------------------------------- 107
xv
Bases de Dados NewSQL
Notação e Glossário
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
xvii
Bases de Dados NewSQL
Capítulo 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
1
Bases de Dados NewSQL
Capítulo 1
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;
2
Bases de Dados NewSQL
Capítulo 1
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.
3
Bases de Dados NewSQL
4
Capítulo 1
Bases de Dados NewSQL
Capítulo 2
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.
5
Bases de Dados NewSQL
Capítulo 2
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.
6
Bases de Dados NewSQL
Capítulo 2
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
7
Bases de Dados NewSQL
Capítulo 2
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).
8
Bases de Dados NewSQL
Capítulo 2
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:
9
Bases de Dados NewSQL

Capítulo 2
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.
10
Bases de Dados NewSQL
Capítulo 3
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;
11
Bases de Dados NewSQL

Capítulo 3
É 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
12
Bases de Dados NewSQL
Capítulo 3
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;
13
Bases de Dados NewSQL
Capítulo 3
 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
14
Bases de Dados NewSQL
Capítulo 3
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.
15
Bases de Dados NewSQL
Capítulo 3
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.
16
Bases de Dados NewSQL
Capítulo 3
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
17
Bases de Dados NewSQL
Capítulo 3
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
18
Bases de Dados NewSQL
Capítulo 3
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,
19
Bases de Dados NewSQL
Capítulo 3
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.
20
Bases de Dados NewSQL
Capítulo 4
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 (DBEngines 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-aService (StormDB)
21
Bases de Dados NewSQL
Capítulo 4
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.
22
Bases de Dados NewSQL
Capítulo 4
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).
23
Bases de Dados NewSQL
Capítulo 4
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.
24
Bases de Dados NewSQL
Capítulo 4
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.
25
Bases de Dados NewSQL
Capítulo 4
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.
26
Bases de Dados NewSQL
Capítulo 4
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:
27
Bases de Dados NewSQL
Capítulo 4

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.
28
Bases de Dados NewSQL
Capítulo 4
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
29
Bases de Dados NewSQL
Capítulo 4
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).
30
Bases de Dados NewSQL
Capítulo 4
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.
31
Bases de Dados NewSQL
32
Capítulo 4
Bases de Dados NewSQL
Capítulo 5
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
33
Bases de Dados NewSQL
Capítulo 5
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;

34
Q5 – lista o volume de receitas feito através de fornecedores locais;
Bases de Dados NewSQL

Capítulo 5
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;
35
Bases de Dados NewSQL

Capítulo 5
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.
36
Bases de Dados NewSQL
Capítulo 6
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-04precise/ 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
http://devzone.zend.com/1504/getting-started-with-drizzle-and-php/
e
através
em
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
37
Bases de Dados NewSQL
Capítulo 6
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.
38
Bases de Dados NewSQL
Capítulo 7
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.
39
Bases de Dados NewSQL
Capítulo 7
Tabela 7.1 – Comparação das características técnicas dos Sistemas NewSQL
Modelo da
Base de Dados
Drizzle
TokuDB
NuoDB
Relacional
Relacional
Relacional
SQL
SQL
SQL
ACID /
ACID /
MVCC
MVCC
VoltDB
StormDB
Relacional Relacional
Linguagem
para
SQL/Rest
SQL
ACID
MVCC
pesquisas
Modelo de
Integridade
MVCC
ACID
Sim
Sim
Sim
Sim
Sim
Transacções
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Não
Não
Sim
Sim
Sim
Desconhecido
Não
Sim
Sim
2GB
1GB
4GB
4GB
Cloud
Sim
Sim
Sim
Sim
Não
Sim
Sim
Sim
+/-
Sim
Sim
Sim
Sim
Sim
Não
Sim
Sim
Não
Escalabilidade
Horizontal
Sharding
Arquitectura
Sharednothing
Memória
mínima
Open source
Fácil de
utilizar
Manual de
utilização
Fóruns de
dúvidas
40
Sim mas
pouco
esclarecedor
Não
Bases de Dados NewSQL
Capítulo 7
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.
41
Bases de Dados NewSQL
Capítulo 7
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
42
Bases de Dados NewSQL
Capítulo 7
Tabela 7.3 – Tempos obtidos para a criação de chaves primárias para 1GB
Nation Region
Part
Supplier Partsupp Customer Orders Lineitem
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.
43
Bases de Dados NewSQL
Capítulo 7
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
44
Bases de Dados NewSQL
Capítulo 7
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.
45
Bases de Dados NewSQL
Capítulo 7
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.
46
Bases de Dados NewSQL
Capítulo 7
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
47
Bases de Dados NewSQL
Capítulo 7
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
48
Bases de Dados NewSQL
Capítulo 7
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.
49
Bases de Dados NewSQL
Capítulo 7
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)
50
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
Bases de Dados NewSQL
Capítulo 7
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.
51
Bases de Dados NewSQL
Capítulo 7
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
52
Bases de Dados NewSQL
Capítulo 7
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.
53
Bases de Dados NewSQL
Capítulo 7
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.
54
Bases de Dados NewSQL
Capítulo 7
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)
55
Bases de Dados NewSQL
Capítulo 7
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
56
Bases de Dados NewSQL
Capítulo 7
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
57
Bases de Dados NewSQL
Capítulo 7
Tabela 7.7 – Tempo de carregamento de dados para 10GB
Nation Region
Part
Supplier Partsupp Customer
Orders
Lineitem
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
Nation Region
Part
Supplier Partsupp Customer
Orders
Lineitem
6656.58
MySQL
1.37
3.16
162.46
9.49
878.57
134.04
1243.90
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
StormDB
0.61
0.54
1.09
0.77
4.06
0.84
5.55
2842.49
20.64
Tabela 7.9 – Tempos obtidos para a criação de chaves forasteiras para 10GB
Nation Supplier Partsupp Customer
Orders
Lineitem
83253.01
MySQL
4.53
9.51
1267.18
132.37
7521.12
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.
58
Bases de Dados NewSQL
Capítulo 7
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.
59
Bases de Dados NewSQL
Capítulo 7
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
60
Bases de Dados NewSQL
Capítulo 7
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
61
Bases de Dados NewSQL
Capítulo 7
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)
62
Bases de Dados NewSQL
Capítulo 7
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.
63
Bases de Dados NewSQL
64
Capítulo 7
Bases de Dados NewSQL
Capítulo 8
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.
65
Bases de Dados NewSQL
Capítulo 8
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.
66
Bases de Dados NewSQL
Referências
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/NoSQLBasel/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-talkabout-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-newsqland-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-phonenetworks-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
67
Bases de Dados NewSQL
Referências
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-extractingvalue-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-sqlto-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://nosqldatabases.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
68
Bases de Dados NewSQL
Referências
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/whymysql/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).
http://en.wikipedia.org/wiki/VoltDB
Consultado
em
04-04-2013,
no
site
Why StormDB (2013) Consultado em 22 de Novembro de 2013, no site
http://www.stormdb.com/
69
Bases de Dados NewSQL
Referências
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/
70
Bases de Dados NewSQL
Anexo A
Anexos
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.
71
Bases de Dados NewSQL
Anexos
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.
72
Bases de Dados NewSQL
Anexos
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.
73
Bases de Dados NewSQL
Anexos
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.
74
Bases de Dados NewSQL
Anexo B
Anexos
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
75
Bases de Dados NewSQL
Anexos
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:
Welcome to the MySQL monitor. Commands end with ; or \g.
76
Bases de Dados NewSQL
Anexos
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>
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
77
Bases de Dados NewSQL
Anexos
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
78
Bases de Dados NewSQL
Anexos
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
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.30-tokudb-7.0.4 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>
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:
79
Bases de Dados NewSQL
Archive
directory:
Anexos
/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
80
Bases de Dados NewSQL
Anexo C
Anexos
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.
81
Bases de Dados NewSQL
Anexos
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]
82
Bases de Dados NewSQL
Anexo D
Anexos
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
83
Bases de Dados NewSQL
and r_name = 'AMERICA'
and ps_supplycost = (
select
min(ps_supplycost)
from
partsupp,
supplier,
nation,
region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
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
84
Anexos
Bases de Dados NewSQL
Anexos
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_orderkey = o_orderkey
and l_suppkey = s_suppkey
and c_nationkey = s_nationkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
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;
85
Bases de Dados NewSQL
Anexos
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 c_custkey = o_custkey
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
86
Bases de Dados NewSQL
Anexos
part,
supplier,
lineitem,
orders,
customer,
nation n1,
nation n2,
region
where
p_partkey = l_partkey
and s_suppkey = l_suppkey
and l_orderkey = o_orderkey
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 o_orderkey = l_orderkey
and s_nationkey = n_nationkey
and p_name like '%maroon%'
) as profit
group by
nation,
87
Bases de Dados NewSQL
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
c_custkey = o_custkey
and l_orderkey = o_orderkey
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 s_nationkey = n_nationkey
and n_name = 'UNITED KINGDOM'
group by
ps_partkey having
sum(ps_supplycost * ps_availqty) > (
select
88
Anexos
Bases de Dados NewSQL
Anexos
sum(ps_supplycost * ps_availqty) *
0.0000100000
from
partsupp,
supplier,
nation
where
ps_suppkey = s_suppkey
and s_nationkey = n_nationkey
and n_name = 'UNITED KINGDOM'
)
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
(
89
Bases de Dados NewSQL
Anexos
select
c_custkey,
count(o_orderkey) as c_count
from
customer left outer join orders on
c_custkey = o_custkey
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
90
Bases de Dados NewSQL
Anexos
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
p_partkey = ps_partkey
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,
91
Bases de Dados NewSQL
Anexos
part
where
p_partkey = l_partkey
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
)
and c_custkey = o_custkey
and o_orderkey = l_orderkey
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
(
92
Bases de Dados NewSQL
Anexos
p_partkey = l_partkey
and p_brand = 'Brand#31'
and p_container in ('SM CASE', 'SM BOX', 'SM PACK',
'SM PKG')
and
and
and
and
l_quantity >= 5 and l_quantity <= 5 + 10
p_size between 1 and 5
l_shipmode in ('AIR', 'AIR REG')
l_shipinstruct = 'DELIVER IN PERSON'
)
or
(
p_partkey = l_partkey
and p_brand = 'Brand#43'
and p_container in ('MED BAG', 'MED BOX', 'MED PKG',
'MED PACK')
and
and
and
and
l_quantity >= 20 and l_quantity <= 20 + 10
p_size between 1 and 10
l_shipmode in ('AIR', 'AIR REG')
l_shipinstruct = 'DELIVER IN PERSON'
)
or
(
p_partkey = l_partkey
and p_brand = 'Brand#15'
and p_container in ('LG CASE', 'LG BOX', 'LG PACK',
'LG PKG')
and
and
and
and
l_quantity >= 27 and l_quantity <= 27 + 10
p_size between 1 and 15
l_shipmode in ('AIR', 'AIR REG')
l_shipinstruct = 'DELIVER IN PERSON'
);
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 > (
93
Bases de Dados NewSQL
Anexos
select
0.5 * sum(l_quantity)
from
lineitem
where
l_partkey = ps_partkey
and l_suppkey = ps_suppkey
and l_shipdate >= date '199501-01'
and l_shipdate < date '199501-01' + interval '1' year
)
)
and s_nationkey = n_nationkey
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
)
and s_nationkey = n_nationkey
and n_name = 'UNITED KINGDOM'
group by
s_name
order by
numwait desc,
s_name
limit 100;
94
Bases de Dados NewSQL
Anexos
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;
95
Bases de Dados NewSQL
Anexo E
Anexos
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[1]+"|");
novo1.write(campos[2]+"|");
novo1.write(campos[3]+"|");
novo1.write(campos[4]+"\n");
}
while(ler2.hasNextLine())
{
linha = ler2.nextLine();
campos=linha.split("\\|");
novo2.write(campos[0]+"|");
novo2.write(campos[1]+"|");
novo2.write(campos[2]+"|");
novo2.write(campos[3]+"|");
novo2.write(campos[4]+"|");
novo2.write(campos[5]+"|");
novo2.write(campos[6]+"|");
novo2.write(campos[7]+"|");
novo2.write(campos[8]+"\n");
}
while(ler3.hasNextLine())
{
linha = ler3.nextLine();
campos=linha.split("\\|");
novo3.write(campos[0]+"|");
novo3.write(campos[1]+"|");
novo3.write(campos[2]+"|");
novo3.write(campos[3]+"|");
novo3.write(campos[4]+"|");
novo3.write(campos[5]+"|");
96
Bases de Dados NewSQL
Anexos
novo3.write(campos[6]+"|");
novo3.write(campos[7]+"|");
novo3.write(campos[8]+"|");
novo3.write(campos[9]+"|");
novo3.write(campos[10]+"|");
novo3.write(campos[11]+"|");
novo3.write(campos[12]+"|");
novo3.write(campos[13]+"|");
novo3.write(campos[14]+"|");
novo3.write(campos[15]+"\n");
}
while(ler4.hasNextLine())
{
linha = ler4.nextLine();
campos=linha.split("\\|");
novo4.write(campos[0]+"|");
novo4.write(campos[1]+"|");
novo4.write(campos[2]+"|");
novo4.write(campos[3]+"\n");
}
while(ler5.hasNextLine())
{
linha = ler5.nextLine();
campos=linha.split("\\|");
novo5.write(campos[0]+"|");
novo5.write(campos[1]+"|");
novo5.write(campos[2]+"\n");
}
while(ler6.hasNextLine())
{
linha = ler6.nextLine();
campos=linha.split("\\|");
novo6.write(campos[0]+"|");
novo6.write(campos[1]+"|");
novo6.write(campos[2]+"|");
novo6.write(campos[3]+"|");
novo6.write(campos[4]+"|");
novo6.write(campos[5]+"|");
novo6.write(campos[6]+"|");
novo6.write(campos[7]+"|");
novo6.write(campos[8]+"\n");
}
while(ler7.hasNextLine())
{
linha = ler7.nextLine();
campos=linha.split("\\|");
novo7.write(campos[0]+"|");
novo7.write(campos[1]+"|");
novo7.write(campos[2]+"|");
novo7.write(campos[3]+"|");
novo7.write(campos[4]+"|");
novo7.write(campos[5]+"|");
novo7.write(campos[6]+"\n");
}
while(ler8.hasNextLine())
{
linha = ler8.nextLine();
campos=linha.split("\\|");
novo8.write(campos[0]+"|");
novo8.write(campos[1]+"|");
novo8.write(campos[2]+"|");
novo8.write(campos[3]+"|");
novo8.write(campos[4]+"|");
novo8.write(campos[5]+"|");
novo8.write(campos[6]+"|");
novo8.write(campos[7]+"\n");
}
ler1.close();
ler2.close();
ler3.close();
ler4.close();
ler5.close();
97
Bases de Dados NewSQL
Anexos
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();
campos=linha.split("\\|");
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(campos[1]+"|");
novo.write(campos[2]+"|");
novo.write(campos[3]+"|");
novo.write(campos[4]+"|");
novo.write(campos[5]+"|");
novo.write(campos[6]+"|");
novo.write(campos[7]+"|");
novo.write(campos[8]+"|");
novo.write(campos[9]+"|");
novo.write((c.getTimeInMillis()+3600000)*1000+"|");
novo.write((c2.getTimeInMillis()+3600000)*1000+"|");
novo.write((c3.getTimeInMillis()+3600000)*1000+"|");
novo.write(campos[13]+"|");
novo.write(campos[14]+"|");
novo.write(campos[15]);
novo.write("\n");
}
while(ler2.hasNextLine())
{
linha = ler2.nextLine();
98
Bases de Dados NewSQL
Anexos
campos=linha.split("\\|");
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(campos[0]+"|");
novo2.write(campos[1]+"|");
novo2.write(campos[2]+"|");
novo2.write(campos[3]+"|");
novo2.write((c.getTimeInMillis()+3600000)*1000+"|");
novo2.write(campos[5]+"|");
novo2.write(campos[6]+"|");
novo2.write(campos[7]+"|");
novo2.write(campos[8]);
novo2.write("\n");
}
ler.close();
ler2.close();
novo.close();
novo2.close();
}
}
99
Bases de Dados NewSQL
Anexo F
Anexos
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
100
Bases de Dados NewSQL
Anexos
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)
101
Bases de Dados NewSQL
Anexos
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
Tabela F.3 - Valores da pesquisa Q18 (NuoDB vsMysql,Drizzle e TokuDB)
102
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
Bases de Dados NewSQL
Anexos
Tabela F.4 - Valores da pesquisa Q22 (NuoDB vsMysql,Drizzle e TokuDB)
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)
Figura F.8 - Sequência 2 para 1GB (VoltDB vsMysql,Drizzle e TokuDB)
103
Bases de Dados NewSQL
Anexos
Figura F.9 - Sequência 3 para 1GB (VoltDB vsMysql,Drizzle e TokuDB)
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)
104
Bases de Dados NewSQL
Anexos
Figura F.12 - Sequência 3 para 1GB (StormDB vsMysql,Drizzle e TokuDB)
105
Bases de Dados NewSQL
Anexo G
Anexos
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
106
Bases de Dados NewSQL
Anexos
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
107
Bases de Dados NewSQL
Anexos
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)
108
Bases de Dados NewSQL
Anexo H
Anexos
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]
Instituto Politécnico de Coimbra – Instituto Superior de Engenharia de Coimbra, Rua Pedro Nunes, 3030-199,
Coimbra, Portugal
1
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.
109
Bases de Dados NewSQL
Anexos
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.
110
Bases de Dados NewSQL
Anexos
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:
111
Bases de Dados NewSQL
Anexos
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.
112
Bases de Dados NewSQL
Anexos
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 adhoc 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).
113
Bases de Dados NewSQL
Anexos
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
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
Tabelas
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;

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.
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).
114
Bases de Dados NewSQL
Anexos
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.
115
Bases de Dados NewSQL
Anexos
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.
116
Bases de Dados NewSQL
Anexos
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
117
Bases de Dados NewSQL
Anexos
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-newsqland-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-talkabout-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-withdrizzle-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-nosqlto-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 2409-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/whymysql/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/
118
Bases de Dados NewSQL
Anexo I
Anexos
Proposta de Projecto
119
Bases de Dados NewSQL
120
Anexos