NoSQL: um estudo introdutrio e comparativo entre algumas das principais solues

Euclydes Gregrio de Melo Teresina-PI / Brasil euclydesmelo@gmai.com ABSTRACT

The behavior of applications Web, in particular, having to deal with large data volumes at a low latency and high availability of their services, highlighted the need to adopt new technologies for distributed data storage. The Relational Database, which for decades was virtually the only option considered to persist data, was becoming a critical point in performance. In this context, new thoughts and ideas began to arise regarding the data storage solutions, to guarantee, above all, availability of services. Solutions of these ideas arose practices used currently in several cases of success. To all this moving around new technologies for storing non-relational data, is called NoSQL movement. This movement, as well as some of the main ferramentam that support will be presented and compared in this study. Basically it will be exposed to history of this movement, the characteristics of major solutions such as data model and architecture, and a benchmarking of the performance of these banks, as measured by throghput operations in terms of latency of the responses.

Orientador Prof. Dr. Fbio de Jesus Lima Gomes fabiojlgomes@gmail.com

Esse modelo foi proposto, em 1970, por Ted Codd da IBM Research[2], baseado na teoria dos conjuntos e na lgica de predicados de primeira ordem. A adoo dessa tecnologia por grandes empresas, sua simplicidade e sua forte fundamentao matemtica contribuiram para essa supremacia dos Sistemas de Gerenciamento de Bancos de Dados Relacionais ( Relational Database Management System - RDBMS)[3], fazendo com que, de forma geral, nenhuma outra opo de armazenamento de dados fosse considerada pelos projetista de banco de dados e/ou arquitetos de software ou, simplesmente, esse aspecto nofuncional das aplicaes fosse negligenciado. Outra forte caracterisca presente nos RDBMS's o gerenciamento de transaes, marcado, principalmente, pela implementao das propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade)[3], garantindo um banco de dados consistente, mesmo em um ambiente composto por mltiplos usurios acessando e alterando os dados em operaes paralelas e simultneas, inclusive, salvaguardando as respectivas restries de integridade entre os dados, caso declaradas na definio do esquema[3]. Ao longo dessas dcadas, os sistemas de informao evoluiram, especialmente, as aplicaes web, que passaram a tratar um volume gigantesco de dados, atravs de uma quantidade exorbitante de acessos, denvendo fornecer, ainda, um baixo tempo de resposta s requisies. Nesse contexto, as aplicaes que dependem de persistncia encontram no armazenamento de dados um possvel gargalo, precisando lanar mo de tcnicas de escalabilidade de sistemas para atender as requisies em um tempo razovel. Esse comportamento peculiar das aplicaes web, em especial exigir baixa latncia na manipulao de grandes massas de dados, fez com que os RDBMS's passasem a no mais atender satisfatoriamente alguns requisitos no-funcionais e as necessidades de escalabilidade desse tipo de aplicao. Esse aspecto bastante crtico, tendo em vista os elevados custos e alta complexidade inerentes implementao e manuteno de um cluster de Banco de Dados Relacional, especialmente, por ter que garantir, ao longo dos diversos ns constituintes do cluster, atomicidade e isolamento entre as transaoes e consistncia dos dados aps a confirmao das operaes transacionais. Ficando, portanto, esse tipo de soluo restrita s grandes empresas, detentoras de um aporte tcnico e financeiro considervel [3]. Nesse cenrio, novos conceitos e pensamentos comearam a surgir no tocante as tcnicas de armazenamento de dados, distribuio e escalabilidade de sistemas. A exemplo disso, temos o teorema CAP ( Consistency, Availability and Partition Tolerance), as bases de dados BASE ( Basic Availability, Softstate, Eventual consistency ) e o movimento NoSQL. Comeouse, ento, ser ponderado no desenvolvimento de sistemas de

Categorias e Descries do Assunto

H.2.1 [Logical Degign ]: Banco de dados NoSQL Histrico, fundamentos, caractersticas, arquitetura, modelo de dados H.2.4 [Systems]: Banco de dados Distribudos no relacional, Solues NoSQL, comparao de desempenho entre algumas solues presentes no mercado. H.2.5 [Heterogeneous Databases ]: Apresentao incongruncias de algumas solues NoSQL ( Cloud Store). das

Termos Gerais
Design, Experimento, Medio, performance, Verificao de Desempenho.

Palavras-Chave
Banco de Dados, Modelo Relacional, DBMS, RDBMS, NoSQL, Escalabilidade, Elasticidade, Disponibilidade, performance, Normalizao, Sistema de Banco de dados Distribudo, Cloud Store.

1.

INTRODUO

No incio da dcada de 80, como alternativa aos antigos bancos de dados hierrquicos e de rede[1], surgiram as primeiras implementaes comerciais de bancos de dados relacional: Oracle e SQL/DS da IBM. O modelo de dados utilizados por esses bancos (modelo relacional) viria a se tornar soberano como soluo de armazenamento de dados ao longo de, aproximadamente, trs dcadas.

informao, por exemplo, caracteristicas e requisitos da aplicao que antes estavam sendo, em geral, negligenciados. Permitindo, com isso, optar ou enxergar a melhor abordagem de armazenamento de dados levando em considerao a natureza e requisitos da aplicao. Iniciou-se, naquele momento, a quebra da hegemonia relacional [4] [5] [6].

no escala, pois a falha de um, implica na indisponibilidade do sistema como todo, por conta da impossibilidade de garantir a consistncia em todos os ns [5]. Portanto, percebe-se que o mundo relacional, como j citado, assegura a consistncia dos dados e, ainda, garante certa disponibilidade, porm no resiliente em relao falhas no particionamento, o que pode ser desastroso, caso a rede falhe ou aumente bastante a latncia. Por outro lado, a viso norelacional (NoSQL) pode fornece alta disponibilidade ou consistncia forte com altssima tolerncia falhas, proporcionando, em tese, uma escalabilidade mais natural [5]. Ainda no vis da consistcia, pode-se ter sistemas forte ou fracamente consistentes. Aqueles, em geral, implementam as caractersricas ACID, para garantir a consistncia e integridade dos dados; j estes optam pela disponibilidade mais eficiente em detrimento de uma consistncia mais rgida, ou seja, tem-se um sistema sempre disponvel e eventualmente consistente. Essa abordagem conhecida como BASE, a aqual ser discutida a seguir [5].

