NoSQL na Web 2.0: Um Estudo Comparativo de Bancos
Não-Relacionais para Armazenamento de Dados na Web 2.0
Mauricio De Diana1, Marco Aurélio Gerosa1
1Department of Computer Science – University of São Paulo (USP)
São Paulo – SP – Brazil
{mdediana,gerosa}@ime.usp.br
Abstract. With Web 2.0, the amount of data created, stored and processed has reached a scale never seen before. Web 2.0 organizations have been imple-menting and using solutions beyond relational databases to handle such data volume. These non-relational databases were named NoSQL. To better unders-tand their use cases, it is necessary to categorize, classify and compare them by their scalability and performance attributes.
This article presents an ongoing research to identify the characteristics which determine NoSQL databases scalability and performance by building and com-paring prototypes, and to produce recommendations on NoSQL use regarding the scale of the system in which they will operate.
1. Fundamentação Teórica
O mundo nunca lidou com volumes de dados tão grandes, em parte graças a Web 2.0. No artigo em que define Web 2.0, Tim O’Reilly fala sobre a necessidade de se aproveitar a Inteligência Coletiva 1 e sobre dados como diferencial competitivo [O’Reilly 2005]. Não por acaso muitas inovações na área de gerenciamento de dados vieram de algu-mas empresas pioneiras da Web 2.0, que encontrando limites nas técnicas e ferramen-tas disponíveis naquele momento, criaram sua próprias soluções de gerenciamento de dados distribuído em larga escala, em sua maioria não-relacionais [Chang et al. 2006, DeCandia et al. 2007, Cooper et al. 2008, Dean and Ghemawat 2008]. Boa parte da mo-tivação por trás dessas soluções estava ligada a novos requisitos de escalabilidade e dis-ponibilidade, que fizeram com que outros requisitos tidos como indiscutíveis fossem re-vistos, como a consistência dos dados, por exemplo [Vogels 2009, Pritchett 2008].
Seguindo essa onda de inovações no gerenciamento de dados na web vieram or-ganizações menores e a comunidade de software livre e de código aberto, que inspiradas naquelas primeiras ideias, criaram diversas soluções de bancos de dados não-relacionais, seguindo diferentes paradigmas. Apesar de bancos de dados não-relacionais não se-rem novidade, inclusive existindo antes dos bancos de dados relacionais, a esse con-junto específico de soluções surgidas nessa segunda onda na Web 2.0 deu-se o nome NoSQL. Mesmo ainda estando cercadas de polêmicas e discussões [Stonebraker 2009, Leavitt 2010, Stonebraker 2010], academia e mercado reconhecem a importância e a ne-cessidade de estudá-las [Agrawal et al. 2009, Release 2009, Radar 2010]. No momento, vemos negócios e operações de escala global construídos sobre essas tecnologias, indo de
1Inteligência Coletiva é a emergência de inteligência ou comportamento a partir da colaboração ou
empresas já estabelecidas como Google, Amazon e Yahoo! a empresas mais novas como Facebook, Twitter, Digg e Foursquare.
Assim como o termo não-relacional, o termo NoSQL não ajuda a definir o que esses bancos são de fato. Além do problema da falta de precisão, esse termo também tem contribuído para uma grande confusão em torno dessa categoria de bancos de dados, já que a princípio a linguagem SQL não é sinônimo de bancos de dados relacionais, nem representa as limitações desses bancos de dados. Devido a isso, o termo NoSQL tem sido usado com o significado de “Não Apenas SQL”2numa tentativa da comunidade de reconhecer a utilidade dos modelos tradicionais e não divergir as discussões. No fim, NoSQL não define precisamente esses bancos de dados, mas no geral cada um deles apresenta a maioria das seguintes características: não-relacional, distribuído e escalável horizontalmente, ausência de esquema ou esquema flexível, suporte à replicação nativo e acesso via APIs simples [NOSQL 2010]. Entre os principais fatores que favoreceram seu surgimento estão a natureza dos dados da web (semiestruturados e crús), a importância de atingir altos graus de paralelismo no processamento de grandes volumes de dados [Barroso et al. 2003] e a distribuição de sistemas em escala global [Vogels 2009].
As quatro principais categorias de bancos de dados NoSQL são: bancos de dados orientados a documentos (por exemplo, MongoDB e CouchDB), armazéns de chave-valor (por exemplo, RIAK, Redis e MemcacheDB), bancos de dados de famílias de colunas (por exemplo, Cassandra, HBase e Hypertable) e bancos de dados de grafos (por exemplo, Neo4j e InfoGrid).
Como essas tecnologias são muito recentes, há poucas recomendações indicando em que contexto usar determinado paradigma. Em especial, apesar de haver casos em que bancos de dados NoSQL ajudaram organizações a escalar seus sistemas, há poucos estudos comparativos que indiquem os cenários em que se aplicam e quais são seus li-mites de escalabilidade e desempenho. Esse trabalho tem por objetivo investigar e testar os bancos de dados NoSQL do ponto de vista de escalabilidade e desempenho, e gerar recomendações sobre seu uso.
2. Caracterização da Contribuição
Esta seção apresenta a proposta da pesquisa baseada nos pontos descritos em [Wazlawick 2008].
2.1. Contextualização e colocação do problema
Os bancos de dados NoSQL supostamente apresentam características de escalabilidade e desempenho mais adequadas no contexto da Web 2.0. Há relatos de sucesso da migração de soluções relacionais para NoSQL vindos de empresas da Web 2.0. Mas ainda faltam recomendações que indiquem quando os bancos de dados NoSQL são mais adequados de acordo com o contexto da aplicação, bem como detalhes sobre o compromisso feito entre escalabilidade e outros atributos de qualidade ao se optar por esse tipo de solução. 2.2. Objetivos geral e específicos
O objetivo desse trabalho é entender como diferentes aspectos de bancos de dados NoSQL afetam sua escalabilidade e desempenho através da comparação entre protótipos de ban-cos de dados NoSQL feitas a partir de resultados de experimentos.
Os objetivos específicos desse trabalho são:
a. Criar uma taxonomia dos bancos de dados NoSQL considerando aspectos como modelo de dados, mecanismos de armazenamento, distribuição e replicação, por exemplo.
b. Definir uma arquitetura de referência para bancos de dados NoSQL a partir dos aspectos levantados com a taxonomia.
c. Implementar / estender um arcabouço que implemente a arquitetura de referência para auxiliar nos experimentos.
d. Gerar recomendações sobre o uso dos bancos de dados NoSQL baseadas nos as-pectos levantados na taxonomia e na escala do sistema em questão.
2.3. Justificativa
Muito tem se falado sobre as vantagens de bancos de dados NoSQL sobre bancos de da-dos relacionais com relação à escalabilidade. São comuns relatos vinda-dos de empresas que obtiveram sucesso na migração de bancos de dados relacionais para NoSQL, e alegam te-rem resolvido seus problemas de escalabilidade, mas ainda falta um melhor entendimento do contexto e dos limites desses bancos de dados. O resultado de um estudo comparativo como esse é importante pois ajuda desenvolvedores e arquitetos a decidirem se bancos de dados NoSQL são apropriados para o problema que têm em mãos, e caso sejam, decidir qual deles é o mais apropriado.
2.4. Método de pesquisa
Pretendemos executar experimentos que ajudem a identificar a influência que determina-dos aspectos de bancos de dadetermina-dos NoSQL exercem sobre sua escalabilidade e desempenho. Alguns aspectos a serem estudados são modelo de dados e mecanismo de distribuição e replicação, por exemplo. Para isso, vamos criar protótipos de bancos de dados NoSQL que variem com relação a esses aspectos, e executar testes baseados em benchmarks co-nhecidos. As etapas da pesquisa são:
Taxonomia de bancos de dados NoSQL Vamos criar uma taxonomia dos bancos de dados NoSQL que permita classificá-los com relação a seus modelos de dados, mecanis-mos de armazenamento, distribuição e replicação, etc. Essas informações são importantes para a definição dos aspectos que devem ser considerados para o experimento.
Definição de uma arquitetura de referência de bancos de dados NoSQL A partir da taxonomia, vamos definir uma arquitetura de referência para bancos de dados NoSQL. Uma arquitetura de referência define um modelo para a criação de arquiteturas em um determinado domínio, evidenciando as características comuns dos sistemas pertencentes a esse domínio. O objetivo dessa arquitetura de referência é auxiliar na implementação / extensão de um arcabouço com o qual criaremos protótipos de bancos de dados NoSQL para realizar os experimentos.
Implementação / extensão de um arcabouço para bancos de dados NoSQL O arca-bouço deve preferencialmente ser escrito em alguma linguagem ou plataforma que dis-ponibilize mecanismos que facilitem a implementação de distribuição, como a linguagem
Erlang, por exemplo. Também temos a intenção de partir de algo já existente, como o riak_core3, para diminuir os esforços de desenvolvimento.
Projeto do experimento Vamos usar benchmarks já estabelecidos para comparar os bancos de dados, como os definidos pelo Transaction Processing Performance Council (TPC). Adaptações desses benchmarks serão feitas para que se adequem aos modelos de dados usados pelos NoSQL. Nessa etapa também iremos definir as métricas a serem usadas, o que deve ser feito de acordo com técnicas de análise de desempenho definidas em livros como [Jain 1991, Liu 2009].
Execução dos testes Os bancos de dados serão testados de forma a entender seus com-portamentos em diversas escalas. Assim, testes para cada cenário serão executados, indo de um pequeno volume de dados em um único nó até um volume de dados tal que se espalhe por centenas de nós. Além disso, pretendemos testar distribuições de nós por diferentes localizações geográficas para simular distribuição global do sistema. Existem algumas plataformas acadêmicas para testes como Open Cirrus4e PlanetLab5 que per-mitem esse tipo de experimento, incluindo o uso de múltiplos datacenters.
Análise dos resultados Os resultados para cada protótipo serão analisados e compara-dos. É nesse momento que iremos entender os compromissos entre atributos de qualidade desses bancos de dados – espera-se perceber situações em que um protótipo apresentou resultados melhores com relação a escalabilidade, mas perdeu em tempo de resposta, por exemplo. O objetivo principal desses experimentos é entender a influência de cada as-pecto de um bancos de dados NoSQL em sua escalabilidade e desempenho. Também devemos analisar a adequação do modelo de dados a cada cenário, dado que esse fator impacta atributos de qualidade como manutenibilidade, por exemplo.
3. Estado Atual do Trabalho
Atividades que contribuíram para a pesquisa até o momento foram:
• Revisão bibliográfica na qual foram levantados os principais livros e artigos sobre sistemas de larga escala em geral e gerenciamento de dados em larga escala em particular, necessários para entender o contexto e as tecnologias relacionadas a NoSQL.
• Monografia de título “Bancos de Dados Não-Relacionais Distribuídos” escrita para a disciplina “PCS5736 - Programação Paralela e Distribuída”.
• Seminário com título “Introdução aos Bancos de Dados Não-Relacionais” apre-sentado para o departamento de Ciência da Computação do IME. Os sli-des estão disponíveis em http://www.slisli-deshare.net/mdediana/ introducao-aos-bancosdedadosnaorelacionais.
3http://blog.basho.com/category/riak-core/ 4http://opencirrus.org/
• Grupo de estudos sobre NoSQL ligado à iniciativa “A NoSQL Summer”6, criado
com a ajuda do IME.
• Apresentação “NoSQL: Perdas e Ganhos” sobre conceitos básicos de NoSQL na The Developer’s Conference 2010 7. Os slides estão disponíveis em http:// www.slideshare.net/mdediana/no-sql-perdaseganhos.
No momento, estamos no início da etapa de projeto dos experimentos, estudando técnicas de design de experimentos em paralelo com alguns testes informais de algumas das soluções NoSQL.
4. Trabalhos Relacionados
Ainda existem poucos estudos comparativos entre os bancos de dados NoSQL.
Pavlo et al comparam diferentes soluções para análise de dados em larga escala – uma implementação de MapReduce e outras duas de bancos de dados paralelos usando SQL em [Pavlo et al. 2009]. Os resultados desse comparativo foram discutidos depois em [Stonebraker et al. 2010, Dean and Ghemawat 2010]. Apesar de a análise não ser espe-cificamente sobre bancos de dados NoSQL, o estudo é pertinente pois analisa o MapRe-duce, mecanismo comum a vários desses bancos de dados. Outro estudo de MapReduce é [O’Malley and Murthy 2009], que usa o GraySort8para analisar o Hadoop.
Um estudo que analisa escalabilidade de bancos de dados é [Malkowski et al. 2010], mas ele considera apenas bancos de dados relacionais (MySQL e PostgreSQL).
Um estudo comparativo especificamente sobre NoSQL é [Vicknair et al. 2010], que compara um banco de dados de grafos (Neo4J) a um relacional (MySQL).
5. Avaliação dos Resultados
Esse trabalho deve gerar recomendações de uso de bancos de dados NoSQL de acordo com a escala (considerando a quantidade de nós, por exemplo) e com os atributos defini-dos em uma taxonomia para bancos de dadefini-dos NoSQL. Assim, as recomendações podem ser validadas através de pesquisa com empresas que já usam NoSQL em suas aplicações e também através da avaliação com um grupo de desenvolvedores experientes em sistemas de larga escala.
Referências
Agrawal, R. et al. (2009). The Claremont Report on Database Research. Communications of the ACM, 52(6):56–65.
Barroso, L. A., Dean, J., and Hölzle, U. (2003). Web Search for a Planet: The Google Cluster Architecture. IEEE Micro, 23(2):22–28.
Chang, F. et al. (2006). Bigtable: A Distributed Storage System for Structured Data. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Imple-mentation (OSDI’06), volume 26, pages 1–26.
6http://nosqlsummer.org/
7http://thedevelopersconference.com.br/tdc/2010/index.html 8http://sortbenchmark.org/FAQ-2010.html#gray
Cooper, B. F. et al. (2008). PNUTS: Yahoo!’s Hosted Data Serving Platform. In Procee-dings of the VLDB Endowment, volume 1, pages 1277–1288. VLDB Endowment. Dean, J. and Ghemawat, S. (2008). MapReduce: Simplified Data Processing On Large
Clusters. Communications of the ACM, 51(1):107–114.
Dean, J. and Ghemawat, S. (2010). MapReduce: A Flexible Data Processing Tool. Com-munications of the ACM, 53(1):72–77.
DeCandia, G. et al. (2007). Dynamo: Amazon’s Highly Available Key-value Store. ACM SIGOPS Operating Systems Review, 41(6):205–220.
Jain, R. K. (1991). The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. Wiley, 1 edition. Leavitt, N. (2010). Will NoSQL Databases Live Up to Their Promise? Computer,
43(2):12–14.
Liu, H. H. (2009). Software Performance and Scalability: A Quantitative Approach. Wiley.
Malkowski, S. et al. (2010). Empirical Analysis of Database Server Scalability Using an N-tier Benchmark With Read-intensive Workload. In Proceedings of the 2010 ACM Symposium on Applied Computing, pages 1680–1687. ACM.
NOSQL (2010). NOSQL Databases. http://nosql-database.org/.
O’Malley, O. and Murthy, A. C. (2009). Winning a 60 second dash with a yellow elephant. O’Reilly, T. (2005). What Is Web 2.0. http://oreilly.com/lpt/a/6228.
Pavlo, A. et al. (2009). A Comparison of Approaches to Large-Scale Data Analysis. In Proceedings of the 35th SIGMOD International Conference on Management of Data, volume 2, pages 165–178. ACM.
Pritchett, D. (2008). BASE: An Acid Alternative. Queue, 6(3):48–55. Radar (2010). ThoughtWorks Technology Radar. (April):8.
Release (2009). Release 2.0. (11).
Stonebraker, M. (2009). The "NoSQL"Discussion has Nothing to Do With SQL. http://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discussion-has-nothing-to-do-with-sql/fulltext.
Stonebraker, M. (2010). SQL databases v. NoSQL databases. Communications of the ACM, 53(4):10–11.
Stonebraker, M. et al. (2010). MapReduce and Parallel DBMSs: Friends or Foes. Com-munications of the ACM, 53(1):64–71.
Vicknair, C. et al. (2010). A Comparison of a Graph Database and a Relational Database A Data Provenance Perspective. In The 48th ACM Southeast Conference.
Vogels, W. (2009). Eventually Consistent. Communications of the ACM, 52(1):40–44. Wazlawick, R. S. (2008). Metodologia de Pesquisa para Ciência da Computação.
