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:
- quando uma mudança do banco de dados relacional para o documento deu uma melhoria
- 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
nosql
relational-database
Johan Buret
fonte
fonte
Respostas:
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.
fonte
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 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.
Bem, por exemplo, quando os dados estão principalmente no formato de tabela, com relações claras e você precisa garantir a integridade.
fonte
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.
fonte