1. Banco de Dados Orientado a Documentos com
CouchDB
Filipe Silvestrim
22 de Novembro de 2009
Resumo
Bancos de Dados Orientado a Documentos não armazenam dados em
tabelas com campos de tamanhos uniforme para cada registro. Ao invés
disso, cada registro é armazenado com um documento com características
próprias. Com isso, não existem restrições a tamanhos de campos ou tamanho. CouchDB, da Apache Foundation, é uma distribuição tolerante
a falhas e livre de schema baseada em banco de dados orientado a documentos acessível via RESTful HTTP / JSON API. Este banco de dados
não é orientado a objetos.
1
Introdução
Para a maioria dos desenvolvedores de sistemas banco de dados é sinônimo
de tabelas, tuplas, SQL1 , SGBD’s2 , ou normalização, porém tais palavras não
definem um banco de dados ou mesmo dão seu significado. Tais palavras apenas dão significado a um banco de dados que segue o modelo relacional (com
sua estrutura disposta em forma de tabelas, compostas por tuplas (linhas) e
colunas) uma vez que este é o modelo mais reconhecido e utilizado pela comunidade, contudo, tal modelo não é a resposta para todos os problemas envolvendo
armazenamento de dados.
Quando são encarados problemas de escalabilidade e replicabilidade de dados nota-se, acarretando, respectivamente, a desaceleração nos processos e o aumento do custo das despesas de funcionamento. Visto isso, quando problemas
desse tipo acontecem, necessita-se fazer partilha dos dados em diversos servidores, 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 outros
tipos de modelos além do objeto relacional. Neste escopo, dentre tantos modelos
de dados existentes (distribuídos, flat, hierárquico, rede, etc. ), será estudado,
nesse artigo, um dos modelos de bancos não relacionais (NoSQL3 ) o modelo
orientado a documentos — um modelo de banco de dados que tem despertado
a atenção dos desenvolvedores para Internet, em função da sua flexibilidade e
adaptabilidade aos tipos de dados hoje circulando pela grande rede.
1 Structured
Query Language
Gerenciador de Banco de Dados
3 O 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).
2 Sistema
1

2. O movimento NoSQL ganhou muita força com a publicação dos papers “Bigtable: A Distributed Storage System for Structured Data” [] e “Dynamo: Amazon’s Highly Available Key-value Store” []; apesar destes papers serem baseados
em aplicações proprietárias, a maioria das tecnologias que participam do movimento são opensource. Todos os novos bancos derivados desse novo movimento
possuem a característica em comum de serem key-value stores, ou seja eles salvam, como o nome sugere, um conjunto de entradas formadas por uma chave
associada a um valor de qualquer tipo que está sendo salvo de forma desnormalizada (schema-free). Diferentemente dos bancos SQL, este não é constituído
de 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 dentro
e fora da nuvem, sendo guiados por meio de um dizer: “Se você quer um banco
de dados vasto, e com escalabilidade por demanda, você precisa de um banco
de dados não relacional”.
O CouchDB é um banco de dados, free e opensource escrito na linguagem
Erlang, dentre os mais famosos no time dos key-value stores. Este banco de
dados usa documentos para dar definir uma estrutura no banco, armazenando
uma chave associado ao um documento. Ele tem um sistema de armazenamento
e apresentação dados via JSON, sendo documentos que não precisam compartilhar um esquema, porém mantêm a capacidade de consulta por intermédio de
views.
2
Background
Antigamente, quando o código era escrito principalmente com linguagens como
COBOL, até mesmo bancos de dados navegacionais eram suficientes. Bancos
de dados relacionais tem sido quase a única maneira de garantir persistências
de dados de aplicações, sendo que com a implementação desse tipo de modelo
tornaram-se muito mais fácil a consulta a dados. Desde então, não mudou muita
coisa na nossa forma de armazenamento de dados — isto pode ser atribuído ao
fato de que o desempenho da consulta ainda é um dos aspectos mais importantes
para a escolha de um mecanismo de persistência.
Banco de dados relacional são consultados utilizando SQL, sendo que conjuntos de resultados são produzidos a partir de consultas que tem por objetivo
acessar 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 essa
união é feita utilizando um critério definido na relação entre tabelas e colunas).
Para garantir uma mistura de simplicidade, robustez, flexibilidade, escalabilidade, performance, e compatibilidade acerca de dados genéricos, este tipo de
banco de dados tende a aumentar sua complexibilidade internamente (Por exemplo, um simples SELECT em SQL pode ter centenas de querys em potencial em
seu plano de execução).
Apesar desse tipo de modelo ser o mais adotado como espinha dorsal dos
sites modernos, contudo, os dados que permeiam a web são muito voláteis e sem
uma estrutura muito definida e estão se tornando cada vez mais difícil de serem
encaixados em um schema de banco de dados fixo, que é alterado ao longo do
tempo.
A fim de fornecer um novo tipo de flexibilidade de dados, a web está migrando
2

3. para um modelo de banco de dados orientado a documentos, onde os registros
não são agrupados por sua estrutura, mas sim, por seus atributos. Mesmo com
a existência de bibliotecas de mapeamento objeto relacional (como Hibernate
ou Active Record) na tentativa de esconder o modelo relacional subjacente, os
dados esparsos e desnormalizados não foram destinados a estes tipos de sistemas.
Mesmo com essas deficiências em manipular dados muito escaláveis, o modelo
relacional não está fadado ao declínio, pois toda a lógica de negócios e sua
estrutura 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 diferentes
necessidades.
Para serviços de armazenagem de dados na nuvem, empresas como Amazon
tiveram que resolver esta limitação, porque uma nuvem sem uma plataforma
de armazenamento de dados escaláveis não é muito de uma plataforma para
todos. 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 que
incidisse sobre escalabilidade, à custa dos outros benefícios que vêm com bancos
de dados relacionais.
Esta nova geração de SGBD são comumente chamados de armazenamento
sob chave/valor — apesar de nenhum nome oficial ainda existir, então muitas
vezes temô-los referenciados como orientados a documentos, voltados para a
Internet, orientado a atributos, entre outros.
3
Banco de Dados Orientado a Documentos
Como já visto anteriormente, banco de dados orientado a documentos ou de
armazenamento chave/valor, não são registrados em tabelas ou em campos de
tamanho fixo — na verdade, não há nenhuma tabela, linha, coluna ou relacionamento em um banco de dados orientado a documentos. Ao invés disso, cada
registro é armazenado como sendo um documento com características específicas. Qualquer número de campos, de qualquer tamanho ou conteúdo, podem
ser 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 banco
de dados.
Cada documento possui algumas informações similares e outras diferenciadas
— mas diferentemente de SGBDR onde cada registro teria o mesmo conjunto
de campos e campos não utilizados podem ser mantidos vazios, nos registros
em documento não existem campos vazios, isso acontece uma vez que esse tipo
de sistema permite a adição e remoção de dados a qualquer momento, sem o
desperdício de armazenagem de campos vazios.
Vale aqui ressaltar que o uso de XML, YAML ou JSON para armazenamento de informação tem vantagens similares aos banco de dados orientados
a documentos. Nestas línguas cada registro pode ter um valor não-padrão de
informação (chamando de dados semi-estruturado).
Outra vantagem sob banco de dados orientados a documentos é a facilidade
de uso e programação acerca desses tipos de dados armazenados, pois a informação pode ser adicionada sem preocupações como tamanho do registro e
também, programadores necessitam apenas da construção de uma interface para
3

4. manipular com os dados, uma vez que a maioria deles possuem uma sintaxe e
compreensão de fácil manuseio.
O benefício desse tipo de banco de dados para armazenar largas quantidades
de registros em um gigantesco banco de dados é que não existe a necessidade
de modificações em número ou tipos de tuplas em uma tabela; isso é possível
uma vez que com estes novos tipos de modelos de banco de dados é necessário
somente adicionar novos documentos com a nova estrutura — feito isso o banco
de dados automaticamente irá inserir esse novo dado ao atual banco. Ou seja,
se um documento precisar incluir um novo campo, pode simplesmente incluir
esse campo, sem afetar de forma adversa outros documentos do banco de dados.
Outra diferença entre esses tipos de bancos de dados está no armazenamento
de identificadores exclusivos. É comum que os bancos de dados relacionais
usem o conceito de chaves primárias, gerados por um recurso de incremento
automático ou por um gerador de seqüência. É claro que esses identificados são
exclusivos 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ção
de atualização for feita ao mesmo tempo em dois bancos de dados em redes
separadas, ambos não podem recuperar precisamente o próximo identificador
exclusivo.
Outra diferença chave entre os bancos de dados orientados a documentos e
os relacionais é que os bancos de dados orientados a documentos não suportam
junções. Isso é uma conseqüência de não haver nenhuma chave primária nem
estrangeira. A não existência de chaves para basear as junções não significa que
não seja possível recuperar um conjunto de dados relacionados a partir de um
banco de dados orientado a documento, ao invés de chaves, existem as views que
permitem criar uma relação arbitrária entre documentos (relação que não fora
definida no próprio banco de dados). Isso significa que é possível obter todos
os benefícios de consultas de junções SQL típicas sem o peso de predefinir seus
relacionamentos na camada do banco de dados.
É importante observar que, apesar de bancos de dados orientados a documentos operarem de maneira diferente dos bancos de dados relacionais, eles
não são uma tentativa de substituir os bancos de dados relacionais; bem pelo
contrário, são uma alternativa para que os projetos que requerem grande armazenamento em grande escala e muito dinâmico (como wikis, blogs e sistemas de
gerenciamento de documentos) possam viver livre da preocupação de problemas
como escalabilidade, portabilidade, compartilhamento e serviços na nuvem.
3.1
O CouchDB
O CouchDB é um sistema de software livre de gerenciamento de banco de dados orientado a documentos desenvolvido em Erlang4 que armazena dados no
formato 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 a
documentos) de ser extremamente escalável, oferecendo alta disponibilidade e
confiabilidade, mesmo ao executar em hardware que está geralmente sujeito à
falhar.
4 Erlang é 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

