Por que devo usar o banco de dados baseado em documentos em vez do banco de dados relacional?

Por que devo usar banco de dados baseado em documentos como o CouchDB em vez de usar o banco de dados relacional. Existem tipos típicos de aplicativos ou domínios em que o banco de dados baseado em documentos é mais adequado que o banco de dados relacional?

Provavelmente você não deveria :-)

A segunda resposta mais óbvia é que você deve usá-lo se seus dados não forem relacionais. Isso geralmente se manifesta por não ter uma maneira fácil de descrever seus dados como um conjunto de colunas. Um bom exemplo é um banco de dados em que você realmente armazena documentos em papel, por exemplo, digitalizando o correio do escritório. Os dados são o PDF digitalizado e você tem alguns metadados que sempre existem (digitalizados em, digitalizados por, tipo de documento) e vários campos de metadados possíveis que existem em algum momento (número do cliente, número do fornecedor, número do pedido, manter em arquivo até, Texto completo com OCR, etc). Normalmente, você não sabe com antecedência quais campos de metadados você adicionará nos próximos dois anos. Coisas como o CouchDB funcionam muito melhor para esse tipo de dados do que os bancos de dados relacionais.

Pessoalmente, também adoro o fato de não precisar de nenhuma biblioteca de clientes para o CouchDB, exceto um cliente HTTP, que atualmente está incluído em quase todas as linguagens de programação.

A resposta provavelmente menos óbvia: se você não sentir dor usando um RDBMS, continue com ele. Se você sempre precisa contornar o RDBMS para fazer seu trabalho, vale a pena dar uma olhada em um banco de dados orientado a documentos.

Para uma lista mais elaborada, verifique esta postagem de Richard Jones .

CouchDB (do site )

• Um servidor de banco de dados de documentos, acessível por meio de uma API JSON RESTful. Geralmente, os bancos de dados relacionais não são simplesmente acessados ​​por serviços REST, mas requerem uma API SQL muito mais complexa. Geralmente, essas APIs (JDBC, ODBC etc.) são bastante complexas. O REST é bastante simples.

• Ad-hoc e sem esquema com um espaço de endereço plano. Bancos de dados relacionais têm esquema fixo complexo. Você define tabelas, colunas, índices, sequências, visualizações e outras coisas. O sofá não exige esse nível de planejamento avançado complexo, caro e frágil.

• Distribuído, com replicação robusta e incremental com detecção e gerenciamento bidirecional de conflitos. Alguns produtos comerciais SQL oferecem isso. Devido à API SQL e aos esquemas fixos, isso é complexo, difícil e caro. Para o Couch, parece simples e barato.

• Possível para consulta e indexável, apresentando um mecanismo de relatório orientado a tabelas que usa Javascript como linguagem de consulta. O mesmo acontece com SQL e bancos de dados relacionais. Nada de novo aqui.

Assim. Por que o CouchDB?

• O REST é mais simples que o JDBC ou ODBC.
• Nenhum esquema é mais simples que o esquema.
• Distribuído de uma maneira que parece simples e barata.

Por estupidamente armazenar e servir dados de outros servidores.

Nas últimas duas semanas, eu tenho jogado com um aplicativo lifestream que pesquisa meus feeds (delicious, flickr, github, twitter ...) e os armazena no couchdb. A beleza do couchdb é que ele permite que eu mantenha os dados originais em sua estrutura original sem sobrecarga. Adicionei um campo 'class' a cada documento, armazenando o servidor de origem e escrevi uma classe de renderização javascript para cada fonte.

Generalizando, sempre que seu servidor se comunica com outro servidor, é melhor o armazenamento sem esquema, pois você não tem controle sobre o esquema. Como bônus, o couchdb usa os protocolos nativos de servidores e clientes - JSON para representação e HTTP REST para transporte.

O rápido desenvolvimento de aplicativos vem à mente.

Quando estou constantemente evoluindo meu esquema, fico constantemente frustrado por ter que manter o esquema no MySQL / SQLite. Embora ainda não tenha feito muito com o CouchDB, gosto de como é simples evoluir o esquema durante o processo RAD.

Um caso em que você pode não querer usar um banco de dados não relacional é quando você tem muitos relacionamentos muitos-para-muitos; Ainda estou pensando em como criar boas funções do MapReduce para esse tipo de relacionamento, principalmente se você precisar de metadados no relacionamento de união. Não tenho certeza, mas não acho que as funções do Mapa do CouchDB possam chamar suas próprias consultas no banco de dados, pois isso pode causar loops infinitos.

Use um banco de dados baseado em documento quando não precisar armazenar dados em tabelas com campos de tamanho uniforme para cada registro. Em vez disso, você precisa armazenar cada registro como um documento que possui certas características. Qualquer número de campos de qualquer tamanho pode ser adicionado dinamicamente a um documento a qualquer momento, sem a necessidade de "modificar a tabela" primeiro. Os campos baseados em documentos também podem conter vários dados.

Para elaborar sobre smdelfin: flexibilidade. Você pode armazenar dados em qualquer estrutura (não estruturada e tudo) e todos os documentos podem ser completamente diferentes. O CouchDB é especificamente útil porque, com seus índices de "visualização", você pode filtrar documentos específicos e consultar apenas essa visualização quando desejar esses subconjuntos do seu banco de dados.

Meu maior ponto vencedor nos bancos de dados de documentos que armazenam dados no formato JSON: este é o formato nativo do JavaScript. Portanto, os aplicativos Web JavaScript funcionam incrivelmente bem com o CouchDB. Recentemente, criei um aplicativo Web que utiliza o CouchDB e é rápido como foguete, além de ser capaz de lidar com uma estrutura de dados que varia constantemente.

Os bancos de dados baseados em documentos têm uma grande vantagem sobre os bancos de dados relacionais, pois não exigem a definição inicial de um esquema - antes de serem capazes de inserir dados.

Além disso, você deve usar um banco de dados de documentos se os dados não forem relacionais e não puderem ser armazenados em uma tabela, mas for um conjunto de imagens ou, por exemplo, artigos de jornal.

Outra vantagem é a facilidade de usar bancos de dados baseados em documentos no desenvolvimento da web. Para uma comparação mais aprofundada dos modelos de banco de dados NoSQL, verifique esta fonte: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf