DCC- Faculdade de Ciências da
Universidade do Porto

SQL e NoSQL
Escalabilidade em Data Stores

Rui Costa
Teresa Costa

06...
Conteúdo
1.

Introdução .....................................................................................................
1. Introdução
Com advento da Web 2.0 surgiram aplicações que necessitam de sistemas que consigam
lidar com milhares de uti...
2.2 Teorema de CAP
O teorema de CAP (2), também conhecido como Teorema de Brewer afirma que é
impossível, num sistema de c...
recente de um registo está consistente num nó, sendo que as versões mais antigas deste
registo podem ainda existir noutros...
•

Document: permite que os valores estejam agrupados em documentos ou listas e os
nomes dos atributos são automaticamente...
informação, o resto das operações são transparentes. Os nós podem ser adicionados ou
removidos que o sistema adapta-se aut...
3.2.1 SimpleDB
Este sistema é propriedade da Amazon (5). Tal como o nome sugere é um sistema simples:
SimpleDB tem as oper...
•

A operação “findAndModify” faz um update atómico e retorna automaticamente o
documento actualizado. Esta operação é mui...
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 ...
índices. Desta forma, é possível saber que nós podem ter aquele conjunto particular de valores
não havendo necessidade de ...
4. Análise dos Sistemas

4.1 Comparação entre Sistemas

Voldemort
Membrain
Membase
SimpleDB
MongoDB

Controlo de
Concorrên...
4.2 SQL vs. NoSQL – Conflito de Opiniões

Este tópico é um assunto bastante controverso (1).
Os argumentos a favor do SQL ...
•

•
•
•
•
•
•
•

Seis servidores:
o 8 cores (2x quadcore) 2.5 GHz CPUs, 8 GB RAM, 6 x 146GB 15K RPM SAS drives
in RAID 1+...
lado, o HBase é muito instável, tendo uma performance medíocre com três ou menos
servidores.

TESTE 2 – Elasticidade
Neste...
A data store Cassandra apresenta bastantes variações de latência sempre que há
necessidade de migrar dados para os novos s...
remotamente. Esta foi a única solução prática que encontramos para actualizações de
informação remota.
Na nossa opinião ex...
6. Bibliografia
1. Scalable SQL and NoSQL Data Stores. Cattell, Rick. 4, s.l. : ACM SIGMOD Record, 2010,
Vol. 39.
2. Thara...
Upcoming SlideShare
Loading in...5
×

xxx no sequel

132

Published on

oijsaoda suhdao

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
132
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

xxx no sequel

  1. 1. DCC- Faculdade de Ciências da Universidade do Porto SQL e NoSQL Escalabilidade em Data Stores Rui Costa Teresa Costa 060316042 050316021
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×