DCC- Faculdade de Ciências da

Universidade do Porto

SQL e NoSQL Escalabilidade em Data Stores

Rui Costa 060316042 Teresa Costa 050316021

Page 1

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 2

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 3

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 4

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 5

• 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 6

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 7

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 8

• 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 9

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 10

í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 11

4. Análise dos Sistemas

4.1 Comparação entre Sistemas

Sistema Controlo de

Concorrência Armazenamento Replicação

Key-Value

Data Store

Voldemort MVCC RAM ou DBD Assíncrona

Membrain Locks Flash + Disco Síncrona

Membase Locks Disco Síncrona

Document

Data Store

SimpleDB Nenhum S3 Assíncrona

MongoDB Locks Disco Assíncrona

Extensible

Records Data

Store

HBase Locks Hadoop Assíncrona

Cassandra MVCC Disco Assíncrona

Sistemas

Relacionais

Escaláveis

MySQL Cluster ACID Disco Síncrona

ScaleBase ACID Disco 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 12

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 13

• 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 14

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 15

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 16

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 17

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-on-distributed-systems/.

3. Voldemort, Project. Project Voldemort. Project Voldemort. [Online] http://project-voldemort.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/.