5. O CouchDB é um projeto de software livre de alto nível da Apache Software
Foundation, liberado sob a V2.0 da licença Apache. Essa licença de software
livre permite que o código de origem seja usado e modificado para ser usado em
outro software, desde que o aviso de copyright e a renúncia de responsabilidade
sejam 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 atualmente
suportado oficialmente, está sendo realizado um trabalho em um instalador
binário não oficial para a plataforma Windows).
No CouchDB, não há nenhum mecanismo de bloqueio de acesso de dado
simultâneo, em vez disso, usa-se um método referido como Multiversion concurrency control (MVCC) — onde cada cliente recebe uma captura instantânea da
versã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 redes
separadas, ambos não podem recuperar precisamente o próximo identificador
exclusivo. Não sendo fornecido com um recurso de incremento automático ou
de sequência, o CouchDB designa um Universally Unique Identifier (UUID) para
todo e qualquer documento, tornando praticamente impossível que outro banco
de dados selecione acidentalmente o mesmo identificador exclusivo.
Até o momento, o CouchDB não é realmente um banco de dados distribuídos. Pois, ele não tem funções de replicação que permitam que os dados
sejam sincronizados entre os servidores, mas esse não é o tipo de distribuição
necessário para construir ambientes altamente escaláveis.
O CouchDB é construído em um poderoso mecanismo de armazenamento Btree, que é responsável por manter os dados do CouchDB classificados e fornece
um mecanismo para procurar, inserir e excluir em tempo amortizado de forma
logarí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ça
benefícios em termos de flexibilidade e escalabilidade, o CouchDB depende do
uso de views para criar relacionamentos arbitrários entre documentos e para
fornecer recursos de agregação e relatório (para desnormalizar os dados). As
views são utilizadas para extrair dados dos documentos e são baseadas nos
conceitos de MapReduce. A função de MAP extrai os dados dos documentos
enquanto a função de REDUCE executa cálculos sobre os dados retornados pela
função de MAP. Views podem ser permanentes ou temporárias.
Visualizações no CouchDB são criadas on demand e podem ser usadas para
agregar, juntar e relatar sobre documentos do banco de dados. Elas são construídas dinamicamente e não têm nenhum efeito nos documentos do banco de
dados. As visualizações são definidas em documentos de design e podem ser
replicadas em instâncias. Esses documentos de design contêm funções JavaScript que executam consultas usando o conceito MapReduce. A função mapear
da visualização usa o documento como um argumento e executa uma série de
computações para determinar quais dados devem estar disponíveis através da
visualização. Se uma visualização tiver uma função reduzir, é usada para agregar os resultados. Recebe um conjunto de chaves e valores e combina os mesmos
em um único valor.
5

6. 3.1.2
Conclusões
Em última análise, existem quatro razões pelas quais deveriam ser escolhidos
banco de dados não-relacionais para aplicações: 1) Quando os dados são fortemente orientados a documentos, tornando-se mais natural a adaptação ao
modelo chave/valor. 2) Quando o ambiente de desenvolvimento é fortemente
orientado a objetos aonde um banco de dados de chave/valor poderia minimizar
a necessidade de ajuste de código. 3) O armazenamento de dados é mais barato
e se integra facilmente com o fornecedor de serviços web. 4) Quando a principal
preocupação é on-demand, escalabilidade, compartilhamento e persistência em
nuvem. 5) Quando as limitações do banco de dados e os riscos enfrentados por
ramificaçõ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 de
possibilidade dentro dos modelos de bancos de dados existentes. Eles nunca
irão “matar” bancos de dados relacionais ou outros, porém eles se adaptam
melhor a necessidade e dificuldades que os outros apresentam. Essa dificuldade
não quer dizer que esses bancos são piores, mas sim que eles possuem propósitos
diferentes. Os bancos de dados relacionais surgiram em um momento anterior
a 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 receber
milhares de acessos por segundo sendo necessário mais de uma instancia para
servir aos usuários. É nesse momento os bancos de dados tradicionais começam
a se tornar um gargalo e que bancos de dados orientados a documentos, como
o 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, 1st
Edition, O’Reilly Media, Inc. Online. Acessado em 20 de Novembro de
2009. Disponível em <http://books.couchdb.org/relax/>.
[3] Michael J. Carey; David J. DeWitt. Of Objects and Databases: A
Decade of Turmoil. Proceedings of the 22nd VLDB Conference. Mumbai(Bombay), India, 1996
[4] Apache CouchDB, Online. Acessado em 20 de Novembro de 2009. Disponível em <http://couchdb.apache.org/>
[5] IBM,
Explorando
o
CouchDB,
Online.
Acessado
em
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). Online. 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. Disponível em <http://json.org/>.
6