2.

ESCALABILIDADE

Segundo Andr B. Bondi[4], escalabilidade a capacidade de um sistema, em rede ou em um processo, manipular uma quantidade crescente de trabalho de forma uniforme ou aumentar esse poder de manipulao quando necessrio. Na esfera do armazenamento de dados, existem algumas estratgias de escalar um banco de dados. A menos traumtica delas a Escalabilidade Vertical, que consiste em aumentar o poder computacional do servidor de banco de dados, atravs do upgrade do hardware ou implantando a aplicao em uma mquina mais potente. Isso muito caro, principalmente, por criar uma dependncia de fornecedor, como o caso das solues Blade1, na qual um reforo computacinal pode ser feito com a aquisio de mais uma lmina e, alm disso, esse upgrade ser infinito, pois sempre surgiro aplicaes que consumiro esse ganho [3]. Outra opo escalar o banco de dados horizontalmente, atravs da criao de um cluster de servidores. Essa, sem dvida, uma soluo bem mais complexa, porm mais flexvel e dependendo da abordagem utilizada (ACID ou BASE) pode-se ganhar muito com a escalabilidade. Um apecto importante a possibilidade de particionar os dados entre os divernos ns do cluster, permitindo que o sistema continue operando como esperado, mesmo que a rede ou um n falhe. Essa tcnica conhecida como Partition Tolerannt (tolerancia partio ou tolerncia ao particionamento) e ser discutida a seguir, bem como solues BASE [5].

3.

TEOREMA CAP

Esse teorema foi proposto por Eric Brewer no Simpsio Principles of Distributed Computing (PODC) da Association for Computing Machinery (ACM) em 2000[5]. Segundo o teorema, impossvel um sistema distribuido garantir, ao mesmo tempo, consistncia, disponibilidade e tolerncia ao particionamento, porm qualquer combinao formadas por dois desses princpios pode ser suportada, como mostra a Figura 1. Tem-se, ento, sistemas que exigem forte consistncia (C) e tolerncia ao particionamento (P) CP. Nesse caso, necessrio abrir mo, um pouco, da disponibilidade. Algumas solues NoSQL utilizam essa abordagem, como BigTable e MongoDB. Outras solues precisam de altssima disponibilidade (A) e, por conseguinte, necessitam saber lidar com possveis falhas de partio (P) AP. Nesse tipo de sistema, a consistncia ser sacrificada ( eventual-consistency ), podendo existir janelas de inconsistncia, pois a lgica sempre aceitar operaes de escrita e tentar sincroniz-las, nos outros ns, posteriormente (read-consistency ). Apache Cassandra um exemplo de banco de dados NoSQL que implementa essa tcnica. Por ltmo, encontra-se os casos do qual a consistncia forte (C) e a alta disponibilidade (A) so requisitos CA. Esses sistemas no sabem lidar com falhas no particionamento de dados na rede, so os casos de algumas configuraes de banco de dados relacional, no qual todos os ns do cluster so altamente disponveis, porm
________________________________________

Figura 1. Teorema CAP e exemplos de modelos de dados aplicveis em cada combinao possvel.

4.

ACID X BASE

Eric Brewer, no evento j citado (PODC)[5], relevou que a maioria das pesquisas sobre Sistemas de Gerenciamento de Banco de Dados (DBMS) so, principalmente, sobre as caractersticas ACID e considerou fundamental perder Consistncia e Integridade para ganhar Disponibilidade e performance. Dan Pritchett[6], em seu artigo intitulado BASE: An Acid Alternative, observou que, em banco de dados particionados, abrindo mo de alguma consistncia a disponibilidade pode levar a melhorias na escalabilidade.

Blade Server um tipo de servidor compactado constitudo por vrios computadores (lminas) , dispostos em um hack, interligados por barramento, compartilhando unidade de armazenamento ( Storage ), econimizando espao e consumo de energia, dentre outros benefcios.
1

Enquanto sistemas ACID primam pela garantia da constncia e integridade dos dados, solues BASE valorizam mais a disponibilidade e performance em detrimento da consistncia. BASE um acrnimo forado, na idia de se contrapor, como na qumica, ao termo ACID, significando: B asically Available; Soft-state; Eventual Consistency.

O termo NoSQL foi usado pela primeira vez em 1998, por Carlo Strozzi [7], para nomear seu projeto de banco de dados relacional open source, com a proposta de ser uma implementao leve e de no expor ao programador a interface SQL. Porm, foi em 2009 em um evento organizado por Johan Oskarsson [8], para discutir sobre os bancos de dados distribudos open source, que Eric Evans [9] reutilizou o termo NoSQL para denominar o surgimento das inmeras solues de armazenamento de dados distribudos que, em geral, no forneciam as garantias ACID, caracterstica forte presente nos bancos de dados relacionais. Outra caractersca relevante nos bancos de dados NoSQL que, tambm, os contrape aos bancos relacionais a quebra da normalizao dos modelos de dados, por conta do desrespeito da primeira forma normal (1FN)[3], que especifca que todos os atributos devem ser monovalorados e no devem ser compostos. Como bem explana Navathe[3]: 1FN impede as 'relaes dentro de relaes' ou as 'relaes como valores de atributo dentro de tuplas'. Os nicos valores de atributos permitidos pela 1FN so valores nicos, atmicos (ou indivisveis ). Isso interessante, pois elimina a necessidade de joins entre as entidades, tendo em vista, por exemplo, que as dependncias de uma tabela encontram-se em um array na prpria tabela (campo composto) [3]. Por conta dessa caractersca os bancos NoSQL, tambm, so conhecidos como NF2 ou N1NF ( non first normal form ) e Carlo Strozzi, acredita que esse movimento deveria ser, mais adequadamente, chamado de NoRel ou algo parecido, devido seu afastamento do modelo relacional. Porm, importante ressaltar que o termo NoSQL no significa no ao SQL, mais sim no somente ao SQL (Not only SQL), como props Strozzi [7]. Contudo, entende-se que esse movimento no significa uma nova tecnologia ou padro de armazenamento de dados, consiste, basicamente, em uma escola de pensamento, uma nova forma de enxergar o armazenamento de dados e que, alm disso, no pretende desclassificar o modelo relacional, pelo contrrio, apresenta-se como uma opo racional aquele modelo e que sero as caracterscas, requisitos e arquitetura das aplicaes que definiro a melhor opo de armazenamento, podendo, inclusive coexistir os dois mundos em um mesmo sistema [9] [10]. Nesse sentido, ser explorado nas prximas sees as caracterscas das principais solues NoSQL, bem como um estudo comparativo entre essas solues na tica da seguinte taxinomia: modelo de dados alternativos ao relacional, arquitetura, performance, configurao, documentao, licena, classificao segundo teorema CAP (CP, CA, AP) e aplicaes prticas.

Ou seja, sistemas basicamente disponveis e eventualmente consistentes. Fora isso, solues que adotam essa idia, como mostra a Tabela 1, so, em comparao com as que implementam ACID, mais simples e evoluem (escalam) facilmente, pois no possuem um esquema rgido com restries de integridade de entidade e de integridade referencial, como presente no modelo ACID [6]. Percebe-se, ento, que o particionamento de dados uma caracteristica bem vinda a um sistema que necessita escalar e, portanto, sistemas tolerantes ao particionamento devem sacrificar a consistncia forte ou a alta disponibilidade para garantir escalabilidade, respeitando o teorema CAP. nessa atmosfera que se enquandram as solues NoSQL, que diferentemente dos RDBMS's no possuem essa caracteristica no seu design ou deixa isso a cargo do sistema de arquivo. ACID Consistncia Forte BASE Consistncia Fraca

Isolamento (Transaes no se Disponibilidade em primeiro enxergam) lugar Foco no Commit Baixa disponibilidade Conservador (persimista) Dificuldade de evoluir (esquema rgido e normalizado) Poltica do melhor esforo Simples e mais rpido Agressivo (otimista) Fcil evoluo

Tabela 1. Quadro comparativo entre sistemas ACID e BASE. Retirado e adaptado da apresentao de Eric Brewer no Simpsio PODC.

5.

MOVIMENTO NO-SQL

Como j foi discutido, as aplicaes web cada vez mais lidam com excessiva quantidade de requisies e grandes volumes de dados e exigem, ainda, um baixo tempo de resposta. Por conta disso, o mecanismos de armazenamento de dados tornou-se um ponto crtico na manutenao da performance dos sistemas como um todo. Nesse contexto, vrias solues open source de armazenamento de dados no-relacionais comearam a surgir e/ou ganhar fora, tendo em vista as dificuldades dos sistemas de banco de dados relacional escalarem.

5.1.

Modelos de Dados

O modelo de dados relacional organiza o banco de dados como um conjunto de relaes (tabelas), na qual cada tupla (linha) representa uma coleo de valores (colunas) de dados relacionados, correspondendo a uma entidade ou a um relacionamento do mundo real. Essas colees so organizadas, juntamente com as respectivas restries do modelo (Integridade de Entidade, Integridade Referencial e Chaves Estrangeiras), em estruturas conhecidas como esquemas de banco de dados (databases schemas). Outro tipo importante de restries so as

dependncias de dados (funcionais e multivaloradas), que medem a maturidade de um projeto de banco de dados relacional atravs da normalizao de relaes[3]. Por outro lado, os modelos de dados no-relacionais possuem um esquema mais leve e desnormalizado e, em muitos casos, outros tipos de representao de dados, como JSON, YAML e XML, so utilizados para persistir entidades do mundo real. Atualmente, as principais ferramentas NoSQL utilizam um dos quatros modelos de dados alternativos ao relacional descritos a seguir, porm existem outras solues que implementam alguma outra representao ou, ainda, mesclam mais de uma tipo[10].

Todos esses formatos, embora organizados de formas diferentes, compe uma estrutura de dados constituda de uma quantidade varivel de atributos de diferentes tipos de dados, podendo, inclusive, conter outros documentos (subdocumentos). Isso permite que esses bancos armazenem qualquer documento, sem necessidade prvia da definio de sua estrutura, sendo considerados, portanto, livres de esquema ( schema-free) [22]. Observa-se, tambm nesse caso, a desnormalizao do esquema, tendo em vista que todas as dependncias ou relaes de uma entidade so armazenadas no mesmo documento, como pode ser observado na Listagem 2. Essa caracterstica favorece o particionamento de dados e, consequentemente, a escalabilidade [22].

5.1.1. Key-Value Store (Chave-Valor)

O modelo de dados key-value o mais simples utilizado pelos bancos de dados NoSQL; no por conta da sua implementao, que pode ser um tanto complexa, mas devido a simples API de programao que esse modelo expe aos usurios. A maioria das solues que utilizam esse conceito, disponibiliza alguma variao da interface mostrada na Listagem 1.

{ "Aluno" : [ { "nome": "Euclydes", "notas": [ 8, 9, 7 ] } ] }

void put(String key, byte[] value); byte[] get(String key); void remove(String key);

Listagem 2. Exemplo de um Documento no formato JSON, que possui um atributo multivalorado, notas.

5.1.3. Column Colunas)

Listagem 1. Exemplo de Interface utilizada pela maioria das solues que usa Key-Value como modelo de dados. Observa-se que esse modelo armazena os dados por chave e que esses dados ( value) constituem um array de byte (blob 2), permitindo, assim, que qualquer estrutura de dados seja armazenada nesse campo. No se tem, portanto, um esquema de armazenamento de dados definido e toda semntica dos dados dada ou conhecida pela aplicao. Isso torna muito simples trabalhar com esse tipo de armazenamento, alm de favorecer a escalabilidade [20]. Outro aspecto importante nesse mtodo a impossibilidade de efetuar pesquisas, exceto pela chave. Isso implica diretamente na performance das consultas, devido a possibilidade de otimizar o padro de acesso s chaves [20]. Amazenamento por Key-value funciona muito bem quando se precisa acessar os dados pela chave. Isso parece limitado, porm acesso baseado em chaves mais comum do que se pensa. Por exemplo, recuperar sees e perfis de usurios, carrinho de compras em lojas virtuas, lookup de recursos diversos dentre outros. Um case de sucesso desse modelo o carrinho de compras da Amazon que utiliza o banco DynamoDB que keyvalue store [21].

