Bases de Dados NewSQL: uma avaliação experimental

Transcrição

1 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

2 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

3 Ao meu namorado e à minha família

4

5 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

6

7 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

8 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

9 Í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 O problema do crescimento dos dados Evolução do SQL ao NewSQL NoSQL NewSQL Porquê criar o NewSQL? Problemas do SQL Características das soluções NewSQL Categorias do NewSQL Novas Arquitecturas Novos motores de armazenamento MySQL Sharding Transparente NewSQL-as-a-Service Sistemas NewSQL MySQL Drizzle TokuDB NuoDB ix

10 4.5 VoltDB StormDB Ambiente experimental TPC-H Benchmark Características a avaliar Principais dificuldades Avaliação Experimental Comparação de características técnicas Bases de dados com 1GB MySQL vs Drizzle vs TokuDB NuoDB VoltDB StormDB Bases de dados de com 10GB MySQL vs Drizzle vs TokuDB StormDB Conclusões e trabalho futuro Referências Anexo A Tutorial de instalação do Ubuntu Anexo B Tutorial de instalação do MySQL e dos sistemas NewSQL B.1 MySQL B.2 Drizzle B.3 TokuDB B.4 NuoDB B.5 VoltDB Anexo C Como utilizar o TPC-H Anexo D Pesquisas do TPC-H x

11 Anexo E Scripts utilizados no VoltDB E.1 Script E.2 Script Anexo F Resultados para a base de dados de 1GB Anexo G Resultados da base de dados de 10GB Anexo H Artigo Científico Anexo I Proposta de Projecto xi

12 Índice de Figuras Figura 2.1- Estimativa dos dados gerados em todo mundo entre 2005 e 2011, em exabytes, adaptado de (Gantz & Reinsel, 2011) Figura 2.2 Crescimento dos 3 Vs (Rouse, 2013) Figura Armazenamento distribuído dos dados (Venkatesh & S, 2012) Figura 3.1 Sharding de uma base de dados Figura 4.1 Ecossistema NewSQL, (451 Group, 2012) Figura 4.2 Interface do MySQL no Ubuntu Figura 4.3 Interface do Drizzle Figura 4.4 Interface do TokuDB Figura 4.5 Interface do domain Figura 4.6 Interface do NuoSQL Figura 4.7 Interface do servidor do VoltDB Figura 4.8 Interface do sqlcmd do VoltDB Figura 4.9 Interface StormDB Figura 4.10 Gestão da base de dados no StormDB Figura 5.1 Esquema da base de dados do TPC-H Figura 7.1 Tempo de criação das tabelas para 1GB Figura 7.2 Erro ao definir uma chave forasteira no StormDB Figura 7.3 Definição correcta de uma chave forasteira no StormDB Figura 7.4 Média dos tempos de execução para 1GB após executar as três sequências Figura 7.5 Tempo total de execução de todas as sequências para 1GB Figura Média dos tempos de execução para 1GB após esxecutar as três sequências (NuoDB MySQL, Drizzle e TokuDB) Figura Tempo total de execução de todas as sequências para 1GB (NuoDB MySQL, Drizzle e TokuDB) Figura Erro VoltDB, order join Figura 7.9 Erro VoltDB, condição having Figura 7.10 Erro VoltDB, criar vistas e pesquisas com subpesquisas Figura 7.11 Erro VoltDB, espaço para tabela temporária excedido xii

