View Indexes

Antes de começar com a tradução sobre os índices de views do CouchDB, quero fazer um agradecimento especial ao Marcos Tapajós pela divulgação em CouchDB para brasileiros. O Tapajós trabalha para o Redeparede, para a Improve It e é commiter da gem CouchRest. Valeu Tapajós =]

Índices de views

As views são representações dinâmicas do conteúdo atual dos documentos de um banco de dados, e o CouchDB faz ser simples a criação de views úteis dos dados. Mas gerar uma view de um banco de dados com centenas de milhares ou milhões de documentos leva tempo e consome recursos, não é algo que o sistema deve fazer do zero toda hora.

Para manter a exibição de consultas rápida, a view engine mantém índices dessas views, e atualiza-os incrementalmente para refletir as mudanças no banco de dados. O design do core do CouchDB é largamente otimizado para criação eficiente de views e seus índices.

Visões e suas funções são definidas dentro de documentos especiais de “design” e um documento de design pode conter várias funções de views (unicamente nomeadas). Quando um usuário abre uma view e seu índice é automaticamente atualizado, todas as views no mesmo documento de design são indexadas em um único grupo.

O construtor de views usa o ID de sequência do banco de dados para determinar se um grupo de views está totalmente atualizado com o banco de dados. Se não, a view engine examina todos os documentos do banco (embalados em ordem sequencial) mudados desde a última atualização. Os documentos são lidos na ordem em que estão os arquivos no disco, reduzindo a frequência e custo de buscas no disco.

As views podem ser lidas e consultadas simultaneamente enquanto estão também sendo atualizadas. Se um cliente está recebendo o conteúdo de uma view grande, a mesma view pode ser aberta e atualizada concorrentemente por outro cliente sem bloquear o primeiro cliente. Isso é verdade para qualquer número de leituras de clientes simultâneos, que podem ler e consultar a view enquanto o índice está concorrentemente sendo atualizado por outros clientes sem causar problemas para os leitores.

Assim os documentos são examinados, os seus valores de linha anterior são removidos dos índices de views, se existirem. Se o documento for selecionado por uma função de view, os resultados da função são inseridos na view como uma nova linha.

Quando as mudanças nos índices de views são escritas no disco, as atualizações são sempre anexadas ao fim do arquivo, servindo tanto para reduzir as buscas no disco durante commits e para garantir que crashes e falhas de falta de energia não corrompam os índices. Se uma falha ocorrer durante uma atualização de um índice, a atualização incompleta do índice é simplesmente perdida e reconstruída incrementalmente a partir do seu estado anterior.

Essa é uma tradução adaptada:
http://couchdb.apache.org/docs/overview.html

Views no CouchDB

Views são o método de agregação e relatórios sobre os documentos em uma base de dados (os SELECTs dos bancos relacionais), e são construídas por demanda para agregar, juntar e reportar documentos. As views são construídas dinamicamente e não afetam o documento subjacente, você poder ter várias representações diferentes dos mesmos dados que desejar.

As definições de views são estritamente virtuais e somente mostram os documentos da instancia corrente do banco de dados, fazendo-os separados dos dados que eles mostram e compatíveis com replicação. As views do CouchDB são definidas dentro de documentos de design especiais e podem ser replicadas em várias instancias de bancos de dados como documentos regulares, de modo que não apenas os dados são replicados no CouchDB, mas o design da aplicação inteira também é replicado.

Funções Javascript

As views são definidas usando funções javascript que atuam como map em um sistema de map-reduce. Uma view pega um documento do CouchDB como um argumento e então faz o cálculo que precisar fazer para determinar os dados que serão disponibilizados pela view, se houverem. É possível adicionar multiplas linhas para a view com base em um único documento.

Índices de Views

Essa é uma tradução adaptada:
http://couchdb.apache.org/docs/overview.html

CouchDB – Propriedades ACID

O CouchDB possui totais características das propriedades ACID (atomicidade, consistencia, isolamento e durabilidade). Em disco, o CouchDB nunca sobrescreve dados salvos ou estruturas associadas, assegurando que os dados estejam sempre em um estado consistente. Trata-se de um design “crash-only” aonde o servidor CouchDB não passa por um processo de shut down, ele é simplesmente terminado.

Alterações nos documentos (adicionar, editar, deletar) são serializadas, exceto os blobs binários que são escritos concorrentemente. Leituras no banco nunca são bloqueadas (lock) e nunca tem que esperar por escritas ou outras leituras. Qualquer número de clientes podem ler documentos sem serem bloqueados ou interrompidos por atualizações concorrentes, mesmo no mesmo documento. O CouchDB lê operações utilizando o modelo MVCC (Multiversion concurrency control) aonde cada cliente ve uma cópia consistente do banco de dados desde o início até o fim da operação de leitura.

Os documentos são indexados em b-trees pelo seu nome (DocID) e um ID de sequência. Cada atualização para uma instância de banco de dados gera um novo número sequencial. IDs de sequência são usados depois para encontrar as mudanças de forma incremental em uma base de dados. Esses índices b-trees (árvores B) são atualizados simultaneamente quando os documentos são salvos ou deletados. A atualização dos índices sempre ocorre no final do arquivo (append-only updates).

Os documentos têm a vantagem dos dados serem convenientemente “embalados” para armazenamento em vez de dividir em numerosas tabelas e linhas como na maioria dos bancos de dados. Quando os documentos são salvos em disco, os campos dos documentos e metadados são colocados em buffers, sequencialmente um documento depois do outro (depois isso é útil para construção de views).

Quando os documentos do CouchDB são atualizados, todos os dados e índices associados são “descarregados” (flushed) no disco e o commit transacional sempre deixa o banco em um estado completamente consistente. Commits ocorrem em dois passos:

1 – Todos os dados dos documentos e atualizações em índices associados são “esvaziados” (flushed) no disco de maneira síncrona.
2 – O cabeçalho do banco de dados atualizados é escrito em dois pedaços consecutivos e idênticos para compor os primeiros 4k do arquivo, então é “esvaziados” (flushed) no disco de maneira síncrona.

No caso do sistema operacional dar “crash” ou uma falta de energia no passo 1, as atualizações parcialmente liberadas são simplesmente esquecidas ao reiniciar. Se acontecer algum acidente no passo 2 (commitando o cabeçalho), uma cópia sobrevivente idêntica aos cabeçalhos anteriores permanecerão, garantido a coerência de todos os dados previamente salvos. Exceto a área de cabeçalho, checagens de consistencia ou consertos depois de um crash ou falta de energia, nunca são necessários.

Essa é uma tradução adaptada:
http://couchdb.apache.org/docs/overview.html

Como os documentos são armazenados no CouchDB?

O CouchDB armazena os dados em documentos. Cada documento tem um nome único no banco e o CouchDB provê uma API HTTP RESTful para ler e atualizar (adicionar, editar, excluir) os documentos do banco de dados.

Os documentos são as unidades primárias de dados, consistem em um número qualquer de campos e anexos. Os documentos também incluem metadados que são mantidos pelo sistema de banco de dados. Os campos possuem nomes únicos (por documento) e contem valores de vários tipos (texto, número, booleano, listas, etc) e não há qualquer limite definido para o tamanho do texto ou elemento.

O modelo de atualização de documentos do CouchDB é lockless (sem lock) e otimista. Edições nos documentos são feitas por aplicações clientes que carregam os documentos, aplicam as alterações e salvam de volta ao banco de dados. Se outro cliente que estiver editando o mesmo documento salvar as alterações primeiro, o cliente recebe um erro de conflito de edição. Para resolver o conflito de atualização, a versão mais recente do documento pode ser aberta, a edição é reaplicada e a atualização é tentada novamente.

As alterações nos documentos (adicionar, editar, excluir) são “tudo ou nada”, tem sucesso completamente ou falha completamente. O banco nunca contem documentos salvos ou editados parcialmente.

Essa é uma tradução adaptada do início do Overview técnico do CouchDB:
http://couchdb.apache.org/docs/overview.html

Instalar CouchDB no Ubuntu

Para instalar o CouchDB no Ubuntu você pode simplesmente rodar o seguinte comando:

sudo apt-get install couchdb

Se quiser ter a última versão:

sudo apt-get build-dep couchdb
sudo apt-get install libmozjs-dev libicu-dev libcurl4-gnutls-dev libtool

Baixe a última versão (.tar.gz)
http://couchdb.apache.org/downloads.html

Descompacte (hoje a versão mais nova é a 0.10.1)
tar -zxvf apache-couchdb-0.10.1.tar.gz
cd apache-couchdb-0.10.0

Instale
./configure
make
sudo make install

Com o couchdb instalado, rode para testar:
sudo couchdb
e abra no browser http://localhost:5984/_utils

Você pode encontrar mais detalhes na wiki do couchdb.

CouchDB

Um conceito interessante que conheci recentemente é o do NoSQL. Existem alguns bancos de dados orientados a documentos que estão sendo comentados com certa frequência pela comunidade. Fiz uma tradução sobre o CouchDB, em breve vou escrever sobre ele e também sobre o MongoDB.

O Apache CouchDB é um banco de dados orientado a documentos que pode ser consultado e indexado com MapReduce utilizando Javascript. O CouchDB também oferece replicação incremental com detecção de conflitos bi-direcionais e resolução.

O CouchDb provê uma API JSON RESTful que pode ser acessada por qualquer ambiente que permita requisições HTTP. Existem inúmeras bibliotecas de terceiros que fazem seu uso mais fácil da linguagem de programação de sua escolha. CouchDB tem um console de administração web que fala diretamente com o banco de dados usando requisições HTTP enviadas do seu navegador.

É escrito em Erlang, uma linguagem de programação robusta, funcional ideal para construir sistemas distribuídos concorrentes. Erlang permite design flexível que é facilmente escalável e facilmente extensível.