DCC- Faculdade de Cincias da Universidade do Porto

SQL e NoSQL
Escalabilidade em Data Stores

Rui Costa Teresa Costa

060316042 050316021

Contedo
1. 2. 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 3. Introduo ..................................................................................................................... 2 Diferentes Tipos de Base de Dados ............................................................................... 2 Bases de Dados SQL e NoSQL .................................................................................... 2 Teorema de CAP ........................................................................................................ 3 Consistncia........................................................................................................... 3 Disponibilidade ...................................................................................................... 4 Tolerncia a Falhas ................................................................................................ 4 Terminologia ............................................................................................................. 4 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 Escalveis .................................................................................. 10 3.4.1 MySQL Cluster ............................................................................................................ 10 3.4.2 ScaleBase .................................................................................................................... 10 4. 4.1 4.2 4.3 5. 6. Anlise dos Sistemas ................................................................................................... 11 Comparao entre Sistemas.................................................................................... 11 SQL vs. NoSQL Conflito de Opinies ..................................................................... 12 Benchmaking ........................................................................................................... 12 Concluso .................................................................................................................... 15 Bibliografia .................................................................................................................. 17

Page 1

1. Introduo
Com advento da Web 2.0 surgiram aplicaes que necessitam de sistemas que consigam lidar com milhares de utilizadores e escalar milhes de updates e leituras a base de dados. Este volume de operaes contrasta com o design das bases de dados e data warehouses tradicionais. Para responder a esta necessidade necessrio desenvolver novos sistemas e mecanismos que consigam escalar estas aplicaes por diversos servidores. Nos ltimos anos verificou-se o desenvolvimento de novos sistemas, desenhados para proporcionar uma boa escalabilidade horizontal, permitindo operaes de leitura/escrita distribudas pelos diversos servidores. Estes novos sistemas vm contrastar com as bases de dados tradicionais que tm pouca ou nenhuma capacidade para essa escalabilidade horizontal. Nesta monografia apresentamos e comparamos alguns desses novos sistemas de bases de dados distribudas.

2. Diferentes Tipos de Base de Dados

2.1 Bases de Dados SQL e NoSQL

Os novos sistemas so designados de NoSQL data stores. Esta definio tanto diz respeito a Not Only SQL como a Not Relational. Como tal, vamos fixar algumas caractersticas referentes aos sistemas NoSQL que vamos referir neste trabalho. (1) 1. Capacidade de escalar horizontalmente operaes simples pelos diversos servidores; 2. Capacidade de replicar e distribuir informao por diversos servidores; 3. Interface de call level simples, contrastando com o SQL binding; 4. Um modelo de concorrncia mais fraco que o modelo ACID; 5. Uso eficiente para ndices distribudos e RAM para o armazenamento de informao; 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 operaes simples de leitura/escrita, por segundo. Para a implementao destes sistemas, a ideia desistir das restries do ACID de forma a obter maior performance e escalabilidade. Contudo, os sistemas que vamos apresentar, variam na forma em que desistem dessas restries. Por exemplo, a maior parte dos sistemas denominam-se de eventualmente consistentes.

Page 2

2.2 Teorema de CAP

O teorema de CAP (2), tambm conhecido como Teorema de Brewer afirma que impossvel, num sistema de computao distribuda, ter simultaneamente as seguintes propriedades: Consistncia Disponibilidade; Tolerncia a falhas. Estes trs requisitos influenciam o desenho e instalao de sistemas de base de dados distribudas. Deste teorema e de uma profunda anlise resultou uma revoluo da arquitectura dos sistemas distribudos de dados em grande escala. ento importante definir o que so cada uma destas propriedades. Reconhecer quais dos requisitos do teorema de CAP so importantes para o nosso sistema o primeiro passo para construir com sucesso um sistema distribudo, escalvel e com alta disponibilidade.

Figura 1 - Diagrama representativo da interligao das propriedades do Teorema de CAP e as diversas data stores.

