Bancos de Dados NoSQL x SGBDs Relacionais:Anlise Comparativa*

Ricardo W. Brito, Faculdade Farias Brito e Universidade de Fortaleza, ricardow@ffb.edu.br

bsica da normalizao consiste na separao dos dados referentes a elementos distintos em tabelas distintas, associadas atravs da utilizao das chaves. Adicionalmente, o modelo relacional passou a adotar como linguagem de definio, manipulao e consulta de dados a SQL (Structured Query Language). Desenvolvida originalmente pela IBM, o SQL uma linguagem declarativa de para banco de dados relacional inspirada na lgebra relacional. Sua simplicidade e alto poder de expresso fizeram do SQL a linguagem de consulta de dados mais utilizada no mundo e ajudou a consolidar a posio dominando do modelo relacional.

ResumoO Modelo Relacional tem sido amplamente utilizado em praticamente todos os tipos de sistemas de bancos de dados nas ltimas dcadas. Porm, com o crescimento cada vez mais intenso do volume de dados de certas organizaes, certos fatores limitantes tm propiciado que modelos alternativos de banco de dados sejam utilizados em tais cenrios. Motivados principalmente pela questo da escalabilidade do sistema, uma nova gerao de bancos de dados conhecidos como NoSQL vem ganhando fora e espao tanto na academia quanto no mercado. Neste artigo, so apresentadas as principais caractersticas desses bancos de dados e se discute de que forma essas novas solues podem abordar certas questes atualmente enfrentadas. Index Terms Banco de Dados, Modelo Relacional, NoSQl, Escalabilidade, Disponibilidade, Performance.

II. SGBDS RELACIONAIS Os SGBDs relacionais oferecem aos usurios processos de validao, verificao e garantias de integridade dos dados, controle de concorrncia, recuperao de falhas, segurana, controle de transaes, otimizao de consultas, dentre outros. A utilizao de tais recursos facilitou a vida dos desenvolvedores de aplicaes, possibilitando que estes pudessem se preocupar exclusivamente com o foco da aplicao. Como um dos conceitos mais bsicos do modelo relacional, as chaves representam uma forma simples e eficaz de associao entre as tabelas do banco de dados. A chave primria foi criada com o objetivo de identificar de forma nica as tuplas da tabela e ainda de determinar a ordem fsica dessas tuplas. A chave estrangeira permite uma relao de dependncia entre atributos de tabelas distintas, de forma que os valores permitidos em um atributo dependam dos valores existentes em outro atributo. Tais recursos so amplamente utilizados em bancos de dados relacionais e servem como base para a utilizao de outros componentes, como o caso dos ndices. Estes elementos tornaram-se padro para todo tipo de tabela por propiciarem um significativo ganho de performance no processamento de consultas. Alm desses componentes, os SGDBs Relacionais possibilitam que mltiplos usurios possam acessar e manipular um mesmo banco de dados simultaneamente de forma eficiente, recurso indispensvel para sistemas de grande porte.

I. INTRODUO
ESDE sua criao no incio dos anos 1970, o Modelo Relacional de dados tem sido utilizado em larga escala pela grande maioria dos sistemas de gerenciamento de banco de dados. Tendo surgido como sucessor dos modelos hierrquico e de rede, o modelo relacional tornou-se padro para a grande maioria dos SGBDs (Sistemas Gerenciadores de Banco de Dados), tais como o SQL Server, Oracle, PostgreSQL, MySQL, etc. Seus elementos bsicos so as relaes (ou tabelas), as quais so compostas de linhas (ou tuplas) e colunas (ou atributos). Os dados esto estruturados conforme esse modelo [5]. Outra caracterstica fundamental desse modelo a utilizao de restries de integridade. Esses elementos so utilizados para garantir que a integridade dos dados seja mantida. As restries de integridade mais comuns so as chaves, mais especificamente, as chaves primrias e as chaves estrangeiras. A chave primria tem o objetivo de assegurar a identificao nica das tuplas das tabelas. A chave estrangeira torna os valores de determinado atributo dependentes dos valores existentes em outro atributo, normalmente de outra tabela. Outra caracterstica importante do Modelo Relacional o processo de Normalizao. Seu objetivo a aplicao de certas regras sobre as tabelas do banco de dados, de forma a garantir o projeto adequado dessas tabelas. Uma caracterstica

* Este trabalho teve o apoio do CNPq-RHAE e da UNUM.

2 Outra caracterstica importante dos SGDBs relacionais consiste na possibilidade do sistema se recuperar de forma adequada de possveis falhas. O sistema tem a capacidade de retornar ao ponto anterior falha ocorrida, garantindo que o banco permanecer em um estado consistente. Todos esses recursos ajudaram a manter os SGDBs Relacionais em posio de destaque entre os mais diversos tipos de ambientes computacionais, mas no impediram o surgimento de certos problemas, principalmente devido ao crescimento vertiginoso do volume de dados presentes nos bancos de certas organizaes. at ento passou a ser um problema a ser contornado e as solues propostas tinham como base a eliminao ou minimizao dessa estruturao. O objetivo dos projetistas de banco de dados de organizaes de grande porte passou a ser desenvolver uma nova estratgia de armazenamento na qual pudessem estar livres de certas estruturas e regras presentes no Modelo Relacional. Assim, foram surgindo solues que pareciam voltar no tempo, retornando ao simples sistemas de gerenciamento de arquivos. Se, por um lado, tais solues perdiam todo o arcabouo de regras de consistncia presentes no Modelo Relacional, por outro lado, poderiam ganhar em performance, flexibilizando os sistemas de banco de dados para as caractersticas particulares de cada organizao. O termo NoSQL surgiu em 1998, a partir de uma soluo de banco de dados que no oferecia uma interface SQL, mas esse sistema ainda era baseado na arquitetura relacional [14]. Posteriormente, o termo passou a representar solues que promoviam uma alternativa ao Modelo Relacional, tornandose uma abreviao de Not Only SQL (no apenas SQL), sendo utilizado principalmente em casos em que o Modelo Relacional no apresentava performance adequada. O propsito, portanto, das solues NoSQL no substituir o Modelo Relacional como um todo, mas apenas em casos nos quais seja necessria uma maior flexibilidade da estruturao do banco. Em portugus j existe o acrnimo MRNN para Modelo Relacional No-Normalizado. Uma das primeiras implementaes de um sistema realmente no-relacional surgiu em 2004 quando o Google lanou o BigTable, um banco de dados proprietrio de alta performance que tinha como objetivo promover maior escalabilidade e disponibilidade. A idia central era justamente flexibilizar a forte estruturao utilizada pelo Modelo Relacional [4]. Outra implementao foi realizada em 2007, pela Amazon, com a apresentao do sistema Dynamo, o qual tinha como caracterstica bsica ser um banco de dados no-relacional, de alta disponibilidade, utilizado pelos web services da Amazon [6]. Em 2008, iniciou-se outro importante projeto. O Cassandra foi projetado para ser um sistema de banco de dados distribudo e de alta disponibilidade, desenvolvido pelo site Facebook para lidar com grandes volumes de dados [7]. No incio de 2010, o Cassandra desbancou o MySQL como banco de dados do Twitter, demonstrando sua importncia cada vez mais crescente [17]. Na mesma poca, comeou o desenvolvimento do Apache CouchDB, um banco de dados livre e orientado a documentos, os quais armazenam os dados sem a necessidade de qualquer esquema pr-definido, e que utiliza o conceito de arquitetura MapReduce, especialmente projetada para suportar computao distribuda em larga escala [1], [3], [9]. Outro soluo emergente, lanada em 2009, foi o MongoDB, um banco de dados orientado a documentos,

III. LIMITAES Devido ao intenso crescimento do nmero de aplicaes, solues, recursos e tudo o que se refere a sistemas computacionais nas ltimas dcadas, o volume de dados associados a tais tipos de sistemas tambm teve um ritmo de crescimento acelerado. Atualmente, o volume de dados de determinadas organizaes, como o caso do Google, atinge o nvel de petabytes, o que corresponde a 1015 bytes. Em cenrios nos quais o gerenciamento de grande volume de dados tem se mostrado problemtico, a utilizao de SGBDs relacionais, ou em outras palavras do prprio Modelo Relacional, j no se mostra to eficiente. De um modo geral, os principais problemas encontrados com a utilizao do Modelo Relacional estavam concentrados na dificuldade em se conciliar tal modelo com a demanda por escalabilidade cada vez mais frequente. Como exemplo, tomemos uma determinada aplicao web sendo executada sobre um SGBD relacional. Com o crescimento do nmero de usurios, o sistema comea a ter uma queda de performance. Para superar esse problema, restam duas alternativas promover um upgrade no servidor ou aumentar o nmero de servidores. Tais opes no seriam suficientes se o nmero de usurios continuar a crescer em ritmo intenso porque o problema passa a se concentrar no prprio acesso base de dados. A soluo, portanto, passa a ser escalar o banco de dados, distribuindo-o em vrias mquinas. Tal abordagem possvel em um SGBD relacional, porm, no realizada de maneira to simples. Devido a sua natureza estruturada, os desenvolvedores comearam a perceber a dificuldade em se organizar os dados do Modelo Relacional em um sistema distribudo trabalhando com particionamento de dados [8]. justamente nesse ponto em que o foco das solues no-relacionais esto concentradas.

IV. BANCOS DE DADOS NOSQL As mudanas ocorridas na tentativa de se propor alternativas ao uso do Modelo Relacional levaram os desenvolvedores a pensar em um modo alternativo de se modelar as bases de dados. A estrutura pouco flexvel utilizada

3 escalvel, de alta performance e livre de esquemas, com vrias caractersticas semelhantes ao CouchDB [15]. Todas essas solues apresentam certas caractersticas em comum e outras particulares que os diferenciam. O captulo a seguir descreve e categoriza as principais caractersticas dos principais sistemas de banco de dados NoSQL. persistncias ocasionais; aqueles que mantm suas informaes em disco, como so os casos do CouchDb e do MongoDb; e aqueles configurveis, tais como BigTable e o Cassandra. A seguir, so confrontadas certas caractersticas entre os Sistemas Gerenciados de Bancos de Dados relacionais e as solues NoSQL.

V. CLASSIFICAO DE BANCOS DE DADOS NOSQL Apesar de possurem certas caractersticas em comum, tais como serem livres de esquema, promoverem alta disponibilidade e maior escalabilidade, os sistemas de bancos de dados NoSQL existentes possuem diversas singularidades. Quando distribuio de dados, certos sistemas promovem o particionamento e a replicao dos dados, enquanto outros deixam essa tarefa para o cliente. A maioria das solues distribuda, como caso do Amazon Dynamo, do CouchDB, do MongoDb, do BigTable e do Cassandra. Quando ao modelo de dados, existem quatro categorias bsicas: os sistemas baseados em armazenamento chave-valor, como o caso do Amazon Dynamo; os sistemas orientados a documentos, entre os quais temos o CouchDB e o MongoDB; os sistemas orientados a coluna, que tem como exemplos o Cassandra e o BigTable; e os sistemas baseados em grafos, como so os casos do Neo4j e do InfoGrid. Na primeira categoria, existe uma coleo de chaves nicas e de valores, os quais so associados com as chaves. No segundo grupo, os documentos so as unidades bsicas de armazenamento e estes no utilizam necessariamente qualquer tipo de estruturao pr-definida, como o caso das tabelas do Modelo Relacional. Um documento do CouchDB [1], [16], por exemplo, um objeto que possui um identificador nico e que consiste de certos campos. Esse documento segue o formato JSON (JavaScript Object Notation), padro que visa uma fcil legibilidade e independncia de linguagem [12]. No exemplo ilustrado na Figura 1, o documento possui cinco campos com seus respectivos valores. VI. SGBDS X NOSQL Quando se analisa a possibilidade de se optar por uma estratgia NoSQL em detrimento de um SGBD tradicional, preciso levar em considerao algumas questes bsicas, como, por exemplo, os critrios de escalonamento, consistncia de dados e disponibilidade. A seguir, so apresentadas discusses comparativas a respeito desses trs critrios. A questo do escalonamento essencial porque justamente nesse ponto em que os bancos NoSQL apresentam as principais vantagens em relao aos SGBDs relacionais, basicamente pelo fato de terem sido criados para esse fim, enquanto os sistemas relacionais possuem uma estruturao menos flexvel e menos adaptada para cenrios em que o escalonamento faz-se necessrio. Seja uma aplicao determinada aplicao web, com arquitetura simples conforme ilustrado na Figura 2, para se promover opes de atendimento ao nmero crescente de usurios, os responsveis pelo sistema poderiam optar pelo upgrade no servidor, soluo tambm conhecida como Escalonamento Vertical (scale up); ou pelo aumento na quantidade de servidores, soluo tambm conhecida como Escalonamento Horizontal (scale out), o qual pode ser visualizado na Figura 3.

Figura 1. Exemplo de documento do CouchDB

Figura 2. Arquitetura Tradicional de uma Aplicao Web

