oijsaoda suhdao

1. DCC- Faculdade de Ciências da
Universidade do Porto
SQL e NoSQL
Escalabilidade em Data Stores
Rui Costa
Teresa Costa
060316042
050316021

2. Conteúdo
1.
Introdução ..................................................................................................................... 2
2.
Diferentes Tipos de Base de Dados ............................................................................... 2
2.1
Bases de Dados SQL e NoSQL .................................................................................... 2
2.2
Teorema de CAP ........................................................................................................ 3
2.2.1
Consistência........................................................................................................... 3
2.2.2
Disponibilidade ...................................................................................................... 4
2.2.3
Tolerância a Falhas ................................................................................................ 4
2.3
Terminologia ............................................................................................................. 4
3.
Categorias das Data Stores............................................................................................ 5
3.1 Key-Value Stores ........................................................................................................... 5
3.1.1 Projecto Voldemort ...................................................................................................... 5
3.1.2 Memcached, Membrain e Membase ........................................................................... 6
3.1.3 Yahoo Sherpa ............................................................................................................... 6
3.2 Document Store ............................................................................................................ 6
3.2.1 SimpleDB ...................................................................................................................... 7
3.2.2 MongoDB...................................................................................................................... 7
3.3 Extensible Data Records ............................................................................................... 8
3.3.1 HBase............................................................................................................................ 9
3.3.2 Cassandra ..................................................................................................................... 9
3.4 Sistemas Relacionais Escaláveis .................................................................................. 10
3.4.1 MySQL Cluster ............................................................................................................ 10
3.4.2 ScaleBase .................................................................................................................... 10
4.
Análise dos Sistemas ................................................................................................... 11
4.1
Comparação entre Sistemas.................................................................................... 11
4.2
SQL vs. NoSQL – Conflito de Opiniões ..................................................................... 12
4.3
Benchmaking ........................................................................................................... 12
5.
Conclusão .................................................................................................................... 15
6.
Bibliografia .................................................................................................................. 17
Page 1

3. 1. Introdução
Com advento da Web 2.0 surgiram aplicações que necessitam de sistemas que consigam
lidar com milhares de utilizadores e escalar milhões de updates e leituras a base de dados. Este
volume de operações contrasta com o design das bases de dados e data warehouses
tradicionais.
Para responder a esta necessidade é necessário desenvolver novos sistemas e mecanismos
que consigam escalar estas aplicações por diversos servidores.
Nos últimos anos verificou-se o desenvolvimento de novos sistemas, desenhados para
proporcionar uma boa escalabilidade horizontal, permitindo operações de leitura/escrita
distribuídas pelos diversos servidores. Estes novos sistemas vêm contrastar com as bases de
dados tradicionais que têm pouca ou nenhuma capacidade para essa escalabilidade horizontal.
Nesta monografia apresentamos e comparamos alguns desses novos sistemas de bases de
dados distribuídas.
2. Diferentes Tipos de Base de Dados
2.1 Bases de Dados SQL e NoSQL
Os novos sistemas são designados de NoSQL data stores. Esta definição tanto diz respeito
a “Not Only SQL” como a “Not Relational”. Como tal, vamos fixar algumas características
referentes aos sistemas NoSQL que vamos referir neste trabalho. (1)
1. Capacidade de escalar horizontalmente operações simples pelos diversos servidores;
2. Capacidade de replicar e distribuir informação por diversos servidores;
3. Interface de “call level” simples, contrastando com o SQL binding;
4. Um modelo de concorrência mais fraco que o modelo ACID;
5. Uso eficiente para índices distribuídos e RAM para o armazenamento de informação;
6. Capacidade de adicionar dinamicamente novos atributos aos registos de dados.
A principal key feature destes sistemas é a escalabilidade horizontal baseada no “shared
nothing”, replicando e particionando os dados pelos servidores.
Esta ideologia permite suportar um grande volume de operações simples de
leitura/escrita, por segundo.
Para a implementação destes sistemas, a ideia é desistir das restrições do ACID de forma a
obter maior performance e escalabilidade. Contudo, os sistemas que vamos apresentar,
variam na forma em que desistem dessas restrições. Por exemplo, a maior parte dos sistemas
denominam-se de “eventualmente consistentes”.
Page 2