2.2.1 Consistncia
a caracterstica que descreve como e se o estado de um sistema fica consistente aps uma operao. Num sistema distribudo de dados significa que uma vez escrito um registo, este fica imediatamente disponvel e pronto para ser utilizado. Uma base de dados distribuda consistncia classificada como fortemente consistente ou como tendo fraca consistncia. Os sistemas com uma forte consistncia, implementam as caractersticas ACID (Atomicidade, Consistncia, Isolamento e Durabilidade), sendo estas implementadas na maior parte das bases de dados relacionais. Na outra extremidade, de fraca consistncia, temos as bases de dados BASE (Basic Availability, Soft-State, Eventual Consistency). A consistncia fraca fornecida de forma de consistncia 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 so replicados. Aqui apenas existe a garantia que a verso mais

Page 3

recente de um registo est consistente num n, sendo que as verses mais antigas deste registo podem ainda existir noutros ns, mas eventualmente todos os ns iro ter a ltima verso.

2.2.2 Disponibilidade
Esta caracterstica refere-se concepo e implementao de um sistema de modo a que seja assegurado que este permanece activo durante um determinado perodo de tempo. Ou seja, significa que o sistema tolerante a falhas de software e/ou hardware e que se encontra igualmente disponvel durante a actualizao destes. Disponibilidade no apenas um proteco contra falhas, mas tambm uma forma de obter um balanceamento de carga e operaes concorrentes, nomeadamente para operaes de leitura. Uma das formas mais comuns de fazer a implementao desta caracterstica numa base de dados relacional recorrendo replicao master-master. Desta forma, a falha ou actualizao de um n no implica a indisponibilidade do sistema.

2.2.3 Tolerncia a Falhas

Esta caracterstica refere-se capacidade de um sistema continuar a operar na presena de uma falha de rede.

2.3 Terminologia
Antes de descrevermos os diversos sistemas necessrio clarificar alguns termos que sero utilizados neste trabalho (1). Por operaes simples entendemos key lookups, leitura ou escrita de um registo ou de uma pequena quantidade de registos. Tendo em conta o estado actual das aplicaes, onde milhes de utilizadores lem e escrevem informao, a escalabilidade destas pequenas operaes tornou-se muito importante. J foi referido anteriormente o termo escalabilidade horizontal. Este termo refere-se capacidade de distribuir a informao e a carga de processamento das operaes por vrios servidores, sem ser necessrio a partilha de RAM ou disco entre os servidores. Esta escalabilidade difere da escalabilidade vertical onde o disco e memria so partilhados pelos servidores. A terminologia utilizada em NoSQL Data Stores , muitas vezes inconsistente. De forma a existir consistncia, 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 so escalares. Os valores so referenciados pelo nome do atributo.

Page 4

Document: permite que os valores estejam agrupados em documentos ou listas e os nomes dos atributos so automaticamente definidos a cada execuo. A grande diferena em relao aos tuplos que aqui os atributos no esto esquematizados. Extensible Record: um hbrido entre um tuplo e um document. Aqui a famlia de atributos est pr-definida na base de dados, mas novos atributos podem ser adicionados Objecto: similar ao conceito de objecto em linguagens de programao, mas no tem mtodos procedimentais. Os valores que este toma ou so referncias ou objectos agrupados.

3. Categorias das Data Stores

Os sistemas referenciados neste trabalho esto 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 so 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 ns. 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 memria cache um ndice key-value para todos os dados. Tal como o memcached, nenhum dos sistemas nesta categoria oferecem ndices ou chaves secundrias. Por outro lado, fornecem mecanismos de persistncia e outras funcionalidades como replicao, manuteno de verses, locking ou sorting.

3.1.1 Projecto Voldemort

Este sistema um avanado key-value store. Sendo open source tm muitas contribuies, nomeadamente do LinkedIn. Fornece um mecanismo de controlo de verses (MVCC) para os updates. As rplicas sofrem update de forma assncrona no garantindo, por isso, consistncia. Contudo, pode garantir uma vista actualizada se a leitura for feita maior parte das rplicas. O Projecto Voldemort (3) suporta tambm um lock da data store optimista, para garantir a actualizao de registos mltiplos. Assim, se existir algum conflito, a actualizao no efectuada. Outro mecanismo suportado o sharding automtico dos dados. Este mecanismo possibilita que existam mais ns virtuais do que fsicos (servidores). Uma vez particionada a

Page 5

informao, o resto das operaes so transparentes. Os ns podem ser adicionados ou removidos que o sistema adapta-se automaticamente. Voldemort detecta automaticamente falhas nos ns e capaz de as recuperar. Este sistema permite guardar a informao 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 indexao distribuda na memria que foi melhorado surgindo o Membase que acrescentou novas caractersticas ao sistema como persistncia, replicao, alta disponibilidade, crescimento dinmico e backups, por exemplo. Sem a persistncia e a replicao o Memcached no se classifica como uma data store. Mas o Membrain e o Membase sim. E uma vez que estes sistemas so compatveis com o Memcached so amplamente utilizados. O Membase um sistema open source. A sua caracterstica 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 necessrio. O Membrain um sistema proprietrio, sendo necessrio uma licena por cada servidor. A sua caracterstica mais apelativa a afinao especial que tem para lidar com memria flash. A performance obtida com este tipo de memria bastante superior em relao aos outros sistemas.

3.1.3 Yahoo Sherpa

Esta data store est a ser desenvolvida pela Yahoo (4). um sistema multi-tenant onde uma aplicao armazena dados numa tabela, sendo esta um conjunto de records. Essa tabela dividida em shards que so distribudos por diversos ns. Com ajuda de um software que guarda informao sobre a distribuio de shards, sempre que existe um pedido, este reencaminhado para o n correcto. O acesso aos registos feito atravs uma chave primria. A escalabilidade deste sistema deve-se ao particionamento da informao. Cada shard contm um range de dados, restringindo assim as operaes aos ns onde possivelmente esto as informaes pretendidas. O Sherpa considerado um sistema elstico permitindo que novos ns sejam adicionados dinamicamente. O particionamento ou reparticionamento tambm feito dinamicamente. Os dados so replicados, de forma automtica por mltiplos ns com intuito de prevenir falhas. A falha de um n transparente para as aplicaes.

3.2 Document Store

Este tipo de data stores suportam dados mais complexos, comparativamente s Key-Value Stores. Ao contrrio destas, estes sistemas suportam ndices secundrios e mltiplos tipos de documents (objectos) por base de dados.

Page 6

3.2.1 SimpleDB
Este sistema propriedade da Amazon (5). Tal como o nome sugere um sistema simples: SimpleDB tem as operaes Select, Delete, GetAttributes e PutAttributes. Por ser to simples no permite documentos agrupados. Este sistema suporta consistncia eventual, mas no consistncia transaccional. Suporta tambm replicao assncrona. Tal como as Document Stores, o SimpleDB suporta mais do que um grupo por base de dados. Os documents so postos em domnios que suportam indexao mltipla. Os domnios e a sua meta-informao podem ser enumerados. A operao de Select feita num domnio, onde so especificados um conjunto de restries. So da forma de:
select <atributes> from <domain> where <list of attribute value constraints>

Os diferentes domnios so armazenados em diferentes ns da Amazon. Os ndices num domnio so automaticamente actualizados quando os atributos de um document so modificados. Este sistema no particiona automaticamente os dados pelos servidores. Pode-se conseguir alguma escalabilidade horizontal lendo qualquer uma das rplicas, isto se a verso mais actual no for importante. A escrita no escalvel porque as actualizaes tm de ser de forma assncrona. 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 caractersticas interessantes: Suporta sharding automtico, distribuindo os documentos pelos servidores; A replicao na maior parte dos casos utilizada em casos de failover; No fornece consistncia global mas tem consistncia local, mantendo actualizada a cpia original do documento; Suporta queries dinmicas, com uso automtico de ndices, como as bases de dados relacionais; As operaes sobre os documentos so atmicas.

As operaes sobre os campos fornecidas so: O comando update ampliado, facilitando mudanas atmicas a valores individuais. Por exemplo, $inc incrementa um valor, $push adiciona um elemento a um array, etc. Os updates so feitos localmente para evitar overhead no servidor. A conveno update if current apenas permite alterar um campo se o valor corresponder a um valor prvio;

Page 7

A operao findAndModify faz um update atmico e retorna automaticamente o documento actualizado. Esta operao muito til quando lidamos com estruturas de dados que requerem atomicidade;

O MongoDB guarda a informao num formato binrio, semelhante ao JSON, denominado de BSON. Este formato suporta os tipos booleanos, integer, float, date, string e binrio. Este sistema suporta ainda GridFS fundamental para dados binrios de grande dimenso, como imagens ou vdeos. Como so armazenados em pedaos, ao serem transmitidos para o cliente h eficincia na entrega. Este sistema suporta ainda replicao master-slave, com recuperao automtica de failovers. Esta recuperao feita ao nvel dos shards. As collections so automaticamente partilhadas por uma shard-key definida pelo utilizador. A replicao assncrona 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 bsico, de colunas e linhas, e a escalabilidade est em dividir tanto as colunas como as linhas por diferentes ns (servidores): As linhas so divididas por vrios ns atravs do sharding da chave primria. So divididas por range, possibilitando que uma pesquisa no necessite de todos os ns. As colunas so distribudas pelos vrios ns em forma de grupo.

Os grupos de colunas so pr-definidas com extensible record stores. As linhas so anlogas a documents, tendo um nmero varivel de atributos, com nomes distintos, e esto agrupadas em collections.

Page 8

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 fundao Apache, derivando da BigTable da Google: Usa Hadoop como sistema de ficheiros distribudo. Os updates so guardados em memria e periodicamente so escritos em disco; Os updates vo para o fim do ficheiro de dados, para evitar procuras desnecessrias. Para uma recuperao mais eficiente, em caso de crash do servidor, os updates vo para o fim do log. As operaes sobre as linhas so atmicas, com um locking das transaces de baixo nvel. Usa controlo de concorrncia optimista, abortando se existir conflitos entre updates. O particionamento e distribuio so transparentes. Existe mltiplo suporte para masters, para evitar um ponto singular de falhas. A utilizao do MapReduce permite que as operaes sejam distribudas de forma eficiente.

3.3.2 Cassandra
O Cassandra (9) similar aos outros sistemas Extensible Record Stores. Tem grupos de colunas, as actualizaes so guardadas na cache da memria e periodicamente escritas em disco. Faz particionamento e replicao. Tem mecanismos de deteco de falhas assim como recuperao automtica. Contudo, o Cassandra tem um modelo de concorrncia fraco, no apresentando mecanismos de locking e tendo as actualizaes das rplicas assincronamente. Este sistema confere automaticamente nova disponibilidade aos ns de um cluster. Usando o algoritmo Phi Accrual consegue detectar a falha de um n. tambm 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 nvel 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 nvel dos

Page 9

ndices. Desta forma, possvel saber que ns podem ter aquele conjunto particular de valores no havendo necessidade de procurar em todos os ns.

3.4 Sistemas Relacionais Escalveis

Ao contrrio das Data Stores, um SGDB relacional tem um esquema completo e prdefinido, um interface SQL e transaces ACID. Contudo, tradicionalmente, as SGDBR no oferecem escalabilidade como os sistemas anteriormente mencionados. Os mais recentes desenvolvimentos mostram que possvel implementar alguma escalabilidade comparada com a das Data Stores NoSQL com duas ressalvas: Usar operaes de curta extenso. Como j foi visto, operaes que precisem de utilizar muitos ns, como joins de mltiplas tabelas, no escalam bem se no se utilizar shards; Usar transaces de curta extenso. Como anteriormente, transaces que necessitem de muitos ns so ineficientes.

O NoSQL contorna estes dois problemas impossibilitando, ou tornando difcil, fazer operaes e transaces deste calibre. No caso das SGBDR, estas apenas penalizam o utilizador se as realizar. Uma vantagem dos SGBDR escalveis a linguagem de alto nvel 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 distribuda chamada de NDB. Este sistema particiona a informao por vrios servidores, criando shards. Cada shard replicado, para suportar a recuperao em caso de falhas. Replicao bidireccional geogrfica tambm suportada. O MySQL Cluster tambm suporta dados na memria ou no disco. Caso a informao esteja na memria, 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 prprio MySQL. Este sistema possui um parser parcial de SQL e um optimizador que particiona as tabelas por mltiplos ns nicos de bases de dados MySQL (10). Implementar sharding em cima de MySQL introduz um novo problema se as transaces no forem abrangidas pelo MySQL.

Page 10

4. Anlise dos Sistemas

4.1 Comparao entre Sistemas

Sistema Key-Value Data Store Document Data Store Extensible Records Data Store Sistemas Relacionais Escalveis Voldemort Membrain Membase SimpleDB MongoDB HBase Cassandra MySQL Cluster ScaleBase

Controlo de Concorrncia MVCC Locks Locks Nenhum Locks Locks MVCC ACID ACID

Armazenamento RAM ou DBD Flash + Disco Disco S3 Disco Hadoop Disco Disco Disco

Replicao Assncrona Sncrona Sncrona Assncrona Assncrona Assncrona Assncrona Sncrona Assncrona

Tabela 1 - Sumrio das caractersticas das diversas data stores.

A comparao dos diversos data stores apresentados pode resumir-se, a nvel de mecanismos Tabela 1. Mecanismos de Controlo de Concorrncia Locks: permitem que apenas um utilizador leia ou modifique uma entidade (objecto, document, linha ou campo); MVCC: fornecem um mecanismo de multi-verses, permitindo que exista uma consistncia na leitura das base de dados mas que tm como desvantagem um conflito de verses caso existam modificaes simultaneamente; ACID: j bem conhecido dos sistemas relacionais. A estes, de forma a evitar conflitos, acrescentou-se uma pr-anlise de transaces; Nenhum: existem data stores que no implementam qualquer mecanismo de controlo de concorrncia, permitindo que diferentes utilizadores alterem diferentes partes de um objecto em paralelo e no fornecendo qualquer garantia de que verso o utilizador vai obter quando ler a base de dados. Sistemas de Armazenamento Alguns sistemas esto desenhados para armazenar a informao na RAM, podendo ou no armazenar replicas ou snapshots em disco. Outros sistemas, esto desenhados para armazenar a informao no disco e conter alguma informao na RAM. Mecanismos de Replicao Este mecanismo garante que as cpias que existem esto sempre sincronizadas. Isso conseguindo fazendo um lock base de dados sempre que existe um update a ser feito que apenas termina quando as rplicas tambm so actualizadas. Uma alternativa utilizada a actualizao assncrona que feita em background permitindo que a base de dados continue operacional enquanto essas actualizaes so feitas.

Page 11

4.2 SQL vs. NoSQL Conflito de Opinies

Este tpico um assunto bastante controverso (1). Os argumentos a favor do SQL so: Existem novos sistemas SQL que conseguem fazer aquilo a que o NoSQL se prope, com performance e escalabilidade similar, mas com a vantagem de ser SQL e ACID. SGBDR tm uma grande quota do mercado. J foram construdos muitos SGBDR para responder s necessidades dos clientes no passado. Os produtos SQL tm uma interface comum, transaces e esquemas relacionais que facilitam a aprendizagem e a troca de informao.

Por outro lado, os argumentos a favor do NoSQL so: No existem bons e independentes benchmarkings que mostrem que um SGBDR consegue a escalabilidade comparvel 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 aplicaes necessitam de um esquema flexvel, permitindo que cada collection tenha atributos diferentes. Atribuir novos atributos, em execuo, incomum nos SGBDR. Os SGBDR permitem facilmente operaes em multi-tabelas em multi-ns. No NoSQL essas operaes so impossveis ou demasiado custosas de implementar (logo mal existem). Enquanto que os SGBDR tm uma grande quota de mercado, os sistemas NoSQL tm um mercado mais restrito onde existe realmente necessidade de implementar estas capacidades em particular.

4.3 Benchmaking
Os testes e resultados que sero aqui apresentados foram efectuados pela equipa de investigao da Yahoo! e esto disponveis online para consulta (11) (4). Configuraes

Page 12

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 Mquinas extra para simular clientes, routers, controlo, etc. Cassandra 0.5.0 HBase 0.20.3 MySQL 5.1.32 organizado numa configurao com sharding Sherpa 1.8 com MySQL 5.1.24 Sem replicao Updates forados para o disco (excepto no HBase que os updates vo primeiro para a memria) Workloads

120 milhes 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 informao e o workload. Mede-se a latncia. Idealmente a latncia deve ser constante.

Figura 4 - Workload de heavy reads variando o hardware

Como podemos ver no grfico, Sherpa e Cassandra tm um bom escalonamento, mantendo a linha da latncia quase sem variaes medida que o sistema aumenta. Por outro

Page 13

lado, o HBase muito instvel, tendo uma performance medocre com trs ou menos servidores.

TESTE 2 Elasticidade Neste testes o workload executado em N servidores. Gradualmente o nmero de servidores aumenta. medida a latncia das leituras base de dados. Idealmente, a latncia deve diminuir medida que so adicionados novos ns.

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 variao de performance quando os tablets (shards) migram. Mas depois desse processo, a performance estabiliza e torna-se mais rpido 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

A data store Cassandra apresenta bastantes variaes de latncia 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 latncia muito baixos comparativamente s duas data stores anteriormente apresentadas. O pico que podemos ver no grfico deve reconfigurao do cluster. Contudo, estes valores so ilusrios. A informao s vai migrar para os novos servidores quando for compactada, sendo essa operao uma actividade peridica. Esses valores no esto presentes no grfico no sendo ento possvel fazer uma verdadeira comparao com os sistemas anteriores.

5. Concluso
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 sumrio das caractersticas das diferentes data stores que apresentamos na Tabela 1. Dos dados analisados podemos concluir que os sistemas que so RAM-based permitem a utilizao da memria virtual do sistema operativo. Contudo, a performance decresce significativamente quando existe um overflow da memria fsica da mquina. Da anlise dos dados disponveis verificou-se tambm que a replicao assncrona permite operaes mais rpidas, nomeadamente para rplicas remotas. Por outro lado, alguns updates podem perder-se caso se verifique um crash no sistema. Uma alternativa implementada a replicao sncrona em cpias locais e replicao assncrona para cpias alojadas

Page 15

remotamente. Esta foi a nica soluo prtica que encontramos para actualizaes de informao remota. Na nossa opinio existem vantagens e desvantagens em utilizar NoSQL como soluo para uma base de dados escalvel. As bases de dados NoSQL escalam de forma elstica, expandindo-se de forma transparente pelos ns, tirando partido de novas tecnologias, como a Cloud, uma vez que esto 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, tm demasiadas restries o que as torna impeditivas para algumas situaes. Os sistemas NoSQL utilizam sistemas como o Hadoop para lidar com esse volume de dados, solucionando esse problema. Manter um SGBDR de grandes dimenses precisa de administradores especializados, o que envolve mais custos. As bases de dados NoSQL esto desenhadas para necessitar de menos gesto: tm recuperao automtica de falhas, distribuio automtica de informao, e modelos de dados mais simples, na teoria. Na prtica continua a necessitar de gesto humana. Economicamente menos custosa que uma base de dados relacional. Enquanto a base de dados relacional necessita de servidores dedicados a essa funo e servidores para armazenar os dados, uma base de dados no relacional pode utilizar um cluster reduzindo o custo, por gigabyte ou por transaco/segundo. A ausncia de um modelo especfico de dados para utilizar as bases de dados NoSQL igualmente uma vantagem. Enquanto uma base de dados SQL tem um modelo de dados muito especfico e inflexvel, com NoSQL h maior flexibilidade existindo uma soluo vivel 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 esto 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 no o suficiente. Por exemplo, se numa empresa o SGBDR falhar existe suporte dos vendedores dos servios. No caso dos sistemas NoSQL, uma vez que na sua maioria so projectos open source, a ajuda advm de uma comunidade e no de uma empresa como a Oracle, Microsoft ou IBM que tm uma credibilidade maior. A administrao 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 comeam a vingar no panorama das bases de dados e, quando utilizadas correctamente, oferecem benefcios reais. Contudo, a migrao das grandes bases de dados deve ser feita com muita cautela e com a conscincia das limitaes e constrangimentos que ainda esto associados a estas bases de dados.

Page 16

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