Family

Database

(Famlia

de

Pode-se dizer que o modelo que mais se assemelha ao relacional, por conta da organizao de suas estruturas, mas conceitualmente eles so bem diferentes, por exemplo, esse modelo realiza o armazenamento de dados baseado em colunas (column-based store), enquanto o modelo relacional, sem variao, utiliza armazenamento baseado em linhas ( row-based store) [23]. Alguns conceitos so necessrios ao entendimento desse modelo, como: Keyspaces, Column Family (Famlia de Colunas), Columns (Colunas) e Super Columns (Super Colunas) [23]. Keyspace uma estrutura lgica que organiza as famlias de colunas; assemelha-se as tablespaces presentes em alguns RDBMS e, em geral ,tem-se apenas um por aplicao [23]. Column Family a forma como os dados so armazenados no disco (ou memria), agrupando as colunas ou super colunas em listas ordenadas, identificadas por uma chave nica e referenciadas pelo seu nome. So estruturas semelhantes s tabelas dos bancos de dados relacionais, porm possui caractersticas peculiares, como quantidades variveis de colunas por linha e o versionamento de colunas. a nica estrutura que precisa ser definida antecipadamente, no entando, ao contrrio de uma tabela, a nica coisa que deve-se definir o seu nome e as opes de classificao pela chave, portanto, tambm, no possui um esquema definido [23]. A Coluna o componente mais granular desse modelo, composta por nome, valor e timestamp. O nome o rtulo da coluna, o valor o dado arzamenado e o timestamp o elemento que permite o versionamento da coluna, como citado a cima. As colunas podem, em algumas solues, conter outras colunas, classificando-se, neste caso, como uma super coluna [23].

5.1.2. Document Databases (Documento)

A idia central dos bancos de dados orientados a documentos a prpria noo de documento. Embora cada implementao desse tipo de banco difere nos detalhes dessa definio, em geral, todos eles assumem encapsulamento e codificao de dados em algum formato padro de serializao de dados. Por exemplo, XML, JSON, YAML e outros [22].
________________________________________

Blob (Binary Large OBject) uma estrutura de dados contendo informaes binrios de qualquer formato, podendo ser um imagem, vdeo, audio etc.
2

5.1.4. Graph Databases (Grfico)

Grfico, nesse contexto, uma estrutura de dados composta por uma coleo de vrtices conectados por um conjunto de arestas. Os vrtices ou ns onde os dados so registrados, atravs dos valores de suas propriedades. O grfico mais simples possvel constitudo de um nico n e este, por sua vez, pode conter uma ou mais propriedades. Em algum momento, faz sentido quebrar um n distribundo suas propriedades em vrios ns, interligados por relaes explcitas. Essas relaes ou relacionamentos representam as arestas do grfico e so responsveis por organizar os ns em estruturas arbitrrias, como uma lista, uma rvore, um mapa ou uma entidade composta, podendo ser combinada com algo mais complexo, constituindo uma estrutura ricamente interconectada [24]. Uma caracterstica interessante desse modelo o mtodo de explorao dos grficos, conhecido como traversal (ou traverse). Essa tcnica aplica algum algoritmo de navegao entre os relacionamentos na tentativa de identificar caminhos e classificaes lgicas entre os ns, perminto encontrar informaes ocultas como, produtos mais relevantes em uma loja virtual, sugesto de pessoas prximas a voc em uma rede social dentre outras [25].

solues tentam otimizar essa escalabilidade permitindo que novos ns sejam adicionados ao cluster de forma otimizada e transparente, sem a necessidade, por exemplo, de reiniciar o cluster. essa capacidade dar-se o nome de elasticidade e, dependendo das caractersticas do sistema, pode ser desejvel ou desnecessria [12] [26].

5.2.3. Mecanismo de Persistncia

Basicamente, existem duas formas de persistncia: o disco e a memria. O primeiro tem a vatagem de ser duradouro e a desvatagem de ser mais lento, o segundo apesar de ser voltio extremamente rpido, o que o torna uma excelente opo em sistemas que exigem baixa latncia. A questo da volatilidade ou perda de dados em caso de falhas no sistema contornvel com replicao, que em memria mais rpida que em disco, e com a confiabilidade que o hardware de datacenters modernos oferece atulamente, como pode ser observado no monitoramento feito pela empresa Pingdom3, no qual o Twitter teve uma disponibilidade de 99,72% em 2010 e de, aproximadamente, 99,66% em 2011. Portanto, a possibilidade de adotar uma soluo de banco de dados que persista os dados em memria deve ser ponderado caso a necessidade do sistema exiga baixo tempo de resposta, pois como bem observou Jim Gray [11] : Memory is the new disk and disk is the new tape.

5.2.

Arquitetura

Como foi visto, para manipular grandes volumes de dados as solues NoSQL precisaram abrir mo da normalizao e trabalhar com dados semi ou no estruturados. Alm dessa, outras propriedades so inerentes s solues que priorizam alta disponibilidade e baixa latncia. Em geral, as solues NoSQL implementam ou tentam tornar mais simples algumas caractersticas que os banco de dados relacionais, por conta de seu design, no disponibilizam ou muito complexo configurar e mater, como distribuio de dados e elasticidade do cluster, por outro lado, existem outros aspectos que tambm os diferenciam, mas que no implicam no throughput dos dados, como a API de consulta.

5.2.4. API de Cosulta

As solues NoSQL, atualmente, no possuem nenhuma interface de consulta a dados padronizada. Cada soluo possui sua prpria forma de gravar e consultar os dados, inclusive a maioria das solues permite apenas recuperar o registro pelo seu identificador (ID), uma espcie de chave primria, fazendo aluso aos bancos relacionais, ou atravs de composio de campos pr-estabelecida. Outras solues, porm, disponilizam um conjunto de operadores e opes que possibilitam certa flexibilidade nas consultas, como o caso do MongoDB, mas nada comparado com a DML (Data Manipulation Language ) do SQL [10] [16].

5.2.1. Distribuio e Replicao de Dados

A desnormalizao dos dados facilita sua distribuio, pois permite mais facilmente o particionamento das tabelas do banco e armazenamento dessas parties em servidores distintos do cluster, sem se preocupar com quebras de relacionamento entre as entidades, tendo em vista que, dependendo do modelo de dados usado, uma informao pode ser gravada com todas suas dependncias em um nico registro, como o caso dos Documents Databases [6]. Outro aspecto importante que deve ser considerado a replicao de dados, que tambm objeto de investimento dos banco de dados NoSQL, pois ajuda a garantir disponibilidade dos dados. Agora, os detalhes de como as ferramentas implementam ou se comportam com essas propriedades devem ser bem conhecidos pelos projetistas ou arquitetos de software quando da adoo de uma ou outra soluo, para eleger a que melhor se adeque s suas realidades. O fato que os bancos NoSQL tentam minimizar a complexidade de distribuir e replicar dados, nascendo distribudos e no os tornando depois de adultos [6].

6. YAHOO! CLOUD BENCHMARK (YCSB)

SERVING

importante observar que as solues NoSQL foram surgindo, em geral, para atender demandas especficas de empresas, como Google, Facebook, Twiter, LinkedIn, Amazon, Yahoo e outras, que precisavam tratar um enorme volume de requisies e tinham o armazenamento de dados como principal gargalo nesse processo. Assim, as solues foram sendo concebidas de acordo com suas necessidades de negcio, inexistindo, dessa forma, qualquer padronizao e/ou conveo no desenvolvimento dessas ferramentas. Essa falta de padronizao, em especial no modelo de dados, na interface ou linguagem de manipulao de dados e na forma de distribuir os dados e escalar o cluster, dificulta qualquer iniciativa de comparao entre os banco de dados NoSQL. Foi baseado nessa dificuldade e na miscelnea de solues NoSQL, que um grupo de pesquisadores do Yahoo! Research desenvolveu um framework chamado Yahoo! Cold Serving Benchmark (YCSB) [12][13], que auxilia na avaliao de desempenho entre esses bancos. Esse framework expe uma interface (classe abstrata) para realizao de um CRUD (create, read, update, delete), como

5.2.2. Elasticidade do Cluster

Um objetivo subjacente dos banco de dados NoSQL facilitar a escalabilidade horizontal de sistemas de informao. Algumas
________________________________________

Pingdom uma empresa que monitora gratuitamente o uptime, downtime e o desempenho de sites, redes e servidores, semelhante ao Google Analytics.
3

mostra a Listagem 3, que deve ter uma implementao para cada banco que se deseja comparar. A carga de trabalho ( workload), a qual cada banco ser submetido, deve ser definida em arquivos de propriedades. Dentre outros parmetros, pode-se definir nesse arquivo: a quantidade de operaes (leitura e/ou escrita) que sero realizadas no benchmarking, a quantidade de operaes por segundo que o banco deve processar ( throughput) e a proporo de operaes de leitura e escrita que ser considerada na comparao. int read( String table, String key, Set<String > fields, HashMap <String ,ByteIterator> result); int scan( String table, String startkey, int recordcount, Set <String > fields, Vector <HashMap <String ,ByteIterator>> result); int update( String table, String key, HashMap <String ,ByteIterator> values); int insert( String table, String key, HashMap <String ,ByteIterator> values); int delete( String table, String key);

Em relao a frao 8:2 (80% de escrita e 20% de leitura), salutar destacar que ela foi utilizada por ser considerada uma proporo real existente entre operaes de leitura e escrita em sistemas corporativos, permitindo, portando, que os resultados dessa anlise possam ser considerados em ambientes com comportamentos semelhantes a este. Nesses dois momentos, foram medidos o throghput de operaes em relao a latncia, o consumo de memria utilizado pelos processos dos bancos de dados quando da realizao das workloas, bem como o uso de CPU. AMD Phenom(tm) II X2 B53 Processor / 64bits 2800MHz 256KB / 1GHz 1MB / 1GHz 6MB / 1GHz DIMM DDR3 Synchronous 8GB / 1333MHz ATA Disk ST3500418AS Seagate - 1TB Ubuntu 11.04 Natty x86_64 GNU/Linux NetXtreme BCM5761 Gigabit Ethernet PCIe - 1Gbits/s

CPU Clock Chace L1 Cache L2 Cache L3 RAM

Hard Disk SO Ethernet interface

Listagem 3. Interface DB ( DataBase) do YCSB. Atualmente, essa ferramenta permite a realizao de estudos comparativos apoiados em dois critrios: performance, que mede a latncia (tempo de resposta) das requisies quando o banco de dados est sobrecarrregado, e escalabilidade, que mede o desempenho do banco quando o cluster aumentado e quo transparente esse incremento (elasticidade).

Tabela 2. Configurao da Mquina usado no benchmarking.

7.

METODOLOGIA

field0 = [#3<.:><!%(2("<*1*,69(1#&/%&<*#?/+ >+>,8='* %0,07!;04&,'?/(?8.7&?*6328***$59$41&/. 9?&:?"4<2%=#!,:/<] field1 = [)4)0.4 72#>(0#.!'036## (%.=&?,"092?32 .'%,544%<0?9-4'=#+ (8:,=8?&)4"9&>2=/?-*/>(>+,(<(;?=,8&$3&04" :] field2 = [ /?%;)).793&#75< (3$539!+"&&;9!;<-/4<.#3#8/(#)222#$#3>:7>>(*>9."=.-:8?7*:/!483>8&,685:812$<+3#6+8%(] field9 = [ /?%;)).793&#75< (3$539!+"&&;9!;<-/4<.#3#8/(#)222#$#3>:7>>(*>9."=.-:8?7*:/!483>8&,685:812$<+3#6+8%(]

Neste tabalho foi avaliado a performance dos bancos de dados NoSQL MongoDB, Apache Cassandra, Redis e Voldemort, configurados em um nico servidor ( standalone), no em cluster. Segue, na Tabela 2, a configurao da mquina utilizada nesse experimento. A anlise foi divida em duas etapas ( workload's). Na primeira, efetuou-se a carga do banco, na qual 1 milho de registro de 1KB cada foi inserido no banco de dados, exigido dele 5000 insert's por segundo. Na segunda, o banco foi submetido a uma carga de, tambm, 1 milho de operaes a 5000 por segundo, porm distribudas em 80% de leitura e 20% de escrita ( update) workload 8:2. Cabe ressaltar que os insert's no foram em batch (quando se abre uma transao no incio da operao e confirma no final), mas sim, 5000 operaes de escrita isoladas e paralelas, simulando 5000 usurios gravando algo de 1KB no banco. Esse registro de 1 KB constitudo de 10 campos de 100 bytes cada, como mostra a Listagem 4.

Listagem 4. Exemplo de um registro utilizado na carga do banco de dados. Para catalogar a utilizao de memria e CPU pelos processos, foi utilizado os binrios top e free da distribuio Linux usada neste estudo e realizada uma mdia aritimtica do percentual total de utilizao de cada um desses recursos por cada um dos bancos, porm, para atribuio da nota de desempenho, foi considerado o percentual inverso do consumo desses recursos,

tendo em vista que uma alta utilizao deles pode ser crtico caso a carga do sistema aumente, ou seja, como um baixo consumo desejado, um banco que ocupou 75% do processador obteve um redimento de 2,5 (25%) nesse quesito. Para avaliar a performance de cada soluo foi registrado a quantidade de operaes ( throghput) que cada banco efetivava a cada 100ms. A latncia mxima ideal considerada neste estudo foi 100ms, justamente, o tempo em que foi realizada a primeira coleta do throghput. Os outros ponto de coleta ocorreram a cada 100ms, ou seja, de 0 a 100ms, de 100ms a 200ms, de 200ms a 300ms e assim por diante, at o o limite de 1000ms. Dessa forma, as operaes efetivadas em um tempo superor a 1000ms foram registradas nesta latncia (acima de 1000ms). Observou-se que a latncia mnima, mxima ou mdia no seriam bons parmetros para avaliar a performance, pois podiam indicar picos de processamento ou ter uma mdia corrompida por esses picos. O parmetro utilizado, ento, foi uma mdia ponderada entre os throghout's medidos, utilizando-se pesos para cada latncia, por exemplo: as operaes realizadas at 100ms receberam peso 10, at 200ms receberam peso 9, at 300ms receberam peso 8 e assim por diante, at chegar nas operaes que demoraram 1000ms ou mais, estas receberam peso 1. Nesse sentido, a frmula utilizada para identificar a performance de cada banco de dados avaliado foi:

banco de dados patrocinado pela VMWare, que em maro de 2010 contratou o italiano Salvatore Sanfilippo, idealizador desse projeto, para se dedicar no seu desenvolvimento e aprimoramento. Esse banco possui uma boa documentao e um dos mais difundidos bancos NoSQL atualmente [15].

8.4.

Cassandra

Cassandra um banco de dados no-relacional mantido pela fundao Apache, que organiza seus dados em famlias de colunas (Column Family Database) e foi desenvolvido em Java. Inicialmente, era um projeto do Facebook, desenvoldido por Avinash Lakshman, mas que em 2008 teve seu cdigo fonte liberado e no ano seguinte integrou o portflio de projetos da fundao Apache. Possui uma boa documentao e uma razovel adoo pela comunidade [17].

8.7.

Voldemort

Voldemort um sistema de armazenamento de dados distribudos, escrito em Java e baseado em chave-valor ( keyvalue). Dentre outras caractersticas, possui particionamento e replicao automtica de dados em diversos servidores e tratamento tranparente de falhas em um servidor. Um detalhe interesante desse banco que ele garante integridade dos dados, conseguida atravs do versionamento dos itens de dados. Ele usado no LinkedIn para certos problemas de escalabilidade de alto armazenamento no qual o particionamento funcional simples no suficiente. O prprio site oficial o considera, ainda, como um sistema novo, que tem arestas no aparadas, mensagens de erro falsas e, provavelmente, muitos erros no detectados. Possui um documentao boa e uma comunidade incipiente [18]. A seguir, na Tabela 3, encontra-se um quadro que resume as principais caractersticas de cada um desses bancos.

8.

SOBRE AS SOLUES TESTADAS

Foram submetidos a metodologia descrita anteriormente os seguintes bancos de dados NoSQL:

Modelo de Dados MongoDB Redis Cassandra Voldmort Document Key-value Column Family Key-value CP CP AP AP GNU AGPL v3.0 BSD Apache License 2 Apache License 2 10gen VMWare Apache Foundation LinkedIn CAP Licena Empresa

8.1.

MongoDB

Mongo DB um banco de dados NoSQL open source, escrito em C++, orientado documentos ( Documents Database) e inscrito sob a licena GNU AGPL v3.0. Ele se prope a ser escalvel e de alta performance, com capacidade de manipular grandes volumes de dados. Seu nome oriundo da palavra humongous, que significa muito grande, fazendo jus a seu propsito. Uma caracterstica peculiar desse banco a flexibilidade nas consulta. Diferentemente da maioria dos bancos NoSQL, ele possui vrios operadores binrios que permitem a realizao de consulta adhoc. Possui uma excelente documentao e participao da comunidade, inclusive permitindo que seja testado on-line, atravs de um shell script disponibilizado no site oficial [16].

8.2.

Redis

Redis uma soluo open source de armazenamento de dados baseado no modelo key-value. Ele escrito em C e est disponvel sob a licena BSD. Em prol de excelncia no desempenho, ele trabalha, principalmente, com persistncia de dados em memria, porm, dependendo da necessidade, ele fornece mecanismos para descarregar esses dados no disco em algum momento, bem como possibilidade de gravar todos os comando executados sobre a base em um log. Atualmente, esse

Tabela 3. Quadro sinttico das caractersticas das solues NoSQL avaliadas.

9.

RESULTADOS ENCONTRADOS

Na etapa de carga dos bancos, duas solues, Redis e Voldemort, se destacaram das demais, pois chegaram a gravar quase 100% dos registros (1 milho) em menos de 100ms, sendo que Voldemort ainda inseriu a mais que Redis quase 45 mil registros nessa mesma latncia. Cassandra, por sua vez, foi o banco que

menos operaes de insero efetivou nesse tempo de resposta, praticamente, a metada dos dois primeiros bancos, cerca 500 mil registros. J MongoDB ficou no meio desses extremos, conseguindo realizar com sucesso, aproximadamente, 75% das inseres nesse intervalo de tempo. O comportamento do nmero de operaes efetivadas em relao a latncia pode ser melhor observado analisando o grfico exibido na Figura 2. Aplicando-se a frmula definida na metodologia para avaliar a performance de cada banco, pode-se observar que Voldemort e Redis destacaram-se, nesse quesito, em relao as outras solues avaliadas, como mostra a Figura 3. Voldemort, em especial, demonstrou, em relao aos critrios usados na pesquisa, um excelente tempo de resposta, com redimento de quase 100%, como ja citado. Por outro lado, Voldemort juntamente com Cassandra foram os que mais exigiram do processador, este usufruiu de quase 90% do uso da CPU e aquele cerca do 80%. MongoDB, por sua vez, utilizou 50% da capacidade de processamento da mquina durante a realizao dessas operaes e Redis, pouco mais de 30%. O consumo de memria foi relativamente baixo e homognio. O banco que mais consumiu memria no usou 2MB (16%), como pode-se observar na Figura 4. Figura 4. Consumo mdio de Mmora e uso da CPU em % do total da memria principal (8GB) - Workload de Carga. Na segunda etapa desse estudo, os bancos foram submetidos a workload (8:2), na qual 80% das operaes eram de leitura e 20% de escrita. Em relao as operaes de escrita, todas as solues testadas apresentaram um desempenho bem prximo um dos outros. A discrepncia entre os bancos que tiveram a melhor (Voldemort) e a pior (Cassandra) performance foi de, somente, 150 mil operaes realizadas na latncia desejada por este estudo (100ms), como pode ser visualizado na Figura 5.

Figura 2. Throughput (operaes/segundos) das operaes de insero versus Latncia (ms) Workload de Carga. Figura 5. Throughput (operaes/segundos) das operaes de escrita versus Latncia (ms) - Workload 8:2. No tocante as operaes de leitura, j percebe-se uma diferena mais acentuada na performance. Mais uma vez Voldemort e Redis destacam-se dos demais, efetivando quando 100% das operaes em menos de 100ms, mais especificamente, este atingiu 97% e aquele 99%, porm, agora, MongoDB aproximouse, conseguindo dar vazo a cerca de 93% das requisies na mesma latncia. Cassandra no teve uma performance muito eficiente se comparado com os demais bancos, pois conseguiu, nesse tempo de resposta, processar, apenas, 62% das operaes de leitura, como mostra a Figura 6. Figura 3. Perfamace ponderada dos bancos de dados em relao o throghput e a latncia Worload de Carga.

A Tabela 4, contm um quandro comparativo que resume os resultados encontrados.

Figura 6. Throughput (operaes/segundos) das operaes de leitura versus Latncia (ms) - Workload 8:2. Com as devidas ponderaes aplicadas sobre o throghput alcanado em cada medio de latncia, pode-se aferir, conforme grfico da Figura 7, que Voldemort conseguiu dar maior vazo as requisies nesta workload (8:2), seguido do Redis, MongoDB e um pouco mais afastado, Apache Cassandra. Porm, interessante d relevo ao fato de que as diferenas so bem prximas, pois este ltimo teve uma performance circulando em torno de 9,6 e 9,7; MongoDB entre 9,8 e 9,9; e Redis e Voldemort orbitaram entre uma performance de nota 9,9 e 10. Mas de qualquer forma, em sistemas que exigem baixa latncia, as disparidades apesar de, as vezes, serem mnimas devem ser consideradas, pois essa diferena evidenciada medida que a sobrecarga do sistema aumenta. Figura 7. Consumo mdio de Mmora e uso da CPU em % do total da memria principal (8GB) - Workload 8:2.

performance Carga Redis MongoDB Cassandra Voldemort 9,901887 9,284453 9,119946 9,979221 8:2 9,940514 9,878387 9,66583 9,989142

Uso de CPU Carga 6,731169 4,912857 1,237143 1,955556 8:2 6,757303 6,797101 0,295070 0,964765

Consumo de Memria Carga 8,365 9,196 8:2 6,825056 8,393044

8,745643 8,165986 8,892593 7,892593

Tabela 4. Quadro comparativo entre as solues NoSQL avaliadas.

10.

CONCLUSO

Figura 7. Perfamace ponderada dos bancos de dados em relao o throghput e a latncia Workload 8:2. Em relao ao cunsumo de memria e processador, nessa segunda etapa do benchmarking , fora o MongoDB que teve uma diminuio em torno de 20% do uso da CPU em relao primeira etapa dos testes (carga) e o Redis que se manteve com o mesmo percentual de utilizao do processador, os outros dois bancos, Voldemort e Cassandra, tiveram um incremento em torno de 10% na ocupao da CPU, como pode ser visto na Figura 7. O uso de memria, como na primeira etapa, foi bem tranquilo, apesar de ter dobrado essa utilizao por todos os bancos, exceto Cassadra que aumentou seu uso em torno de 6%, mas ainda sim, continua sendo uma ocupao bem razovel, se no suscinta.

Neste trabalho foi realizado um estudo comparativo entre algumas das mais populares solues NoSQL, explorando, principalmente, a performance de cada banco quando submetido a uma carga expressiva de requisies. Foi avaliado o throghput de operaes e o comportamento da latncia em relao a quantidade de operaes solicitadas. Alm disso, mediu-se, tambm, o consumo de memria e uso do processador durante os testes aos quais os bancos foram submetidos. Observou-se que, de certa forma, todas as solues avalidas tiveram uma performance interessante, porm duas delas, Redis e MongoDB, se destacaram por, em ambos os testes, apresentarem um tempo de resposta razovel medida que as requisies iam sendo disparadas, somado com um uso de CPU muito baixo, se comparado com Cassandra e Voldemort, essas solues, sem dvida, no ambiemte proposto, se comportaram mais adequadamente. Voldemort apesar de ter sido muito eficiente no processamento das requisies, exigiu muito do processamento, o que pode ser crtico, caso a carga aumente muito. O mesmo acontecou com Cassandra, porm este, ainda, apresentou uma performance inferior.

Sobretudo cabe ressaltar que esses testes foram realizados utilizando uma carga de trabalho especfica em um comportamento peculiar de aplicaes corporativas, portando, em outros ambientes, com outras necessidades de negcio devem ser considerados outros workload's para encontrar a soluo que melhor se adeque a realidade proposta. Alm disso, outros aspectos devem ser ponderados, como arquitetura da soluo e modelo de dados, este ltimo, em especial, deve ser cuidadosamente analisado, pois dependendo da natureza do sistema um ou outro modelo pode aderir melhor ao domnio da aplicao.

[6] Pritchett, Dan. BASE: An Acid Alternative. May 1, 2008. http://portal.acm.org/ft_gateway.cfm? id=1394128&type=pdf. Acessado em 29/02/2012 s 19:30. [7] Strozzi, Carlo. NoSQL: A Relational Database Management System. http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/. Acessado em 29/02/2012 s 09:10. [8] Oskarsson, Johan. NoSQL debrief. San Francisco, June 2009. http://blog.oskarsson.nu/2009/06/nosql-debrief.html. Acessado em 01/03/2012 s 14:45. [9] Evans, Eric. NoSQL: What's in a name? http://blog.symlink.com/2009/10/30/nosql_whats_in_a_name.html. Acessado em 01/03/2012 s 20:40. [10] http://nosql-database.org/. 16:10. Acessado em 06/03/2012 s Acessado Acessado em em

11.

TRABALHOS FUTUROS

Foi explorado neste trabalho a performance de sistemas de armazenamento em cloud, levando em considerao throughput , latncia, consumo de memria e CPU. Porm, outro ponto muito importante que deve ser ponderado quando da adoo de alguma soluo NoSQL a escalabilidade e elasticidade do sistema. Precisa-se compreender como essas ferramentas fornecem essas propriedades e at que nvel elas so interessantes em relao ao custo operacional. Para realizar esse estudo, mais um vez o framework YCSB pode ser til, tendo em vista que ele possui uma camada especfica para realizao de teste de escalabilidade em sistemas cloud store. Outro trabalho interessante nesse cenrios , identificado o banco NoSQL que melhor se adeque a um propsito especfico, implementar um fornecedor JPA (Java Persistence API) [19] que disponibilize as funcionalidades desse banco atravs das interfaces do JPA ou testar framework's prontos nesse sentido, como o caso do Hibernate OGM (Object/Grid Mapper) [14].

[11] http://dl.acm.org/citation.cfm?id=864078. 23/04/2012 s 23:19. [12] http://dl.acm.org/citation.cfm?id=1807152. 14/03/2012 s 21:45.

[13] http://research.yahoo.com/Web_Information_Management/Y CSB. Acessado em 14/03/2012 s 21:40. [14] http://www.hibernate.org/subprojects/ogm.html. em 23/04/2012 s 02:35. [15] http://redis.io/. Acesso em 22/04/2012 s 23:10. [16] http://www.mongodb.org/. Acessado em 23/04/2012 s 23:45. [17] http://cassandra.apache.org/. Acessado em 24/04/2012 s 00:10. [18] http://project-voldemort.com/. Acessado em 24/04/2012 s 00:45. [19] http://jcp.org/aboutJava/communityprocess/final/jsr317/inde x.html. Acessado em 24/04/2012 s 02:38. Acessado

12.

REFERNCIAS

[20] http://dl.acm.org/citation.cfm?id=1993843. 26/05/2012 s 09:30. [21] http://dl.acm.org/citation.cfm?id=1294281. 26/05/2012 s 10:15. [22] http://dl.acm.org/citation.cfm?id=62528. 26/05/2012 s 11:30. [23] http://dl.acm.org/citation.cfm?id=2095583. 26/05/2012 s 13:150. [24] http://dl.acm.org/citation.cfm?id=1322433. 26/05/2012 s 14:00. [25] http://dl.acm.org/citation.cfm?id=2206879. 26/05/2012 s 15:30. [26] http://dl.acm.org/citation.cfm?id=2063973. 27/05/2012 s 09:40.

Acessado Acessado Acessado Acessado Acessado Acessado Acessado

em em em em em em em

[1] http://www.ibm.com/developerworks/xml/library/xmatters8/index.html. Acessado em 26/02/2012 s 11:42. [2] Ted Cood, Edgar Frank. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 1970. http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf. Acessado em 27/02/2012 s 07:50. [3] Elmasri, Ramez e Navathe, Shamkant B. Sistemas de Banco de Dados. Pearson Addison Wesley, 4 Edio, So Paulo, 2005. [4] Andr B. Bondi, Characteristics of scalability and their impact on performance, Proceedings of the 2nd international workshop on Software and performance, Ottawa, Ontario, Canada, 2000. http://dl.acm.org/citation.cfm?id=350391.350432. Acessado em 29/02/2012 s 11:00. [5] Brewer, Eric. Towards Robust Distributed Systems. Principles of Distributed Computing (PODC). Portland, OR. July 2000. http://www.cs.berkeley.edu/~brewer/cs262b2004/PODC-keynote.pdf. Acesso em 29/02/2012 s 16:40.