4. 2.2 Teorema de CAP
O teorema de CAP (2), também conhecido como Teorema de Brewer afirma que é
impossível, num sistema de computação distribuída, ter simultaneamente as seguintes
propriedades:
• Consistência
• Disponibilidade;
• Tolerância a falhas.
Estes três requisitos influenciam o desenho e instalação de sistemas de base de dados
distribuídas. Deste teorema e de uma profunda análise resultou uma revolução da
arquitectura dos sistemas distribuídos de dados em grande escala.
É então importante definir o que são cada uma destas propriedades. Reconhecer quais dos
requisitos do teorema de CAP são importantes para o nosso sistema é o primeiro passo para
construir com sucesso um sistema distribuído, escalável e com alta disponibilidade.
Figura 1 - Diagrama representativo da interligação das propriedades do Teorema de CAP e as diversas data
stores.
2.2.1 Consistência
É a característica que descreve como e se o estado de um sistema fica consistente após
uma operação. Num sistema distribuído de dados significa que uma vez escrito um registo,
este fica imediatamente disponível e pronto para ser utilizado.
Uma base de dados distribuída consistência é classificada como fortemente consistente ou
como tendo fraca consistência. Os sistemas com uma forte consistência, implementam as
características ACID (Atomicidade, Consistência, Isolamento e Durabilidade), sendo estas
implementadas na maior parte das bases de dados relacionais. Na outra extremidade, de fraca
consistência, temos as bases de dados BASE (Basic Availability, Soft-State, Eventual
Consistency).
A consistência fraca é fornecida de forma de consistência eventual. Isto significa que a
base de dados pode atingir um estado consistente. Nestas incluem-se, normalmente, as bases
de dados em que os dados são replicados. Aqui apenas existe a garantia que a versão mais
Page 3

5. recente de um registo está consistente num nó, sendo que as versões mais antigas deste
registo podem ainda existir noutros nós, mas eventualmente todos os nós irão ter a última
versão.
2.2.2 Disponibilidade
Esta característica refere-se à concepção e implementação de um sistema de modo a que
seja assegurado que este permanece activo durante um determinado período de tempo. Ou
seja, significa que o sistema é tolerante a falhas de software e/ou hardware e que se encontra
igualmente disponível durante a actualização destes.
Disponibilidade não é apenas um protecção contra falhas, mas também é uma forma de
obter um balanceamento de carga e operações concorrentes, nomeadamente para operações
de leitura.
Uma das formas mais comuns de fazer a implementação desta característica numa base de
dados relacional é recorrendo à replicação master-master. Desta forma, a falha ou
actualização de um nó não implica a indisponibilidade do sistema.
2.2.3 Tolerância a Falhas
Esta característica refere-se à capacidade de um sistema continuar a operar na presença
de uma falha de rede.
2.3 Terminologia
Antes de descrevermos os diversos sistemas é necessário clarificar alguns termos que
serão utilizados neste trabalho (1).
Por “operações simples” entendemos key lookups, leitura ou escrita de um registo ou de
uma pequena quantidade de registos. Tendo em conta o estado actual das aplicações, onde
milhões de utilizadores lêem e escrevem informação, a escalabilidade destas pequenas
operações tornou-se muito importante.
Já foi referido anteriormente o termo “escalabilidade horizontal”. Este termo refere-se à
capacidade de distribuir a informação e a carga de processamento das operações por vários
servidores, sem ser necessário a partilha de RAM ou disco entre os servidores. Esta
escalabilidade difere da “escalabilidade vertical” onde o disco e memória são partilhados pelos
servidores.
A terminologia utilizada em NoSQL Data Stores é, muitas vezes inconsistente. De forma a
existir consistência, vamos definir alguns termos importantes:
•
Tuplo: é uma linha numa tabela relacional com os atributos pré-definidos no esquema
da base de dados e cujos valores são escalares. Os valores são referenciados pelo
nome do atributo.
Page 4

6. •
Document: permite que os valores estejam agrupados em documentos ou listas e os
nomes dos atributos são automaticamente definidos a cada execução. A grande
diferença em relação aos tuplos é que aqui os atributos não estão esquematizados.
•
Extensible Record: é um híbrido entre um tuplo e um document. Aqui a família de
atributos está pré-definida na base de dados, mas novos atributos podem ser
adicionados
•
Objecto: é similar ao conceito de objecto em linguagens de programação, mas não
tem métodos procedimentais. Os valores que este toma ou são referências ou
objectos agrupados.
3. Categorias das Data Stores
Os sistemas referenciados neste trabalho estão divididos em 4 categorias distintas (1):
1. Key-Value Stores: estes sistemas armazenam valores e um índice para os encontrar,
baseado numa chave programada.
2. Document Stores: estes sistemas armazenam documentos. Estes são indexados e é
fornecido um mecanismo de pesquisa muito simples.
3. Extensible Record Storage: estes sistemas armazenam extensible records que podem ser
particionados vertical ou horizontalmente pelos nós.
4. Relational Databases: estes sistemas armazenam tuplos, indexando-os.
3.1 Key-Value Stores
A data store mais simples utiliza um modelo muito similar ao popular memcahed
distribuindo pela memória cache um índice key-value para todos os dados. Tal como o
memcached, nenhum dos sistemas nesta categoria oferecem índices ou chaves secundárias.
Por outro lado, fornecem mecanismos de persistência e outras funcionalidades como
replicação, manutenção de versões, locking ou sorting.
3.1.1 Projecto Voldemort
Este sistema é um avançado key-value store. Sendo open source têm muitas contribuições,
nomeadamente do LinkedIn. Fornece um mecanismo de controlo de versões (MVCC) para os
updates. As réplicas sofrem update de forma assíncrona não garantindo, por isso, consistência.
Contudo, pode garantir uma vista actualizada se a leitura for feita à maior parte das réplicas.
O Projecto Voldemort (3) suporta também um lock da data store optimista, para garantir a
actualização de registos múltiplos. Assim, se existir algum conflito, a actualização não é
efectuada. Outro mecanismo suportado é o sharding automático dos dados. Este mecanismo
possibilita que existam mais nós virtuais do que físicos (servidores). Uma vez particionada a
Page 5

7. informação, o resto das operações são transparentes. Os nós podem ser adicionados ou
removidos que o sistema adapta-se automaticamente. Voldemort detecta automaticamente
falhas nos nós e é capaz de as recuperar.
Este sistema permite guardar a informação na RAM mas permite, da mesma forma,
armazená-la num sistema de armazenamento, suportando Berkeley BD e Random Access File.
3.1.2 Memcached, Membrain e Membase
O Memcached é um sistema open source de indexação distribuída na memória que foi
melhorado surgindo o Membase que acrescentou novas características ao sistema como
persistência, replicação, alta disponibilidade, crescimento dinâmico e backups, por exemplo.
Sem a persistência e a replicação o Memcached não se classifica como uma data store. Mas o
Membrain e o Membase sim. E uma vez que estes sistemas são compatíveis com o
Memcached são amplamente utilizados.
O Membase é um sistema open source. A sua característica mais atractiva é a sua
elasticidade que permite adicionar ou remover servidores sem necessidade de parar o sistema,
mover dados e redireccionar dinamicamente os pedidos sempre que necessário.
O Membrain é um sistema proprietário, sendo necessário uma licença por cada servidor. A
sua característica mais apelativa é a afinação especial que tem para lidar com memória flash. A
performance obtida com este tipo de memória é bastante superior em relação aos outros
sistemas.
3.1.3 Yahoo Sherpa
Esta data store está a ser desenvolvida pela Yahoo (4). É um sistema multi-tenant onde
uma aplicação armazena dados numa tabela, sendo esta um conjunto de records. Essa tabela é
dividida em shards que são distribuídos por diversos nós. Com ajuda de um software que
guarda informação sobre a distribuição de shards, sempre que existe um pedido, este é
reencaminhado para o nó correcto. O acesso aos registos é feito através uma chave primária.
A escalabilidade deste sistema deve-se ao particionamento da informação. Cada shard
contém um range de dados, restringindo assim as operações aos nós onde possivelmente
estão as informações pretendidas.
O Sherpa é considerado um sistema elástico permitindo que novos nós sejam adicionados
dinamicamente. O particionamento ou reparticionamento também é feito dinamicamente.
Os dados são replicados, de forma automática por múltiplos nós com intuito de prevenir
falhas. A falha de um nó é transparente para as aplicações.
3.2 Document Store
Este tipo de data stores suportam dados mais complexos, comparativamente às Key-Value
Stores. Ao contrário destas, estes sistemas suportam índices secundários e múltiplos tipos de
documents (objectos) por base de dados.
Page 6

