Banco de Dados Orientado a Documentos comCouchDB

Filipe Silvestrim

22 de Novembro de 2009

ResumoBancos de Dados Orientado a Documentos não armazenam dados em

tabelas com campos de tamanhos uniforme para cada registro. Ao invésdisso, cada registro é armazenado com um documento com característicaspróprias. Com isso, não existem restrições a tamanhos de campos ou ta-manho. CouchDB, da Apache Foundation, é uma distribuição tolerantea falhas e livre de schema baseada em banco de dados orientado a docu-mentos acessível via RESTful HTTP / JSON API. Este banco de dadosnão é orientado a objetos.

1 IntroduçãoPara a maioria dos desenvolvedores de sistemas banco de dados é sinônimode tabelas, tuplas, SQL1, SGBD’s2, ou normalização, porém tais palavras nãodefinem um banco de dados ou mesmo dão seu significado. Tais palavras ape-nas dão significado a um banco de dados que segue o modelo relacional (comsua estrutura disposta em forma de tabelas, compostas por tuplas (linhas) ecolunas) uma vez que este é o modelo mais reconhecido e utilizado pela comuni-dade, contudo, tal modelo não é a resposta para todos os problemas envolvendoarmazenamento de dados.

Quando são encarados problemas de escalabilidade e replicabilidade de da-dos nota-se, acarretando, respectivamente, a desaceleração nos processos e o au-mento do custo das despesas de funcionamento. Visto isso, quando problemasdesse tipo acontecem, necessita-se fazer partilha dos dados em diversos servi-dores, acarretando em gastos (com sistemas pagos como Oracle e Microsoft),diante da infra-estrutura necessária para amparar tais requisições.

Diante desse ponto de vista é importante evidenciar a presença de outrostipos de modelos além do objeto relacional. Neste escopo, dentre tantos modelosde dados existentes (distribuídos, flat, hierárquico, rede, etc. ), será estudado,nesse artigo, um dos modelos de bancos não relacionais (NoSQL3) o modeloorientado a documentos — um modelo de banco de dados que tem despertadoa atenção dos desenvolvedores para Internet, em função da sua flexibilidade eadaptabilidade aos tipos de dados hoje circulando pela grande rede.

1Structured Query Language2Sistema Gerenciador de Banco de Dados3O movimento NoSQL tem como objetivo resolver o problema de escalabildade dos bancos

tradicionais (devido o motivo de ser muito caro ou/e complexo escalar um banco SQL).

1

O movimento NoSQL ganhou muita força com a publicação dos papers “Big-table: A Distributed Storage System for Structured Data” [] e “Dynamo: Ama-zon’s Highly Available Key-value Store” []; apesar destes papers serem baseadosem aplicações proprietárias, a maioria das tecnologias que participam do movi-mento são opensource. Todos os novos bancos derivados desse novo movimentopossuem a característica em comum de serem key-value stores, ou seja eles sal-vam, como o nome sugere, um conjunto de entradas formadas por uma chaveassociada a um valor de qualquer tipo que está sendo salvo de forma desnor-malizada (schema-free). Diferentemente dos bancos SQL, este não é constituídode um schema — facilitando a distribuição dos dados entre vários servidores,sendo cada servidor possuidor apenas de uma fatia dos dados (shard).

Recentemente, vários novos bancos de dados não relacionais surgiram dentroe fora da nuvem, sendo guiados por meio de um dizer: “Se você quer um bancode dados vasto, e com escalabilidade por demanda, você precisa de um bancode dados não relacional”.

O CouchDB é um banco de dados, free e opensource escrito na linguagemErlang, dentre os mais famosos no time dos key-value stores. Este banco dedados usa documentos para dar definir uma estrutura no banco, armazenandouma chave associado ao um documento. Ele tem um sistema de armazenamentoe apresentação dados via JSON, sendo documentos que não precisam compar-tilhar um esquema, porém mantêm a capacidade de consulta por intermédio deviews.

2 BackgroundAntigamente, quando o código era escrito principalmente com linguagens comoCOBOL, até mesmo bancos de dados navegacionais eram suficientes. Bancosde dados relacionais tem sido quase a única maneira de garantir persistênciasde dados de aplicações, sendo que com a implementação desse tipo de modelotornaram-se muito mais fácil a consulta a dados. Desde então, não mudou muitacoisa na nossa forma de armazenamento de dados — isto pode ser atribuído aofato de que o desempenho da consulta ainda é um dos aspectos mais importantespara a escolha de um mecanismo de persistência.

