1 ESTUDO DE CASO – BANCO DE DADOS NOSQL
Davi Pistorello1 Fábio Giordani2 Kaie Guex3
Resumo: Os bancos de dados relacionais são amplamente utilizados como solução de armazenagem em diversos tipos de sistemas, mas devido ao crescimento das empresas e da quantidade de dados que movimentam as novas aplicações da web 2.0, novas abordagens estão sendo desenvolvidas e empregadas, como é o caso dos bancos de dados NoSQL. São soluções que vem sendo adotadas e consolidadas por grandes empresas de tecnologia para solucionar os novos desafios que estão surgindo com o grande volume de dados movimentado pelos sistemas da atualidade. Neste artigo será feita uma análise do que é um banco de dados NoSQL e serão demonstradas quais as necessidades que este modelo de banco de dados veio atender no atual mercado de TI, conceituando-o junto a outros modelos existentes, procurando saber qual sua real vantagem e desvantagem em relação a estes.
Palavras Chave: NoSQL, Escalabilidade, Banco de dados, web 2.0.
1 Introdução
O setor de tecnologia da informação, TI, sempre procurou atender as demandas conforme a necessidade do seu tempo, demandas que ficam cada vez mais complexas devido ao crescimento do uso da internet e as rápidas mudanças e inovações deste mercado. O ritmo da inovação no armazenamento de dados acelerou significativamente na última década, e com isso as ferramentas para gerenciamento também precisaram ser repensadas sobre o desempenho do armazenamento e controle sobre o acesso aos dados. A
1 Aluno do Curso de Tecnólogo em Análise e Desenvolvimento de Sistemas 2 Aluno do Curso de Tecnólogo em Análise e Desenvolvimento de Sistemas 3 Aluno do Curso de Tecnólogo em Segurança da Informação
2 abordagem mais inteligente no gerenciamento de armazenamento de grandes dados inclui um conjunto de ferramentas, serviços, software e hardware. Grandes empresas como o
Twitter já relataram problemas em administrar sua grande quantidade de dados e a seu
constante crescimento. Para lidar com este problema a solução adotada em foi migrar seu banco dados relacional para um banco de dados não-relacional, o NoSQL (Not Only SQL), no caso do Twitter foi selecionado o banco de dados Cassandra, que promete escalabilidade, alta disponibilidade, sem comprometer o desempenho. O Cassandra inicialmente foi criado pelo
Facebook, que abriu seu código-fonte para a comunidade em 2008, e de acordo com o
engenheiro Avinash Lakshman [1] tem o poder de escrever 2500 vezes mais rápido em um grande banco de dados de 50 Gb do que o MySQL.
O NoSQL aparece como uma solução para atender esta necessidade iminente de processamento de grandes montantes de dados que as empresas estão achando custosas realizar com um banco de dados relacional. As grandes preocupações com os dados criaram uma oportunidade para que as pessoas pensem na hora sobre as suas necessidades de armazenamento de dados, e algumas equipes de desenvolvimento podem ver que o uso de um banco de dados NoSQL ajudam na sua produtividade, simplificando o acesso do banco de dados, mesmo que eles não tenham a necessidade de escalar além de uma única máquina.
2 Referencial Teórico
2.1 NoSQL
Apesar de estar em maior evidência hoje, segundo Sadalage e Fowler o termo NoSQL foi utilizado pela primeira vez em 1998 referenciado a um banco de dados de código aberto que não utilizava a linguagem SQL. Mais tarde em 2009 este termo ganhou mais força quando utilizado em uma conferência de defensores de banco de dados não-relacionais em San Francisco. A principal vantagem de um tipo de banco de dados não relacional é que, diferente da abordagem tradicional, eles lidam bem com dados desestruturados, tais como e-mails, dados multimídia e dados provenientes de mídias sociais (Leavit, 2010).
3 Os bancos de dados, antes o hierárquico e o de rede, até chegarmos ao banco de dados mantido pelas relações entre as tabelas o modelo relacional, não foram projetados para funcionar de forma eficiente em clusters. Desta maneira, procurando atender à necessidade das grandes empresas, desenvolvedores de bancos de dados passaram a pensar novas estratégias de armazenamento, estratégias essas que os desprenderiam de trabalhar nas regras que o modelo relacional impunha.
O desenvolvimento próprio começa, segundo Levitt, principalmente em empresas da web 2.0, gigantes como a Google e Amazon foram pioneiras, criando bancos de dados NoSQL para trabalharem com sua enorme quantidade de dados, chamados de BigTable e
DynamoDB. NoSQL, não se define a um tipo banco de dados de fato, mas a uma característica
comum, segundo Fowler 2012:
a) Não utilizam o modelo relacional nem a linguagem SQL; b) São de código aberto (Open source);
c) Desenhados para utilização em grandes cluster; d) Baseados nas necessidades da web 2.0;
e) Não existe um esquema, permitindo que campos possam ser adicionados a qualquer registro. Ausência de esquema ou esquema flexível;
f) Suporte à replicação nativo; g) Acesso via APIs simples.
2.2 Tipos NoSQL
As categorias nas quais o NoSQL pode ser agrupado são definidas como chave-valor, orientado a colunas, orientado a documentos e orientado a grafos.
2.2.1 Chave-valor
Podendo também ser definida como key-value ou tabela de hash, essa categoria é conhecida como sendo um modelo de fácil implementação, uma vez que os dados serão
4 armazenados e consultados utilizando-se de chaves hash, como definido no conceito dicionário ou mapa de dados (DE DIANA e GEROSA, 2010).
Esse modelo permite visualizar o banco de dados em tabelas hash. Utilizando-se da sua característica, simplicidade, o banco acaba por ser composto por inúmeras chaves, onde cada uma delas está associada a um valor único.
Como exemplo de banco de dados desta categoria de NoSQL o DynamoDB acaba sendo o mais difundido, pois além de ser fornecido como alternativa de armazenamento de dados pela Amazon, esse foi utilizado com base para o desenvolvimento do Cassandra.
Segundo afirma Strauch (2011), o DynamoDB foi criado para ser um sistema de consistência eventual, ou seja, quando uma operação for executada, o retorno da operação acontece antes de todos os nós serem atualizados, ocasionando que leituras posteriores possam retornar versões diferentes dos dados.
2.2.2 Orientado a colunas
Comumentemente relacionado ao tipo de armazenamento definido por Chang (2006) em "BigTable: A distributed Storage System for Structured data", vários projetos além do próprio BigTable utilizam este conceito de bancos de dados, que suportam um grande número de colunas por linha e permitem buscas mais ágeis nos valores das colunas. Estas por sua vez, podem possuir valores baseados em listas, sub colunas ou outras linhas com colunas. Nesse modelo, a indexação dos dados é efetuada pela tripla formada pela linha, coluna e data/hora. Para identificação, tanto a linha quanto a coluna são identificadas por chaves e o timestamp, é um diferenciador entre as versões dos dados, segundo Lóscio, De Oliveira e Pontes (2011).
Criado pela Google em 2004, o BigTable, foi uma das implementações pioneiras de um sistema não relacional objetivando a promoção de uma maior escalabilidade e disponibilidade (BRITO, 2010), contudo este modelo não suporta uniões, fazendo-se necessária a tratativa de relacionamentos na aplicação e não em nível de banco de dados como ocorre nos sistemas relacionais.
5 2.2.3 Orientado a documentos
Na categoria de NoSQL orientado a documentos, cada documento é implementado como um objeto com um identificador único e possui um conjunto de campos. Os documentos têm como característica a flexibilidade de seu esquema (definição), permitindo assim que cada documento possa possuir seu próprio conjunto de campos sem que seja seguido rigidamente um padrão de tabelas estruturadas (LÓSCIO, DE OLIVEIRA e PONTES, 2011). Com esta abordagem, os desenvolvedores podem adicionar quantos campos se fizerem necessários e de quaisquer tipos disponíveis, sem restrições estruturais.
O CouchDB, que desde 2008 pertence à Apache Software Foundation, é um dos exemplos de banco de dados desta categoria. Uma característica interessante é que o controle de concorrência dos dados é feito utilizando identificadores de sequência para cada uma das versões do documento. Quando este é alterado por outro usuário desde a sua última leitura, a aplicação é notificada e por sua vez combina ou descarta as alterações e por fim, após as alterações serem confirmadas os dados são gravados.
2.2.4 Orientado a grafos
O modelo de grafos possui três elementos básicos: os vértices dos grafos (nós), as arestas (relacionamentos) e os atributos (propriedades dos nós e dos relacionamentos) (LÓSCIO, DE OLIVEIRA e PONTES, 2011).
A vantagem da utilização deste modelo se dá ao aplicá-lo em consultas mais complexas na extração de dados por parte do usuário. Ao se comparar esse com o modelo conceitual onde estas pesquisas exigiriam, em grande parte, uma melhor implementação da aplicação que poderia ocasionar perda de desempenho, a orientação a grafos resultaria em melhores resultados com relação ao tempo de retorno dessas informações.
OrientDB é um dos principais bancos de dados de NoSQL desta categoria.
Conforme definido pela própria Orient Technologies LTD: é um banco open source, escrito em Java e mistura funcionalidade dos modelos orientados a documento e orientados a grafos e
6 permite a utilização com schema rígido quanto flexível, dando também suporte a SQL, que permite a migração de programadores acostumados com o modelo relacional [2].
Na figura encontram-se exemplos de bancos de dados conforme os modeles descritos:
2.3 NoSQL x Relacionais
De acordo com Elmasri e Navathe (2006), bancos de dados Relacionais baseiam-se no conceito de entidade e relacionamento, onde todos os dados são armazenados em tabelas e separados de forma única tentando diminuir ao máximo a redundância. A informação é criada pelo conjunto dos dados e é aí que entram as relações entre as tabelas. As características mais marcantes deste modelo são: Tabelas, hierarquia, esquema definido, mínima redundância, entidades, relacionamentos e transações ACID (Atomicity, Consistency,
7 a) A – Atomicidade: Garante que as transações sejam atômicas (indivisíveis). A
transação será executada totalmente ou não será executada.
b) C – Consistência: Garante que o banco de dados passará de uma forma consistente para outra forma consistente.
c) I – Isolamento: A propriedade de isolamento garante que a transação não será interferida por nenhuma outra transação concorrente.
d) D – Durabilidade: A propriedade de durabilidade garante que o que foi salvo, não será mais perdido.
Bancos de dados NoSQL abrem mão destas propriedades, ganhando em flexibilidade, disponibilidade, desempenho e menor tempo de resposta a consultas, valendo-se da abordagem BASE (Basically Available, Soft state e Eventual consistency em inglês) [3].
a) BA – (Basically Available) Basicamente Disponível – Prioridade na disponibilidade dos dados.
b) S - (Soft-State) Estado leve – Não precisa ser consistente o tempo todo.
c) E – (Eventually Consistent) Eventualmente Consistente - torna-se consistente no momento devido.
Ippolito (apud STRAUCH, 2011, p. 32) resume a propriedade em: “uma aplicação funciona basicamente todo o tempo (disponibilidade básica), não necessita ser consistente todo o tempo (estado leve), mas terá um estado consistente eventual (consistência eventual)”.
Tal ideia se baseia no Teorema de Eric Brewer conhecido como Teorema CAP (Consistency, Availability e Partition Tolerance), o qual afirma que é impossível para um sistema computacional distribuído garantir, de forma simultânea, consistência, disponibilidade e tolerância ao particionamento. Segundo esse teorema, um sistema distribuído pode garantir apenas duas dessas três características simultaneamente. (Leite, 2010)
8 O teorema CAP em português significa: consistência, disponibilidade e tolerância ao particionamento (no quadro representado pelo escalonamento) em uma comparação com o banco de dados relacional (Brito, 2010 p.5):
Segundo Padalage e Fowler, diferentes aplicações têm diferentes necessidades estruturais e de desempenho, por isso, sabendo que nem todos os dados podem ser estruturados, os tipos de banco de dados NoSQL cresceram nos últimos anos.
Na Tabela 1 encontram-se comparações complementares entre os modelos.
BANCOS DE DADOS SQL BANCOS DE DADOS NOSQL Tipos Um tipo (banco de dados SQL) com
pequenas variações
Muitos tipos diferentes, incluindo
chave-valor, orientados a documentos, orientado a grafos e etc.
História de Desenvolvimento
Desenvolvido em 1970 para lidar com a primeira onda de aplicações de armazenamento de dados
Desenvolvido em 2000 para lidar com as limitações dos bancos de dados SQL,
9 escala, replicação e
armazenamento de dados não estruturados.
Exemplos MySQL, Postgres, Oracle Database MongoDB, Cassandra, HBase, Neo4j
Modelo de Armazenamento de Dados
Os registros individuais (Ex: “empregados”) são armazenados como linhas em tabelas, com cada coluna armazenando uma parte específica de dados sobre esse registro (Ex: “gerente”, “setor”, etc.), bem como uma
planilha. Tipos de dados separados são armazenadas em tabelas separadas, e depois juntaram-se quando as consultas mais complexas são executadas. Por exemplo, "escritórios" pode ser armazenado em uma tabela, e "empregados" em outra. Quando um usuário quer encontrar o endereço de trabalho de um empregado, o motor de banco de dados se junta ao "empregado" e "escritório" mesas em conjunto para obter todas as informações necessárias.
Varia com base no tipo de banco de dados. Por exemplo,
armazenagens chave-valor funcionam de forma semelhante aos bancos de dados SQL, mas tem apenas duas colunas (“key” e “value”), com informações mais complexas, por vezes, armazenados dentro das colunas "valor". Bancos de dados documentais acabam com o modelo de tabela-e-linha por completo, armazenam todos os dados relevantes juntos em um único "documento" em
JSON, XML ou outro formato,
que pode agrupar valores hierarquicamente.
10 Esquemas Estrutura e tipos de dados são
determinados com
antecedência. Para armazenar informações sobre um novo item de dado, toda a base de dados tem de ser alterada, tempo durante o qual a base de dados tem de ser colocada no modo offline.
Tipicamente dinâmica. Os registros podem adicionar novas informações em tempo real, e ao contrário de linhas da tabela SQL, dados diferentes podem ser armazenados juntos conforme necessário. Para alguns bancos de dados (por exemplo, column-family), é um pouco mais desafiador para adicionar novos campos dinamicamente.
Escalabilidade Vertical, ou seja, um único servidor deve ficar mais poderoso, a fim de lidar com o aumento da
demanda. É possível espalhar bancos de dados SQL ao longo de muitos servidores, mas geralmente uma significativa engenharia adicional é necessária.
Horizontal, significa que um administrador de banco de dados pode simplesmente adicionar mais servidores ou instâncias de nuvem. O banco de dados espalha
automaticamente dados entre servidores conforme se faz necessário.
Modelo de Desenvolvimento
Mix de código-fonte aberto (por exemplo, Postgres, MySQL) e de código fechado (por exemplo, banco de dados Oracle)
Open source
Suporta Transações
Sim, as atualizações podem ser configuradas para completar totalmente ou não
Em determinadas circunstâncias e em determinados níveis (por exemplo, nível de documento vs. nível de banco de dados)
11 Manipulação de
Dados
Linguagem específica utilizando
SELECT, INSERT e UPDATE. Ex: SELECT campos FROM tabela WHERE ...
Através de APIs orientadas a objeto
Consistência Pode ser configurado para uma forte consistência
Depende do produto. Alguns fornecem consistência forte (por exemplo, MongoDB), enquanto outros oferecem consistência eventual (por exemplo,
Cassandra)
Tabela 1
2.4 Principais aplicações (cases)
Os principais utilizadores do NoSQL são empresas que processam uma enorme quantidade de dados e esses dados devem estar acessíveis de forma rápida. 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, após a utilização do
Cassandra, esse tempo foi sensivelmente reduzido para 23 horas e 45 minutos [4].
Outros, exemplos de empresas que adotaram o modelo NoSQL são:
Empresa Banco de Dados
Bigtable Google
Dynamo Amazon
Hadoop Yahoo
Cassandra Facebook, Digg, Twitter, IBM, Netflix
Voldemort LinkedIn
12 3 Metodologia
O desenvolvimento deste artigo foi realizado através coleta de dados em livros, pesquisas acadêmicas e visitas em portais de tecnologia em busca de dados que mostrassem a real utilização e os detalhes de como o NoSQL está presente nas empresas de web 2.0, detalhes de onde e como estão sendo utilizados nessas organizações. Após a coleta destes dados buscamos identificar quais as características e vantagens que esse novo conceito de armazenamento de dados em larga escala tem proporcionado para empresas como Google,
Amazon, Twitter e outras grandes da tecnologia atual.
4 Considerações Finais
De acordo com os apontamentos anteriores, percebe-se que as soluções NoSQL, mesmo que empregadas por gigantes da tecnologia como a Google, não vieram substituir as relacionais, que permanecem como principal opção para aplicações consideradas críticas, e sim suprir novas demandas que surgiram com as inovações da Web 2.0.
Aplicações que movimentam uma massa de dados gigantesca, onde em alguns casos pode passar de 15 Terabytes gerados diariamente, como é o caso do Facebook [3], clamavam por alternativas que viabilizassem a escalabilidade, esquema flexível, alto desempenho e alta disponibilidade, tornando o gerenciamento de seus dados muito mais eficiente, mesmo que para isso tenham de se submeter a possiblidade de nem sempre ser possível garantir que os dados estejam consistentes e de que haja um controle na concorrência, dentre outras características dos banco de dados tradicionais.
Entre perdas e ganhos, conclui-se que são soluções diferentes para problemas específicos, cabe aos desenvolvedores e projetistas mensurarem os pros e contras de cada solução para cada tipo de problema.
13 5 Referencial Teórico
Pramod J Sadalage, Martin Fowler, NoSQL distilled : a brief guide to the emerging world of polyglot persistence / Crawfordsville, Indiana. August 2012
Leavit, N. Will NoSQL Databases Live Up to Their Promise? 2010. Computer, 12. ISSN 0018-9162
BRITO, R. W. Bancos de Dados NoSQL x SGBDs Relacionais:Análise Comparativa. InfoBrasil, 2010. Disponível em:
http://www.infobrasil.inf.br/userfiles/27-05-S4-1-68840-Bancos%20de%20Dados%20NoSQL.pdf . Acessado em: 15 out. 2014
LEITE, Gleidson Sobreira. Análise Comparativa do Teorema CAP Entre Bancos de Dados NoSQL e Bancos de Dados Relacionais. 2010. 49 p. Monografia (Bacharel em Ciências da Computação) – Faculdade Farias Brito, Fortaleza.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 5ª. ed. [S.l.]: Addison Wesley, 2006. Acesso em: 21 maio 2012.
CHANG, F; Dean, J; GHEMAWATT, S; HSIEH, W. C. B;, DEBORAH A. W. M; CHANDRA, T; FIKES, A GRUBER, R. E. Bigtable: A Distributed Storage System for Structured Data, 2006 - OSDI '06 Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation - Volume 7
DE DIANA, M.; GEROSA, M. A. NOSQL na Web 2.0: Um Estudo Comparativo de Bancos Não-Relacionais para Armazenamento de Dados na Web 2.0. Workshop de Teses e Dissertações em Banco de Dados. Belo Horizonte: [s.n.]. 2010.
LÓSCIO, B. F.; DE OLIVEIRA, H. R.; PONTES, J. C. D. S. NoSQL no desenvolvimento de aplicações Web colaborativas. Simpósio Brasileiro de Sistemas Colaborativos, Paraty, ago. 2011. Disponível em: http://www.addlabs.uff.br/sbsc_site/SBSC2011_NoSQL.pdf Acessado em: 17 out 2014.
STRAUCH, C. NoSQL Databases. iiWAS '11 Proceedings of the 13th International Conference on Information Integration and Web-based Applications and Services, Nova Iorque, dez. 2011. 278-283. Disponível em: http://dl.acm.org/citation.cfm?id=2095583 Acessado em: 10 out. 2014.
[1]
http://www.computerworld.com/article/2526317/database-administration/no-to-sql--anti-database-movement-gains-steam.html
[2] ORIENTDB.Disponível em: https://github.com/orientechnologies/orientdb/ Acesso em: 05 out. 2014.
[3] FHH: Facebook, Hadoop, and Hive. 2009. http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/
14 [4] “Twitter growth prompts switch from MySQL to 'NoSQL' database”.
http://www.computerworld.com/s/article/9161078/Twitter_growth_prompts_switch_from
