Uma Anlise dos Novos Sistemas de Bancos de Dados Relacionais

Escalveis
Pedro Henrique dos Santos Lemos
Pedro Soares Figueiredo

Projeto de Graduao apresentado ao Curso de

Engenharia de Computao e Informao da
Escola Politcnica, Universidade Federal do Rio
de Janeiro, como parte dos requisitos necessrios
obteno do ttulo de Engenheiro.

Orientador:

Rio de Janeiro
Maro de 2014

Alexandre de Assis Bento Lima

UMA ANLISE DOS NOVOS SISTEMAS DE BANCOS DE DADOS RELACIONAIS

ESCALVEIS
Pedro Henrique dos Santos Lemos
Pedro Soares Figueiredo
PROJETO DE GRADUAO SUBMETIDO AO CORPO DOCENTE DO CURSO DE
ENGENHARIA DE COMPUTAO E INFORMAO DA ESCOLA POLITCNICA DA
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS
NECESSRIOS

PARA

OBTENO

DO

GRAU

DE

ENGENHEIRO

DE

COMPUTAO E INFORMAO.
Examinada por:

______________________________________________
Prof. Alexandre de Assis Bento Lima, D.Sc.
______________________________________________
Profa. Marta Lima de Queirs Mattoso, D.Sc.
______________________________________________
Prof. Ricardo Cordeiro de Farias, Ph.D.

RIO DE JANEIRO, RJ BRASIL

MARO de 2014

Pedro Henrique
Figueiredo,
Pedro
dos
Soares
Santos Lemos
Pedro Soares
Lemos,
Pedro Figueiredo
Henrique dos Santos
UmaUma
Anlise
Anlise
dosdos
Novos
Novos
Sistemas
SistemasdedeBancos
Bancos de
de Dados
Relacionais Escalveis/Pedro Henrique dos Santos Lemos e
Pedro Soares Figueiredo. Rio de Janeiro: UFRJ/ Escola
Politcnica, 2014.
VIII, XII,
58 p.:
71il.;
p.:29,7
il.; 29,7
cm. cm.
Orientador:
Orientador:
Alexandre
Alexandre
de de
Assis
Assis
Bento
Bento
Lima
Lima
Projeto
Projeto
de Graduao
de Graduao
UFRJ/Escola
UFRJ/Escola
Politcnica/
Politcnica/
Curso de
Engenharia
Curso
de Engenharia
de Computao
de Computao
e Informao,
e Informao,
2014.
2014.
Referncias
Referncias
Bibliogrficas:
Bibliogrficas:
pxx p. 66-69
1. Banco
1. Banco
de de
Dados
Dados
2. 2.Modelo
ModeloRelacional
Relacional3.3. NoSQL
NoSQL 4.
NewSQL. I.Universidade
Lima, Alexandre
Federal
de Assis
do Rio
Bento
de Janeiro,
II. Universidade
Escola
Politcnica,
Federal
do Rio
Curso
de Janeiro,
de Engenharia
Escola Politcnica,
de Computao
Curso de
e
Informao. de
III. Computao
Ttulo.
Engenharia
e Informao. III. Titulo.

iii

AGRADECIMENTOS
Por Pedro Lemos:
Chegar em um momento como esse no algo fcil. Foram 6 intensos anos,
nos quais inmeras dificuldades surgiram, muitas coisas foram deixadas de lado, para
que esse momento chegasse, mas principalmente, muitas coisas foram conquistadas
ao longo desses anos, que hoje me fazem ter a certeza que esse tempo no foi em
vo, e sim muito proveitoso. Mas para enfrentar todos os obstculos e mesmo assim
sentir o prazer dessa conquista, foi necessrio uma comunho de foras, as quais
agradeo aqui nesse momento.
minha famlia, principalmente meus pai, Artur e Wania, minhas irms,
Larissa e Renata e minha namorada Anlia, por todo o apoio e dado durante esse
longo perodo. No teria sido fcil, sem a ajuda de vocs, sem o suporte emocional
necessrio, para aguentar viradas de noites de estudos, estgios durante o fim de
semana, viagens a trabalho e passar 1 ano morando longe de casa. Obrigado por todo
o amor e carinho que vocs sempre me deram.
Aos amigos de ECI, que fizeram cada dia de faculdade, ser um dia diferente.
Sem vocs, esses anos no seriam os mesmos, e teriam passado muito mais
devagar. Obrigado por me ajudar a levar a faculdade com a seriedade, mas tambm
com a alegria necessria.
Fluxo e seus membros, por ter me feito aprender muito mais que
Engenharia. Por me deixar conhecer esse imenso mundo que o Empreendedorismo.
Sem todos os EMPIs, PAMEs, reunies de fim de semana, sem ter conhecido todos
vocs, essa faculdade no teria a menor graa. Obrigado por ser minha 2 casa.
Aos amigo feitos no Porto, obrigado pela grande experincia de ter morado
fora de casa durante 1 ano. Vocs tornaram esse momento, mais incrvel do que eu
poderia imaginar.

iv

AGRADECIMENTOS
Por Pedro Figueiredo:
Primeiramente, tenho que agradecer meus pais, Srgio e Mnica, pelas
primeiras orientaes que recebi na vida. O amor, o carinho, o apoio incondicional, a
educao dada e os valores que me passaram fizeram com que tudo o que aconteceu
at aqui fosse possvel. Obrigado por me ensinarem a acreditar. meus irmos, Lucas
e Joo Felipe, obrigado por serem os melhores irmos possveis.
Aos queridos amigos da turma de 2008 da ECI, agradeo por terem tornado
essa jornada prazerosa, mesmo nos momentos mais difceis. As salas de estudo,
virtuais e reais, sero lembradas. Todas as outras reunies, mais ainda! Obrigado por
terem se tornado amigos de verdade. Um agradecimento especial ao Pedro Lemos
pela parceria inestimvel na realizao deste projeto.
Aos amigos da poca de colgio, vocs me ensinaram o significado real da
palavra amizade. Essa foi uma lio incrvel! Obrigado pelo apoio de sempre.
Aos companheiros da Plannera, obrigado por terem feito parte da minha vida
profissional. E obrigado por terem me ensinado a aprender a errar melhor.

E a todos que de alguma forma contriburam para este momento, agradeo.

Por ambos:
Ao professor Alexandre Assis, agradecemos pelas aulas que eventualmente
levaram escolha deste tema, pela orientao neste trabalho, pela dedicao em
todas as revises do texto. E aos demais professores, obrigado por todos os
momentos igualmente inspiradores.

Resumo do Projeto de Graduao apresentado Escola Politcnica/ UFRJ como parte

dos requisitos necessrios para a obteno do grau de Engenheiro de Computao e
Informao.
Uma Anlise dos Novos Sistemas de Bancos de Dados Relacionais Escalveis
Pedro Henrique dos Santos Lemos
Pedro Soares Figueiredo

Maro/2014

Orientador: Alexandre de Assis Bento Lima

Curso: Engenharia de Computao e Informao

Sistemas de Gerncia de Bancos de Dados Relacionais (SGBDR) tradicionalmente
so usados como parte da soluo de aplicaes de Processamento de Transaes.
Nos ltimos anos, porm, surgiram novas aplicaes, geralmente baseadas na Web:
redes sociais, jogos multijogadores online, anlise de dados em tempo real, entre
outros. Aplicaes bem sucedidas desses tipos so caracterizadas por um alto volume
de interaes por segundo e um tempo de resposta baixo, o que demanda requisitos
de escalabilidade e desempenho melhorados dos SGBD. Sistemas NoSQL, uma
classe de SGBD no-relacionais, surgiram para atender a esta demanda, fornecendo
escalabilidade horizontal, em troca de uma consistncia relaxada dos dados, chamada
consistncia tardia, e da ausncia de uma linguagem de consulta de alto nvel, como a
SQL, o que dificulta sua adoo em larga escala. Assim, uma nova classe de SGBDR
vem surgindo: os SGBD NewSQL, com suporte a SQL e transaes ACID, que se
diferenciam por novas estratgias de implementao, que incluem, entre outras, dados
residentes em memria, escalabilidade horizontal em ambientes com arquitetura de
memria distribuda, e por serem projetados para atender a tipos especficos de
aplicaes. Essa nova classe de SGBDR constitui o objeto de anlise deste projeto.
Para isso, suas motivaes e suas principais caractersticas foram estudadas. Para
fins ilustrativos, foram realizados testes de desempenho com um SGBD NewSQL
atravs da aplicao de um conjunto de benchmarks, que simulam cargas de trabalho
tpicas de domnios de aplicaes distintos.
vi

Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of

the requirements for the degree of Computer and Information Engineer.

Analysis of the New Scalable Relational Database Systems

Pedro Henrique dos Santos Lemos
Pedro Soares Figueiredo

March/2014

Advisor: Alexandre de Assis Bento Lima

Major: Computer and Information Engineering

Relational Database Management Systems (RDBMS) are traditionally used as a part of
Transaction Processing applications. In recent years, however, new Web-based
applications emerged: social networks, online multiplayer games, real-time data
analytics, among others. Successful applications of that kind are characterized by a
high volume of interactions per second and low response time, which demands
improved performance and scalability from DBMS. NoSQL systems, a non-relational
class of DBMS, emerged to fulfill this task, providing horizontal scalability, in exchange
of relaxed data consistency (called eventually consistent systems) and the absence of
a high-level query language, such as SQL, which makes their adoption harder. Thus, a
new class of RDBMS arose: NewSQL, that supports both SQL and ACID-compliant
transactions, and differentiates themselves from traditional RDBMS by presenting new
strategy implementations that include in-memory data storage and horizontal scalability
in shared nothing clusters. They are also designed according to specific application
requirements. NewSQL systems are the object of analysis of this project. Motivations
for their development and main features were studied. For illustrative purposes,
performance evaluation of one NewSQL DBMS was done through the execution of a
set of synthetic benchmarks, simulating a variety of distinguished application workloads.

vii

SUMRIO
Captulo 1 - Introduo ................................................................................................ 1
1.1 Tema...................................................................................................................... 1
1.2 Justificativa ............................................................................................................ 1
1.3 Objetivo.................................................................................................................. 2
1.4 Metodologia ........................................................................................................... 2
1.5 Organizao do Texto ........................................................................................... 3
Captulo 2 - Fundamentao Terica .......................................................................... 4
2.1 Estratgias tradicionais para implementao de SGBD ........................................ 4
2.2 Novo Ambiente ...................................................................................................... 5
2.3 Bancos de Dados Distribudos .............................................................................. 7
2.4 NoSQL ................................................................................................................. 14
2.4.1 Motivao ......................................................................................................... 14
2.4.2 Principais Caractersticas ................................................................................. 14
2.4.3 Classificao..................................................................................................... 15
2.4.4 Problemas......................................................................................................... 17
2.5 Avaliao de Desempenho em Sistemas de Bancos de Dados.......................... 18
Captulo 3 - NewSQL ................................................................................................. 21
3.1 NuoDB ................................................................................................................. 22
3.1.1 Viso Geral ....................................................................................................... 22
3.1.2 Arquitetura ........................................................................................................ 23
3.1.2.1 Estrutura em nveis ........................................................................................ 23
3.1.2.2 Os tomos ..................................................................................................... 25
3.1.2.3 Controle de Concorrncia .............................................................................. 26
3.2 VoltDB.................................................................................................................. 27
3.2.1 Viso Geral ....................................................................................................... 27
3.2.2 Arquitetura ........................................................................................................ 28
3.3 MemSQL.............................................................................................................. 31
viii

3.3.1 Viso Geral ....................................................................................................... 31

3.3.2 Arquitetura ........................................................................................................ 31
3.3.2.1 Alocao de Tabelas ..................................................................................... 32
3.3.2.2 Controle de Concorrncia .............................................................................. 33
3.3.3 Execuo de Consultas .................................................................................... 34
3.3.4 Propriedades ACID ........................................................................................... 35
3.4 Google Spanner................................................................................................... 36
3.4.1 Viso Geral ....................................................................................................... 36
3.4.2 Arquitetura ........................................................................................................ 37
Captulo 4 - Avaliao experimental .......................................................................... 39
4.1 OLTP-Bench ........................................................................................................ 39
4.1.1 TPC-C ............................................................................................................... 40
4.1.2 TATP................................................................................................................. 42
4.1.3 YCSB ................................................................................................................ 44
4.1.4 Twitter ............................................................................................................... 46
4.2 Ambiente de Testes ............................................................................................. 48
4.3 Procedimento Experimental................................................................................. 49
4.3.1 Objetivo............................................................................................................. 49
4.3.2 Metodologia ...................................................................................................... 49
4.3.3 Configurao dos SGBD .................................................................................. 51
4.4 Resultados Experimentais ................................................................................... 52
4.4.1 TATP................................................................................................................. 52
4.4.2 Twitter ............................................................................................................... 54
4.4.3 YCSB ................................................................................................................ 56
4.4.4 TPC-C ............................................................................................................... 58
Captulo 5 - Concluso .............................................................................................. 62
5.1 Limitaes............................................................................................................ 63
5.2 Trabalhos Futuros................................................................................................ 64
ix

Referncias Bibliogrficas ............................................................................................ 66

Anexo A ........................................................................................................................ 70

LISTA DE FIGURAS
Figura 1 Um sistema de banco de dados distribudo. Adaptado de (ZSU,
VALDURIEZ, 2010). ..................................................................................................... 10
Figura 2 - Arquitetura do NuoDB. Adaptado de www.nuodb.com ................................ 25
Figura 3 - Arquitetura do MemSQL. Adaptado de www.memsql.com .......................... 32
Figura 4 - Execuo de Consultas no MemSQL. Adaptado de www.memsql.com ...... 35
Figura 5 - Esquema do TPC-C ..................................................................................... 41
Figura 6 - Esquema do TATP ....................................................................................... 43
Figura 7 - Esquema do YCSB ...................................................................................... 45
Figura 8 Esquema do Twitter .................................................................................... 46
Figura 9 - Resultados TATP - 2 Ns ............................................................................ 53
Figura 10 - Resultados TATP - 4 Ns .......................................................................... 53
Figura 11 - Resultados TATP - 128 Usurios Virtuais .................................................. 54
Figura 12 - Resultados Twitter - 2 Ns ......................................................................... 55
Figura 13 - Resultados Twitter - 4 Ns ......................................................................... 55
Figura 14 - Resultados Twitter - 128 Usurios Virtuais ................................................ 56
Figura 15 - Resultados YCSB - 2 Ns .......................................................................... 57
Figura 16 - Resultados YCSB - 4 Ns .......................................................................... 57
Figura 17 - Resultados YCSB - 128 Usurios Virtuais ................................................. 58
Figura 18 - Resultados TPCC - 2 Ns .......................................................................... 58
Figura 19 - Resultados TPCC - 4 Ns .......................................................................... 59
Figura 20 - Resultados TPCC - 128 Usurios Virtuais ................................................. 59

xi

LISTA DE SIGLAS
ACID Atomicidade, Consistncia, Isolamento e Durabilidade
BASE Basically Available, Soft-state services with Eventual-Consistency
JDBC Java Database Connectivity
LDD Linguagem de Definio de Dados
MV Mquina Virtual
MVCC Multi Version Concurrency Control
OLTP Processamento de Transaes em Tempo Real (do ingls, Online Transaction
Processing)
SBD Sistemas de Bancos de Dados
SBDD Sistemas de Bancos de Dados Distribudos
SBDR Sistemas de Bancos de Dados Relacionais
SGBD Sistema de Gerncia de Banco de Dados
SM Gerenciador de Armazenamento (do ingls, Storage Manager)
SQL Linguagem de Consulta Estruturada (do ingls, Structured Query Language)
SSD Solid State Drives
TE Motor de Transaes (do ingls, Transaction Engine)
TPC Transaction Processing Performance Council
XML eXtended Markup Language
YCSB Yahoo! Cloud Serving Benchmark

xii

Captulo 1 - Introduo
1.1 Tema
Este projeto traz os resultados de um estudo sobre as novas tecnologias utilizadas
para implementao de Sistemas de Gerncia de Bancos de Dados Relacionais
(SGBDR), conjuntamente denominadas NewSQL.

1.2 Justificativa
SGBDR tradicionalmente so usados como parte da soluo de aplicaes com
grande nmero de transaes. Nos ltimos anos, porm, surgiram uma variedade de
novas aplicaes, geralmente baseadas na Web: redes sociais online, jogos
multijogadores, comrcio eletrnico a nvel global, mensageiros instantneos, etc.
Aplicaes bem sucedidas desses tipos so caracterizadas por um alto volume de
interaes por segundo e, normalmente, espera-se que o tempo de resposta seja
muito baixo, o que demanda requisitos de escalabilidade e desempenho melhorados
dos SGBD (STONEBRAKER,2011). As estratgias de implementao dos SGBDR
atuais (armazenamento baseado em disco, arquitetura centralizada, entre outros) so
um empecilho para atender a esses requisitos. Uma abordagem do tipo dividir para
conquistar para o problema da escalabilidade, como fragmentar os dados em uma
arquitetura distribuda, por exemplo, tem um custo elevado de manuteno em um
SGBDR. O aprimoramento de tecnologias de hardware, como processadores mais
rpidos, memrias com mais capacidade (e que ficaram, ao mesmo tempo, mais
baratas), e novas formas de armazenamento no-voltil, como os Solid State Drives
(SSD), tambm devem ser consideradas. Bases de dados residentes unicamente em
memria passam a ser uma opo, por exemplo.
Por isso, surgiu o movimento NoSQL. Sistemas NoSQL visam atender a
problemas especficos, atravs de modelos de dados distintos, como: orientados a
1

grafos (adequados a uma rede social, por exemplo), a documentos (adequados a

sistemas web que utilizam estruturas tipo XML ou JSON, por exemplo) e
armazenamento chave-valor (um exemplo seria uma espcie de cache). O problema
que esse tipo de sistema prov um maior desempenho em troca de relaxar a
consistncia, sendo tardiamente consistentes, e no possuem uma linguagem de
consulta unificada, como o SQL, o que pode tornar complexo o acesso aos dados,
podendo at inviabilizar a deciso de adoo desse tipo de tecnologia.
Assim, pesquisadores como STONEBRAKER et al.(2007) sugerem solues
que

mantenham

Modelo

Relacional,

as

transaes

ACID

(Atomicidade,

Consistncia, Isolamento e Durabilidade) e a SQL, reduzindo custos de transio,

mas que, ao mesmo tempo, tenham arquiteturas e estratgias de implementaes
projetadas para atender a necessidades especficas, pois assim evitam sobrecargas
induzidas por recursos que existem em SGBDR tradicionais e, muitas vezes, so
desnecessrias, pois estes tendem a ser generalistas (uma aplicao para tudo). A
esse conjunto de novas solues deu-se o nome NewSQL.

1.3 Objetivo
O objetivo principal deste projeto realizar um estudo sobre as novas tecnologias para
SGBDR denominadas NewSQL, mostrando desde os motivos da sua concepo at
os detalhes de funcionamento de algumas dessas ferramentas, passando pelas
principais diferenas entre o NewSQL e os SGBDR tradicionais. Um outro objetivo
verificar, atravs de experimentos, o desempenho de alguns dos novos SGBDR. Para
tanto, uma ferramenta (NuoDB) foi analisada com a utilizao de quatro benchmarks
com caractersticas bastante distintas.

1.4 Metodologia
As seguintes etapas foram realizadas para a concluso deste estudo:
2

I.

Levantamento de material didtico, a fim de realizar um estudo

aprofundado sobre as tecnologias de bancos de dados NewSQL.

II.

Pesquisa exploratria de diversos conceitos de bancos de dados e do

cenrio atual, tentando entender o porqu da necessidade de novas
tecnologias.

III.

Planejamento e organizao de um ambiente de testes para realizao

de quatro benchmarks entre um sistema NewSQL e um SGBDR atual.

IV.

Escolha de ferramentas NewSQL para avaliao de desempenho.

V.

Avaliao das ferramentas selecionadas atravs da execuo dos

benchmarks escolhidos.

VI.

Anlise dos resultados obtidos.

1.5 Organizao do Texto

Este projeto est organizado da seguinte forma: no Captulo 2 so apresentadas as
caractersticas dos SGBDR tradicionais e as demandas das novas aplicaes, que no
conseguem ser atendidas por esses sistemas de forma satisfatria. Alm disso, so
apresentados conceitos de bancos de dados distribudos e uma breve descrio das
tecnologias NoSQL, uma das primeiras alternativas aos SGBDR tradicionais. Tambm
h uma breve introduo a mtodos para avaliao de desempenho em SGBD, e
quais caractersticas especficas podem ser medidas por eles. No Captulo 3
apresentado o conceito de NewSQL e algumas ferramentas desenvolvidas so
analisadas. O Captulo 4 descreve os experimentos realizados e seus resultados.
O Captulo 5 conclui o projeto.

Captulo 2 - Fundamentao Terica

2.1 Estratgias tradicionais para implementao de SGBD
Os SGBD tradicionais, especialmente os que suportam aplicaes que executam
processamento de transaes em linha (OLTP, do ingls On-line Transaction
Processing), possuem uma srie padro de recursos, tais como suporte ao modelo de
dados Relacional (SGBDR), estruturas para armazenamento de dados em disco,
controle de concorrncia entre transaes e recuperao de falhas atravs de
arquivos de log (HARIZOPOULOS et al., 2008). Alguns destes recursos j faziam
parte do System R (STONEBRAKER et al., 2007), SGBD Relacional lanado na
dcada de 1970, quando as bases de dados eram muito maiores que a quantidade de
memria principal disponvel em um servidor de banco de dados e o custo de um
computador apropriado para tais bases era altssimo.
Duas das principais caractersticas desses sistemas so a utilizao da
linguagem SQL para consultas (devido ao modelo Relacional) e a garantia das
propriedades ACID em suas transaes. A primeira possui vantagens como: promover
a independncia dos dados, ser uma linguagem de alto nvel, declarativa, amplamente
disseminada na comunidade (fazendo parte do currculo de praticamente todos os
cursos ligados Computao), proporcionar relativa facilidade de aprendizado e
compreenso e ser uma linguagem independente de plataforma, sendo suportada por
basicamente todos os SGBDR.
As propriedades ACID garantem aos usurios a execuo correta e consistente
de suas transaes. So transaes atmicas, pois todas as suas operaes so
executadas com sucesso, ou, em caso de alguma falha, todas so desfeitas;
consistentes, pois toda transao leva o banco de dados de um estado consistente a
outro estado consistente, respeitando as restries de integridade; isoladas, pois,
caso ocorram transaes concorrentes, uma transao no interfere no resultado da

outra, permitindo que o resultado da execuo paralela das transaes seja o mesmo
obtido caso as mesmas tivessem sido executadas sequencialmente; e durveis, pois,
em caso de sucesso, as alteraes causadas pela transao so persistidas mesmo
em caso de falhas. Esse tipo de garantia crucial para o bom funcionamento de
sistemas OLTP como, por exemplo, sistemas bancrios e de compras de passagens
areas. Por isso, nestes sistemas, o benefcio de garantir a consistncia dos dados
por muitas vezes acaba sendo superior perda de desempenho induzida pela
sobrecarga causada por alguns mecanismos de controle de concorrncia.
Devido, em grande parte, estas caractersticas, os SGBDR ainda so
amplamente utilizados. Esta ampla utilizao, nos ltimos 40 anos, levou seus
desenvolvedores a desenvolv-los como ferramentas que podem ser utilizadas por
qualquer tipo de aplicao que necessite de persistncia de dados (one size fits all (STONEBRAKER, CENTINTEMEL, 2005)). O cenrio, no entanto, vem mudando
desde a dcada de 2000, conforme mostra a prxima seo.

2.2 Novo Ambiente

O principal mercado a ser atendido pelos SGBDR, na poca em que foram criados,
era o de aplicaes transacionais OLTP, mais especificadamente o de processamento
de dados de negcios (STONEBRAKER et al. 2007), como por exemplo sistemas para
compra de passagens de avio. De forma diferente do cenrio atual, este tipo de
operao no era realizado diretamente pelo cliente atravs da Internet, j que a
mesma ainda nem existia. Nos EUA, por exemplo, as transaes eram realizadas por
operadores

profissionais

especializados,

contatados

por

telefone,

que

ento

manipulavam o banco de dados com sua aplicao cliente, atravs de um terminal,

para fazer a reserva com operaes simples.

Apesar de parecer que ter um sistema nico para todas as aplicaes possa
ser fantstico, do ponto de vista financeiro e operacional, a perspectiva sobre os
SGBDR vem mudando (STONEBRAKER et al., 2007).
Nos ltimos anos uma enorme quantidade de outros mercados surgiu,
incluindo motores de busca na Web, redes sociais e o mercado de comunicao
mvel, entre outras aplicaes em tempo real, fazendo com que o cenrio OLTP dos
dias atuais seja claramente distinto: existem dispositivos, em escala global,
constantemente conectados Internet, como smartphones e tablets, que so
potenciais geradores de transaes. Considerando o exemplo da reserva de
passagens de avio mencionado anteriormente, por exemplo: hoje esse objetivo pode
ser alcanado enquanto se toma um caf. Basta que se disponha de um dispositivo
mvel conectado a Internet. Essa comodidade, associada a um mundo dinmico em
que as pessoas desejam a todo momento que suas solicitaes sejam atendidas com
rapidez, levanta duas demandas em relao aos SGBDR: maior vazo (em nmero de
transaes por unidade de tempo) e alta disponibilidade, normalmente alcanada na
forma de replicao (STONEBRAKER, 2011).
Alm das mudanas nas aplicaes que utilizam SGBD e no contexto
informacional que estamos, podemos citar tambm uma grande mudana no cenrio
dos hardwares utilizados. Segundo STONEBRAKER et al. (2007) os processadores
modernos so bem mais rpidos, e executam transaes em microssegundos, os
discos rgidos aumentaram significativamente de tamanho, e novas tecnologias de
armazenamento no-voltil foram desenvolvidas, como os SSD (do ingls, Solid State
Drive ), que possuem tempos de resposta bastante reduzidos. Alm disso, o custo da
memria principal diminuiu, e j possvel ter servidores com capacidade suficiente
para tornar possvel a implantao de bases de dados residentes unicamente em
memria principal (STONEBRAKER, WEISBERG, 2013). Some-se a isso o fato de
que aglomerados (do ingls clusters) de computadores, constitudos de dezenas ou
at mesmo milhares de computadores comuns interconectados, ganharam grande
6

popularidade como soluo para aumentar a capacidade de processamento disponvel

a baixo custo, e este cenrio se torna ainda mais factvel.
Mas claro que os SGBDRs atuais no so idnticos aos lanados inicialmente.
Ao longo dos anos, diversas melhorias j foram implantadas como arquiteturas de
memria compartilhada, ndices baseados em mapas de bits, suporte para tipos de
dados definidos pelo usurio entre outros (STONEBRAKER et al., 2007). Ainda assim,
parte desse esforo de desenvolvimento introduziu uma srie de sobrecargas em uma
tentativa de tornar o sistema genrico o suficiente para atender a mltiplos casos de
uso, quando solues especializadas com foco em escalabilidade e distribuio de
dados podem ser mais adequadas a algumas organizaes.

2.3 Bancos de Dados Distribudos

Um dos principais objetivos de um SGBD permitir independncia dos dados
armazenados em relao aplicao que os consome, ou seja, retirar as lgicas de
armazenamento, acesso e controle aos dados da prpria aplicao e passar essas
responsabilidades a um software especializado. A forma mais simples de se conseguir
isso instalando uma instncia de um SGBD em um servidor, esteja ele localizado no
prprio centro de dados (do ingls datacenter) da organizao ou em uma Mquina
Virtual (MV) de uma operadora de servios de computao em nuvem. Esta soluo
pode, a princpio, ser mais simples de administrar, porm apresenta o mesmo
problema inerente a outras aplicaes que seguem uma arquitetura centralizada: h
um ponto de falha nico, o que pode levar indisponibilidade do servio.
Alm disso, empresas que utilizem um SBD centralizado para integrar seus
dados podem ter filiais em todo o mundo. Isso levanta algumas questes
interessantes: Como garantir uma maior disponibilidade desses dados? Nenhuma
empresa gostaria que os dados de seus usurios (potencialmente milhes deles) no

estejam disponveis por causa da falha de um computador, sob o risco de grandes

prejuzos financeiros.
Tambm razovel assumir que se uma empresa deste porte guardar um
histrico das transaes comerciais de todos os seus usurios desde que o sistema
entrou em funcionamento, por exemplo, possuir dados da ordem de grandeza de
alguns terabytes ou petabytes. Como um nico servidor de banco de dados se sai ao
lidar com bases de dados dessa magnitude (e, possivelmente, com muitas transaes
concorrentes)? Alm disso, se uma hipottica empresa X tem filiais em So Paulo e
Tquio, por exemplo, ser que os dados disponveis a respeito da filial de So Paulo
so relevantes para a equipe situada em Tquio?
Para resolver o primeiro problema, alguns SGBD, como o MySQL 1 ou o
PostgreSQL2, ao longo dos seus ciclos de desenvolvimento, introduziram mecanismos
de replicao de dados. Um exemplo normalmente suportado a replicao do tipo
mestre-escravo, onde o computador configurado como mestre armazena em um
arquivo de log todas as tuplas que foram atualizadas e depois propaga as
modificaes para o(s) computador(es) escravo(s). Assim, se o mestre falhar um
escravo pode assumir sua funo. Essa uma soluo que acarreta grande
redundncia de dados, se baseando em cpias de uma base de dados inteira. Se
mestre e escravos forem executados por servidores localizados no mesmo espao
fsico, ainda h um risco de uma catstrofe natural, por exemplo, tornar a operao do
servio indisponvel. Se, por outro lado, estes servidores estiverem separados
geograficamente, a latncia da comunicao entre eles pela rede pode vir a se tornar
um fator importante para a degradao do desempenho, que diretamente
proporcional distncia.

1
2

http://dev.mysql.com/doc/refman/5.7/en/replication.html, acessado pela primeira vez em 27/02/2014

http://www.postgresql.org/docs/9.3/static/high-availability.html, acessado pela primeira vez em 27/02/2014

Com respeito segunda questo, existe um limite fsico para acomodar bases
de dados muito grandes, a prpria capacidade de armazenamento do servidor. Uma
possvel soluo para esse problema seria migrar a base de dados para um servidor
com maior capacidade de armazenamento, o que conhecido como escalabilidade
vertical (STONEBRAKER

et al.,2007). Esta soluo envolve a compra de

equipamentos caros e cujo incremento de desempenho limitado, pois chega um

ponto em que no h como melhor-lo atravs de novas atualizaes de hardware.
Alm disso, implica em deixar o servidor inoperante durante o tempo em que a
migrao acontece, sendo este possivelmente o maior prejuzo. Uma alternativa
escalabilidade vertical aumentar a capacidade de processamento de dados ao
adicionar mais servidores a um aglomerado de computadores que, conjuntamente,
possuem uma capacidade de processamento superior ao de um nico servidor com
muitos recursos. Aumentar o desempenho ao adicionar mais ns ao aglomerado
conhecido como escalabilidade horizontal.
Estas so algumas das razes que motivaram a pesquisa e o desenvolvimento
de sistemas de bancos de dados distribudos. Antes de definir o que so sistemas de
bancos de dados distribudos, porm, deve-se definir o que so sistemas distribudos
em geral.
Um sistema computacional distribudo pode ser definido como um nmero de
elementos de processamento autnomos (no necessariamente homogneos),
interconectados por uma rede de computadores, que cooperam para realizar as
tarefas que lhes foram atribudas. Nessa definio, elementos de processamento
so dispositivos capazes de executar um programa por conta prpria (ZSU,
VALDURIEZ, 2010).
Nesse caso, podem ser distribudos: a lgica de processamento, conforme a
definio anterior implicitamente sugere; as funes de um computador, que podem
ser delegadas a componentes de hardware ou software distintos; os prprios dados e
tambm o controle da execuo de um determinado programa, que pode ser realizado
9

por diversos computadores ao invs de um nico (ZSU, VALDURIEZ, 2010). Do

ponto de vista de sistemas de bancos de dados, todos esses modos de distribuio
so importantes.
Assim, ZSU e VALDURIEZ (2010) definem banco de dados distribudo como
uma coleo de mltiplos bancos de dados, logicamente inter-relacionados e
distribudos por uma rede de computadores. Um Sistema de Gerncia de Bancos de
Dados Distribudos (SGBDD) ento definido como o software que permite a
gerncia de bancos de dados distribudos e torna a distribuio transparente para os
usurios. O nome Sistema de Banco de Dados Distribudo (SBDD) tambm utilizado
como referncia ao conjunto formado pelo banco de dados distribudo e seu SGBDD e
aplicaes associadas.
importante ressaltar que um SBDD no uma coleo de arquivos que
podem ser armazenados individualmente nos ns de uma rede de computadores. Em
um SBDD, alm de logicamente relacionados, deve haver estrutura comum entre
esses arquivos, e o acesso deve ser feito por uma interface comum (ZSU,
VALDURIEZ, 2010). A Figura 1 demonstra o que foi dito:

Figura 1 Um sistema de banco de dados distribudo. Adaptado de (ZSU, VALDURIEZ, 2010).

10

ZSU e VALDURIEZ (2010) tambm apresentam as quatro caractersticas

fundamentais dos SBDD: gerncia transparente de dados distribudos e replicados,
acesso confivel aos dados atravs de transaes distribudas, desempenho
melhorado e uma maior facilidade em expandir o sistema.
Ao falar em gerncia transparente dos dados, o termo transparente significa
uma separao entre semnticas de alto nvel e os detalhes de implementao de
baixo nvel, ou seja, um sistema transparente esconde os detalhes de implementao
dos usurios. Para ilustrar o que isso quer dizer, um exemplo: suponha que a mesma
empresa hipottica X mencionada anteriormente deseje guardar os dados de projetos
executados no Brasil apenas na filial de So Paulo. Isso possvel atravs de um
procedimento chamado fragmentao, em que cada relao da base de dados pode
ser dividida em um conjunto de fragmentos que sero armazenados em locais
diferentes (ZSU, VALDURIEZ, 2010). Se ento uma consulta (em SQL, por exemplo)
for submetida ao sistema (distribudo) buscando os registros correspondentes aos
projetos de So Paulo, em um sistema completamente transparente isso poderia ser
feito utilizando a mesma consulta que seria feita caso o sistema fosse centralizado,
sem que o usurio se preocupasse com os detalhes da fragmentao e localizao
dos dados.
Em SBDD, para garantir confiabilidade ainda so utilizadas transaes,
sequncias de operaes executadas como aes atmicas que levam o banco de um
estado consistente a outro, mesmo quando diversas dessas transaes ocorrem de
forma concorrente (ZSU, VALDURIEZ, 2010). Para dar suporte transaes
distribudas, porm, necessria a implementao de mecanismos de controle de
concorrncia distribudos e protocolos de segurana distribudos (logs de recuperao
por exemplo), que so mais complexos que os equivalentes em um cenrio
centralizado.
A melhoria de desempenho em SGBDD est baseada no conceito de
localizao dos dados, ou seja, os dados devem ser armazenados prximos aos seus
11

pontos de uso reais. Os potenciais benefcios da localizao dos dados so: como
cada local responsvel apenas por uma poro dos dados, isso ocasiona um uso
menos intensivo dos recursos computacionais, como da CPU, no servidor; alm disso,
a localizao reduz o tempo de acesso remoto normalmente envolvido em redes de
longa distncia (WAN, do ingls Wide Area Network), permitindo que requisies
sejam servidas com um menor tempo de resposta. Alm disso, em sistemas
distribudos, se torna possvel explorar tcnicas de processamento paralelo nas formas
inter-consulta e intra-consulta. Paralelismo inter-consulta diz respeito execuo de
mltiplas consultas simultaneamente, enquanto o paralelismo intra-consulta envolve
reescrita de uma consulta feita em um esquema de dados global em um certo nmero
de subconsultas, cada uma podendo ser executada em locais diferentes (ZSU,
VALDURIEZ, 2010).
A ltima caracterstica apresentada a maior facilidade com relao
expanso do sistema, o que torna mais fcil acomodar bases de dados de tamanhos
crescentes. Tambm existe uma implicao econmica: normalmente mais barato
acrescentar computadores com configurao mais modesta a um aglomerado de
computadores que tenham o mesmo poder computacional que um nico computador
com um nvel muito elevado de recursos. (ZSU, VALDURIEZ, 2010)
Embora tragam importantes benefcios, o desenvolvimento de SBDD possui
uma srie de desafios (ZSU, VALDURIEZ, 2010):
O primeiro deles o prprio projeto do banco de dados, ou seja, determinar
como os dados devem ser divididos entre as possveis localidades. Existem duas
alternativas neste caso: replicao e fragmentao. A replicao pode ser total (toda a
base replicada em mais de um local) ou parcial (alguns fragmentos so replicados).
Quanto fragmentao, as decises mais importantes so: como realizar a
fragmentao em si e qual a melhor alocao destes fragmentos. Alm disso, deve
existir uma forma de mapear itens de dados em fragmentos atravs de uma espcie

12

de catlogo, que normalmente chamado diretrio. Um exemplo de questo relativa

gerncia deste diretrio pode ser: o mesmo global ou apenas local?
Outra questo a ser tratada como realizar o processamento de consultas
distribudas, o que envolve desenvolver algoritmos que analisem as consultas
recebidas e gerem planos de execuo das mesmas com o menor custo,
considerando fatores como a distribuio dos dados e custos de comunicao entre
ns.
O controle de concorrncia distribudo, mencionado anteriormente de forma
breve, envolve a sincronizao de acessos ao banco de dados distribudo, de forma
que a integridade do mesmo seja mantida, ou seja, mltiplas cpias de dados devem
convergir para o mesmo valor mutuamente. Existem diversas abordagens neste caso
(pessimistas ou otimistas) e este pode ser considerado o problema mais estudado
neste campo de pesquisa.
Finalmente, h a deteco e recuperao de falhas. Replicao de dados
aumenta a redundncia e tem o potencial de fazer com que a operao se mantenha
ativa mesmo quando h uma falha. Porm, se uma ou diversas instncias se tornarem
inacessveis (por problemas na rede) ou inoperantes, devem existir mecanismos
capazes de identificar quando a falha acontece, manter as demais instncias
consistentes e atualizadas e, eventualmente, quando os outros computadores (ou a
rede) se recuperarem da falha, o SBDD deve voltar a funcionar normalmente.
Embora a classe de SBDD investigados neste trabalho (NewSQL) seja
relativamente nova, bancos de dados distribudos e os problemas associados a eles
so estudados h bastante tempo. ROTHNIE et. al. (1980) descrevem o
desenvolvimento de um SBDD chamado SDD-1 com uma linguagem de consulta
chamada Datalanguage. BERNSTEIN e GOODMAN (1981a) propem um mtodo
para otimizao do processamento de consultas no SDD-1. RAM (1989), DAUDPOTA
(1998) sugerem modelos para o problema da alocao de dados. KHAN e AHMAD
(2010) propem um algoritmo especfico para gerenciar dados replicados. Controle de
13

concorrncia

distribudo

foi

estudado

por

(BERNSTEIN,GOODMAN,1981b)

(CAREY,LIVNY,1988), para dar alguns exemplos.

2.4 NoSQL
2.4.1 Motivao
SGBDR no atendem satisfatoriamente aplicaes que poderiam se beneficiar de
escalabilidade horizontal, como as que precisam de capacidade analtica em tempo
real, para citar um exemplo. Para buscar atender esta demanda, surge o NoSQL. Com
a inteno original de se criar sistemas distribudos escalveis, com modelos mais
simples que o relacional e com alta disponibilidade, o movimento NoSQL (mais
conhecido hoje em dia como Not only SQL) iniciado no final da dcada de 2000
(STONEBRAKER, 2010) vem crescendo rapidamente e j conta com o mais de 1503
SGBD desenvolvidos.

2.4.2 Principais Caractersticas

Uma das caractersticas fundamentais dos sistemas NoSQL a escalabilidade
horizontal baseada em uma arquitetura do tipo memria distribuda com replicao e
fragmentao dos dados em diferentes servidores (CATTELL, 2010). Isso permite que
esses sistemas possam suportar um grande nmero de operaes de leitura/escrita
por segundo, sendo elas normalmente caractersticas de sistemas OLTP. Em sua
maioria, esses sistemas NoSQL, diferentemente de SBGDR, no fornecem suporte s
propriedades transacionais ACID. Atualizaes, por exemplo, so propagadas para
todo o aglomerado, porm sem saber antecipadamente o momento exato em que
todas as rplicas de um item de dados estaro atualizadas, o que caracteriza um

http://nosql-database.org/ , acessado pela primeira vez em 03/12/2013

14

relaxamento na consistncia de dados, chamado consistncia tardia. Alguns autores

sugerem um novo acrnimo no lugar do ACID, o BASE (do ingls, Basically Available,
Soft State, Eventually Consistent) (CATTELL, 2010), representando uma forma de
sacrificar algumas restries impostas pelas propriedades ACID para que um sistema
possa conseguir um desempenho e uma escalabilidade muito maiores (CATTELL,
2010). Logo, os SGBD NoSQL operam sobre a relao entre desempenho e
complexidade do modelo, tendendo sempre a aumentar a primeira.
So definidas por CATTELL (2010) seis importantes caractersticas dos novos
sistemas NoSQL:
1.

Aumento de desempenho de operaes simples quando do aumento do

nmero de ns;

2.

Replicao e distribuio de dados em diferentes ns;

3.

No lugar do SQL, um protocolo simples de comunicao com o SGBD;

4.

Um modelo de controle de concorrncia mais relaxado do que o

utilizado nos SGBDR tradicionais;

5.

Uma distribuio eficiente dos ndices e utilizao de memria RAM para

armazenamento de dados; e

6.

Adio dinmica de atributos aos registros j existentes na base (pela

no-obrigao de ter esquemas fixos).

2.4.3 Classificao
Como sistemas NoSQL no so regulados por nenhum modelo em especfico,
partilhando apenas algumas caractersticas em comum, foram propostas algumas
classificaes para os mesmos, dos quais as principais so (LEAVITT, 2010,
CATTELL, 2010):
Armazm de Pares Chave-Valor. um sistema que armazena valores
indexados para posterior recuperao atravs de chaves. Esses sistemas podem

15

utilizar dados estruturados e/ou no estruturados. A escalabilidade nesses sistemas

obtida atravs da distribuio das chaves entre os diversos ns. Esses sistemas
geralmente possuem funcionalidades como replicao, versionamento de itens de
dados, entre outras. Os SGBD NoSQL do tipo chave-valor so ideais para aplicaes
que possuem um nico tipo de objeto a ser guardado, e cujas consultas sejam
baseadas em um nico atributo (chave) (CATTELL, 2010). Um exemplo disso seria
um cache de pginas web dinmicas: pginas que carreguem objetos pesados podem
ser armazenadas em cache para reduzir o tempo de espera do usurio. Por exemplo,
em uma aplicao de comrcio eletrnico, a chave poderia ser gerada sobre
parmetros que identificam um produto. Desde que a gerao dessa chave seja
determinstica, sempre ser possvel recuper-la.
Exemplos de SGBD NoSQL chave-valor so o Voldemort4 e o Redis5.
Orientados Coluna. Diferentemente dos SGBDR, que armazenam as
informaes em tabelas fortemente estruturadas em linhas e colunas, esse tipo de
sistema contm uma tabela extensvel de dados minimamente relacionados. Cada
linha desta tabela pode possuir um conjunto prprio de colunas, que no precisa ser
igual aos das demais. A escalabilidade feita atravs da distribuio das linhas e
colunas pelos ns, fragmentando inicialmente as colunas de uma tabela (criando-se
novas pequenas tabelas e montando grupos de tabelas relacionadas) e depois
fragmentando as linhas dessas tabelas resultantes pela chave primria, com
fragmentao por intervalo. Exemplos de bancos NoSQL orientados coluna so o
HBASE6 e o Cassandra7.
Baseado em Documento. Esses SGBD armazenam e organizam dados como
uma coleo de documentos, ao invs de tabelas estruturadas com tamanhos
uniformes para cada registro. Sendo assim, os usurios podem adicionar quantos

http://www.project-voldemort.com/, acessado pela primeira vez em 15/12/2013

http://redis.io/, acessado pela primeira vez em 15/12/2013
https://hbase.apache.org/, acessado pela primeira vez em 15/12/2013
7
http://cassandra.apache.org/, acessado pela primeira vez em 15/12/2013
5
6

16

atributos forem necessrios, de qualquer tamanho, a um documento. A escalabilidade

geralmente atingida atravs de leituras sobre rplicas de dados j modificados.
Exemplos de bancos de dados NoSQL baseados em documentos so o SIMPLEDB8
da Amazon e o MongoDB9.

2.4.4 Problemas
As solues NoSQL chegaram ao mercado como uma alternativa para atender s
necessidades das aplicaes que os SGBDR tradicionais tm dificuldade em suprir,
devido aos problemas de escalabilidade e disponibilidade. No entanto, estas solues
j enfrentam alguns problemas (LEAVITT, 2010), que devem ser bem analisados por
qualquer futuro utilizador, para que seja avaliada a viabilidade de sua utilizao.
Complexidade e Sobrecarga
Como os bancos NoSQL no possuem uma linguagem unificada de consulta,
como o SQL, eles necessitam de uma programao manual das consultas, o que pode
no ser uma tarefa vivel para aqueles que no saibam ou no desejem codific-las.
Mais do que isso, ao longo dos anos, tempo de pesquisa e desenvolvimento foi
investido em aprimorar compiladores SQL para gerar planos de execuo de
consultas otimizados. Ao desenvolver novos mtodos de acesso, perde-se esta
experincia adquirida, e novos trabalhos precisam ser desenvolvidos.
Consistncia
Os sistemas NoSQL do suporte apenas a consistncia tardia de dados. Os
usurios devem estar cientes de que h uma troca envolvida. No caso de aplicaes
cuja exatido dos dados crtica, no ter garantias de consistncia pode no ser uma
opo.

8
9

http://aws.amazon.com/simpledb/, acessado pela primeira vez em 15/12/2013

http://www.mongodb.org/, acessado pela primeira vez 15/12/2013

17

Pouca Maturidade da Tecnologia

A maioria das organizaes e pessoas no so familiarizados com os sistemas
NoSQL, o que pode atrapalhar na sua adoo no mercado.
Dados esses problemas, principalmente os relacionados ausncia de uma
linguagem como SQL e das propriedades ACID, que uma nova corrente surgiu na
comunidade de bancos de dados. O movimento NewSQL, termo citado pela primeira
vez em 2011 (ASLETT,2011), argumenta que os problemas dos SGBDR no esto
relacionados linguagem SQL ou s transaes ACID, e sim algumas limitaes
impostas por projetos que datam de vrios anos, como uma natureza intrinsecamente
centralizada e armazenamento de dados baseado em disco. No prximo captulo os
sistemas NewSQL e suas principais caractersticas so analisados em maiores
detalhes.

2.5 Avaliao de Desempenho em Sistemas de Bancos de

Dados
SGBD so softwares complexos que, alm de exercer uma srie de atividades
naturalmente complexas, como manter a consistncia dos dados e possuir tolerncia a
falhas, devem, preferencialmente, atender tambm a alguns requisitos no-funcionais,
como ser eficientes no armazenamento de dados e ter alto desempenho. Com a
popularizao de sistemas para suporte inteligncia empresarial (do ingls business
intelligence) e anlise de dados em tempo real, esses se tornam fatores ainda mais
relevantes na deciso de adotar ou no uma determinada soluo de banco de dados
para atender certas necessidades de negcio. Com uma boa variedade de opes de
SGBD disponveis, incluindo os de cdigo aberto, importante que uma pessoa no
papel de tomador de deciso tenha como medir, de alguma, forma um conjunto de
caractersticas entre os sistemas candidatos.

18

Medir o desempenho de um SGBD, porm, no uma tarefa trivial, dado que a

prpria definio de desempenho pode ser dada em funo de um conjunto de
variveis diferentes. Para algumas aplicaes, que lidem com dados muito sensveis
ou crticos de alguma forma (um sistema de monitoramento, por exemplo), pode ser
importante que muitas operaes de atualizao sejam realizadas rapidamente, logo
tendo uma alta vazo (do ingls throughput) de transaes por unidade de tempo. J
para outras, pode ser mais importante que o SGBD a ser avaliado apresente alta
disponibilidade, pois tempo do sistema fora do ar representa prejuzo financeiro
elevado.
Algumas caractersticas gerais, porm, podem ser avaliadas. BING apud
PAUL (2008) define como propsitos bsicos da avaliao de desempenho de SGBD:
1.

Dado um nico SGBD, descobrir a melhor configurao e ambiente de

operao

2.

Estudar dois ou mais sistemas de bancos de dados e realizar uma

comparao sistemtica entre eles

Um benchmark um conjunto de instrues executveis usado para medir e

comparar o desempenho quantitativo e relativo de dois ou mais sistemas
gerenciadores de bancos de dados atravs da execuo de experimentos controlados
(SENG et al., 2004). Os dados gerados pela execuo de um benchmark, como vazo,
tempo de resposta, relao preo/desempenho, entre outros, podem ser usados para
representar ou predizer o desempenho de um sistema. Este tipo de informao pode
ajudar

grupos

de

usurios

distintos

(administradores

de

banco

de

dados,

desenvolvedores, gestores, etc.) a tomar decises a respeito da aquisio de um novo

sistema, ou a encontrar um gargalo na operao de um j existente, por exemplo.
Benchmarks de banco de dados so compostos de bases de teste e cargas de
trabalho (workloads) de teste, podendo ser sintticos ou empricos. Um benchmark
sinttico simula uma aplicao tpica em um domnio pr-determinado e gera uma
carga de trabalho correspondente, enquanto benchmarks empricos utilizam cenrios e
19

dados reais. Embora utilizar cargas de trabalho reais sejam o teste ideal para um
sistema, os custos de implementao do ambiente podem ser maiores que os
benefcios obtidos. Por isso, normalmente, a utilizao de benchmarks sintticos so
solues preferidas (SENG et al., 2004).
Um dos desafios apresentados por benchmarks sintticos a reprodutibilidade
dos testes realizados. Os resultados podem variar de acordo com configuraes de
usurio, por exemplo. Assim, resultados alcanados em um ambiente no
necessariamente sero reproduzidos em outro e, por isso, devem ser utilizados como
estimativa, normalmente com o propsito de comparao relativa (SENG et al., 2004).

20

Captulo 3 - NewSQL
Os SGBD NoSQL buscam alternativas para melhorar a escalabilidade e o
desempenho dos SBD atuais. No entando, isto conseguido, em detrimento da
utilizao da SQL e das propriedades ACID para as transaes. Para muitos, houve
uma grande perda nessa troca, pois no apresentar garantias integrais para a
consistncia dos dados, assim como ter que recodificar mtodos de acesso, no
interessante.
Por isso novas pesquisas foram e continuam sendo feitas para conseguir
encontrar uma combinao perfeita entre escalabilidade e consistncia. Para sistemas
empresariais que lidam com dados de alto nvel, como instituies financeiras,
companhias areas e outras mais, essa no uma questo simples. Apesar de existir
hoje a necessidade de aumentar a escalabilidade de seus sistemas, e, principalmente,
a velocidade de respostas aos clientes, garantir a consistncia e a durabilidade das
informaes essencial. E para continuar com essas propriedades, usando os
SGBDR tradicionais, existem algumas possibilidades. Uma delas adquirir um
servidor com maior capacidade de processamento (escalabilidade vertical). Outra
possibilidade fragmentar a base manualmente, o que, alm de um processo de difcil
manuteno (j que eventualmente ser necessrio redistribuir os fragmentos), pode
demandar que alguma lgica de acesso aos dados seja includo no cdigo da
aplicao, por exemplo, o que exatamente uma prtica que se deseja evitar ao
utilizar um SGBD.
Nesse contexto, surgiram os sistemas NewSQL (ASLETT, 2011) que designa
uma nova classe de SGBD que buscam promover a mesma melhoria de desempenho
e escalabilidade dos sistemas NoSQL enquanto mantm o suporte linguagem SQL e
s propriedades ACID, que tem ampla adoo com os SGBDR tradicionais.

21

STONEBRAKER e CATTEL (2011) definem cinco caractersticas de um SGBD

NewSQL:
1.

Linguagem SQL como meio de interao entre o SGBD e a aplicao;

2.

Suporte para transaes ACID;

3.

Controle de concorrncia no bloqueante, para que as leituras e escritas

no causem conflitos entre si;

4.

Arquitetura que fornea um maior desempenho por n de processamento;

5.

Arquitetura escalvel, com memria distribuda e com capacidade de

funcionar em um aglomerado com um grande nmero de ns.

Diferente dos SGBDR tradicionais, que eram considerados solues para

qualquer tipo de aplicao, os SGBD NewSQL utilizam uma estratgia diferente. Cada
novo sistema desenvolvido visa atender a uma necessidade especfica. Ou seja, os
sistemas NewSQL tentam dividir as novas demandas em diferentes nichos de
mercado e buscam alcan-los de forma separada, terminando com o antigo conceito
de ter um nico sistema que sirva para qualquer tipo de aplicao.
Nas sees seguintes so apresentadas as demandas de aplicaes que
alguns desses sistemas buscam atender, assim como as principais decises de
implementao tomadas para esse fim.

3.1 NuoDB
3.1.1 Viso Geral
NuoDB um SGBD NewSQL em memria que tem como foco a utilizao em
ambientes de dados geo-distribudos, sendo direcionado para empresas que precisam
expandir suas bases de dados para mltiplos servidores mas no querem perder os
benefcios da lgebra relacional e das propriedades ACID.

22

Para garantir escalabilidade, o NuoDB define uma arquitetura para bases de

dados distribudas aproveitando dois dos maiores recentes avanos tecnolgicos,
como processadores de mltiplos ncleos e memria estendida.

3.1.2 Arquitetura
O

NuoDB possui uma arquitetura distribuda com uma abordagem de cache

distribudo e durvel (do ingls, durable distributed cache), baseada em replicao sob
demanda (NuoDB Bloor Report, 2013). Para o NuoDB, s existe o suporte ao modo
replicao total dos dados armazenados. Alm disso, o NuoDB no realiza
fragmentao da base de dados entre os ns de um aglomerado. Os ns de
processamento formam um cache distribudo em uma rede ponto-a-ponto. Portanto,
em um dado momento, mltiplas cpias de um item de dados podem estar disponveis
em memria (o que permite balanceamento de carga nas requisies realizadas),
assim como no estar em nenhum n, devendo ser trazido do disco. Esses conceitos
so mais detalhados nas prximas sees.

3.1.2.1 Estrutura em nveis

O NuoDB estruturado em 3 diferentes nveis: administrativo, de processamento e de
armazenamento. A separao entre os nveis de processamento e de armazenamento
o que busca dar escalabilidade ao sistema. Ao separar esses dois nveis, a
durabilidade do sistema passa a ser uma tarefa separada do processamento de
transaes, o que permite configurar ambas as propriedades de forma separada.
Assim o desempenho pode ser aumentado, sem causar impacto em como e onde os
dados so armazenados (NuoDB Bloor Report, 2013). Cada nvel representado por
uma instncia de NuoDB, rodando um dos processos detalhados a seguir:
O nvel de processamento consiste em motores de transao, doravante
denominados de TE (do ingls, transaction engine). Esse nvel responsvel por
23

garantir as propriedades Atomicidade, Consistncia e o Isolamento do ACID, deixando

a durabilidade para ser garantida pelo nvel de armazenamento.
O nvel de armazenamento responsvel pela Durabilidade e tambm por
disponibilidade. uma fonte de dados sempre ativa e consistente. constitudo de
gerentes de armazenamento, doravante denominados de SM (do ingls, storage
managers). Cada um destes SM possui acesso a um espao em disco chamado
arquivo, que contm uma cpia de toda a base de dados. Um SM pode servir
qualquer item de dados a um TE a partir deste arquivo. Por isso, embora existam
diferentes instncias fsicas da mesma base de dados, o conjunto formado por eles
representam uma nica instncia lgica, transparente para o usurio.
O nvel administrativo responsvel por garantir escalabilidade horizontal por
demanda e o balanceamento de carga. Cada n possui um agente local. Juntos, os
agentes formam uma rede ponto-a-ponto, que recebe o nome de Domnio (NuoDB
Technical WhitePaper, 2013). Para cada domnio, existem um ou mais agentes da
rede chamados brokers. Um broker um tipo especial de agente, encarregado das
funes administrativas, e somente atravs dos brokers possvel gerenciar (iniciar,
parar ou migrar) as bases de dados, inicializar, terminar e obter os logs dos TE e dos
SM e monitorar todo o sistema para saber se tudo est ocorrendo como o esperado.
Na Figura 2, mostrado um exemplo de arquitetura do NuoDB em 5
computadores, com dois SM e dois TE. Nesse exemplo, o broker possui um servidor
dedicado. A base est replicada em dois SM, garantindo que caso um processo SM
falhe, a base de dados continue funcionando normalmente no outro SM.

24

Figura 2 - Arquitetura do NuoDB. Adaptado de www.nuodb.com

3.1.2.2 Os tomos
Tendo explicado o que so cada um dos nveis da arquitetura, necessrio ir mais a
fundo e explicar como eles so constitudos de fato. E para isso um novo conceito
precisa ser definido, o de tomos. Mesmo parecendo uma base de dados SQL, o mais
certo ao definir o NuoDB seria cham-lo de uma base de dados de objetos distribuda,
com uma camada SQL no topo (NuoDB Technical WhitePaper, 2013). Por trs dessa
camada toda a lgica opera em objetos denominados tomos, que so objetos autocoordenados que podem representar qualquer tipo de informao como por exemplo,
dados, metadados, esquemas, ndices e outras mais. Esses objetos facilitam a
comunicao interna e a implementao do cache. O nvel de processamento
transacional responsvel por fazer o mapeamento entre o contedo SQL e os
devidos tomos.
Alm do contedo da base de dados, existe outro tipo de tomo, o chamado
tomo de Catlogo, que utilizado para buscar os demais tomos entre os
processos correntes. Quando da criao da base de dados, e da ativao do primeiro
TE, um objeto diretamente colocado no seu cache, o Catlogo Mestre. O Catlogo
Mestre indica onde todos os elementos da base de dados podem ser descobertos.
25

atravs desses catlogos que qualquer TE sabe onde um tomo est disponvel.
Quando um tomo de dados requisitado a um TE, ele buscado na seguinte ordem:
no cache do prprio TE (informao do catlogo local), no cache de outros TE e,
finalmente, se no estiver em nenhum destes, requisitado a um SM para que o mesmo
busque no disco.
Essa abstrao de todos os dados em tomos serve para simplificar o modelo
de durabilidade do NuoDB. Todo os acessos na arquitetura so feitos atravs dos
tomos, e todos eles so guardados como pares de chave-valor.

3.1.2.3 Controle de Concorrncia

Os tomos ajudam o NuoDB a garantir a durabilidade do sistema, mas eles no so
responsveis por gerenciar conflitos ou consistncia. E, sem isso, o NuoDB no teria
como garantir as propriedade ACID. Para isso, ele utiliza o protocolo Multi-Version
Concurrency Control (MVCC). Esse protocolo funciona guardando verses diferentes
de itens de dados. Alm disso, todas as atualizaes e remoes de dados geram
novas verses dos mesmos. Os motores de transao, TE, so caches e, dentro
deles, esto diferentes verses de um mesmo dado. Aps uma atualizao, a nova
verso fica pendente at que a transao associada a ela tenha realizado com
sucesso a sua efetivao.
Como todas as modificaes de verses so guardadas em cache, nada de
fato imediatamente modificado no meio de armazenamento persistente (disco por
exemplo). Assim o sistema pode usar uma abordagem otimista para comunicar as
modificaes para todo os interessados e, caso necessrio, desfazer a transao,
deixando a ltima atualizao no cache de lado. Junto com o MVCC o NuoDB possui
um modelo de visibilidade da base de dados, chamado de Isolamento Instantneo
(Snapshot Isolation). Esse modelo permite obter uma viso constante da base de
dados no exato momento em que uma transao se inicia.

26

Porm, mesmo com o MVCC e o Isolamento Instantneo, ainda teramos

problemas caso duas transaes tentassem fazer modificaes em um mesmo valor
simultaneamente. Nesses casos, em atualizaes ou remoes de dados, o NuoDB
utiliza uma TE como mediadora, denominada Presidente (do ingls, Chairman), que
define por ordem temporal, qual transao ir concluir e qual no ir ser realizada.
importante notar que para cada tomo existe uma TE funcionando como Presidente, e
essa TE deve ser uma que possui o tomo em seu cache.
Duas caractersticas importantes do NuoDB so o modo como garante
escalabilidade, atravs da abordagem baseada em replicao sobre demanda, e por
possuir uma certa elasticidade, podendo dinamicamente aumentar ou diminuir o
tamanho do domnio, simplesmente adicionando ou retirando ns e processos TE e
SM.

3.2 VoltDB
3.2.1 Viso Geral
VoltDB um SGBDD com armazenamento em memria principal, em conformidade
com as propriedades ACID e que utiliza uma arquitetura de memria distribuda.
VoltDB implementa um projeto similar ao do H-Store (KALLMAN et al.,2008), seu
predecessor, que foi utilizado como prottipo em pesquisa acadmica. Uma restrio
imposta pelo VoltDB: a necessidade da base de dados caber integralmente em
memria. Os benefcios originrios desta deciso so: garantir que no haja
sobrecargas, evitando inserir recursos para gerncia de acesso a armazenamentos
baseados em disco, e um menor tempo de busca aos dados (justamente por ser em
memria, em comparao a armazenamento em disco). Em compensao,
necessrio que a capacidade de memria principal do servidor seja suficientemente
grande para acomodar os dados da aplicao a qualquer momento.

27

O propsito do VoltDB ser mais rpido que os SGBDR tradicionais em uma

certa classe de aplicaes em tempo real, como manter o estado de partidas de jogos
online, negociaes eletrnicas e a localizao de anncios em pginas web
(STONEBRAKER,WEISBERG,2013). A motivao para o desenho da arquitetura do
VoltDB

se

baseia

(HARIZOPOULOS

em
et

al.,

eliminar
2008),

as
a

fontes
saber:

de

sobrecarga

sobrecargas

com

mostradas
gerncias

em
de

buffer,mltiplas linhas de execuo (multi-threading), bloqueios de registros e arquivos

de logs com escritas adiantadas (write-ahead logs).

3.2.2 Arquitetura
O ambiente de utilizao adequado para o VoltDB proporcionado por um
aglomerado de computadores (STONEBRAKER,WEISBERG, 2013). Nesse ambiente,
o VoltDB pode realizar fragmentaes horizontais para cada tabela, alocando os
fragmentos para diferentes ns do aglomerado. A fragmentao apropriada para
tabelas grandes que so acessadas ou atualizadas frequentemente. Para tabelas
menores e que sofrem poucas atualizaes, tambm suportada a opo de repliclas integralmente em todos os ns, o que mais apropriado.
Quando fragmentada, a definio da localizao dos fragmentos de uma tabela
dada por uma funo hash aplicada a um dos seus atributo da tabela o que
indicado em um catlogo. Um catlogo no VoltDB um conjunto pr-compilado de
instrues SQL utilizado para criar ou recuperar uma base de dados. Nele, geralmente
constam instrues LDD (Linguagem de Definio de Dados) com as definies dos
esquemas e dos fragmentos, alm de procedimentos armazenados, que podem ser
escritos em SQL ou Java (no momento da escrita deste projeto, estas so as
linguagens suportadas) e compilados junto com o catlogo. Alm disso, cada
fragmento replicado K+1 vezes, de acordo com o conceito de K-safety (indica a
quantidade de rplicas redundantes que podem falhar e o sistema continuar ativo). O

28

valor padro de K igual a zero, e este pode ser modificado no arquivo de

configurao da aplicao.
Para o VoltDB, uma transao implementada como um procedimento
armazenado registrado junto ao sistema (STONEBRAKER, WEISBERG,2013).
Consultas ad-hoc so compiladas em tempo real em procedimentos armazenados
temporrios. As transaes so analisadas em tempo de compilao, categorizadas e
armazenadas junto ao sistema. As categorias de transaes so:
i.

Transaes de um nico n: neste caso, as transaes utilizam apenas

fragmentos que pertencem ao mesmo n;

ii.

Transaes

tiro-nico:

so

transaes

compostas

de

diversas

declaraes SQL que podem ser executadas em paralelo em mltiplos

ns, pois envolvem diversos fragmentos por exemplo;
iii.

Transaes gerais: alm de envolver mltiplos ns, so compostas de

mltiplas fases, onde cada fase deve ser completada antes da prxima.

Um usurio executa uma transao ao invocar um procedimento armazenado

correspondente e fornecendo parmetros em tempo de execuo. O VoltDB executa
todas as transaes em ordem determinstica: quando uma transao for do tipo n
nico, enviada a um controlador do n, no n correto, que responsvel por
fornecer uma organizao sequencial de todas as transaes deste tipo. As
transaes so ento executadas, sequencialmente, sem que haja necessidade de
realizar bloqueios. As transaes que pertencem s demais categorias so enviadas a
um tipo especial de controlador, o controlador global, que responsvel por definir
um ordenamento sequencial das mesmas. As declaraes SQL destes tipos de
transaes devem ser enviadas aos ns corretos, onde elas sero inseridas no fluxo
de transaes de ns nicos (STONEBRAKER, WEISBERG, 2013). Se, ao projetar
uma aplicao e o esquema da base de dados associado, as transaes forem

29

majoritariamente locais em relao aos fragmentos, possvel tirar proveito de um

maior grau de paralelismo com essa soluo.
Em cada n, uma instncia do VoltDB executada atravs de uma nica
thread, o que elimina a sobrecarga que existe quando preciso gerenciar recursos
compartilhados em ambientes com mltiplas threads. Como todos os dados devem
caber em memria principal, tambm no h necessidade de existir um buffer, que,
em sistemas baseados em disco, faria cache de dados. O VoltDB garante durabilidade
desses dados atravs de dois recursos: instantneos (snapshots) e logs de comandos.
Um instantneo uma cpia completa do contedo da base de dados, em um
determinado momento no tempo, que gravada em disco. Instantneos podem ser
criados manualmente, atravs de uma ferramenta administrativa do VoltDB (voltadmin),
ou automaticamente, atravs de intervalos de tempo definidos no arquivo de
configurao. O problema surge caso uma falha ocorra entre a criao de dois
instantneos: caso o intervalo programado para criao de um instantneo seja de 10
minutos, por exemplo, e uma falha ocorra no instante t=12 minutos, todas as
transaes que ocorreram entre 10 e 12 minutos sero perdidas. Por este motivo, o
VoltDB permite que seja habilitado o recurso de log de comandos, que nada mais
que um log de todas as transaes executadas, escrito no disco em intervalos de
tempo configurveis (modo assncrono) ou antes de cada transao sofrer uma
efetivao (modo sncrono). Desta forma, caso ocorra uma falha, o servidor pode
recuperar o estado da base de dados primeiramente pelo ltimo instantneo
atualizado e, depois, recriando as transaes descritas no log.
Alta disponibilidade no VoltDB alcanada atravs da replicao de dados.
Quando uma transao executada, ela primeiramente enviada para todas as
rplicas, que a processam em paralelo. Como o controle de concorrncia
determinstico, a transao ter sucesso ou ir falhar em todos os ns, dispensando
sincronizao adicional (STONEBRAKER,WEISBERG,2013). Os ns trocam ento
mensagens entre si para indicar que permanecem funcionais e, caso haja um
30

problema com algum deles, este seja desconectado: at K rplicas podem falhar antes
de um aglomerado parar de operar totalmente.

3.3 MemSQL
3.3.1 Viso Geral
O SGBD MemSQL comeou a ser desenvolvido em Janeiro de 2011 por dois exfuncionrios do Facebook, que imaginavam existir uma nova possvel maneira de dar
ao SQL escalabilidade e velocidade. O resultado foi um SGBD distribudo em
memria, que consultado atravs de uma interface SQL, tendo como foco aplicaes
transacionais, e que tambm apresenta capacidade para execuo de anlises de
dados em tempo real. Os setores que esto se destacando na utilizao do MemSQL
so os servios financeiros, as telecomunicaes e os servios de propaganda
(ASLETT, 2012).

3.3.2 Arquitetura
O MemSQL possui uma arquitetura distribuda organizada em dois nveis de ns,
Agregadores e Folhas:
Agregadores trabalham como gerentes de consultas, recebendo-as e
distribuindo-as entre os ns folhas. Aps as consultas serem executadas pelos ns
folhas, os agregadores combinam os resultados e os retornam para o usurio. Alm
disso, a fragmentao dos dados entre os ns folhas tambm controlada pelo
agregador. Os agregadores armazenam apenas metadados.
Agregador Mestre (MA) responsvel pelo monitoramento do aglomerado.
Todo aglomerado precisa ter no mnimo um MA para poder ser iniciado. O agregador
mestre trata de todas as operaes LDD a serem feitas no banco de dados. Todas as
bases de dados, tabelas, adio e remoo de ns e rebalanceamento

dos

fragmentos so feitas atravs do agregador mestre.

31

Folhas possuem uma arquitetura de memria distribuda e armazenam os

dados do banco. Recebem as consultas dos ns agregadores e as executam. Um n
folha no sabe da existncia dos outros, pois o protocolo de controle de concorrncia
s atua em um n, e no entre eles.
A arquitetura do MemSQL, exemplificada na Figura 3, foi projetada para alocar
a maior quantidade de trabalho para os ns folhas, possibilitando a escalabilidade do
aglomerado e um melhor desempenho das consultas ao aumentar o nmero de ns
folhas disponveis. Essa adio de ns pode ser feita de forma dinmica, sem a
necessidade de reiniciar nenhum agregador ou folha do aglomerado. Ao adicionar
folhas, o balanceamento dos dados feito de forma automtica, desde que haja
memria disponvel para executar a operao.

Figura 3 - Arquitetura do MemSQL. Adaptado de www.memsql.com

3.3.2.1 Alocao de Tabelas

Quanto alocao de dados, o MemSQL suporta dois tipos de tabelas: as tabelas
replicadas, criadas a partir do uso da expresso REFERENCE, e as tabelas
distribudas (fragmentadas). As replicadas, como o prprio nome diz, so copiadas em
todos os ns folhas do aglomerado. As tabelas fragmentadas so distribudas entre os
ns do aglomerado atravs das chaves de fragmentao (SK, do ingls, Shard Keys) e
das chaves estrangeiras de fragmentao (FSK, do ingls, Foreign Shard Keys),
32

fazendo com que registros com valores iguais para o atributo de fragmentao estejam
sempre no mesmo fragmento, o que facilita a execuo de operaes de juno. O
resultado da criao padro de uma tabela no MemSQL (ou seja, se a expresso
CREATE TABLE for utilizada sem nenhum modificador) : criar uma tabela
fragmentada, dividida em um total de fragmentos igual a oito vezes o nmero de ns
folhas ativos no aglomerado. Esse valor pode ser modificado ao incluir o modificador
PARTITIONS N na expresso, onde N o nmero de fragmentos total desejado.
As definies das chaves de fragmentao so guardadas pelos Agregadores,
que as utilizam na hora de alocar as consultas, enviadas pelo cliente, aos ns folhas.
Para fragmentar uma tabela, o MemSQL tem suporte s fragmentaes
primria e derivada. A fragmentao primria pode ser realizada por qualquer atributo
da tabela que seja especificado como chave de fragmentao (se nenhum for atribudo,
a chave de fragmentao padro a chave primria). A fragmentao derivada uma
estratgia para tentar alocar, em um mesmo n, fragmentos que possuam o mesmo
valor de chave estrangeira, e definida usando a chave estrangeira de fragmentao.
Para qualquer tabela, somente um modo pode ser usado. Alm disso, quando so
utilizadas chaves estrangeiras de fragmentao, para qualquer operao de juno
(entre as tabelas A e B, onde B referencia A, por exemplo), a condio de juno deve
ser que a chave estrangeira de fragmentao de B seja igual a chave de fragmentao
de A, para quaisquer pares de tabelas.

3.3.2.2 Controle de Concorrncia

Para o controle de concorrncia, o MemSQL utiliza o protocolo MVCC em conjunto
com ndices no bloqueantes, a fim de garantir um melhor desempenho em cenrios
com operaes concorrentes, sem que haja uma degradao da consistncia. Assim,
as operaes de leitura no bloqueiam as operaes de escrita e vice-versa. Esta

33

configurao favorece o uso do MemSQL em aplicaes de escrita intensa, ou que

tenham uma proporo semelhante para as operaes de escrita e leitura.
Para aumentar o grau de concorrncia, o MemSQL suporta apenas transaes
formadas por uma nica consulta. Alm disso, se uma transao utiliza dados de
diferentes fragmentos do banco, uma nova transao aberta para cada fragmento,
ou seja, caso uma consulta de leitura ou escrita falhe em um fragmento, o SGBD ir
desfazer somente essa consulta, permitindo que as consultas nos demais fragmentos
continuem a ser executadas. Tal caracterstica precisa ser tratada de maneira
cuidadosa pelo desenvolvedor de aplicaes, pois pode levar a srias inconsistncias
no banco de dados.
O SGBD MemSQL pode dinamicamente adicionar novos ns ao aglomerado
para aumentar a capacidade de armazenamento ou o poder de processamento. A
fragmentao nos novos ns feita automaticamente e o aglomerado faz o rebalanceamento dos dados automaticamente tambm.

3.3.3 Execuo de Consultas

As consultas submetidas ao MemSQL so compiladas e convertidas em cdigos C++.
Em seguida, so armazenadas em um cache de consultas. Quando uma nova
consulta recebida, o MemSQL verifica se j existe cdigo C++ para ela no cache. Tal
fato pode ocorrer se uma consulta idntica em estrutura, mas possivelmente diferente
quanto aos parmetros, tiver sido recebida recentemente pelo SGBD. O MemSQL
consegue ento reutilizar o cdigo previamente compilado, alterando somente os
valores dos parmetros e reduzindo significativamente o tempo de processamento. O
cache de consultas no armazena resultados de execues de consultas anteriores.
Isso limitaria o reaproveitamento a casos em que as consultas so idnticas em
relao tanto estrutura quanto aos valores dos parmetros.

34

Ao receber uma requisio, o Agregador Mestre, verifica na tabela hash que

contm os planos de consulta (cache de consultas), se a consulta atual est presente.
Caso esteja, os parmetros so passados para o cdigo j compilado e a consulta
executada. Caso contrrio, a consulta compilada em cdigo C++ e adicionada na
tabelas de planos de consulta. Esse processo est demonstrada na Figura 4.

Figura 4 - Execuo de Consultas no MemSQL. Adaptado de www.memsql.com

3.3.4 Propriedades ACID

Para garantir a durabilidade da base de dados, a configurao do MemSQL
utiliza trs importantes variveis, definidas como durability, transaction_buffer e
snapshot_trigger_size10. A primeira, quando recebe valor zero, faz com que nenhum
log e/ou instantneo da base de dados seja guardado em disco, e depois que o
sistema sai do ar, todos os dados alocados se perdem. A base de dados e as
definies das tabelas, porm, so persistidos. O buffer de transaes o buffer do
log de transaes de cada base de dados. Quando o tamanho deste buffer atinge o
valor determinado pela varivel transaction_buffer, as alteraes, at ento em
memria, so escritas no disco. Por padro, o MemSQL escreve as mudanas no
disco de forma assncrona. Quando a varivel transaction_buffer colocada em zero,
a durabilidade do banco de dados realizada de forma sncrona, ou seja, todos os

10

www.developers.memsql.com, acessado pela primeia vez em 20/01/2014

35

logs so escritos em disco com a efetivao da transao. Atualmente, o MemSQL

suporta somente o nvel de isolamento read-committed e cada uma das requisies
executada em uma transao independente.

3.4 Google Spanner

3.4.1 Viso Geral
BigTable um sistema de armazenamento distribudo para dados estruturados que
foi projetado para ter uma escalabilidade que o permita gerenciar bases de dados
extensas: petabytes de dados espalhados em milhares de servidores comuns
(CHANG et al., 2006). Ele foi utilizado em diversos projetos do Google e o artigo
publicado (CHANG et al., 2006) foi considerado um dos trabalhos seminais na rea de
NoSQL.
BigTable, porm, apresenta alguns problemas, especificamente em aplicaes
que tenham esquemas complexos e em evoluo ou que precisem de uma forte
consistncia na presena de replicao em redes de longa distncia (CORBETT et al.,
2012). Para isso, o Google desenvolveu o Spanner, um SGBD escalvel, multi-verso
(cada verso de um item de dados recebe uma estampa temporal no momento de
uma efetivao), distribudo globalmente e com replicao sncrona. Spanner tambm
suporta uma linguagem de consulta que baseada no SQL. De acordo com
CORBETT et al. (2012), este o primeiro sistema a distribuir dados em escala global e
suportar transaes distribudas com consistncia externa (do ingls externallyconsistent distributed transactions). Em um SGBDD, a ordem em que as transaes
so completadas no tempo definem uma nica escala de execuo (schedule) serial,
chamado a escala de execuo externa. Um sistema prov consistncia externa se
garantir que a escala de execuo a ser usada para processar um conjunto de
transaes for igual a escala de execuo externa (GIFFORD,1982).

36

Em um alto nvel de abstrao, Spanner pode ser definido como um banco de

dados que fragmenta os dados entre um conjunto de muitas mquinas de estado
Paxos em centros de dados espalhados por todo o mundo (CORBETT et al., 2012).
Uma mquina de estados Paxos consiste em um mtodo de implementar um sistema
distribudo com tolerncia a falha atravs da replicao de servidores e comunicao
entre os ns, utilizando para isso uma famlia de protocolos para resolver o problema
de consenso, chamada de Paxos. O nome foi dado em homenagem ao sistema
empregado pelos habitantes da ilha de Paxos, na Grcia, para manter o Parlamento
funcionando ainda que seus moradores alternassem com frequncia nos cargos de
parlamentares (LAMPORT, 1998). No Spanner, a replicao serve aos propsitos de
manter uma alta disponibilidade global e localizao geogrfica (dos clientes). Alm
disso, automaticamente refaz a fragmentao dos dados sob demanda, conforme a
quantidade de dados aumenta ou o nmero de servidores muda, alm de migr-los
entre os servidores em resposta a falhas ou para balanceamento de carga (CORBETT
et al., 2012).

3.4.2 Arquitetura
Spanner organizado em um conjunto de zonas, que representam o conjunto de
locais em que os dados podem ser replicados. Zonas podem ser adicionadas ou
removidas conforme um centro de dados colocado em servio ou desligado,
respectivamente. Uma zona tem um zonemaster e diversos spanservers (variando
tipicamente de cem a diversos milhares). O zonemaster atribui dados aos spanservers,
que servem dados aos clientes(CORBETT et al., 2012).
Cada spanserver responsvel por cerca de cem a mil instncias de uma
estrutura de dados chamada tablet. O estado de um tablet armazenado em um
sistema de arquivos distribudo chamado Colossus.
Suporte a replicao alcanado ao implementar uma mquina de estados
Paxos sobre um tablet. Cada mquina de estados armazena metadados e o log do
37

tablet correspondente. Para cada rplica a que atribuda a condio de lder, o

spanserver tambm implementa um gerente de transaes que d suporte as
transaes distribudas.
Spanner utiliza o protocolo de Efetivao em Duas Fases (2PC, do ingls, TwoPhase Commit) sobre as mquinas Paxos para realizar o controle de concorrncia
distribudo. CORBETT et al. (2012) acreditam que melhor que programadores de
aplicaes lidem com problemas de desempenho devido ao uso excessivo de
transaes do que ter sempre que codificar em torno da falta de transaes.
Em um universo (um ambiente de implantao do Spanner), podem ser criadas
uma ou mais bases de dados. Cada base de dados pode conter um nmero ilimitado
de tabelas, que contm linhas, colunas e valores, cada um com seus respectivos
conjuntos de verses. A linguagem de consulta utilizada no detalhada, mas se
parece com SQL com algumas extenses (CORBETT et al., 2012).

38

Captulo 4 - Avaliao experimental

Neste captulo, apresentada uma abordagem para verificar o desempenho
apresentado por ferramentas NewSQL. A ttulo de ilustrao, uma das ferramentas
apresentadas no captulo anterior foi escolhida, e esta foi submetida a aplicao de um
conjunto de testes planejados a partir de quatro benchmarks distintos. A seo 4.1
descreve o conjunto de benchmarks utilizados e uma sute de testes que simplifica a
execuo dos mesmos. A seo 4.2 descreve o ambiente de testes utilizado. A seo
4.3 descreve os objetivos e a metodologia utilizadas para a execuo do procedimento
experimental. A seo 4.4 conclui o captulo apresentando os resultados obtidos e as
anlises pertinentes.

4.1 OLTP-Bench
OLTP-Bench uma sute de testes, para execuo de benchmarks de SGBDs
relacionais com cargas de trabalho focadas em aplicaes OLTP e processamento
Web (DIFALLAH et al., 2013). Neste caso, uma carga de trabalho a implementao
de um benchmark existente ou criado pela equipe. O OLTP-Bench rene 15
benchmarks, com cargas de trabalho diferenciadas e agrupadas em 4 tipos de
domnios de aplicaes. Entre esses benchmarks o TPC-C, TATP, YCSB e Twitter
foram utilizados nesse trabalho por representarem uma gama bem diferenciada de
aplicaes.
O OLTP-Bench, alm de agrupar vrios benchmarks j muito utilizados, conta
com algumas facilidades para sua utilizao (DIFALLAH, et al., 2013) como
extensibilidade, suporte para controle da distribuio das transaes, definio de
taxas de desempenho alvo, e suporte para vrios SGBDs, atravs da interface JDBC
(Java Database Connectivity).

39

DIFALLAH, et al., (2013), dividem os benchmarks encontrados nesta sute de

testes em trs tipos:
i.

Benchmarks Transacionais, com transaes de escrita intensa e

relacionamentos complexos.

ii.

Benchmarks orientados Web, com caractersticas de redes sociais,

com operaes baseadas em grafos de relaes muitos para muitos.
Esses

benchmarks

levam

em

considerao

dados

disponveis

publicamente para simular uma aplicao real.

iii.

Benchmarks de teste funcional, com inteno de testar funcionalidades

individuais de determinado SGBD.
Para os experimentos foram utilizados os trs tipos de benchmarks definidos

acima, utilizando o TPC-C e o TATP como benchmarks transacionais, o Twitter como

orientado web e o YCSB (Yahoo! Cloud Serving Benchmark) como de teste funcional.

4.1.1 TPC-C
O benchmark TPC-C (TPC, 2010), publicado pelo TPC (Transaction Processing
Performance Council) o padro atual para avaliao de desempenho de sistemas
OLTP tradicionais. O benchmark simula um ambiente onde uma srie de usurios
virtuais, ou terminais na nomenclatura do benchmark, executam mltiplas transaes
em uma base de dados, simulando uma aplicao de processamento de pedidos em
um armazm.
Este um benchmark com caractersticas de cargas de trabalho intensivas em
escrita e muitas transaes concorrentes.
O tamanho da base de dados do TPC-C varia de acordo com o nmero de
armazns. Todas as tabelas (com exceo da tabela Item), tem sua cardinalidade
influenciadas pela quantidade de armazns. O esquema da base de dados do TPC-C
mostrada na Figura 5:

40

Figura 5 - Esquema do TPC-C

Entre as transaes contidas no benchmark esto incluso de novos pedidos,

entrega de pedidos, contagem de estoque, registro de pagamentos e controle de
situao dos pedidos.
Essas transaes so executadas de acordo com uma distribuio de
frequncia pr-definida, que pode ser alterada pelo usurio (no OLTP-Bench). Para os
testes realizados nesse trabalho, utilizamos a distribuio padro das transaes que
seguem o seguinte modelo:
i.

Transaes New-Order (~45%): Insero de um novo pedido na base de

dados,

ii.

Transaes Payment (~43%): Insero de um registro de pagamento no

histrico.

iii.

Transaes Order Status (~4%): Consulta para saber se o pedido foi

processado.

iv.

Transaes Stock Level (~4%): Consulta para saber quais itens possuem
um baixo nvel de estoque.

41

v.

Transaes Delivery (~4%): Um item removido do estoque e a situao

do pedido atualizada.

importante salientar que as descries acima so uma declarao de alto

nvel dos objetivos pretendidos com cada uma das transaes. Cada uma dessas
transaes, na verdade, responsvel por representar uma lgica de negcios
complexa, sendo compostas de vrias operaes SQL.
A mtrica utilizada pelo TPC-C para avaliao do desempenho dos SGBD o
nmero de transaes do tipo New-Order que so executadas por minuto (tpmC)
enquanto as demais transaes acontecem simultaneamente no sistema.
A implementao do TPC-C contida na sute de testes OLTP-Bench se
diferencia da especificao original, pois omite o tempo de pensamento que os
submetedores de transaes demoram antes de iniciar cada transao. Assim, cada
submetedor realiza transaes ininterruptamente, e com isso somente um pequeno
nmero de conexes paralelas necessrio para saturar o servidor.
Para este benchmark, foi utilizado o fator 16 durante a fase de carga, o que
equivalente a ter 16 armazns distintos. A base de dados equivalente tem 1,3 GB.

4.1.2 TATP
O benchmark TATP (Telecommunication Application Transaction Processing) simula
uma tpica aplicao de telecomunicaes (IBM Software Group, 2009). O esquema
da sua base de dados foi modelado de maneira semelhante a um banco de dados
central que contm dados sobre os assinantes de telefonia mvel que esto
autorizados a usar as tecnologias GSM (Global System for Mobile Communications) e
o WCDMA (Wide Band Code Division Multiple Access).

42

Ao contrrio do TPC-C, este benchmark possui cargas de trabalho

principalmente de leitura, com transaes curtas (poucas operaes SQL) e no
conflitantes.
O esquema da base de dados utilizada pelo TATP mostrado na Figura 6:

Figura 6 - Esquema do TATP

So pr-definidas sete transaes a serem realizadas, as quais inserem,

atualizam, removem e selecionam dados na base de dados. Durante o tempo de
execuo, o nmero de vezes em que cada transao ocorre segue a distribuio de
transaes pr-definida pelo usurio. Para esse projeto, foram utilizadas as seguintes
distribuies:
Transao de Leitura (~80%):
i.

Transaes Get Access Data (~35%): Seleciona os dados para validao

de acesso, com probabilidade de sucesso de 62,5%.

43

ii.

Transaes Get New Destination (~10%): Seleciona o corrente destino do

encaminhamento de chamadas, com probabilidade de sucesso de 23,9%.

iii.

Transaes Get Subscriber Data (~35%): Seleciona um registro da tabela

Subscriber, com probabilidade de sucesso de 100%.

Transaes de Escrita (~20%):

iv.

Transaes Delete Call Forwarding (~2%): Remove um registro de

encaminhamento de chamadas, com probabilidade de sucesso de
31,25%.

v.

Transaes Insert Call Forwarding (~2%): Adiciona um novo registro de

encaminhamento de chamadas, com probabilidade de sucesso de
31,25%.

vi.

Transaes Update Location (~14%): Atualiza a localidade do assinante,

com probabilidade de sucesso de 100%.

vii.

Transaes Update Subscriber Data (~2%): Atualiza dados do perfil do

assinante, com probabilidade de sucesso de 62,5%.

O processo de carga dos dados para este benchmark foi realizado utilizando
fator de carga 10, o que equivalente a inserir um milho de assinantes. A base de
dados resultante tem 740 MB.

4.1.3 YCSB
O Yahoo! Cloud Serving Benchmark (YCSB) contm um conjunto de cargas de
trabalho simples, micro benchmarks, que representam aplicaes com operaes
simples mas que necessitam de grande escalabilidade. Esse benchmark foi
desenvolvido para comparar o PNUTS (COOPER et al.,2008), um SGBD prprio do
Yahoo!, com outros SGBD em nuvem, principalmente os NoSQL (SILBERSTEIN et al.,
2010). Seu desenvolvimento foi iniciado pois os bancos NoSQL que estavam surgindo
tinham modelos de dados diferentes entre si (j explicados na seo 2.4), o que
44

dificultava a comparao atravs dos benchmarks existentes, como o TPC-C, por

exemplo.
O YCSB possui uma nica tabela, chamada usertable, detalhada na Figura 7,
sobre a qual as cargas de trabalho so executadas. O benchmark j vem com 6
cargas de trabalho pr-definidas, onde as operaes na base de dados e suas
frequncias mudam de acordo com o escolhido. Alm dos existentes, o YCSB permite
que novas cargas de trabalho sejam criados estendendo a classe CoreWorkload de
onde todos os demais foram criados. Com isso, podem ser criadas carga de trabalho
personalizadas, para atender a necessidades especficas.

Figura 7 - Esquema do YCSB

Com todas essas possibilidades diferentes de testes, o YCSB j foi utilizado em

estudos anteriores para explorar a troca entre disponibilidade, consistncia e
fragmentao e tambm o aumento de desempenho utilizando SGBD em memria
(CURINO, et al., 2012).
Para o processo de carga de dados deste benchmark, foi utilizado o fator 600,
que equivalente a inserir 600.000 registros na tabela usertable. A base de dados
resultante tem 766 MB. A carga de trabalho utilizada foi 50% escrita e 50% leitura.

45

4.1.4 Twitter
Inspirado pelo micro-blog de mesmo nome, este benchmark parte integrante do
OLTP-Bench, e no uma implementao da especificao de um benchmark
preexistente. Foi criado com base em um instantneo, annimo, do grafo social do
Twitter de agosto de 2009, contendo 51 milhes de usurios e quase dois bilhes de
relacionamentos do tipo X segue Y (DIFALLAH et al.,2013).
O benchmark possui um gerador de cargas de trabalho sintticos que
baseado em uma aproximao das consultas e transaes necessrias para
representar as funcionalidades da aplicao original. O esquema da base do Twitter
mostrado na Figura 8 :

Figura 8 Esquema do Twitter

46

Uma breve explicao sobre o que representam as entidades acima pode ser
necessria:
O Twitter 11 um sistema em que usurios postam mensagens de curta
extenso (limitados a 140 caracteres), chamados tweets. Usurios podem formar uma
rede social entre si seguindo uns aos outros. Essa uma relao assimtrica no
grafo, pois usurio X seguir Y no garante que Y siga X. Um tweet postado por um
usurio visto por seus seguidores em seus feeds, uma listagem de publicaes em
ordem decrescente quanto ao tempo de publicao, da mais recente para a mais
antiga. Existem outras caractersticas, mas obviamente este benchmark no se prope
a ser uma representao exata do sistema, e sim uma aproximao relativamente
precisa do tipo de carga de trabalho que o mesmo suporta regularmente.
As transaes que o compem, assim como a frequncia de ocorrncia padro
de cada uma, esto detalhadas a seguir:
i.

GetTweet (~0,07%): recupera um tweet pelo seu id

ii.

GetTweetsFromFollowing (~0,07%): recupera os tweets de um conjunto de

usurios seguidos por outro

iii.

GetFollowers (~7,67%): recupera os seguidores (f2) de um determinado

usurio, identificado por (f1)

iv.

GetUserTweets (~91,26%): recupera todos os tweets pelo id de usurio

v.

InsertTweet(~0,92%): insere um registro na tabela added_tweets