Banco de dados relacional são consultados utilizando SQL, sendo que con-juntos de resultados são produzidos a partir de consultas que tem por objetivoacessar dados de uma ou mais tabelas. Acessar várias tabelas por meio de umaúnica consulta resulta na união desse conjunto de dados (normalmente essaunião é feita utilizando um critério definido na relação entre tabelas e colunas).Para garantir uma mistura de simplicidade, robustez, flexibilidade, escalabili-dade, performance, e compatibilidade acerca de dados genéricos, este tipo debanco de dados tende a aumentar sua complexibilidade internamente (Por exem-plo, um simples SELECT em SQL pode ter centenas de querys em potencial emseu plano de execução).

Apesar desse tipo de modelo ser o mais adotado como espinha dorsal dossites modernos, contudo, os dados que permeiam a web são muito voláteis e semuma estrutura muito definida e estão se tornando cada vez mais difícil de seremencaixados em um schema de banco de dados fixo, que é alterado ao longo dotempo.

A fim de fornecer um novo tipo de flexibilidade de dados, a web está migrando

2

para um modelo de banco de dados orientado a documentos, onde os registrosnão são agrupados por sua estrutura, mas sim, por seus atributos. Mesmo coma existência de bibliotecas de mapeamento objeto relacional (como Hibernateou Active Record) na tentativa de esconder o modelo relacional subjacente, osdados esparsos e desnormalizados não foram destinados a estes tipos de sistemas.

Mesmo com essas deficiências em manipular dados muito escaláveis, o modelorelacional não está fadado ao declínio, pois toda a lógica de negócios e suaestrutura continuam muito poderosas para sistemas em seu universo de domínio,porém é interessante validar novos tipos de modelos quando o assunto é web,computação na nuvem, portabilidade e escalabilidade em diversos servidores.Ou seja, cada um desses tipos de banco é projetado para atender diferentesnecessidades.

Para serviços de armazenagem de dados na nuvem, empresas como Amazontiveram que resolver esta limitação, porque uma nuvem sem uma plataformade armazenamento de dados escaláveis não é muito de uma plataforma paratodos. Então, com tal situação, tais empresas tiveram uma única opção viável:eles tiveram que implementar um novo tipo de sistema de banco de dados queincidisse sobre escalabilidade, à custa dos outros benefícios que vêm com bancosde dados relacionais.

Esta nova geração de SGBD são comumente chamados de armazenamentosob chave/valor — apesar de nenhum nome oficial ainda existir, então muitasvezes temô-los referenciados como orientados a documentos, voltados para aInternet, orientado a atributos, entre outros.

3 Banco de Dados Orientado a DocumentosComo já visto anteriormente, banco de dados orientado a documentos ou dearmazenamento chave/valor, não são registrados em tabelas ou em campos detamanho fixo — na verdade, não há nenhuma tabela, linha, coluna ou relacio-namento em um banco de dados orientado a documentos. Ao invés disso, cadaregistro é armazenado como sendo um documento com características específi-cas. Qualquer número de campos, de qualquer tamanho ou conteúdo, podemser adicionados ao documento. Isso significa que são livres de esquema, ou seja,não é necessário definir nenhum esquema rígido antes de realmente usar o bancode dados.

Cada documento possui algumas informações similares e outras diferenciadas— mas diferentemente de SGBDR onde cada registro teria o mesmo conjuntode campos e campos não utilizados podem ser mantidos vazios, nos registrosem documento não existem campos vazios, isso acontece uma vez que esse tipode sistema permite a adição e remoção de dados a qualquer momento, sem odesperdício de armazenagem de campos vazios.

Vale aqui ressaltar que o uso de XML, YAML ou JSON para armazena-mento de informação tem vantagens similares aos banco de dados orientadosa documentos. Nestas línguas cada registro pode ter um valor não-padrão deinformação (chamando de dados semi-estruturado).

Outra vantagem sob banco de dados orientados a documentos é a facilidadede uso e programação acerca desses tipos de dados armazenados, pois a in-formação pode ser adicionada sem preocupações como tamanho do registro etambém, programadores necessitam apenas da construção de uma interface para

3

manipular com os dados, uma vez que a maioria deles possuem uma sintaxe ecompreensão de fácil manuseio.

O benefício desse tipo de banco de dados para armazenar largas quantidadesde registros em um gigantesco banco de dados é que não existe a necessidadede modificações em número ou tipos de tuplas em uma tabela; isso é possíveluma vez que com estes novos tipos de modelos de banco de dados é necessáriosomente adicionar novos documentos com a nova estrutura — feito isso o bancode dados automaticamente irá inserir esse novo dado ao atual banco. Ou seja,se um documento precisar incluir um novo campo, pode simplesmente incluiresse campo, sem afetar de forma adversa outros documentos do banco de dados.

Outra diferença entre esses tipos de bancos de dados está no armazenamentode identificadores exclusivos. É comum que os bancos de dados relacionaisusem o conceito de chaves primárias, gerados por um recurso de incrementoautomático ou por um gerador de seqüência. É claro que esses identificados sãoexclusivos somente para a tabela ou o banco de dados no qual são usados —podem ser reutilizados por outras tabelas e bancos de dados. Se uma operaçãode atualização for feita ao mesmo tempo em dois bancos de dados em redesseparadas, ambos não podem recuperar precisamente o próximo identificadorexclusivo.

Outra diferença chave entre os bancos de dados orientados a documentos eos relacionais é que os bancos de dados orientados a documentos não suportamjunções. Isso é uma conseqüência de não haver nenhuma chave primária nemestrangeira. A não existência de chaves para basear as junções não significa quenão seja possível recuperar um conjunto de dados relacionados a partir de umbanco de dados orientado a documento, ao invés de chaves, existem as views quepermitem criar uma relação arbitrária entre documentos (relação que não foradefinida no próprio banco de dados). Isso significa que é possível obter todosos benefícios de consultas de junções SQL típicas sem o peso de predefinir seusrelacionamentos na camada do banco de dados.

É importante observar que, apesar de bancos de dados orientados a docu-mentos operarem de maneira diferente dos bancos de dados relacionais, elesnão são uma tentativa de substituir os bancos de dados relacionais; bem pelocontrário, são uma alternativa para que os projetos que requerem grande arma-zenamento em grande escala e muito dinâmico (como wikis, blogs e sistemas degerenciamento de documentos) possam viver livre da preocupação de problemascomo escalabilidade, portabilidade, compartilhamento e serviços na nuvem.

3.1 O CouchDBO CouchDB é um sistema de software livre de gerenciamento de banco de da-dos orientado a documentos desenvolvido em Erlang4 que armazena dados noformato JSON (não existe necessidade de se definir um esquema previamente)e proporciona uma interface REST para a criação, update e consultas. O termo“Couch"é um acrônimo para “Cluster Of Unreliable Commodity Hardware",refletindo o objetivo do CouchDB (bem como de outros bancos orientados adocumentos) de ser extremamente escalável, oferecendo alta disponibilidade econfiabilidade, mesmo ao executar em hardware que está geralmente sujeito àfalhar.

4Erlang é uma linguagem de programação criada pela Ericsson para aplicações distribuídas,tolerante a falhas e com alto poder de concorrência que se tornou opensource em 1998.

4

O CouchDB é um projeto de software livre de alto nível da Apache SoftwareFoundation, liberado sob a V2.0 da licença Apache. Essa licença de softwarelivre permite que o código de origem seja usado e modificado para ser usado emoutro software, desde que o aviso de copyright e a renúncia de responsabilidadesejam preservados. Os requisitos do sistema para sua instalação são POSIX,incluindo Linux R© e Mac OS X (apesar de o Windows R© não ser atualmentesuportado oficialmente, está sendo realizado um trabalho em um instaladorbinário não oficial para a plataforma Windows).

No CouchDB, não há nenhum mecanismo de bloqueio de acesso de dadosimultâneo, em vez disso, usa-se um método referido como Multiversion concur-rency control (MVCC) — onde cada cliente recebe uma captura instantânea daversão mais recente do banco de dados. Isso significa que nenhuma mudança évista pelos outros usuários até a transação ter sido consolidada. Se uma opera-ção de atualização for feita ao mesmo tempo em dois bancos de dados em redesseparadas, ambos não podem recuperar precisamente o próximo identificadorexclusivo. Não sendo fornecido com um recurso de incremento automático oude sequência, o CouchDB designa um Universally Unique Identifier (UUID) paratodo e qualquer documento, tornando praticamente impossível que outro bancode dados selecione acidentalmente o mesmo identificador exclusivo.

Até o momento, o CouchDB não é realmente um banco de dados distri-buídos. Pois, ele não tem funções de replicação que permitam que os dadossejam sincronizados entre os servidores, mas esse não é o tipo de distribuiçãonecessário para construir ambientes altamente escaláveis.