8. 3.2.1 SimpleDB
Este sistema é propriedade da Amazon (5). Tal como o nome sugere é um sistema simples:
SimpleDB tem as operações Select, Delete, GetAttributes e PutAttributes. Por ser tão simples
não permite documentos agrupados.
Este sistema suporta consistência eventual, mas não consistência transaccional. Suporta
também replicação assíncrona.
Tal como as Document Stores, o SimpleDB suporta mais do que um grupo por base de
dados. Os documents são postos em domínios que suportam indexação múltipla. Os domínios
e a sua meta-informação podem ser enumerados. A operação de Select é feita num domínio,
onde são especificados um conjunto de restrições. São da forma de:
select <atributes> from <domain> where
<list of attribute value constraints>
Os diferentes domínios são armazenados em diferentes nós da Amazon. Os índices num
domínio são automaticamente actualizados quando os atributos de um document são
modificados.
Este sistema não particiona automaticamente os dados pelos servidores. Pode-se
conseguir alguma escalabilidade horizontal lendo qualquer uma das réplicas, isto se a versão
mais actual não for importante. A escrita não é escalável porque as actualizações têm de ser
de forma assíncrona. Se um cliente quiser melhor escalonamento tem de ser ele a
implementá-lo.
3.2.2 MongoDB
O MongoDB (6) é um sistema open source e GPL que proporciona índices em collections, é
lockless e fornece um mecanismo de query aos documentos. Este sistema possui algumas
características interessantes:
• Suporta sharding automático, distribuindo os documentos pelos servidores;
•
A replicação é na maior parte dos casos utilizada em casos de failover;
•
Não fornece consistência global mas tem consistência local, mantendo actualizada a
cópia original do documento;
•
Suporta queries dinâmicas, com uso automático de índices, como as bases de dados
relacionais;
•
As operações sobre os documentos são atómicas.
As operações sobre os campos fornecidas são:
• O comando update é ampliado, facilitando mudanças atómicas a valores individuais.
Por exemplo, $inc incrementa um valor, $push adiciona um elemento a um array,
etc. Os updates são feitos localmente para evitar overhead no servidor.
•
A convenção “update if current” apenas permite alterar um campo se o valor
corresponder a um valor prévio;
Page 7

9. •
A operação “findAndModify” faz um update atómico e retorna automaticamente o
documento actualizado. Esta operação é muito útil quando lidamos com estruturas de
dados que requerem atomicidade;
O MongoDB guarda a informação num formato binário, semelhante ao JSON, denominado
de BSON. Este formato suporta os tipos booleanos, integer, float, date, string e binário. Este
sistema suporta ainda GridFS fundamental para dados binários de grande dimensão, como
imagens ou vídeos. Como são armazenados em pedaços, ao serem transmitidos para o cliente
há eficiência na entrega.
Este sistema suporta ainda replicação master-slave, com recuperação automática de
failovers. Esta recuperação é feita ao nível dos shards. As collections são automaticamente
partilhadas por uma shard-key definida pelo utilizador.
A replicação é assíncrona para que a performance do sistema seja elevada o que faz com
que alguns updates sejam perdidos em caso de crash do sistema.
Figura 2 - Esquema de uma base de dados em MongoDB.
3.3 Extensible Data Records
O desenvolvimento destes sistemas foi motivado pelo sucesso da BigTable da Google (7). É
um modelo básico, de colunas e linhas, e a escalabilidade está em dividir tanto as colunas
como as linhas por diferentes nós (servidores):
•
As linhas são divididas por vários nós através do sharding da chave primária. São
divididas por range, possibilitando que uma pesquisa não necessite de todos os nós.
•
As colunas são distribuídas pelos vários nós em forma de grupo.
Os grupos de colunas são pré-definidas com extensible record stores. As linhas são
análogas a documents, tendo um número variável de atributos, com nomes distintos, e estão
agrupadas em collections.
Page 8

10. Figura 3 - Esquema do caminho de leitura e escrita em bases de dados baseadas na Big Table.
3.3.1 HBase
O HBase (8) é um projecto da fundação Apache, derivando da BigTable da Google:
•
Usa Hadoop como sistema de ficheiros distribuído. Os updates são guardados em
memória e periodicamente são escritos em disco;
•
Os updates vão para o fim do ficheiro de dados, para evitar procuras desnecessárias.
Para uma recuperação mais eficiente, em caso de crash do servidor, os updates vão
para o fim do log.
•
As operações sobre as linhas são atómicas, com um locking das transacções de baixo
nível. Usa controlo de concorrência optimista, abortando se existir conflitos entre
updates.
•
O particionamento e distribuição são transparentes. Existe múltiplo suporte para
masters, para evitar um ponto singular de falhas. A utilização do MapReduce permite
que as operações sejam distribuídas de forma eficiente.
3.3.2 Cassandra
O Cassandra (9) é similar aos outros sistemas Extensible Record Stores. Tem grupos de
colunas, as actualizações são guardadas na cache da memória e periodicamente escritas em
disco. Faz particionamento e replicação. Tem mecanismos de detecção de falhas assim como
recuperação automática. Contudo, o Cassandra tem um modelo de concorrência fraco, não
apresentando mecanismos de locking e tendo as actualizações das réplicas assincronamente.
Este sistema confere automaticamente nova disponibilidade aos nós de um cluster.
Usando o algoritmo Phi Accrual consegue detectar a falha de um nó. É também capaz de
determinar se um nó pertence a um cluster utilizando um algoritmo gossip-style.
Cassandra cria o conceito de super-coluna, proporcionando um novo nível de
agrupamento com os grupos de colunas originais. Este sistema usa ainda uma hash de índices
ordenados, dando as potencialidades quer de uma hash quer de uma árvore-B no nível dos
Page 9

11. índices. Desta forma, é possível saber que nós podem ter aquele conjunto particular de valores
não havendo necessidade de procurar em todos os nós.
3.4 Sistemas Relacionais Escaláveis
Ao contrário das Data Stores, um SGDB relacional tem um esquema completo e prédefinido, um interface SQL e transacções ACID. Contudo, tradicionalmente, as SGDBR não
oferecem escalabilidade como os sistemas anteriormente mencionados.
Os mais recentes desenvolvimentos mostram que é possível implementar alguma
escalabilidade comparada com a das Data Stores NoSQL com duas ressalvas:
•
Usar operações de curta extensão. Como já foi visto, operações que precisem de
utilizar muitos nós, como joins de múltiplas tabelas, não escalam bem se não se utilizar
shards;
•
Usar transacções de curta extensão. Como anteriormente, transacções que necessitem
de muitos nós são ineficientes.
O NoSQL contorna estes dois problemas impossibilitando, ou tornando difícil, fazer
operações e transacções deste calibre. No caso das SGBDR, estas apenas penalizam o utilizador
se as realizar.
Uma vantagem dos SGBDR escaláveis é a linguagem de alto nível que possui e as
propriedades ACID.
3.4.1 MySQL Cluster
Propriedade da Oracle, o MySQL Cluster trabalha substituindo o motor InnoDB por uma
camada distribuída chamada de NDB.
Este sistema particiona a informação por vários servidores, criando shards. Cada shard é
replicado, para suportar a recuperação em caso de falhas. Replicação bidireccional geográfica
também é suportada. O MySQL Cluster também suporta dados na memória ou no disco. Caso
a informação esteja na memória, a resposta é em tempo real.
3.4.2 ScaleBase
Esta é uma nova abordagem, procurando obter escalabilidade horizontal com uma camada
nova sobre o MySQL em vez de alterar o próprio MySQL. Este sistema possui um parser parcial
de SQL e um optimizador que particiona as tabelas por múltiplos nós únicos de bases de dados
MySQL (10).
Implementar sharding em cima de MySQL introduz um novo problema se as transacções
não forem abrangidas pelo MySQL.
Page 10

12. 4. Análise dos Sistemas
4.1 Comparação entre Sistemas
Voldemort
Membrain
Membase
SimpleDB
MongoDB
Controlo de
Concorrência
MVCC
Locks
Locks
Nenhum
Locks
HBase
Locks
Hadoop
Assíncrona
Cassandra
MVCC
Disco
Assíncrona
MySQL Cluster
ACID
Disco
Síncrona
ScaleBase
ACID
Disco
Assíncrona
Sistema
Key-Value
Data Store
Document
Data Store
Extensible
Records Data
Store
Sistemas
Relacionais
Escaláveis
Armazenamento
Replicação
RAM ou DBD
Flash + Disco
Disco
S3
Disco
Assíncrona
Síncrona
Síncrona
Assíncrona
Assíncrona
Tabela 1 - Sumário das características das diversas data stores.
A comparação dos diversos data stores apresentados pode resumir-se, a nível de
mecanismos à Tabela 1.
Mecanismos de Controlo de Concorrência
• Locks: permitem que apenas um utilizador leia ou modifique uma entidade (objecto,
document, linha ou campo);
• MVCC: fornecem um mecanismo de multi-versões, permitindo que exista uma
consistência na leitura das base de dados mas que têm como desvantagem um conflito
de versões caso existam modificações simultaneamente;
• ACID: já bem conhecido dos sistemas relacionais. A estes, de forma a evitar conflitos,
acrescentou-se uma pré-análise de transacções;
• Nenhum: existem data stores que não implementam qualquer mecanismo de controlo
de concorrência, permitindo que diferentes utilizadores alterem diferentes partes de
um objecto em paralelo e não fornecendo qualquer garantia de que versão o
utilizador vai obter quando ler a base de dados.
Sistemas de Armazenamento
Alguns sistemas estão desenhados para armazenar a informação na RAM, podendo ou não
armazenar replicas ou snapshots em disco. Outros sistemas, estão desenhados para armazenar
a informação no disco e conter alguma informação na RAM.
Mecanismos de Replicação
Este mecanismo garante que as cópias que existem estão sempre sincronizadas. Isso é
conseguindo fazendo um lock à base de dados sempre que existe um update a ser feito que
apenas termina quando as réplicas também são actualizadas. Uma alternativa utilizada é a
actualização assíncrona que é feita em background permitindo que a base de dados continue
operacional enquanto essas actualizações são feitas.
Page 11

13. 4.2 SQL vs. NoSQL – Conflito de Opiniões
Este tópico é um assunto bastante controverso (1).
Os argumentos a favor do SQL são:
• Existem novos sistemas SQL que conseguem fazer aquilo a que o NoSQL se propõe,
com performance e escalabilidade similar, mas com a vantagem de ser SQL e ACID.
•
SGBDR têm uma grande quota do mercado.
•
Já foram construídos muitos SGBDR para responder às necessidades dos clientes no
passado.
•
Os produtos SQL têm uma interface comum, transacções e esquemas relacionais que
facilitam a aprendizagem e a troca de informação.
Por outro lado, os argumentos a favor do NoSQL são:
• Não existem bons e independentes benchmarkings que mostrem que um SGBDR
consegue a escalabilidade comparável com sistemas NoSQL, como por exemplo a
BigTable do Google.
•
A ideologia key-value é mais simples de entender do que o esquema relacional
tradicional. Assim como o armazenamento de documentos. A curva de aprendizagem
depende da complexidade do que se quer aprender.
•
Algumas aplicações necessitam de um esquema flexível, permitindo que cada
collection tenha atributos diferentes. Atribuir novos atributos, em execução, é
incomum nos SGBDR.
•
Os SGBDR permitem facilmente operações em multi-tabelas em multi-nós. No NoSQL
essas operações são impossíveis ou demasiado custosas de implementar (logo mal
existem).
•
Enquanto que os SGBDR têm uma grande quota de mercado, os sistemas NoSQL têm
um mercado mais restrito onde existe realmente necessidade de implementar estas
capacidades em particular.
4.3 Benchmaking
Os testes e resultados que serão aqui apresentados foram efectuados pela equipa de
investigação da Yahoo! e estão disponíveis online para consulta (11) (4).
Configurações
Page 12

14. •
•
•
•
•
•
•
•
Seis servidores:
o 8 cores (2x quadcore) 2.5 GHz CPUs, 8 GB RAM, 6 x 146GB 15K RPM SAS drives
in RAID 1+0, Gigabit ethernet, RHEL 4
Máquinas extra para simular clientes, routers, controlo, etc.
Cassandra 0.5.0
HBase 0.20.3
MySQL 5.1.32 organizado numa configuração com sharding
Sherpa 1.8 com MySQL 5.1.24
Sem replicação
Updates forçados para o disco (excepto no HBase que os updates vão primeiro para a
memória)
Workloads
•
•
•
•
120 milhões de registos de 1KB = 20GB por servidor
Reads: retornam um registo inteiro
Updates: escrevem num único campo
100 ou mais threads dos clientes
Teste 1 – Escalabilidade
Neste teste o hardware aumenta-se o harware proporcionalmente com o volume de
informação e o workload. Mede-se a latência. Idealmente a latência deve ser constante.
Figura 4 - Workload de heavy reads variando o hardware
Como podemos ver no gráfico, Sherpa e Cassandra têm um bom escalonamento,
mantendo a linha da latência quase sem variações à medida que o sistema aumenta. Por outro
Page 13

15. lado, o HBase é muito instável, tendo uma performance medíocre com três ou menos
servidores.
TESTE 2 – Elasticidade
Neste testes o workload é executado em N servidores. Gradualmente o número de
servidores aumenta. É medida a latência das leituras à base de dados. Idealmente, a latência
deve diminuir à medida que são adicionados novos nós.
Figura 5 - Read heavy workload utilizando o Sherpa. Inicialmente em 2 servidores. Depois foram adicionados
um 4º, um 5º e um 6º.
Esta data store mostra alguma variação de performance quando os tablets (shards)
migram. Mas depois desse processo, a performance estabiliza e torna-se mais rápido com o 6º
servidor é adicionado.
Figura 6 – Read heavy workload utilizando Cassandra. Inicialmente em 2 servidores. Depois foram
adicionados um 4º, um 5º e um 6º.
Page 14

16. A data store Cassandra apresenta bastantes variações de latência sempre que há
necessidade de migrar dados para os novos servidores, demorando algumas horas a
estabilizar.
Figura 7 - Read heavy workload utilizando HBase. Inicialmente em 2 servidores. Depois foram adicionados
um 4º, um 5º e um 6º
Esta data store apresenta valores de latência muito baixos comparativamente às duas data
stores anteriormente apresentadas. O pico que podemos ver no gráfico deve à reconfiguração
do cluster. Contudo, estes valores são ilusórios. A informação só vai migrar para os novos
servidores quando for compactada, sendo essa operação uma actividade periódica. Esses
valores não estão presentes no gráfico não sendo então possível fazer uma verdadeira
comparação com os sistemas anteriores.
5. Conclusão
Neste trabalho descrevemos brevemente o constrangimento relacionado com a
escalabilidade de bases de dados relacionais e apresentamos algumas alternativas NoSQL para
resolver esse mesmo problema.
Das diversas alternativas apresentadas, fizemos um sumário das características das
diferentes data stores que apresentamos na Tabela 1.
Dos dados analisados podemos concluir que os sistemas que são RAM-based permitem a
utilização da memória virtual do sistema operativo. Contudo, a performance decresce
significativamente quando existe um overflow da memória física da máquina.
Da análise dos dados disponíveis verificou-se também que a replicação assíncrona permite
operações mais rápidas, nomeadamente para réplicas remotas. Por outro lado, alguns updates
podem perder-se caso se verifique um crash no sistema. Uma alternativa implementada é a
replicação síncrona em cópias locais e replicação assíncrona para cópias alojadas
Page 15

17. remotamente. Esta foi a única solução prática que encontramos para actualizações de
informação remota.
Na nossa opinião existem vantagens e desvantagens em utilizar NoSQL como solução para
uma base de dados escalável. As bases de dados NoSQL escalam de forma elástica,
expandindo-se de forma transparente pelos nós, tirando partido de novas tecnologias, como a
Cloud, uma vez que estão desenhadas para um escalonamento low cost.
Outra vantagem do NoSQL é a facilidade com que manuseiam grandes quantidades de
dados. Apesar dos sistemas relacionais tentarem acompanhar este aumento de dados, têm
demasiadas restrições o que as torna impeditivas para algumas situações. Os sistemas NoSQL
utilizam sistemas como o Hadoop para lidar com esse volume de dados, solucionando esse
problema.
Manter um SGBDR de grandes dimensões precisa de administradores especializados, o que
envolve mais custos. As bases de dados NoSQL estão desenhadas para necessitar de menos
gestão: têm recuperação automática de falhas, distribuição automática de informação, e
modelos de dados mais simples, na teoria. Na prática continua a necessitar de gestão humana.
Economicamente é menos custosa que uma base de dados relacional. Enquanto a base de
dados relacional necessita de servidores dedicados a essa função e servidores para armazenar
os dados, uma base de dados não relacional pode utilizar um cluster reduzindo o custo, por
gigabyte ou por transacção/segundo.
A ausência de um modelo específico de dados para utilizar as bases de dados NoSQL é
igualmente uma vantagem. Enquanto uma base de dados SQL tem um modelo de dados muito
específico e inflexível, com NoSQL há maior flexibilidade existindo uma solução viável para
quase todos os tipos de estruturas, como mostramos neste trabalho.
As bases de dados NoSQL criaram muitas expectativas e muito entusiasmo na
comunidade. Contudo existem ainda alguns desafios nesta área.
Por ser um sistema relativamente recente ainda necessita de maturidade. Os sistemas
existentes ainda estão a implementar as suas key features. E comparativamente com os SGBDR
que existem há muito tempo, falta-lhes a estabilidade e as funcionalidades que estes possuem.
O suporte existente ainda não é o suficiente. Por exemplo, se numa empresa o SGBDR
falhar existe suporte dos vendedores dos serviços. No caso dos sistemas NoSQL, uma vez que
na sua maioria são projectos open source, a ajuda advém de uma comunidade e não de uma
empresa como a Oracle, Microsoft ou IBM que têm uma credibilidade maior.
A administração de uma base de dados NoSQL exige, na realidade, pessoas com bastantes
conhecimentos para instalar, configurar e manter o sistema.
As bases de dados NoSQL começam a vingar no panorama das bases de dados e, quando
utilizadas correctamente, oferecem benefícios reais.
Contudo, a migração das grandes bases de dados deve ser feita com muita cautela e com a
consciência das limitações e constrangimentos que ainda estão associados a estas bases de
dados.
Page 16

18. 6. Bibliografia
1. Scalable SQL and NoSQL Data Stores. Cattell, Rick. 4, s.l. : ACM SIGMOD Record, 2010,
Vol. 39.
2. Tharakan, Royans K. Brewers CAP Theorem on distributed systems. Scalable web
architectures. [Online] 2010. http://www.royans.net/arch/brewers-cap-theorem-ondistributed-systems/.
3. Voldemort, Project. Project Voldemort. Project Voldemort. [Online] http://projectvoldemort.com/.
4. Cooper, Brian F. Yahoo! Cloud Serving Benchmark. 2010.
5. SimpleDB: A Simple Java-Based Multiuser System for Teaching Database Internals .
Sciore, Edward. s.l. : SIGCSE, 2007.
6. MongoDB. http://www.mongodb.org/. http://www.mongodb.org/. [Online]
http://www.mongodb.org/.
7. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach.
Bigtable: A Distributed Storage System for Structured Data. 2006.
8. Foundation, The Apache Software. Apache HBase. Apache HBase. [Online]
9. —. Cassandra. Cassandra. [Online] http://cassandra.apache.org/.
10. Ramakrishnan, Raghu. Sherpa: Cloud Computing of the Third Kind. s.l. : Yahoo!
Research and Platform Engineering Team, 2008.
11. Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, Russell Sears.
Benchmarking Cloud Serving Systems with YCSB. s.l. : Yahoo! Research, 2010.
12. Inc, Scale Base. Scale Base. Scale Base. [Online] http://www.scalebase.com/.
13. Corporation, Oracle. MySQL Cluster CGE. MySQL. [Online]
http://www.mysql.com/products/cluster/.
Page 17