13 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) 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) Figura 7.15 Erro StormDB 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) 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) Figura 7.19 Utilização de memória pelo NuoDB e VoltDB Figura 7.20 Tempo de criação das tabelas para 10GB Figura 7.21 Média dos tempos de execução para 10GB Figura 7.22 Tempo total de execução para 10GB Figura Tempo total de execução para 10GB (StormDB MySQL, Drizzle e TokuDB) Figura 7.24 Desvio padrão para 10GB (StormDB MySQL, Drizzle e TokuDB) Figura 7.25 Tempo total de execução para 10GB (StormDB MySQL, Drizzle e TokuDB) 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 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) Figura F.6 - Sequência 3 para 1GB (NuoDB vsmysql,drizzle e TokuDB) 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) 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) Figura F.12 - Sequência 3 para 1GB (StormDB vsmysql,drizzle e TokuDB) Figura G.1 - Sequência 1 para 10G Figura G.2 - Sequência 2 para 10GB Figura G.3 Sequência 3 para 10GB xiii

14 Figura G.4 - Sequência 1 para 10GB (StormDB MySQL, Drizzle e TokuDB) Figura G.5- Sequência 2 para 10GB (StormDB MySQL, Drizzle e TokuDB) Figura G.6 - Sequência 3 para 10GB (StormDB MySQL, Drizzle e TokuDB) xiv

15 Índice de Tabelas Tabela Caracterização das tabelas do TPC-H para 1GB e 10GB Tabela 7.1 Comparação das características técnicas dos Sistemas NewSQL Tabela 7.2 Tempos de carregamento de dados para 1GB em segundos Tabela 7.3 Tempos obtidos para a criação de chaves primárias para 1GB Tabela 7.4 Tempos obtidos para a criação de chaves forasteiras para 1GB Tabela 7.5 Desvio padrão para 1GB Tabela 7.6 Desvio padrão para 1GB (NuoDB MySQL, Drizzle e TokuDB) Tabela 7.7 Tempo de carregamento de dados para 10GB Tabela 7.8 Tempos obtidos para a criação de chaves primárias para 10GB Tabela 7.9 Tempos obtidos para a criação de chaves forasteiras para 10GB Tabela 7.10 Desvio padrão para 10GB Tabela F.1 Valores da pesquisa Q14 para 1GB Tabela F.2 - Valores da pesquisa Q15 (NuoDB vsmysql,drizzle e TokuDB) Tabela F.3 - Valores da pesquisa Q18 (NuoDB vsmysql,drizzle e TokuDB) Tabela F.4 - Valores da pesquisa Q22 (NuoDB vsmysql,drizzle e TokuDB) Tabela G.1 Valores da pesquisa Q9 para 10GB Tabela G.2 Valores da pesquisa Q14 para 10GB xv

16

17 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

18

19 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

20 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

21 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

22 Bases de Dados NewSQL Capítulo 1 4

23 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 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

24 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 exabytes, e vão continuar a crescer até aos 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, 2 60 bytes. O prefixo exa é um termo decimal são 1,152,921,504,606,846,976 bytes em decimal, um pouco mais que 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

25 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

26 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 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 de páginas e a cada vinte minutos eram partilhados de links, enviavam-se de pedidos de amizade e eram enviadas 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

27 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 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

28 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

29 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

30 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

31 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

32 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

33 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

34 Bases de Dados NewSQL Capítulo 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

35 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

36 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 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

37 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 Dois exemplos deste tipo de sistemas são o VoltDB e o SQLFire (NewSQL, 2013) 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) 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) 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

38 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

39 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 (DB- Engines Ranking, 2013), sendo por isso utilizada como referência na avaliação das bases de dados NewSQL. Na figura 4.1 podemos ver o ecossistema NewSQL, isto é, como estão distribuídos os vários sistemas pelas categorias NewSQL. Figura 4.1 Ecossistema NewSQL, (451 Group, 2012) Como é possível ver existem quatro grandes categorias por onde se distribuem os diversos sistemas NewSQL: Novas bases de dados (New Databases); Motores de armazenamento (Storage engines); Clustering/Sharding; NewSQL-as-a-Service; Os sistemas testados e que iremos descrever de seguida pertencem às categorias New Databases (Drizzle, VoltDB, NuoDB), Storage engines (TokuDB) e NewSQL-as-a- Service (StormDB) 21