O CouchDB é construído em um poderoso mecanismo de armazenamento B-tree, que é responsável por manter os dados do CouchDB classificados e forneceum mecanismo para procurar, inserir e excluir em tempo amortizado de formalogarítmica. O CouchDB usa esse mecanismo para todos os dados internos,documentos e visualizações.

3.1.1 As Views do CouchDB

De natureza desestruturada e, embora sua falta de um esquema rígido forneçabenefícios em termos de flexibilidade e escalabilidade, o CouchDB depende douso de views para criar relacionamentos arbitrários entre documentos e parafornecer recursos de agregação e relatório (para desnormalizar os dados). Asviews são utilizadas para extrair dados dos documentos e são baseadas nosconceitos de MapReduce. A função de MAP extrai os dados dos documentosenquanto a função de REDUCE executa cálculos sobre os dados retornados pelafunção de MAP. Views podem ser permanentes ou temporárias.

Visualizações no CouchDB são criadas on demand e podem ser usadas paraagregar, juntar e relatar sobre documentos do banco de dados. Elas são cons-truídas dinamicamente e não têm nenhum efeito nos documentos do banco dedados. As visualizações são definidas em documentos de design e podem serreplicadas em instâncias. Esses documentos de design contêm funções JavaS-cript que executam consultas usando o conceito MapReduce. A função mapearda visualização usa o documento como um argumento e executa uma série decomputações para determinar quais dados devem estar disponíveis através davisualização. Se uma visualização tiver uma função reduzir, é usada para agre-gar os resultados. Recebe um conjunto de chaves e valores e combina os mesmosem um único valor.

5

3.1.2 Conclusões

Em última análise, existem quatro razões pelas quais deveriam ser escolhidosbanco de dados não-relacionais para aplicações: 1) Quando os dados são for-temente orientados a documentos, tornando-se mais natural a adaptação aomodelo chave/valor. 2) Quando o ambiente de desenvolvimento é fortementeorientado a objetos aonde um banco de dados de chave/valor poderia minimizara necessidade de ajuste de código. 3) O armazenamento de dados é mais baratoe se integra facilmente com o fornecedor de serviços web. 4) Quando a principalpreocupação é on-demand, escalabilidade, compartilhamento e persistência emnuvem. 5) Quando as limitações do banco de dados e os riscos enfrentados porramificações fora do caminho relacional não afetarem as decisões do projeto.Para todos outros quesitos, provavelmente SGBDR são mais recomendados.

Ou seja, banco de dados orientados a documentos são um novo leque depossibilidade dentro dos modelos de bancos de dados existentes. Eles nuncairão “matar” bancos de dados relacionais ou outros, porém eles se adaptammelhor a necessidade e dificuldades que os outros apresentam. Essa dificuldadenão quer dizer que esses bancos são piores, mas sim que eles possuem propósitosdiferentes. Os bancos de dados relacionais surgiram em um momento anteriora internet, onde o número de acessos ao banco era algo muito mais previsível.No mundo pós internet as coisas mudaram, um banco de dados pode recebermilhares de acessos por segundo sendo necessário mais de uma instancia paraservir aos usuários. É nesse momento os bancos de dados tradicionais começama se tornar um gargalo e que bancos de dados orientados a documentos, comoo CouchDB pode ser a solução.

Referências[1] Chandler, C., CouchDB in Action, Manning Publications Co., April 2009.

[2] Chris A. J., Lehnardt J., Slater N., CouchDB: The Definitive Guide, 1stEdition, O’Reilly Media, Inc. Online. Acessado em 20 de Novembro de2009. Disponível em <http://books.couchdb.org/relax/>.

[3] Michael J. Carey; David J. DeWitt. Of Objects and Databases: ADecade of Turmoil. Proceedings of the 22nd VLDB Conference. Mum-bai(Bombay), India, 1996

[4] Apache CouchDB, Online. Acessado em 20 de Novembro de 2009. Dispo-nível em <http://couchdb.apache.org/>

[5] IBM, Explorando o CouchDB, Online. Acessadoem 20 de Novembro de 2009. Disponível em<http://www.ibm.com/developerworks/br/library/os-couchdb/>

[6] Fielding, R. T., Representational State Transfer (REST). On-line. Acessado em 20 de Novembro de 2009. Disponível em<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm#sec_5_1>.

[7] Introducing JSON. Online. Acessado em 20 de Novembro de 2009. Dispo-nível em <http://json.org/>.

6