Banco de dados de documentos versus banco de dados relacional: como escolher?


16

Eu sou do tipo SQL, mas sei que não existem apenas bancos de dados SQL - principalmente banco de dados de documentos. Como na maioria das tecnologias, existem prós e contras para cada tecnologia.

Eu li alguns artigos, mas eles eram muito teóricos. O que eu gostaria é de dois casos reais:

  1. quando uma mudança do banco de dados relacional para o documento deu uma melhoria
  2. quando uma troca de banco de dados de documento para banco de dados relacional melhorou

A melhoria é qualquer coisa que produz melhores programas - menos tempo de desenvolvimento, escalabilidade, desempenho, qualquer coisa relacionada à programação. Há uma ressalva para 2.: histórias como "voltar ao banco de dados relacional porque todo mundo conhece SQL" não é bom


8
Abordagem errada. Não se trata de "desempenho" ou "escalabilidade". É sobre qual modelo se encaixa no problema que você está tentando resolver. Convém atualizar sua pergunta para permitir a idéia de que talvez o banco de dados relacional não seja adequado para vários tipos de problemas.
S.Lott

2
@ S.Lott, a escolha é muitas vezes de desempenho. considere que qualquer banco de dados relacional pode ser usado como um banco de dados simples - apenas o desempenho seria uma característica distintiva.
EdA-qa mort-ora-y

Reformulei minha pergunta para que ela não seja carregada de forma alguma.
Johan Buret

2
@ edA-qa mort-ora-y: "qualquer banco de dados relacional pode ser usado como um banco de dados simples". Isso deve ser falso ou as pessoas não teriam inventado uma alternativa. "apenas o desempenho seria uma característica distintiva". Só é verdade se você assumir que o modelo relacional faz tudo igualmente bem. Se fizesse tudo, não haveria alternativa. Ainda. Temos alternativas. Existem muitos problemas (como hierarquias) que não se encaixam perfeitamente no modelo relacional e exigem truques inteligentes. Ou um modelo de dados alternativo.
21811 S.Lott

"ler alguns artigos"? Forneça alguns links ou títulos ou referências ou citações. Não sabemos o que "muito teórico" significa para você.
31511 S.Lott

Respostas:


15

O principal motivo para a escolha de um banco de dados NoSQL nos últimos anos foi a Disponibilidade . Para empresas como Amazon, Google e Facebook, uma hora de inatividade ou mais não é aceitável. Para obter alta disponibilidade, você precisa reduzir o ponto único de falha, o que significa que você precisa usar um sistema distribuído com vários computadores, caso um computador travar, o serviço ainda está disponível.

Os bancos de dados relacionais tradicionais não são muito bons em uma instalação multimestre distribuída. É por isso que o NoSQL tem sido tão popular ultimamente. Portanto, se você precisar de alta disponibilidade, poderá escolher um banco de dados NoSQL como Riak, Cassandra, HBase, S3 ou BigTable.

Há um bom post sobre o Dynamo da Amazon, uma boa introdução aos bancos de dados NoSQL distribuídos.

Agora, o termo NoSQL é muito amplo, portanto existem muitos bancos de dados NoSQL que não são distribuídos. Mas eles resolvem outros problemas. Por exemplo, Neo4j - um banco de dados gráfico é bom em um tipo de consultas para as quais o RDBMS tradicional não é otimizado. Ou, como no seu caso, um banco de dados de documentos, no qual você não precisa alterar o esquema se desejar adicionar alguns campos para alguns documentos. Em outras palavras, um banco de dados de documentos é bom quando a maioria das postagens (documentos) possui campos diferentes; portanto, uma tabela relacional com colunas predefinidas não é utilizável.

No entanto, a maioria dos bancos de dados NoSQL não é tão flexível quanto os bancos de dados RDBMS tradicionais, portanto, é uma boa opção usar um banco de dados RDBMS tradicional até que ele não consiga mais resolver seus problemas.


+1, concordou, a flexibilidade é um preço enorme a pagar se você não precisar.
Maple_shaft

12

Eu tenho uma abordagem simples para determinar o banco de dados que melhor se ajusta aos dados.

Eu me pergunto: supondo que não tenho banco de dados, prefiro salvar os dados mais importantes e importantes como documento ou armazená-los em uma planilha.

Quando a resposta é "Planilha", este é um sinal claro de que um modelo relacional e um RDBMS tradicional melhor se adequam às tarefas na maioria das vezes. Se os dados são realmente simples, como apenas pares de valores-chave ou tabelas simples e integridade referencial não é um tópico, um banco de dados NoSQL provavelmente é o mais adequado para a tarefa e pode aumentar bastante o desempenho!

Além disso, quando você não consegue encontrar uma estrutura comum, um banco de dados NoSQL é mais adequado para a tarefa.

Quando os dados são mais parecidos com documentos, por exemplo, dados textuais estruturados hierarquicamente sem relações claras, penso imediatamente em um banco de dados XML, que permite armazenar facilmente documentos estruturados hierárquicos. Às vezes, é melhor usar um software de gerenciamento de documentos.

Portanto, para dar uma resposta concreta e simples às duas perguntas: depende dos dados.

quando uma mudança do banco de dados relacional para o documento deu uma melhoria

Quando você precisa persistir dados textuais estruturados hierarquicamente, um banco de dados Xml pode ser uma grande melhoria em termos de manutenção e provavelmente também de escalabilidade.

quando uma troca de banco de dados de documento para banco de dados relacional melhorou

Bem, por exemplo, quando os dados estão principalmente no formato de tabela, com relações claras e você precisa garantir a integridade.


2
+1 para a analogia da planilha versus documento - grande ajuda - obrigado.
HDave

10

Tivemos que desistir do modelo relacional porque os dados que estávamos obtendo não tinham um esquema estático simples, óbvio, fixo.

Os usuários - e as histórias de usuários - não tinham um esquema estático fixo.

Tentamos impor um esquema RDBMS fixo, estático, mas foi um erro.

Cada entrega de dados de terceiros (de clientes e fornecedores) era semelhante, mas não idêntica. Tentamos mapeá-lo para um esquema relacional fixo, mas a variabilidade era muito grande. Nós tivemos que adicionar campos a cada arquivo (vários a cada semana) ou tivemos que nos afastar do esquema relacional fixo e estático.

Se vimos cada registro como um "documento" com um subconjunto comum de elementos e uma coleção exclusiva (e mal definida) de elementos de dados adicionais, ficaríamos muito, muito mais felizes.

A coleção mal definida de elementos de dados é o que os usuários realmente precisam para seus casos de uso.

O esquema estático fixo do modelo relacional não se encaixava em nossos casos de uso.


Vi outros projetos falharem em atender aos requisitos devido exatamente aos requisitos que você descreveu. É para isso que servem os bancos de dados de documentos.
Maple_shaft
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.