Baseado no julgamento dos desenvolvedores, de que esse conjunto

representativo da carga de trabalho do sistema original, essa composio foi a mesma
utilizada durante a execuo do benchmark.

11

www.twitter.com, acessado pela primeira vez em 05/02/2014

47

Para o processo de carga de dados deste benchmark, foi utilizado o fator 150,
que equivalente a inserir 75.000 usurios. A base de dados resultante tem
aproximadamente 1,1 GB.

4.2 Ambiente de Testes

Para realizarmos os testes desse projeto, inicialmente foi utilizado o ambiente EC212
da Amazon, com a utilizao de Mquinas Virtuais (MV) do tipo micro instncia. Porm,
esse tipo de instncia, por ter menos de 10% da memria recomendada para
utilizao dos SGBD testados e por serem indicadas para aplicaes que requisitam
picos momentneos de desempenho (o que essencialmente diferente dos
benchmarks, que estressam constantemente o sistema), foi abandonada. Portanto,
optamos pela montagem de um aglomerado heterogneo composto de notebooks
pessoais.
Nesse

aglomerado,

utilizamos

computadores

com

as

seguintes

configuraes:
i.

Sistema Operacional Ubuntu 12.04, 4 GB de RAM e processador Intel

Core i5, 300 GB de disco rgido. Identificado como Computador 1

ii.

Sistema Operacional Ubuntu 12.04, 4 GB de RAM e processador Intel

Core i3, 300 GB de disco rgido. Identificado como Computador 2

iii.

Sistema Operacional Ubuntu 12.04, 4 GB de RAM e processador Intel

Core i5, 300 GB de disco rgido. Identificado como Computador 3

iv.

Sistema Operacional OS Mavericks, 4 GB de RAM e processador Intel

Core i5, 500 GB de disco rgido. Identificado como Computador 4

Todos os computadores esto conectados por uma rede Ethernet 100 Mbps. O
Computador 4 foi responsvel por fazer o papel de cliente, ou seja, pela invocao ao
benchmark. A carga de trabalho foi direcionada a uma instncia do SGBD em um
12

http://aws.amazon.com/ec2/, acessado pela primeira vez em 10/01/2014

48

computador diferente, o Computador 3, que foi responsvel por representar a camada

administrativa do SGBD, ou seja, a que recebe requisies e as distribui conforme
necessrio. Com isso, pretende-se que haja o fator comunicao entre ns presente
em todas as configuraes possveis.

4.3 Procedimento Experimental

4.3.1 Objetivo
O objetivo dos testes realizados verificar o desempenho de um SGBD NewSQL sob
cargas de trabalho sintticas que simulam operaes de aplicaes diferentes. Para
isso, foram utilizados os benchmarks TPC-C, TATP, YCSB e Twitter. Os testes
avaliaram a acelerao obtida ao se aumentar gradativamente o nmero de ns no
aglomerado. Foram utilizadas configuraes com um, dois e quatro ns, descritas
abaixo:
i.

Um n: Computador 3 como servidor

ii.

Dois ns: Computadores 3 e 2 como servidores

iii.

Quatro ns: Computadores 1,2,3 e 4 como servidores

4.3.2 Metodologia
O SGBD NewSQL avaliado o NuoDB. Excluindo-se o Google Spanner, por ser
proprietrio, e, portanto, indisponvel para testes, a deciso foi tomada entre os outros
trs SGBD apresentados no Captulo 3. Justifica-se a escolha do NuoDB por ser o
nico entre eles a possuir uma edio (no-comercial) sem nenhuma restrio para
testes, chamada edio desenvolvedor13. A verso utilizada foi a 2.0.3.

13

http://www.nuodb.com/explore/newsql-cloud-database-editions/compare-editions, acessado pela primeira vez em:

10/01/2014

49

Para cada uma das configuraes do aglomerado, foram realizados testes

variando o nmero de terminais do benchmark entre 4 e 128, dobrando o nmero a
cada teste. Terminais simulam usurios virtuais enviando requisies simultneas ao
sistema.
Para cada um dos testes foram realizadas trs rodadas de execues e
obteve-se a mdia do nmero de operaes processadas por unidade de tempo entre
elas. Exemplo: Para 1 n utilizando 4 terminais, foram feitas 3 medies.
OLTP-Bench se encarrega de trs fases da execuo de um benchmark:
criao da base, carga de dados e execuo, devendo a fase ser indicada em tempo
de execuo atravs do parmetro apropriado, durante a invocao do programa (-create, --load ou execute). Os parmetros mnimos que devem ser usados so: o
nome do benchmark escolhido e o arquivo de configurao do mesmo. O arquivo de
configurao do benchmark um XML em que so definidos: os detalhes da conexo
JDBC,o fator de carga (nmero que define a quantidade de registros que sero
inseridos durante o processo de carga da base, particular de cada benchmark),
nmero de terminais (para a fase de execuo), alm de outros parmetros que
regulam a execuo, como quais as transaes disponveis por benchmark e a
composio das mesmas (frequncia em que so utilizadas, devem somar 100%),
tempo de execuo do experimento e a taxa (em requisies/seg.) pretendida. Um
exemplo deste arquivo pode ser visto no Anexo A.
Para cada benchmark disponvel, existe um exemplo de arquivo de
configurao includo no diretrio samples do OLTP-Bench. Para cada par (SGBD
testado, benchmark escolhido), foi feita uma cpia de um arquivo de exemplo,
correspondente ao benchmark correto, na qual os valores de conexo foram editados
de acordo. Para todos os experimentos, o tempo de execuo foi de 60 segundos.
Testes preliminares demonstraram que o valor padro do parmetro taxa (10.000)
limitava o resultado obtido, ento o valor foi aumentado para 100.000, como limite

50

superior. As configuraes particulares de cada benchmark

so as mesmas

mencionadas nas sees 4.1.1 a 4.1.4.

Alm disso, OLTP-Bench guarda os resultados da execuo, em local
especificado, em um conjunto de cinco arquivos: uma cpia das configuraes do
benchmark utilizadas para aquela execuo (*.ben.cnf), uma cpia das configuraes
do SGBD no momento da execuo (*.db.cnf), resumo dos resultados (*.summary),
listagem das transaes realizadas (identificadas por um id que corresponde posio
em que aparecem no arquivo de configurao) e o tempo de durao de cada uma
(*.raw) e um resultado agregado por intervalos de tempo (*.res).
A janela de tempo utilizada para agregar os resultados (no arquivo .res) pode
ser definida em tempo de execuo passando o parmetro s chamada do
executvel oltpbenchmark. Para poder acompanhar o resultado a cada segundo, foi
usado o valor 1.
Desses arquivos, foram obtidos os seguintes dados: nmero mdio de
requisies por segundo, latncia mdia e nmero mximo de requisies realizadas.
Para os dois primeiros, a mdia entre as trs rodadas foi obtida e utilizada como valor
de comparao. Para o ltimo, o maior valor encontrado foi o utilizado para
comparao.

4.3.3 Configurao dos SGBD

Os testes para o SGBD NuoDB foram realizados em duas etapas. Na primeira, a cada
n adicionado ao aglomerado um processo TE era iniciado nesse novo n, totalizando
4 ns com 4 TE ao final dos experimentos. Posteriormente, foram feitos testes
replicando a base original, ou seja, atravs da adio de novos processos SM nos ns
do aglomerado. No total, foram testadas as 6 configuraes mostradas abaixo:
i.

1 TE e 1 SM: 1 TE e 1 SM no Computador 3;

ii.

2 TE e 1 SM: 1 TE e 1 SM no Computador 3, 1 TE no Computador 2;

51

iii.

4 TE e 1 SM: 1 TE em cada computador, 1 SM no Computador 3;

iv.

2 TE e 2 SM: 1 TE e 1 SM em cada um dos Computadores 2 e 3;

v.

4 TE e 2 SM: 1 TE em cada computador, 1 SM no Computador 2, 1 SM

no Computador 3 ; e

vi.

4 TE e 4 SM: 1 TE e 1 SM em cada um dos computadores.

Os testes com replicao das bases foram realizados para verificar se os TE

so os nicos responsveis pelo aumento de desempenho, ou se h benefcios

adicionais ao acrescentar processos SM. O aumento do nmero de TE aumenta o
tamanho do cache distribudo. O aumento no nmero de SM aumenta o nmero de
rplicas do banco de dados utilizados no cenrio.
A sute de testes OLTP-Bench j possui os scripts de criao apropriados para
cada uma das bases base de dados para o NuoDB. Portanto, modificaes no foram
necessrias para executar os procedimentos de criao e carga das bases de dados
de cada benchmark realizado. O processo de carga de dados foi realizado com os
fatores de carga apresentado nas sees 4.1.1 a 4.1.4.

4.4 Resultados Experimentais

4.4.1 TATP
Para uma configurao de dois ns no aglomerado, duas possibilidades foram
comparadas, uma com a utilizao de um SM e outra com 2 SM. Podemos perceber,
na Figura 9, que com o aumento do nmero de usurios virtuais no sistema, existe um
decrscimo no desempenho da configurao com 2 SM, pois quanto maior o nmero
de SM mais comunicaes entre eles so realizadas para manter a consistncia entre
os tomos replicados nos arquivos fsicos.
Para uma configurao de quatro ns no aglomerado, 3 possibilidades foram
comparadas, uma com a utilizao de uma SM, outra com 2 SM e outra com 4 SM.

52

Podemos perceber na Figura 10 o mesmo padro mostrado na Figura 9, explicado

pelo maior nmero de comunicaes entre as rplicas da base de dados. Esse fator se
agrava, quanto maior for o nmero de usurios virtuais fazendo requisies ao SGBD.

Figura 9 - Resultados TATP - 2 Ns

Figura 10 - Resultados TATP - 4 Ns

A Figura 11 demonstra um comparativo de desempenho entre as trs

configuraes testados: NuoDB com um, dois e quatro SM, fixando o nmero de
usurios virtuais simultneos em 128.

53

Figura 11 - Resultados TATP - 128 Usurios Virtuais

Para o NuoDB configurado com um nico SM, o aumento de desempenho de 1

para 2 ns foi de 1,40 vezes, elevando o nmero de ops/seg de 10.050 para 14.156.
Aumentando o aglomerado de 2 para 4 ns, o aumento de desempenho foi de 1,19
vezes, elevando o nmero de ops/seg para 16.786. O aumento geral de desempenho,
de 1 para 4 ns foi de 1,67 vezes.
Para as configuraes do NuoDB com 2 SM e 4 SM, o aumento de
desempenho foi menor, sendo os valores para o aumento geral de desempenho de 1
para 4 ns iguais a 1,33 e 0,95, respectivamente.
O TATP um benchmark de leitura intensiva, sendo 80% de suas transaes
de leitura. O NuoDB utiliza controle de concorrncia MVCC, no gerando bloqueios
entre transaes de leitura e escrita e mostra um bom desempenho no cenrio do
benchmark. Alm disso, com poucas transaes de escrita, a chance de conflito entre
duas delas pequena, por isso verifica-se o aumento de desempenho com um maior
nmero de usurios virtuais.

4.4.2 Twitter
Para as configuraes de 2 e 4 SM, demonstradas nas Figuras 12 e 13, existe uma
degradao na vazo final, se comparada configurao de apenas 1 SM. Para uma
54

base de dados pequena, pode-se dizer que o aumento do nmero de SM no

influencia no resultado final, enquanto aumento do nmero de TE aumenta o
desempenho.

Figura 12 - Resultados Twitter - 2 Ns

Figura 13 - Resultados Twitter - 4 Ns

Fixando-se o nmero de usurios virtuais, na configurao de 1 SM no

aglomerado, o aumento de desempenho entre 1 e 2 ns foi de 2,01 vezes, e de 2 para
4 ns foi de 1,18 vezes. O aumento de desempenho global de 1 para 4 ns foi de 2,38
vezes. J para a configurao de 2 SM, o aumento de desempenho de 1 para 2 ns foi
de 1,8 vezes, e de 2 para 4 ns foi de 1,23 vezes. O aumento global de desempenho

55

entre 1 e 4 ns foi de 2,26 vezes, um pouco menor do que a configurao de apenas 1

SM. Na configurao com 4 SM, o aumento do desempenho global de 1 para 4 ns
de apenas 2 vezes. A Figura 14 mostra estes resultados.

Figura 14 - Resultados Twitter - 128 Usurios Virtuais

De forma geral, para este tamanho de base, aumentar o nmero de ns ao

acrescentar mais TE resulta em maior desempenho.

4.4.3 YCSB
O benchmark YCSB executa transaes simples, compostas de uma nica consulta,
portanto no h paralelismo intra-consulta. O fator a ser observado aqui se aumento
de desempenho pode ser observado por paralelismo inter-consulta. Alm disso, cada
submetedor s envia uma nova transao aps obter o resultado da anterior.
Para as configuraes de 2 e 4 SM, mostradas nas Figuras 15 e 16, percebese uma degradao de desempenho, mostrando que quanto menor o nmero de SM,
melhor o desempenho do NuoDB.
Na Figura 17, esto representados os resultados comparativos das 3
configuraes testadas do NuoDB. Para apenas 1 SM no aglomerado, o aumento de
desempenho do NuoDB de 1 para 2 ns foi de 1,72 vezes, aumentando o nmero de
56

operaes/seg de 1248 para 2149. O desempenho de 4 ns, aumentou em 1,19 vezes

em relao ao aglomerado com 2 ns, elevando o nmero de operaes/seg para
2837. O aumento global de 1 para 4 ns foi de 2,27 vezes. Para as configuraes de 2
e 4 SM, o aumento de desempenho de 1 para 4 ns foi de 2,11 e 1,99 vezes,
respectivamente.

Figura 15 - Resultados YCSB - 2 Ns

Figura 16 - Resultados YCSB - 4 Ns

57

Figura 17 - Resultados YCSB - 128 Usurios Virtuais

4.4.4 TPC-C
Para as configuraes de 2 SM e 4 SM, nas Figuras 18 e 19, vemos novamente um
desempenho inferior a de um nico SM. Podemos ver tambm um decrscimo de
desempenho quando se atinge o nmero de 128 usurios virtuais.

Figura 18 - Resultados TPCC - 2 Ns

Isso explicado pela prpria implementao do TPC-C feita pelo OLTPBench.

Nessa verso, diferente da original do benchmark, os usurios virtuais no possuem

58

um tempo de pensamento, entre a chegada do resultado de uma transao e o envio

da prxima. Isso faz com que o nmero de usurios virtuais necessrios para saturar o
SGBD seja pequeno.

Figura 19 - Resultados TPCC - 4 Ns

Na Figura 20, esto mostrados os resultados para as trs configuraes

testadas. O aumento de desempenho do NuoDB com apenas 1 SM de 1,61 vezes
de 1 para 2 ns e de 2,28 vezes de 2 para 4 ns. O desempenho global de 1 para 4
ns de 3,69 vezes.

Figura 20 - Resultados TPCC - 128 Usurios Virtuais

59

Para todos os benchmarks testados podemos enumerar 2 importantes

ocorrncias:

i.

A configurao do NuoDB com apenas 1 SM a que tem melhor

desempenho. Isso se deve ao fato de que, com 2 e 4 SM, existe uma
maior comunicao entre os SM para que os tomos estejam
consistentes entre si.

ii.

Mesmo no existindo uma acelerao linear do desempenho quando se

aumenta o nmero de ns no aglomerado de 1 para 2 ns e de 2 para 4
ns, observou-se um aumento de desempenho quanto maior o nmero
de TE utilizados no sistema. importante lembrar que para cada n no
aglomerado, sempre existe um TE.

Uma das justificativas para criao dos NewSQL, inclusive do NuoDB, era dar
a possibilidade de se escalar a base de dados horizontalmente, dado que
escalabilidade um dos requisitos das novas demandas do mercado apresentadas no
Captulo 1, e que a opo pela escalabilidade vertical no vivel financeiramente
falando, alm de chegar a um limite de capacidade de aumento de desempenho.
Nos testes realizados, tentou-se verificar se essa escalabilidade horizontal
realmente era fornecida pelo SGBD testado, o NuoDB. Nos benchmarks realizados,
podemos perceber um aumento de desempenho de acordo com o aumento do nmero
de ns e processos TE que eram iniciados no sistema. Isso mostra que, para o
ambiente testado, o NuoDB obteve escalabilidade horizontal.
Com as limitaes desse projeto, apresentadas no Captulo a seguir, ainda no
possvel ter certeza at que ponto de fato o NuoDB fornece uma escalabilidade
horizontal. Para isso novo trabalhos devem ser feitos, como mostra o Captulo final

60

desse trabalho. Porm esse projeto, j mostra uma boa perspectiva do que pode
acontecer em ambientes maiores e mais realistas.

61

Captulo 5 - Concluso
A Internet alterou substancialmente a forma como as pessoas se relacionam. Novos
modelos de negcios e de prestao de servios que surgiram na ltima dcada
culminaram com a criao de aplicaes que antes no eram possveis de imaginar.
Redes sociais online ou servios de mensagem instantnea se tornaram comuns, e o
conhecimento e ferramentas para desenvolv-las esto disponveis para qualquer um.
Qual, ento, pode ser a diferena entre um caso bem sucedido e outro no?
Aplicaes como as mencionadas so consideradas aplicaes em tempo real,
com requisitos de baixo tempo de resposta. Para isso necessrio que a camada de
acesso aos dados, ou seja, o SGBD, apresente um desempenho adequado.
Neste projeto, foram apresentados

os

motivos

que

levam

os

SGBDR

tradicionais a no atenderem a esses requisitos apropriadamente. Novas solues

foram introduzidas. Ainda assim, os anos de pesquisa e desenvolvimento investidos
em aprimorar recursos como os mecanismos de controle de concorrncia e
compiladores da linguagem SQL, que tem ampla adoo no mercado, mostraram que
alternativas aos SGBDR tradicionais no precisam abandonar o Modelo Relacional
para alcanar estes objetivos. Este projeto se props a analisar alguns dos SGBD
chamados NewSQL, que so projetados para atender a nichos de mercados
especficos. Por sua vez, esta caracterstica guia as escolhas de estratgias de
implementao tomadas por estes SGBD. Portanto, este projeto buscou mostrar
algumas dessas estratgias de implementao e as razes por trs dessas escolhas.
A ttulo de ilustrao, o desempenho do NuoDB (um SGBD NewSQL) foi
avaliado atravs de quatro benchmarks, que impem cargas de trabalho distintas
(escrita intensiva, leitura intensiva e uma carga balanceada) ao SGBD, executado em
um pequeno aglomerado de computadores.

62

Considerando os resultados obtidos, observou-se uma melhoria geral na

quantidade de transaes realizadas por segundo ao adicionar ns ao aglomerado,
assim como incluir maior nmero de usurios virtuais. Portanto, nos cenrios
planejados, pode-se afirmar que a escalabilidade horizontal foi alcanada.
importante ressaltar que, devido arquitetura apresentada pelo NuoDB, que ,
simplificadamente, um cache distribudo, no possvel analisar a influncia de um
projeto de fragmentao adequado no resultado final. Se o sistema adotado fosse
similar ao MemSQL, por exemplo, seria preciso que o projetista da base de dados
considerasse o problema da fragmentao e da alocao de fragmentos para obter o
melhor desempenho com as consultas utilizadas pela aplicao.
A experincia obtida com os SGBD NewSQL tambm mostra que ainda
existem algumas limitaes de funcionalidade nos mesmos. Atualizaes (patches)
so lanados com frequncia para incluir correes de erros e ampliar a
compatibilidade com instrues SQL.

5.1 Limitaes
Um conjunto de fatores delimitaram o escopo e desenvolvimento deste projeto. So
eles:
i.

Por limitaes de recursos, os procedimentos experimentais apresentados

foram realizados utilizando computadores pessoais. Os mesmos possuem
capacidade de memria principal disponvel inferiores aos valores
recomendados pelos fabricantes dos SGBD analisados. Isso, porm, no
impede a execuo dos testes, mas limita os tamanhos das bases de
dados utilizadas que possam ser inteiramente armazenadas em memria.
Estas bases de dados, portanto, no se propem a ser uma representao
exata da aplicao correspondente a cada benchmark realizado, mas
servem ao propsito de comparao.
63

ii.

nmero

de

computadores

disponveis

para

os

procedimentos

experimentais tambm limitado. Por isso o nmero de ns do aglomerado

, no mximo, quatro. Em um cenrio de implantao real, esse nmero
poderia

ser

muito

maior.

Alm

disso,

os

computadores

seriam

interconectados por tecnologias de transmisso de dados na rede mais

avanadas, como Ethernet Gigabit. Por isso, o fator comunicao na rede
deve ser pequeno, porm no desprezvel.
iii.

As execues nos benchmarks foram limitadas a durao de um minuto.

Isso permitiu que, quando erros ocorressem, fossem feitas as depuraes
necessrias, e novas execues realizadas, alm de obter maior
diversidade nos resultados (mltiplas opes de nmeros de usurios
virtuais, por exemplo). Essa durao, porm, no a mais adequada, de
acordo com os desenvolvedores dos benchmarks. Alguns recomendam que
as execues tenham durao de duas ou mais horas, por exemplo, o que
inviabilizaria obter a quantidade de execues distintas apresentadas.

5.2 Trabalhos Futuros

Este projeto mostra uma abordagem prtica para avaliao de desempenho em SGBD
NewSQL. Esta abordagem, porm, no exaustiva, pois outras possibilidades de
estudo podem ser conduzidas a partir desta.
Em primeiro lugar, as condies j apresentadas podem ser ampliadas. Por
exemplo, para o mesmo planejamento de testes realizados, outros valores de
parmetros podem ser aplicados: o tempo de durao do experimento, composio
das transaes de cada benchmark, nmero de usurios virtuais, entre outros. Um
estudo sobre ajustes finos no NuoDB tambm pode ser conduzido.
Alm disso, um estudo mais aprofundado pode ser feito a partir da incluso de
um maior nmero de SGBD NewSQL na comparao, e como as diferentes
64

estratgias de implementao adotadas por estes influenciam nos resultados de

desempenho. Outros benchmarks disponveis podem ser includos.
A influncia de outros fatores nos resultados tambm podem ser estudadas,
como: caractersticas especficas de hardware (processadores, memria, discos,
equipamentos de rede) ou de software (diferentes implementaes do mesmo
benchmark).

65

Referncias Bibliogrficas
ASLETT, M., How will the database incumbents respond to NoSQL and NewSQL?, 451
Analyst Report, Abr., 2011
BERNSTEIN, P., GOODMAN, N., et al., 1981a, Query Processing in a System for Distributed
Databases (SSD-1), ACM Transactions on Database Systems, v.6, pp. 602-625
BERNSTEIN, P., GOODMAN, N., 1981b, Concurrency Control in Distributed Database
Systems, Computing Surveys, v.13, n.2, Jun, pp. 185-221
CAREY, M., LIVNY, M., 1988, Distributed Concurrency Control Performance: A Study of
Algorithms, Distribution, and Replication. In: Proceedings of the 14

th

Very Large Database

Conference, pp. 13-25

CATTELL, R., 2010, Scalable SQL and NoSQL Data Stores. In: ACM SIGMOD Record, v. 39,
pp 12-27, Dez.
CHA, M., HADDADI, H., 2010, Measuring User Influence in Twitter: The Million Follower
th

Fallacy. In: Proceedings of the 4 International AAAI Conference on Weblogs and Social Media
CHANG, F., DEAN, J. et al., 2006, Bigtable: A Distributed Storage System for Structured Data,
ACM Transactions on Database Systems, v. 26, n.4, Jun, pp. 1-26
COOPER, B., RAMAKRISHNAN, R., et al., PNUTS: Yahoo!s Hosted Data Serving Platform.
In: Proceedings of the VLDB Endowment, vol. 1, no.2, pp. 1277-1288, Ago. 2008
CORBETT, J., DEAN, J., et al., 2012, Spanner: Googles Globally-Distributed Database. In:
Proceedings of OSDI'12: Tenth Symposium on Operating System Design and Implementation,
pp. 251-264, Hollywood, CA, Out., 2012.

CURINO, C., PAVLO, A., et al., 2012, Benchmarking OLTP/Web Databases in the Cloud: the
OLTP-Bench Framework. In: CloudDB12 Proceedings of the Fourth International Workshop on
Cloud Data Management, pp 17-20.

66

DAUDPOTA, N., 1998, Five Steps to Construct a Model of Data Allocation for Distributed
Database Systems, Journal of Intelligent Information Systems, v.11, pp-153-168
DIFALLAH, D., CURINO, C., et al., OLTP-Bench: An Extensible Testbed for Benchmarking
Relational Databases. In: Proceedings of the Very Large Database Endowment, vol.7, no. 4, pp.
277-288, Dez.2013
GIFFORD,D., Information Storage in a Decentralized Computer System. In: Tech. Rep. CSL81-8,Xerox PARC, 1982
HARIZOPOULOS, S., ABADI, D., et al., 2008, OLTP Through the Looking Glass, and What We
Found There, In: Proceedings of the 2008 ACM SIGMOD International Conference of
Management Data, pp 981-992.
HOWARD, P., 2013, NuoDB InDetail, Bloor Report. Disponvel em: go.nuodb.com/bloorreport-request.html. Acesso em: 5 dez 2013
IBM Software Group Information Management, Telecommunication Application Transaction
Processing

(TATP)

Benchmark

Description,

2009.

Disponvel

em:

http://tatpbenchmark.sourceforge.net/TATP_Description.pdf . Acesso em: 10 fev. 2014

KALLMAN, R., KIMURA, H., H-Store: A High-Performance, Distributed Main Memory
Transaction Processing System. In: Proceedings of the VLDB Endowment, v.1, pp.1496-1499,
Ago., 2008
KHAN, S., AHMAD, I., 2010, Replicating Data Objects in Large Distributed Database Systems:
An Axiomatic Game Theoretic Mechanism Design Approach, Distributed and Parallel
Databases, v. 28, Dez, pp. 187-218
LAMPORT, L., 1998, The Part-Time Parliament, ACM Transactions on Computer Systems, v.
16, n. 2, Mai, pp. 133-169
LEAVITT, N., 2010, Will NoSQL Databases Live Up to Their Promise?, IEEE Computer
Society, v. 43, Feb, pp 12-14.

67

LIM, H., HAN, Y., et al., 2013, How to Fit when No One Size Fits, In: The 6th Biennial
Conference on Innovative Data Systems Research (CIDR).
NUODB, NuoDB Emergent Architechture, 2013. Disponvel em:
http://go.nuodb.com/rs/nuodb/images/ Greenbook_Final.pdf. Acesso em: 10 dez. 2013

NUODB, 2013, Technical Whitepaper, v.1 (Out). Disponvel em: http://go.nuodb.com/whitepaper.html. Acesso em: 5 dez. 2013

OZSU, M., VALDURIEZ, P., Principles of Distributed Database Systems ,

ed.,

London,

Springer, 2010.
PAUL,S., Database Systems Performance Evaluation Techniques, 2008. Disponvel em:

http://www1.cse.wustl.edu/~jain/cse567-08/ftp/db/index.html. Acesso em: 27 fev. 2014

RAM., S, 1989, A Model for Designing Distributed Database Systems, Information and
Management, v. 17, n. 3, (Out), pp.169-180
ROTHNIE, J., BERNSTEIN, P., et al., 1980, Introduction to a System for Distributed Databases
(SDD-1), ACM Transactions on Database Systems, v. 5, n. 1, (Mar), pp. 1-17
SELTZER, M., 2008, Beyond Relational Databases, Communications of the ACM, v. 51, n.
27(Jul), pp. 52-58
SENG, J., YAO, S. B., HEVNER, A. R., 2004, Requirements-driven database systems
benchmark method, Decision Support Systems, v. 38, pp 629-648
SILBERSTEIN, A., COOPER, B., et al., Benchmarking Cloud Serving Systems with YCSB. In:
Proceedings of the 1st ACM Symposium on Cloud Computing, pp 143-154, Indianapolis, IN,
Jun. 2010.
STONEBRAKER, M., 2010, SQL Databases v. NoSQL Databases, Communications of the
ACM, v. 53, n.4(Abr), pp 10-11.

68

STONEBRAKER, M., 2011, New Opportunities for New SQL, Communications of the ACM,
v.55, n. 11(Nov), pp. 10-11
STONEBRAKER, M., ABADI, D., et al., 2007, The End of an Architectural Era (Its Time for a
Complete Rewrite). In: Proceedings of the 33

rd

International Conference on Very Large

Database, pp 1150-1160.
STONEBRAKER, M., CATTELL, R., 2011, 10 Rules for Scalable Performance in Simple
Operation Datastores, Communications of the ACM, v. 54, n. 6(Jun), pp 72-80
STONEBRAKER, M., CETINTEMEL, U., 2005, One Size Fits All: An Idea Whose Time Has
Come and Gone. In: Proceedings of the International Conference on Data Engineering, pp 2-11.
STONEBRAKER, M., WEISBERG, A., 2013, The VoltDB Main Memory DBMS, Bulletin of the
IEEE Computer Society Technical Committee on Data Engineering, vol. 36,n.2,pp.21-27
TPC,

TPC

Benchmark

Standard

Specification,

2010.

Disponvel

em:

http://www.tpc.org/tpcc/spec/tpcc_current.pdf . Acesso em: 8 fev. 2014

69

Anexo A
Exemplo de arquivo de configurao do OLTP-Bench:

<?xml version="1.0"?>
<parameters>

<!-- Connection details -->

<dbtype>nuodb</dbtype>
<driver>com.nuodb.jdbc.Driver</driver>
<DBUrl>jdbc:com.nuodb://server:port/tatp</DBUrl>
<username>user</username>
<password>password</password>
<isolation>TRANSACTION_SERIALIZABLE</isolation>

<!-- Scalefactor increases the number of subscribers -->

<scalefactor>100</scalefactor>

<!-- The workload -->

<terminals>10</terminals>
<works>
<work>
<time>300</time>
<rate>10000</rate>
<weights>2, 35, 10, 35, 2, 14, 2</weights>
</work>
</works>

<!-- Procedures declaration -->

<transactiontypes>
<transactiontype>
<name>DeleteCallForwarding</name>
</transactiontype>
<transactiontype>
<name>GetAccessData</name>
</transactiontype>
<transactiontype>

70

<name>GetNewDestination</name>
</transactiontype>
<transactiontype>
<name>GetSubscriberData</name>
</transactiontype>
<transactiontype>
<name>InsertCallForwarding</name>
</transactiontype>
<transactiontype>
<name>UpdateLocation</name>
</transactiontype>
<transactiontype>
<name>UpdateSubscriberData</name>
</transactiontype>
</transactiontypes>
</parameters>

71