Quando usar um armazenamento de dados de chave-valor vs. um banco de dados relacional mais tradicional?

Question

Quando um escolheria um armazenamento de dados de valor-chave ao longo de um banco de dados relacional? Que considerações entram em decidir um ou outro? Quando é mistura de ambos o melhor caminho? Por favor, forneça exemplos, se puder.

Answer 1

Na minha experiência, se você está mesmo fazendo a pergunta se pretende utilizar tradicional vs práticas esotéricas, em seguida, ir tradicional. Enquanto práticas esotéricas são sexy, desafiador e divertido, 99,999% dos pedidos exigem uma abordagem tradicional.

Com relação ao relacional vs KV, a pergunta que você deve estar se perguntando é:

Por que eu não quiser usar um modelo relacional para este cenário: ...

Uma vez que você não tenha descrito o cenário, é impossível para qualquer um dizer por que você não deve usá-lo. O "catch all" razão para KV é a escalabilidade, o que não é um problema agora. Você conhece as regras de otimização?

1. Não faça isso.
2. (apenas para usuários avançados) Não faça isso agora.

KV é uma altamente solução otimizada para escalabilidade que provavelmente será completamente desnecessário para a sua aplicação.

Answer 2

Key-value, hierárquica, Map-Reduce, ou sistemas de banco de dados gráfico são muito mais perto de estratégias de implementação, eles são fortemente ligada à representação física. A principal razão para escolher uma delas é se há um argumento desempenho convincente e que se encaixa a sua estratégia de processamento de dados muito de perto. Cuidado, consultas ad-hoc normalmente não são práticos para estes sistemas, e você é melhor fora de decidir sobre suas consultas antes do tempo.

sistemas de banco de dados relacionais tentar separar o modelo lógico, orientada para o negócio das estratégias subjacentes representação física e processamento. Esta separação é imperfeito, mas ainda muito bom. sistemas relacionais são grandes para lidar com fatos e extrair informações confiáveis ??a partir de coleções de fatos. sistemas relacionais também são ótimos para consultas ad-hoc, o que os outros sistemas são notoriamente ruim em. Isso é um grande ajuste no mundo dos negócios e muitos outros lugares. É por isso que os sistemas relacionais são tão comuns.

Se é um aplicativo de negócios, um sistema relacional é quase sempre a resposta. Para outros sistemas, é provavelmente a resposta. Se você tiver mais de um problema de processamento de dados, como um gasoduto de coisas que precisam acontecer e você tem enormes quantidades de dados, e você sabe todas as suas dúvidas na frente, outro sistema pode ser bom para você.

Answer 3

Se os dados é simplesmente uma lista de coisas e você pode obter um identificador único para cada item, em seguida, um KVS é um bom jogo. Eles são implementações perto das estruturas de dados simples que aprendemos em ciência da computação calouro e não permitem relações complexas.

Um teste simples: você pode representar os seus dados e todos os seus relacionamentos como uma lista ligada ou tabela hash? Se sim, a KVS pode funcionar. Se não, você precisa de um RDB.

Você ainda precisa encontrar um KVS que irá trabalhar em seu ambiente. Suporte para KVSes, até mesmo as mais importantes, está longe de ser o que é, digamos, PostgreSQL e MySQL / MariaDB.

Answer 4

Um banco de dados relacional tradicional tem problemas de escala além de um ponto. Onde esse ponto é depende um pouco sobre o que você está tentando fazer.

Todos os (a maioria?) Dos fornecedores de computação em nuvem estão fornecendo armazenamentos de dados chave-valor.

No entanto, se você tiver um aplicativo de tamanho razoável com uma estrutura de dados complicado, então o apoio que você começa de usar um banco de dados relacional pode reduzir seus custos de desenvolvimento.

Answer 5

IMO, par de valores-chave (por exemplo, bancos de dados NoSQL) funciona melhor quando os dados subjacentes é desestruturado, imprevisível, ou mudando frequentemente. Se você não tem dados estruturados, um banco de dados relacional vai ser mais problema do que vale a pena porque você vai precisar fazer muitas alterações de esquema e / ou saltar através de aros para conformar os seus dados para a estrutura.

KVP / JSON / NoSQL é grande porque alterações na estrutura de dados não necessitam de refatoração completamente o modelo de dados. Adicionar um campo ao seu objeto de dados é simplesmente uma questão de adicionar-lo para os dados. O outro lado da moeda é que há menos restrições e verificações de validação em um banco de dados KVP / NoSQL do que um banco de dados relacional para que seus dados podem ficar confuso.

Existem benefícios de desempenho e economia de espaço para modelos de dados relacionais. dados relacionais normalizados pode fazer entender e validar os dados mais fácil porque existem chave relacionamentos e restrições de tabela para ajudá-lo.

Uma das piores padrões que eu vi é tentar ter as duas coisas. Tentando colocar um par de valor-chave em um banco de dados relacional é muitas vezes uma receita para o desastre. Eu recomendaria usar a tecnologia que combina com seus dados em primeiro lugar.

Answer 6

Se você quiser O (1) pesquisas de valores com base em chaves, então você quer uma loja KV. Ou seja, se você tiver dados do k1={foo}, k2={bar} forma, etc, mesmo quando os valores são maiores / estruturas aninhadas, e querem pesquisas rápidas, você quer uma loja KV. Mesmo com a indexação adequada, você não pode alcançar O (1) pesquisas em um banco de dados relacional para chaves arbitrárias. Às vezes isso é referido como "pesquisas aleatórias".

Alliteratively afirmou, se você só consulta, uma coluna, uma "chave primária", se quiserem, para recuperar o restante dos dados, em seguida, usando essa coluna como um keyspace eo resto dos dados como um valor em um loja KV é a maneira mais eficiente de fazer pesquisas.

Por outro lado, se você costuma consultar os dados por qualquer uma das várias colunas, aka você apoiar uma API de consulta mais rica para os dados, então você pode querer um banco de dados relacional.