BT

CouchDB, RESTful e um exemplo prático com PHP

Postado por Kassiano Matteussi em 07 Out 2010 |

1. Introdução

O modelo de banco de dados orientado a documento surgiu para contribuir especialmente com o desenvolvimento de sistemas para web, pois combina um modelo de armazenamento de documentos de uma forma intuitiva com um poderoso mecanismo de consulta e facilidades para escalar. Este modelo oferece um novo método para armazenar dados, o que é referido como um modelo de banco de dados orientado a documentos livre de esquema. Ao invés de haver um armazenamento de dados altamente estruturado de um modelo relacional, o CouchDB armazena dados de maneira semi-estruturada.

Sendo assim, percebe-se que o mercado carece de uma ferramenta para auxiliar o gerenciamento destes bancos de dados. Desta forma, no presente artigo será apresentado o estudo para o desenvolvido de uma ferramenta Web com PHP para o gerenciamento de banco de dados CouchDB com o foco em auxiliar na aprendizagem de comunidades acadêmicas e afins, além de fornecer uma ferramenta para contribuir com o trabalho de DBAs no que se refere a gerenciamento de diversas bases de dados orientadas a documentos.

2. Modelo Orientado a Documento

Os bancos de dados neste modelo compreendem uma série de documentos, cada um contendo uma série de campos e valores. Cada documento é independente um do outro e não usam nenhuma restrição quanto a sua estrutura durante a criação. Em vez de um campo de chave primária, cada documento em um banco de dados CouchDB tem um ID único. Esta identificação exclusiva pode ser atribuída pelo usuário ou pelo aplicativo, ou ele pode usar um identificador universalmente exclusivo (UUID); este número aleatório é gerado pelo CouchDB que reduz a chance de duplicar IDs.

Segundo Moraes (2009), a “base de dados orientados a documento é diferente. Não existe hierarquia de dados, somente uma coleção de documentos que pode conter virtualmente qualquer espécie de dados”. Os documentos não precisam ser necessariamente do mesmo tamanho, pois alguns documentos podem conter detalhes de campos que outros não precisam armazenar. “Em outras palavras, você não está condicionado a um esquema de banco de dados”.

Diferente dos bancos de dados relacionais, o banco orientado a documentos não grava dados em tabelas em linhas com campos uniformes. Neste banco de “dados” são inseridos documentos com determinadas características, a cada domínio são inseridos vários campos e esses campos por sua vez podem possuir vários elementos.

2.1. Características

De acordo com Bain (2009), podem ser descritas algumas características deste modelo de banco de dados. Podem-se criar bancos diferentes com vários esquemas.

  • itens são definidos por chaves e a cada item podem ser adicionados vários atributos;
  • em algumas implementações os atributos são todos de um tipo, em outras assumem inteiros, listas e string, entre outros;

Mais algumas características, agora sobre acesso aos dados:

  • os dados são criados, atualizados, e recuperados usando métodos de chamada por API;
  • toda a aplicação e os dados que a integram a lógica estão contidos no código da aplicação.

3. Apache CouchDB

CouchDB foi criado em meados de 2005 por Damien Katz, escrito originalmente em C++ e traduzido para Erlang em 2008. Este combina um modelo intuitivo de armazenagem em documentos com um poderoso sistema de pesquisa acessível via RESTful e HTTP/JSON Api.

Lennon (apud OLIVEIRA, 2009, p.19) observa que o termo ‘Couch’ é um acrônimo para “Cluster of Unreliable Commodity Hardware” (Conjunto de Hardware Não-Confiáveis), “refletindo o objetivo do banco de dados ser extremamente escalável, oferecendo alta disponibilidade e confiabilidade, mesmo quando executando em um hardware que é tipicamente suscetível a falhas”.

O couchDB combina um modelo intuitivo de armazenagem em documentos com um poderoso sistema de pesquisa acessível via RESTful e (HTTP/JSON Api), dentre suas funcionalidades está a replicação bidirecional com detecção de falhas e resolução de conflitos;
sua base de dados é baseada em princípios MapReduce e em vez de armazenar dados em linhas e colunas, o CouchDB gerencia uma coleção de documentos, os chamados “JSON documents”.

Este ainda utiliza um modelo de views baseado em JavaScript para a geração de agregações e filtros, provendo resultados de consultas a partir destes documentos semi- estruturados. Ao invés de armazenar dados em linhas e colunas, o CouchDB gerencia uma coleção de documentos, os chamados “JSON documents”. O mesmo usa um método de visualização (Design Documents) com funções definidas que agregam dados e filtros para serem computados em paralelo.