40 Bases de Dados NewSQL Capítulo MySQL O MySQL foi criado em 1995 por David Axmark, Allan Larsson and Michael "Monty" Widenius da empresa MySQL AB e o seu site é 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 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

41 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 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 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

42 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 é A versão do TokuDB utilizada para executar os testes foi a tokudb

43 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

44 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 é 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

45 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 4.5 VoltDB Figura 4.6 Interface do NuoSQL 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 O site deste sistema é 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

46 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

47 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 4.6 StormDB Figura 4.8 Interface do sqlcmd do VoltDB 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 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

48 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

49 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

50 Bases de Dados NewSQL Capítulo 4 32

51 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 LTS 64-bit, memória (RAM) de 8GB, processador Intel Core i7 CPU 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 Caracterização das tabelas do TPC-H para 1GB e 10GB 1GB 10GB Nation Region 5 5 Part Supplier Partsupp Customer

52 Bases de Dados NewSQL Capítulo 5 Orders Lineitem TOTAL Figura 5.1 Esquema da base de dados do TPC-H O TPC-H tem vinte e duas pesquisas que designamos Q1 a Q22, as quais explicamos de seguida: Q1 volume de negócios que foi facturado e enviado; Q2 procura que fornecedor deve ser seleccionado para fazer o pedido de uma determinada peça numa determinada região; Q3 retorna as 10 encomendas com o valor mais alto que não foram enviadas; Q4 determina se o sistema de ordem de prioridade está a funcionar correctamente e dá uma avaliação da satisfação do cliente; Q5 lista o volume de receitas feito através de fornecedores locais; 34

53 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

54 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

55 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 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 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 precise/ que consistia em remover completamente a versão do MySQL que o Ubuntu tem no seu repositório, mover a pasta my.cnf da localização utilizada por defeito pelo MySQL para uma nova localização e colocar o novo scrip de inicialização do MySQL que está incluído na versão recente, que fizemos download do site, na directoria correcta para que o MySQL funcionasse correctamente. Outro sistema testado foi o Drizzle e para procedermos à sua instalação recorremos à documentação disponibilizada no site deste sistema. Mas de cada vez que seguíamos os passos indicados não obtinhamos uma instalação correcta, chegando por isso à conclusão de que esta documentação é pouco clara. Conseguimos instalar correctamente o Drizzle através dos passos disponibilizados em e através da instalação de pacotes extras que foram sendo pedidos ao longo da instalação. No VoltDB foram várias as dificuldades encontradas: Os dados para carregar as tabelas estão armazenados em vários ficheiros, sendo que a separação de cada campo é feita através do caracter. No 37

56 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

57 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 39

58 Bases de Dados NewSQL Capítulo 7 Tabela 7.1 Comparação das características técnicas dos Sistemas NewSQL Drizzle TokuDB NuoDB VoltDB StormDB Modelo da Base de Dados Linguagem para pesquisas Relacional Relacional Relacional Relacional Relacional SQL SQL SQL SQL/Rest SQL Modelo de Integridade MVCC ACID / MVCC ACID / MVCC ACID MVCC ACID Sim Sim Sim Sim Sim Transacções Sim Sim Sim Sim Sim Escalabilidade Horizontal Sim Sim Sim Sim Sim Sharding Sim Não Não Sim Sim Arquitectura Sharednothing Memória mínima Sim Desconhecido Não Sim Sim 2GB 1GB 4GB 4GB Cloud Open source Sim Sim Sim Sim Não Fácil de utilizar Sim Sim Sim +/- Sim Manual de utilização Sim mas pouco esclarecedor Sim Sim Sim Sim Fóruns de dúvidas Não Não Sim Sim Não 40

59 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

60 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 Drizzle TokuDB NuoDB VoltDB StormDB

61 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 Drizzle TokuDB NuoDB StormDB Tabela 7.4 Tempos obtidos para a criação de chaves forasteiras para 1GB Nation Supplier Partsupp Customer Orders Lineitem MySQL Drizzle TokuDB 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

62 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

63 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 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

64 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

65 Bases de Dados NewSQL Capítulo 7 Tabela 7.5 Desvio padrão para 1GB MySQL Drizzle TokuDB Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 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

66 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 segundos (3min 7.52seg) de execução. O mais rápido dos três é o TokuDB demorando apenas segundos (15min 4.98seg) a executar todas as pesquisas. Assim tendo em consideração os resultados 48

67 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 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

68 Bases de Dados NewSQL Capítulo 7 Figura 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 segundos; Q18 tem uma média de 46, 35, 96 e segundos; por fim a Q22 tem uma média de 0.31, 0.35, 0.45 e 6794 segundos para o MySQL, Drizzle, TokuDB e NuoDB respectivamente. Tabela 7.6 Desvio padrão para 1GB (NuoDB MySQL, Drizzle e TokuDB) MySQL Drizzle TokuDB NuoDB Q Q Q Q Q Q Q

69 Bases de Dados NewSQL Capítulo 7 Q Q Q Q Q Q Q Q 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 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, e vezes que o MySQL, Drizzle e TokuDB, respectivamente, nas pesquisas executadas. 51

70 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 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 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

71 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 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 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

72 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

73 Bases de Dados NewSQL Capítulo 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 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

74 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

75 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

76 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 Drizzle TokuDB StormDB Tabela 7.8 Tempos obtidos para a criação de chaves primárias para 10GB Nation Region Part Supplier Partsupp Customer Orders Lineitem MySQL Drizzle TokuDB StormDB Tabela 7.9 Tempos obtidos para a criação de chaves forasteiras para 10GB Nation Supplier Partsupp Customer Orders Lineitem MySQL Drizzle TokuDB 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

77 Bases de Dados NewSQL Capítulo 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, e de 590; já a média da pesquisa Q14 é de , 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

78 Bases de Dados NewSQL Capítulo 7 Tabela 7.10 Desvio padrão para 10GB MySQL Drizzle TokuDB Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 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

79 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

80 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 StormDB Figura Tempo total de execução para 10GB (StormDB MySQL, Drizzle e TokuDB) A média da pesquisa Q14 é de , 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

81 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

82 Bases de Dados NewSQL Capítulo 7 64

83 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

84 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

85 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 , no site Basel/mattNosqlRoadshowBasel.pdf Aslett, Matthew (2011) What we talk about whe we talk about NewSQL. Consultado em 25 de Fevereiro de 2013, no site Aslett, Matthew (2011) NoSQL, NewSQL and Beyond: The answer to SPRAINed relational databases. Consultado em 24 de Março de 2013, no site Autopia Blog (2011) Cellphone Networks and the Future of Traffic. Consultado em 10 de Novembro de 2013, no site Big Data in 2020 (2012) Consultado em 22 de Novembro de 2013, no site Caldeira, Teresa (2006). Bases de Dados. Consultado em 8 de Novembro de 2013, no site 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 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, Codd, E. F. (Junho de 1970) A Relational Model of Data for Large Shared Banks. Communications of ACM13, 6 (June 1970), Doi= / DB-Engines Ranking (2013) Consultado em 11 de Novembro de 2013, no site Drizzle Documentation (2010). Consultado em 3 de Outubro de 2013, no site 67

86 Bases de Dados NewSQL Referências Facebook Statistics (2013) Consultado em 10 de Novembro de 2013, no site Gantz, John & Reinsel, David (2011). Extracting value from chaos. Consultado em , no site Getting Started with Drizzle and PHP (2009). Consultado em 3 de Outubro de 2013, no site Mehta, Chirag (2013). A Journey from SQL to NoSQL to NewSQL. Consultado em 28 de Fevereiro de 2013, no site More Process (2013) Pros, advantages of SQL (Structured Query Language). Consultado em 11 de Novembro de 2013, no site 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 NoSQL (s.d.). Consultado em 24 de Março de 2013, no site NoSQL Wikipédia (2013). Consultado em 20 de Novembro de 2013, no site NuoDB - Wikipédia (2013). Consultado em 7 de Agosto de 2013, no site NuoDB without compromisse (2013) Consultado em 7 de Agosto de 2013, no site Plew, Ron & Stephens, Ryan (2002) What is SQL? Consultado em 12 de Setembro de 2013, no site Rouse, Margaret (2005). Exabyte (EB). Consultado em 6 de Março de 2013, no site Rouse, Margaret (2013). 3 Vs (Volume, variety and velocity). Consultado em 10 de Novembro de 2013, no site 68

87 Bases de Dados NewSQL Referências Silva, José da (2013) Moving from SQL to NoSQL. Consultado em 11 de Novembro de 2013, no site Stonebraker, Michael (Novembro de 2012). New Opportunities for NewSQL. Communications of the ACM, Vol. 55 No. 11, Pages / Sourceforge (s.d.). NewSQL. Consultado em 25 de Fevereiro de 2013, no site StormDB overview (2012) Consultado em 22 de Novembro de 2013, no site Technology of VoltDB (2013) Consultado em 26 de Novembro de 2013, no site The Architecture & Motivation for NuoDB (2013). Consultado em 11 de Novembro de 2013, no site WfF9wsRonvqvBZKXonjHpfsX56OwtX6K%2BlMI%2F0ER3fOvrPUfGjI4JSMp0a PyQAgobGp5I5FEJSbnYRbBrt6EFXg%3D%3D TokuDB Documentation (s.d.). Consultado em 2 de Outubro de 2013 no site TPC-H Documentation (2013). Consultado em 11 de Novembro de 2013, no site Twitter Statistics (2013) Consultado em 10 de Novembro de 2013, no site 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 Venkatesh, Prasanna & S, Nirmala (2012). NewSQL The new way to handle big data. Consultado em 1 de Março de 2013, no site VoltDB - Wikipedia (2013). Consultado em , no site Why StormDB (2013) Consultado em 22 de Novembro de 2013, no site 69

88 Bases de Dados NewSQL Referências YouTube (s.d.) Estatísticas. Consultado em 10 de Novembro de 2013, no site Zakon, Robert H obbes (2011) Hobbes Internet TimeLine Consultado em 8 de Novembro de 2013, no site 70

89 Bases de Dados NewSQL Anexos Anexo A Tutorial de instalação do Ubuntu 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 Se já tem o Windows instalado no seu computador poderá querer fazer um dual boot e para tal poderá seguir os tutoriais disponibilizados em Mas poderá também utilizar uma máquina virtual ou instalar apenas o Ubuntu 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 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

90 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

91 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

92 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

93 Bases de Dados NewSQL Anexos Anexo B Tutorial de instalação do MySQL e dos sistemas NewSQL Neste anexo apresentamos um tutorial de como instalar cada um dos sistemas testados durante a realização deste projecto. B.1 MySQL O Ubuntu tem uma versão do MySQL pronta a instalar mas nem sempre é a versão mais actual. Se pretender instalar a versão que vem no Ubuntu basta seguir os passos seguintes: shell> sudo apt-get install mysql-server shell> mysql u root p 75

94 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: 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 terá de seguir os seguintes passos: shell> sudo su shell> dpkg i mysql debian6.0-x86_64.deb shell> rm mysql 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-servercore-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

95 Bases de Dados NewSQL Anexos Your MySQL connection id is 15 Server version: 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 ( e do Drizzle ( 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 tar.gz shell> cd libdrizzle-0.3 shell>./configure shell> make shell> make install shell> tar -xzvf drizzle alpha.tar.gz shell> cd drizzle 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

96 Bases de Dados NewSQL Anexos shell> chown -R drizzle. shell> chgrp -R drizzle. shell> /home/debora/drizzle 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: alpha Source distribution (Trunk) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. drizzle> /home/debora/drizzle 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 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 tokudb linuxx86_64.tar.gz shell> ln -sv mysql tokudb 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

97 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: tokudb 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 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

98 Bases de Dados NewSQL Anexos Archive directory: /opt/nuodb/samples/10gb (é necessário dar privilégios de escrita para esta pasta senão a inicialização falha) Initialize archive: true (primeira vez) false (restantes vezes) Started process:... [ pid = 9950 ] nuodb [domain] > start process te host localhost database 10gb Process command-line options: --dba-user dba --dba-password dba (quando se inicia pela primeira vez, depois já não é necessário) Started process:... [ pid = 9961 ] shell> /opt/nuodb/bin/nuosql 10gb@localhost --user dba --password dba SQL> B.5 VoltDB O download pode ser feito em Terá de se registar e após isso irá receber um 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

99 Bases de Dados NewSQL Anexos Anexo C Como utilizar o TPC-H O TPC-H pode ser encontrado em 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 ) Copyright Transaction Processing Performance Council Generating data for suppliers table/ Preloading text % 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

100 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

101 Bases de Dados NewSQL Anexos Anexo D Pesquisas do TPC-H Aqui são apresentadas as pesquisas do TPC-H utilizadas para testar os vários sistemas. Q1 - Pricing Summary Report Query select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order from lineitem where l_shipdate <= date ' ' - interval '64' day group by l_returnflag, l_linestatus order by l_returnflag, l_linestatus; Q2 - Minimum Cost Supplier Query select from where s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment part, supplier, partsupp, nation, region 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

102 Bases de Dados NewSQL Anexos 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 from l_orderkey, sum(l_extendedprice * (1 - l_discount)) as revenue, o_orderdate, o_shippriority customer, orders, lineitem where c_mktsegment = 'MACHINERY' and c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate < date ' ' and l_shipdate > date ' ' group by l_orderkey, o_orderdate, o_shippriority order by revenue desc, o_orderdate limit 10; Q4 - Order Priority Checking Query select from where o_orderpriority, count(*) as order_count orders o_orderdate >= date ' ' and o_orderdate < date ' ' + interval '3' month 84

103 Bases de Dados NewSQL Anexos and exists ( select from where ) group by o_orderpriority order by o_orderpriority; * lineitem l_orderkey = o_orderkey and l_commitdate < l_receiptdate Q5 - Local Supplier Volume Query select from n_name, sum(l_extendedprice * (1 - l_discount)) as revenue 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 ' ' and o_orderdate < date ' ' + interval '1' year group by n_name order by revenue desc; Q6 - Forecasting Revenue Change Query select from where sum(l_extendedprice * l_discount) as revenue lineitem l_shipdate >= date ' ' and l_shipdate < date ' ' + interval '1' year and l_discount between and and l_quantity < 24; 85

104 Bases de Dados NewSQL Anexos Q7 - Volume Shipping Query select from supp_nation, cust_nation, l_year, sum(volume) as revenue ( = 'IRAQ') = 'VIETNAM' ) select from where date ' ' ) as shipping group by supp_nation, cust_nation, l_year order by supp_nation, cust_nation, l_year; 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 supplier, lineitem, orders, customer, nation n1, nation n2 Q8 - National Market Share Query select from 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 or (n1.n_name = 'IRAQ' and n2.n_name ) and l_shipdate between date ' ' and o_year, sum(case when nation = 'CHINA' then volume else 0 end) / sum(volume) as mkt_share ( select from extract(year from o_orderdate) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation 86

105 Bases de Dados NewSQL Anexos where part, supplier, lineitem, orders, customer, nation n1, nation n2, region 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 ' ' and date ' ' 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

106 Bases de Dados NewSQL Anexos o_year order by nation, o_year desc; Q10 - Returned Item Reporting Query select from c_custkey, c_name, sum(l_extendedprice * (1 - l_discount)) as revenue, c_acctbal, n_name, c_address, c_phone, c_comment customer, orders, lineitem, nation where c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate >= date ' ' and o_orderdate < date ' ' + 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 from ps_partkey, sum(ps_supplycost * ps_availqty) as value 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

107 Bases de Dados NewSQL Anexos ) order by value desc; from where sum(ps_supplycost * ps_availqty) * partsupp, supplier, nation ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = 'UNITED KINGDOM' Q12 - Shipping Modes and Order Priority Query select from 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 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 ' ' and l_receiptdate < date ' ' + interval '1' year group by l_shipmode order by l_shipmode; Q13 - Customer Distribution Query select from c_orders.c_count, count(*) as custdist ( 89

108 Bases de Dados NewSQL Anexos select from c_custkey, count(o_orderkey) as c_count 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 * 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 ' ' and l_shipdate < date ' ' + 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 ' ' and l_shipdate < date ' ' + interval '3' month group by l_suppkey; select from s_suppkey, s_name, s_address, s_phone, total_revenue 90

109 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 from p_brand, p_type, p_size, count(distinct ps_suppkey) as supplier_cnt 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

110 Bases de Dados NewSQL Anexos where part 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 from where c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity) customer, orders, lineitem 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 from where sum(l_extendedprice* (1 - l_discount)) as revenue lineitem, part ( 92

111 Bases de Dados NewSQL Anexos 'SM PKG') ) or ( 'MED PACK') 'LG PKG') ) or ( ); p_partkey = l_partkey and p_brand = 'Brand#31' and p_container in ('SM CASE', 'SM BOX', 'SM PACK', and l_quantity >= 5 and l_quantity <= and p_size between 1 and 5 and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON' p_partkey = l_partkey and p_brand = 'Brand#43' and p_container in ('MED BAG', 'MED BOX', 'MED PKG', and l_quantity >= 20 and l_quantity <= and p_size between 1 and 10 and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON' p_partkey = l_partkey and p_brand = 'Brand#15' and p_container in ('LG CASE', 'LG BOX', 'LG PACK', and l_quantity >= 27 and l_quantity <= and p_size between 1 and 15 and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON' Q20 - Potential Part Promotion Query select from where s_name, s_address supplier, nation s_suppkey in ( select from where ps_suppkey partsupp ps_partkey in ( select p_partkey from part where p_name like 'coral%' ) and ps_availqty > ( 93

112 Bases de Dados NewSQL Anexos 01-01' select from where 01-01' + interval '1' year ) ) and s_nationkey = n_nationkey and n_name = 'IRAN' order by s_name; 0.5 * sum(l_quantity) lineitem l_partkey = ps_partkey and l_suppkey = ps_suppkey and l_shipdate >= date '1995- and l_shipdate < date '1995- Q21 - Suppliers Who Kept Orders Waiting Query select from s_name, count(*) as numwait 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

113 Bases de Dados NewSQL Anexos Q22 - Global Sales Opportunity Query select from '22') for 2) in cntrycode, count(*) as numcust, sum(c_acctbal) as totacctbal (select from where '21', '39', '41', '22') ) as custsale group by cntrycode order by cntrycode; substring(c_phone from 1 for 2) as cntrycode, c_acctbal customer substring(c_phone from 1 for 2) in ('35', '37', '25', '21', '39', '41', and c_acctbal > (select avg(c_acctbal) from customer where c_acctbal > 0.00 and substring(c_phone from 1 ('35', '37', '25', ) and not exists ( select * from orders where o_custkey = c_custkey ) 95

114 Bases de Dados NewSQL Anexos Anexo E Scripts utilizados no VoltDB Neste anexo apresentamos os scripts que foram necessários criar para uma correcta utilização do VoltDB. E.1 Script 1 package script; import java.io.bufferedwriter; import java.io.fileinputstream; import java.io.filenotfoundexception; import java.io.filewriter; import java.io.ioexception; import java.util.scanner; public class Script { public static void main(string[] args) throws FileNotFoundException, IOException { Scanner ler1 = new Scanner(new FileInputStream("partsupp.tbl")); Scanner ler2 = new Scanner(new FileInputStream("orders.tbl")); Scanner ler3 = new Scanner(new FileInputStream("lineitem.tbl")); Scanner ler4 = new Scanner(new FileInputStream("nation.tbl")); Scanner ler5 = new Scanner(new FileInputStream("region.tbl")); Scanner ler6 = new Scanner(new FileInputStream("part.tbl")); Scanner ler7 = new Scanner(new FileInputStream("supplier.tbl")); Scanner ler8 = new Scanner(new FileInputStream("customer.tbl")); BufferedWriter novo1 = new BufferedWriter(new FileWriter("partsupp2.tbl")); BufferedWriter novo2 = new BufferedWriter(new FileWriter("orders2.tbl")); BufferedWriter novo3 = new BufferedWriter(new FileWriter("lineitem2.tbl")); BufferedWriter novo4 = new BufferedWriter(new FileWriter("nation2.tbl")); BufferedWriter novo5 = new BufferedWriter(new FileWriter("region2.tbl")); BufferedWriter novo6 = new BufferedWriter(new FileWriter("part2.tbl")); BufferedWriter novo7 = new BufferedWriter(new FileWriter("supplier2.tbl")); BufferedWriter novo8 = new BufferedWriter(new FileWriter("customer2.tbl")); String linha; String []campos; int i=0; while(ler1.hasnextline()) { linha = ler1.nextline(); campos=linha.split("\\ "); novo1.write(campos[0]+" "); novo1.write(campos[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

115 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

116 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() )*1000+" "); novo.write((c2.gettimeinmillis() )*1000+" "); novo.write((c3.gettimeinmillis() )*1000+" "); novo.write(campos[13]+" "); novo.write(campos[14]+" "); novo.write(campos[15]); novo.write("\n"); } while(ler2.hasnextline()) { linha = ler2.nextline(); 98

117 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() )*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

118 Bases de Dados NewSQL Anexos Anexo F Resultados para a base de dados de 1GB Por uma questão de não colocarmos resultados repetidos no capítulo da avaliação experimental decidimos colocar em anexo estes resultados. Figura F.1 Tempos de execução na sequência 1 para 1GB Figura F.2 - Tempos de execução na sequência 2 para 1GB Figura F.3 - Tempos de execução na sequência 3 para 1GB 100

119 Bases de Dados NewSQL Anexos Tabela F.1 Valores da pesquisa Q14 para 1GB S1 S2 S3 MySQL Drizzle TokuDB NuoDB VoltDB StormDB 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

120 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 Drizzle TokuDB NuoDB Tabela F.3 - Valores da pesquisa Q18 (NuoDB vsmysql,drizzle e TokuDB) S1 S2 S3 MySQL Drizzle TokuDB NuoDB

121 Bases de Dados NewSQL Anexos Tabela F.4 - Valores da pesquisa Q22 (NuoDB vsmysql,drizzle e TokuDB) S1 S2 S3 MySQL Drizzle TokuDB NuoDB 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

122 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

123 Bases de Dados NewSQL Anexos Figura F.12 - Sequência 3 para 1GB (StormDB vsmysql,drizzle e TokuDB) 105

124 Bases de Dados NewSQL Anexos Anexo G de 10GB Resultados da base de dados 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

125 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 Drizzle TokuDB Tabela G.2 Valores da pesquisa Q14 para 10GB S1 S2 S3 MySQL Drizzle TokuDB StormDB

126 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