Na terceira categoria, muda-se o paradigma de orientao a registros (ou tuplas) para orientao a atributos (ou colunas). O Cassandra possui colunas (tuplas que contm nome, valor e timestamp), famlias de colunas (um repositrio para colunas, anlogo a uma tabela do Modelo Relacional) e super-colunas (compostas por arrays de colunas) [7]. Na quarta categoria, os dados so armazenados em ns de um grafo cujas arestas representam o tipo de associao entre esses ns. Quanto ao modo de armazenamento dos dados, temos os bancos que mantm suas informaes em memria realizando

Figura 3. Utilizao do Escalonamento Horizontal

4 O Escalonamento Vertical, que se caracteriza por sua simplicidade, tem sido tradicionalmente mais indicado para as camadas de banco de dados, enquanto o Escalonamento Horizontal tem sido mais utilizado nas camadas das aplicaes, principalmente para a Web. O prximo passo consiste em tentar escalonar o prprio banco de dados. A idia bsica distribuir o banco em vrias mquinas, utilizando-se do particionamento dos dados. Esse processo tambm conhecido como sharding. No entanto, esta abordagem esbarra nas caractersticas do SGBD, dada a dificuldade em se adaptar a toda a estrutura lgica do Modelo Relacional soluo proposta. A Figura 4 ilustra essa abordagem. A dificuldade em se aplicar o processo de sharding em bancos de dados relacionais est relacionada com alguns fatores importantes. Primeiro, enquanto os dados de um SGBD relacional obedecem o critrio de normalizao, o processo de sharding se caracteriza justamente pelo inverso: a desnormalizao dos dados. Dados que so utilizados em conjunto so armazenados em conjunto. concorrncia. Os bancos de dados NoSQL foram especialmente projetados para atender essas caractersticas de forma mais natural. O MongoDB inclui um mdulo de sharding automtico que permite a construo de um cluster de banco de dados escalvel horizontalmente projetado para incorporar novas mquinas de forma dinmica [15]. Nessa arquitetura, conforme ilustrado na Figura 5, um cluster consiste de dois ou mais blocos de servidores chamados de shards, um ou mais servidores de configurao os quais armazenam os metadados do banco e qualquer nmero de processos roteadores chamados de mongos atravs dos quais os servidores da aplicao se conectam [15].

Figura 5. Arquitetura de sharding do MongoDB Figura 4. Esquema de sharding

Segundo, existe uma mudana de paradigma em relao ao processo de escalonamento. Enquanto os SGBDs relacionais aplicam a estratgia de escalonamento vertical, ou seja, reforar o servidor; o processo de sharding objetiva trabalhar com o escalonamento horizontal, paralelizando seus dados em vrios servidores. Terceiro, o prprio volume dos dados por mquina sensivelmente minimizado devido ao processo de distribuio. Conjuntos de dados menores so mais fceis de serem acessados, atualizados e gerenciados. Finalmente, o fator mais importante, o grau de disponibilidade do sistema otimizado em relao abordagem relacional, justamente pelo critrio j discutido anteriormente referente ao fato de que a queda de uma mquina no causa a interrupo de todo o sistema. Como exemplo disso, pode ser citado o caso do Twitter. Em 2008, enquanto ainda utilizava o PostgreSQL, o site que funciona como rede social ficou 84 horas for do ar. Em 2009, aps a utilizao do Cassandra, esse tempo foi sensivelmente reduzido para 23 horas e 45 minutos [17]. Pelos fatores anteriormente expostos, os principais benefcios dessa abordagem podem ser identificados como: maior disponibilidade, menor tempo de resposta para consultas, paralelismo de atualizao de dados e maior grau de

Seja um cenrio no qual existem inicialmente, por exemplo, trs servidores, cada qual armazenando partes distintas do banco de dados, a aplicao se conecta ao cluster de ns atravs de um mongos o qual responsvel pelo roteamento das operaes ao destino apropriado. Esse local de destino, conhecido como shard, consiste de dois ou mais servidores, cada um contendo uma rplica da poro do banco armazenado pelo shard [13]. O gerenciamento de falhas se d atravs da substituio automtica do servidor falho por um novo servidor. Assim, cada shard sempre estar on-line. Apesar de, para a aplicao, o cluster continuar sendo visto como um banco de dados no-distribudo, a capacidade do sistema otimizada. Atualizaes e leituras de dados so distribudas atravs dos trs servidores shard. Outra comparao interessante entre as abordagens relacionais e NoSQL se refere ao controle de concorrncia. Enquanto nos primeiros esse processo se utiliza dos bloqueios (locks) para garantir que dois usurios no estejam atualizando o mesmo item de dados no mesmo instante, nas solues NoSQL so utilizadas outras estratgias que permitem um maior grau de concorrncia. O CouchDB, por exemplo, utilizada uma estratgia chamada de Controle de Concorrncia de Multi-verses (MVCC). Neste caso, as requisies aos dados podem ser realizadas em paralelo. A idia criar mltiplas verses dos

5 documentos e permitir a atualizao sobre uma dessas verses, mantendo ainda a verso desatualizada. Assim, no h necessidade de se bloquear os itens de dados. A Figura 6 ilustra o contraste entre o sistema de locking dos SGBDs tradicionais e o MVCC do CouchDB [1]. abordagem de um SGSBD tradicional deve levar em considerao as necessidades do problema. Os fatores que devem ser utilizados como critrios de comparao so de tipos diversos, indo desde a escalabilidade do sistema, passando por questes de consistncia de dados, at problemas de facilidade de uso ou existncia ou no de linguagens de consulta. A comparao realizada neste trabalho foi baseada principalmente em trs fatores: escalabilidade, consistncia dos dados e disponibilidade do sistema. A Tabela 1 apresenta um quadro comparativo entre o paradigma relacional e o paradigma NoSQL conforme esses trs critrios escolhidos e analisados. Como pontos positivos dos SGBDs relacionais deve-se observar que tais sistemas so solues muito mais maduras e experimentadas, enquanto que as implementaes NoSQL ainda esto definindo um padro prprio. Alm disso, a consistncia de dados continua sendo um fator a ser considerado com ateno e as transaes dos SGBDs relacionais ainda so a melhor forma de se trabalhar com esse problema. Alm disso, a utilizao de operaes de junes entre os dados, ainda que pontuais, pode tornar-se bastante custosa. Apesar do fato dos bancos NoSQL serem projetados para no precisar das junes, ainda podem ocorrer consultas que necessitem de operaes dessa natureza, ainda que no no mesmo nvel que faz-se necessrio em sistemas relacionais comuns.
Tabela 1. Anlise Comparativa Modelo Relacional x NoSQL Relacional Possvel, mas complexo. Devido natureza estruturada do modelo, a adio de forma dinmica e transparente de novos ns no grid no realizada de modo natural. NoSQL Uma das principais vantagens desse modelo. Por no possuir nenhum tipo de esquema prdefinido, o modelo possui maior flexibilidade o que favorece a incluso transparente de outros elementos. Realizada de modo eventual no modelo: s garante que, se nenhuma atualizao for realizada sobre o item de dados, todos os acessos a esse item devolvero o ltimo valor atualizado. Outro fator fundamental do sucesso desse modelo. O alto grau de distribuio dos dados propicia que um maior nmero de solicitaes aos dados seja atendida por parte do sistema e que o sistema fique menos tempo no-disponvel.

Figura 6. Controle de Concorrncia: Bloqueios x MVCC. Fonte: [1]

Ao se substituir um SGBD relacional por uma soluo NoSQL, a arquitetura perde em consistncia, mas pode ganhar em flexibilidade, disponibilidade e performance. Tal idia se baseia no Teorema de Eric Brewer conhecido como Teorema CAP (Consistency, Availability e Partition Tolerance), o qual afirma que impossvel para um sistema computacional distribudo garantir, de forma simultnea, consistncia, disponibilidade e tolerncia ao particionamento. Segundo esse teorema, um sistema distribudo pode garantir apenas duas dessas trs caractersticas simultaneamente [2]. O tipo de consistncia utilizada nos bancos de dados NoSQL chamada de Consistncia Eventual: o sistema de armazenamento garante que se nenhuma nova atualizao for realizada sobre o objeto, eventualmente todos os acessos esse objeto retornaro o ltimo valor atualizado. Quando uma escrita for realizada no banco, no se pode garantir que, a partir daquele momento, todos os outros processos tero acesso apenas ao dado atualizado. Estes processos estaro apenas eventualmente capacitados para perceber tais mudanas [11]. Esse conceito estendido para o paradigma chamado BASE (Basically Available, Soft state, Eventual consistency) que se caracteriza por ser basicamente disponvel, ou seja, o sistema parece estar funcionando o tempo todo; em estado leve, o sistema no precisa ser consistente o tempo todo; e eventualmente consistente, o sistema torna-se consistente no momento devido [10]. Esse modelo entra em contraste com o paradigma ACID (Atomicity, Consistency, Isolation, Durability) comumente associado aos SGBDs relacionais. Enquanto o modelo ACID fora a consistncia ao final de cada operao, o modelo BASE permite que o banco de dados esteja eventualmente em um estado consistente. A disponibilidade do modelo BASE est relacionada ao fato de que a queda de uma mquina do sistema no leva o sistema como um todo a ser interrompido, representando apenas uma mquina a menos disponvel [10].

Escalonamento

Consistncia

Ponto mais forte do modelo relacional. As regras de consistncia presentes propiciam uma maior grau de rigor quanto consistncia das informaes. Dada a dificuldade de se conseguir trabalhar de forma eficiente com a distribuio dos dados, esse modelo pode no suportar a demanda muito grande de informaes do banco.

Disponibilidade

VII. CONCLUSES A deciso de se realizar uma mudana dessa natureza optar por um abordagem NoSQL em contraste com uma

Outro fator importante a ser considerado a ausncia de

6 uma linguagem de consulta, como o caso do SQL para os SGBDs relacionais. No existe, em qualquer abordagem noSQL, nada que se aproxime da simplicidade e expressividade oferecida pelo SQL. Adicionalmente, perde-se toda a funcionalidade oferecida pela linguagem, tais como funes, rotinas, etc. Alm disso, deixa-se de utilizar a mais simples restrio de integridade sobre o banco, o que pode tornar a aplicao mais pesada. Adicionalmente, deve-se ter em mente que a escalabilidade em alto grau faz-se necessria apenas em bancos de grande porte, nos quais a alta disponibilidade imprescindvel. Utilizar uma soluo NoSQL para bancos de dados nos quais a disponibilidade no seja um fator imprescindvel ainda uma abordagem discutvel. REFERENCES
[1] [2] [3] [4] J. C. Anderson, N. Slater, J. Lehnardt,, CouchDB: The Definitive Guide, 1 edio, O'Reilly Media, 2009. E. Brewer. Towards Robust Distributed Systems. (Invited Talk). Principles of Distributed Computing (PODC), Portland, Oregon, Julho 200. C. Chandler, CouchDB in Action, 1 edio, Manning Publications, 2009. F. Chang , J. Dean , S. Ghemawat , W. C. Hsieh , D. A. Wallach , M. Burrows , T. Chandra , A. Fikes , R. E. Gruber, Bigtable: A distributed storage system for structured data, In Proceedings of the 7th Conference on Usenix Symposium on Operating Systems Design And Implementation, Volume 7, 2006. E. F. Codd, A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Volume 13, n 6, Junho de 1970, p. 377387. G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall e W. Vogels. "Dynamo: Amazon's Highly Available Key-Value Store", ACM SIGOPS Operating Systems Review, Volume 41, Edio 6, Dezembro 2007, SOSP '07, p. 205220. A. Lakshman, P. Malik, Cassandra - A Decentralized Structured Storage System, LADIS 2009 N. Leavitt, "Will NoSQL Databases Live Up to Their Promise?," Computer, vol. 43, no. 2, pp. 12-14, Feb. 2010. J. Lennon, Beginning CouchDB, 1 edio, Apress, 2009. D. Pritchett, BASE: An Acid Alternative, ACM Queue vol. 6, no. 3, Julho 2008. W. Vogels, Eventually Consistent, Scalable Web Services, Volume 6 No. 6, Outubro de 2008. Introducing JSON. http://json.org/. Acessado em 14/05/2010. MongoDB: Sharding Introduction. http://api.mongodb.org/wiki/current/Sharding Introduction.html. Acessado em 14/05/2010. NoSQL Relational Database Management System: Home Page. Strozzi.it. http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home Page. Acessado em 13/04/2010. Official MongoDB Project Website. http://www.mongodb.org/display/DOCS/Home . Acessado em 13/04/2010. The CouchDBProject. http://couchdb.apache.org/index.html. Acessado em 14/05/2010 Twitter growth prompts switch from MySQL to 'NoSQL' database. http://www.computerworld.com/s/article/9161078/Twitter_growth_pro mpts_switch_from_MySQL_to_NoSQL_database. Acessado em 14/05/2010.

[5] [6]

[7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]