Dentre suas funcionalidades estão à replicação bidirecional com detecção de falhas e resolução de conflitos. Essa base de dados é baseada em princípios de redução de código o chamado MapReduce.

3.1. Características Apache CouchDB

Para Anderson (2009), as principais características do CouchDB são:

  • atomicidade;
  • consistência;
  • isolamento;
  • durabilidade;
  • confiabilidade;
  • tolerante a falhas;
  • suporte a replicação.

4. Desenvolvimento do protótipo

Para o desenvolvimento do projeto, a linguagem PHP foi selecionada devido às inúmeras vantagens compostas pela mesma, tais como, sua vasta documentação, facilidade de uso e aprendizagem, bem como sua imensa biblioteca de funções.

4.1. PHP

O PHP teve inicio por Rasmus Ledorf, que resolveu criar alguns scripts simples para integração com seu site pessoal no ano de 1994. Ledorf queria na verdade somente dar um pouco de vida aos sites estáticos existentes naquele momento, mas ele não imaginava que estava nascendo ali uma das mais poderosas ferramentas para Web, o PHP.

4.2 Usos da Web Service no presente trabalho

No presente trabalho o uso de Web Service se torna primordial para o funcionamento da base de dados uma vez que todas as manipulações são feitas através de chamadas HTTP, usando RESTful/JSON Api.

A Web Service reúne padrões que asseguram a interoperabilidade; estes podem ser acessados via protocolos padrões da Web, tais como: HTTP, HTTPS, entre outros. Os mesmos podem ser aplicados a diversas plataformas de integração e suportam tanto aplicações ponto a ponto (estruturas mais simples) quanto aplicações distribuídas (estruturas mais complexas).

4.3 RESTful

Para Fielding (apud OLIVEIRA, 2009, p.51), REST é “um conjunto de princípios arquiteturais que quando aplicadas como um todo enfatiza a escalabilidade da interação entre componentes para reduzir a latência de interação, garantir segurança e encapsular sistemas legados”.

Fielding também cunhou o termo RESTful e os classificou com os seguintes princípios:

  • cliente servidor;
  • apoiar sistemas de cache;
  • estado nulo;
  • sistema em camadas, ou seja, suportar escalabilidade;
  • stateless;
  • sistema uniforme composto por 4 diretivas padronizadas, GET, PUT, POST, DELETE;

4.4 Características RESTful

Algumas características do RESTful:

  • atribuir identificação as unidades de recurso – URI;
  • utilização de métodos padronizados, GET, PUT, POST, DELETE;
  • apresenta recursos com múltiplas representações ou seja como os dados podem ser tratados text/json, text/xml;
  • comunicação sem controle de estado, esta define que não deve haver dados da sessão do cliente armazenados no servidor.

4.5 Implementação do protótipo

O protótipo tem por fim gerenciar bancos de dados CouchDB, bem como criar o controle para acesso por usuário sobre estes bancos, além de suprir algumas deficiências encontradas em sua interface de administração original, o Futon.

4.6 Pré-requisitos para o funcionamento do protótipo

É necessário observar alguns itens para o pleno funcionamento da interface, antes de usá- la. São eles:

  • o firewall do servidor deve estar desativado, ou deve conter regras para liberação de leitura e escrita para os clientes;
  • o servidor deve conter o Apache CouchDB 0.10 ou superior instalado para funcionamento, uma vez que o protótipo foi construído para uso nestas versões;
  • é necessário que o bind_adress do servidor CouchDB esteja setado com o ip “0.0.0.0”, isso fará com que o banco de dados libere acessos a conexões externas;
  • é necessário que as duas pontas estejam conectadas minimamente a uma rede;
  • a porta deve estar configurada como 5984/tcp no momento de cadastros de novos bancos;

4.7 Interface

Abaixo uma das telas correspondentes a interface produzida.

Tela para adicionar documentos e atributos

Nesta figura, o administrador pode cadastrar um documento passando um nome para o documento, um atributo e um valor; as validações são feitas com javascript, codificação pode ser vista na continuidade:

$curl = curl_init();//Inicia a seção
$aux_conect = "http://".$ip_v.":".$porta_v."/".$bde_v."/".$documento["_id"];
// Remove a chave _id do documento, necessário quando se vai adicionar mais um //atributo ao documento, caso isso não seja feito o banco retorna um erro de //conflito
$documento["_id"] = false;
$documento = array_filter($documento);
curl_setopt($curl, CURLOPT_URL, $url);
//Define o tipo do conteúdo das mensagens a serem criadas, no caso text/json
curl_setopt($curl, CURLOPT_HTTPHEADER, array("Content-Type: text/json"));
curl_setopt($curl, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
//Definindo a entrada dos dados ao documento
curl_setopt($curl, CURLOPT_POSTFIELDS, json_encode($documento));
$retorno = curl_exec($curl);
curl_close($curl);
$retorno = json_decode($retorno);
//Quando um documento é criado com sucesso ele retorno a mensagem {ok ,true} //sendo assim faço a verificação abaixo
if(isset($retorno->ok) && $retorno->ok == "true") {
//retorna menssagem
}

4.8 Vantagens da interface produzida

Abaixo algumas vantagens correspondentes a nova interface produzida:

  • gerenciamento multiplataforma;
  • gerenciamento distribuído;
  • controle de acesso;
    segurança;
  • flexibilidade;
  • controle de usuários;
  • controle sob os dados com maior facilidade;
  • controle de níveis de acesso sobre os bancos aos usuários;
  • com adaptações no código pode ser usada para gerenciar outros bancos de dados SGBD NoSQL;

5. Conclusões

O CouchDB é um ótimo banco de dados. É um novo paradigma que esta crescendo rápido, graças a sua consistência. Sua documentação melhora gradativamente junto com seus grupos de discussões e sites com conteúdos e informações sobre as suas funcionalidades.

O PHP teve papel fundamental no desenrolar do processo, pois combina poderosos mecanismos de programação aliados a sua facilidade de uso e aprendizagem, outro sim se pode observar a evolução obtida pelo acadêmico em técnicas de programação no decorrer do desenvolvimento da interface.

Com este protótipo, o controle da aplicação CouchDB fica muito mais fácil, pois combina controle de usuários com gerência sobre os bancos e suas informações, ficando muito semelhante a ferramentas disponíveis para os SGBDR.

Referências

ANDERSON, Chirs. 2009. Apache CouchDB: The definitive Guide. Disponível em: http://couchdb.apache.org/ Acessado em 05/06/2009.

CHANDLER, Christopher. CouchDB in Action: Greenwich, Manning, 2009.

MORAES, Leonardo. Introdução ao CouchDB. Disponível em: http://leonardomoraes.com.br/blog/. Acessado em 06/06/2009

OLIVEIRA, Leonardo Eloy. Estado da arte de banco de dados orientados a documento, 2009. Monografia (Conclusão do Curso de Graduação em Ciências Tecnológicas) – Universidade de fortaleza – UNIFOR, Ceára, 2009.

Este artigo foi um resumo dos meus artigos originais que podem ser encontrados em:
http://www2.unochapeco.edu.br/~kassianojm/kassiano_artigo.pdf
http://www2.unochapeco.edu.br/~kassianojm/kassiano_mono.pdf

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

REST ... by Marcio Torres

Muito legal. Ainda não tive a oportunidade de trabalhar com esses bancos schema-less. Ficou muito boa a sua monografia, então, está aprovado? Espero que sim.

Apenas achei estranha a figura 14, da equivalência dos métodos HTTP com o SQL onde menciona POST = update e PUT = insert, e sei que pegaste o que está na fonte.

Já vi na internet opiniões sobre POST/PUT e qual seria para criar ou atualizar, mas na maioria vejo o POST como sendo o CREATE e PUT o UPDATE.

Até dei uma olhada no artigo do Sr. Tyagi e achei lá no meio isto:


With RESTFul web services, there is a natural mapping between the HTTP methods and most CRUD-like business operations that many services expose. Though there are no hard and fast rules, the following general guidelines are applicable for most cases:

GET is used to retrieve data or perform a query on a resource. The data returned from the web service is a representation of the requested resource.

POST is used to create a new resource. The web service may respond with data or status indicating success or failure.

PUT is used to update existing resources or data.

DELETE is used to remove a resource or data.


Com o incentivo de seu artigo fui dar uma olhada no CouchDB e POST/PUT são respectivamente para CRIAR/ATUALIZAR.

Alguém mais aí passou por esses misconceptions do REST?

Abraço a todos e parabéns pelo trabalho Kassiano, foi excelente.

Re: REST ... by Kassiano Matteussi

Obrigado pela contribuição caro amigo.

O POST e PUT geralmente causam um nó em muitas mente, inclusive na minha.

a lógica usada foi a seguinte.

Se o documento ainda não existe e você deseja cria um do zero use o POST

Caso o documento já exista e você deseja somente atualizar o mesmo use o PUT.

espero ter esclarecido sua duvidá.

e a propósito fui Aprovado, hahaha.

Boa noite.

Correção by Guilherme Garnier

Uma pequena correção: a URL para o guia (na seção de referências) é couchdb.apache.org/

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT