O que é um banco de dados de armazenamento de chave / valor?

Eu estive olhando a página da wikipedia para o NoSQL e lista várias variações no banco de dados Key / Value Store, mas não consigo encontrar nenhum detalhe sobre o que isso significa por Key / Value Store neste contexto. Alguém poderia explicar ou vincular uma explicação para mim? Além disso, quando eu usaria esse banco de dados?

Você está familiarizado com o conceito de um par de chave / valor? Presumindo que você esteja familiarizado com Java ou C #, isso está no idioma como map / hash / datatable / KeyValuePair (o último é no caso de C #)

A maneira como funciona é demonstrada neste pequeno gráfico de exemplo:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Onde você tem uma chave (esquerda) e um valor (direita) ... observe que pode ser uma string, int ou algo parecido. A maioria dos objetos KVP permite armazenar qualquer objeto à direita, porque é apenas um valor.

Como você sempre terá uma chave exclusiva para um objeto específico que deseja retornar, basta consultar o banco de dados para obter essa chave exclusiva e obter os resultados de volta de qualquer nó que possua o objeto (é por isso que é bom para sistemas distribuídos, porque há outras coisas envolvidas, como a pesquisa nos primeiros nós para retornar um valor que corresponde aos retornos de outros nós).

Agora, meu exemplo acima é muito simples, então aqui está uma versão ligeiramente melhor do KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Então, como você pode ver, a geração simples de chaves é colocar "user" no número único do usuário, um sublinhado e o objeto. Novamente, essa é uma variação simples, mas acho que começamos a entender que, desde que possamos definir a parte à esquerda e que seja formatada de forma consistente, podemos extrair o valor.

Observe que não há restrição no valor da chave (ok, pode haver algumas limitações, como somente texto) ou na propriedade value (pode haver uma restrição de tamanho), mas até agora eu não tinha sistemas realmente complexos. Vamos tentar ir um pouco mais longe:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Você entendeu ... todos eles seriam armazenados em uma "tabela" maciça nos nós distribuídos (há matemática por trás de tudo) e você apenas pediria ao sistema distribuído o valor que você precisa pelo nome.

No mínimo, essa é minha compreensão de como tudo funciona. Posso ter algumas coisas erradas, mas esse é o básico.

link obrigatório da wikipedia http://en.wikipedia.org/wiki/Associative_array

Em termos de SQL, um banco de dados NoSQL é uma tabela única com duas colunas: uma sendo a Chave (Primária) e a outra sendo o Valor. E é isso, é toda a mágica do NoSQL.

Você usaria o NoSQL por um motivo principal: escalabilidade.

Se seu aplicativo precisar lidar com milhões de consultas por segundo, a única maneira de alcançá-lo é adicionar mais servidores. Isso é muito barato e fácil com o NoSQL. Por outro lado, escalar um banco de dados SQL tradicional é muito mais complicado.

Somente os maiores sites do mercado estão aproveitando todo o potencial do NoSQL, como o Facebook, com milhares de servidores executando o Cassandra .

Eu recomendo fortemente ler este post do blog, comparando SQL, NoSQL e ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Suponho que você tenha um entendimento básico do movimento NoSQL e dos modelos de bancos de dados não relacionais.

O armazenamento de valores-chave é um dos modelos de banco de dados sem relação, como gráfico, modelos de banco de dados orientados a documentos.

Armazenamentos de Key Value e o movimento NoSQL

Em geral, o SQL conseguiu lidar com dados especialmente estruturados e permitiu consultas altamente dinâmicas de acordo com as necessidades do departamento em questão.

Embora ainda não haja concorrentes reais para SQL nesse campo específico, o caso de uso em aplicativos da web comuns é diferente. Você não encontrará uma gama altamente dinâmica de consultas cheias de junções externas e internas, uniões e cálculos complexos em tabelas grandes. Você normalmente encontrará uma maneira de pensar muito orientada a objetos. Especialmente com a adoção de padrões como MVC, os dados no back-end geralmente não estão sendo modelados para um banco de dados, mas para a integridade lógica, que também ajuda as pessoas a lidar com o entendimento de grandes infraestruturas de software. O que está sendo feito para colocar esses modelos orientados a objetos em bancos de dados relacionais é uma grande quantidade de normalização que leva a hierarquias complexas de tabelas e direciona completamente a idéia principal por trás da programação orientada a objetos.

O fato de o SQL permitir consultas dinâmicas arbitrárias para conjuntos complexos de dados está se tornando inútil, usando um Banco de Dados SQL apenas para armazenamento persistente de dados orientados a objetos, que é o que basicamente a maioria dos aplicativos faz atualmente.

É aqui que as lojas Key Value entram em jogo. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. Os dados em si costumam ser algum tipo de primitiva da linguagem de programação (uma string, um número inteiro, uma matriz) ou um objeto que está sendo ordenado pelas ligações das linguagens de programação ao armazenamento de valores-chave. Isso substitui a necessidade de modelo de dados fixo e torna menos exigente a exigência de dados formatados corretamente.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. A maior diferença para as lojas "mais simples" é a maneira como você pode (ou não pode) autenticar ou acessar lojas diferentes (se possível). Embora as vantagens de velocidade no armazenamento e recuperação de dados possam ser um motivo para considerá-lo em bancos de dados SQL comuns, outra grande vantagem que surge ao usar armazenamentos de valores-chave é que o código resultante tende a parecer limpo e simples quando comparado a seqüências SQL incorporadas em sua linguagem de programação. Isso é algo que as pessoas tendem a combater com estruturas de mapeamento objeto-relacional, como o Hibernate ou o Active Record. Ter um mapeador relacional de um objeto basicamente parece emular um armazenamento de valores-chave, adicionando muito código realmente complexo entre um banco de dados SQL e uma linguagem de programação orientada a objetos.

Uma comunidade inteira de pessoas se reúne sob a tag " NoSQL " e discute essas vantagens e também as desvantagens do uso de alternativas aos sistemas de gerenciamento de bancos de dados relacionais. leia mais
Este é um artigo um pouco antigo, mas achei muito útil.

when would I use such a database? Could someone explain or link an explanation to me?
É mais uma decisão arquitetural e discutível ... Você deve considerar vários fatores, como escalabilidade, desempenho, etc.

Veja os slides / artigos abaixo e você terá uma idéia, quando, por que e por que não usar o armazenamento de valores-chave :)

• Bancos de dados não relacionais e lojas de chave / valor
• Lojas de valor-chave - a chave para o dimensionamento?
• http://highscalability.com/blog/category/key-value-store [deve ler]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Outros explicaram isso, mas eu vou dar uma facada de qualquer maneira.

Um banco de dados de chave / valor armazena dados por uma chave primária. Isso nos permite identificar exclusivamente um registro em um balde. Como todos os valores são únicos, as pesquisas são incrivelmente rápidas: é sempre uma simples busca de disco.

O valor é qualquer tipo de valor. A maneira como os dados são armazenados é opaca ao próprio banco de dados. Quando você armazena dados em um armazenamento de chave / valor, o banco de dados não sabe nem se importa se é XML, JSON, texto ou imagem. De fato, o que estamos fazendo em um armazenamento de chave / valor está movendo a responsabilidade de entender como os dados são armazenados fora do banco de dados para os aplicativos que recuperam nossos dados. Como você só precisa se preocupar com um único intervalo de chaves por bloco, é muito fácil distribuir as chaves por vários servidores e usar técnicas de programação distribuída para possibilitar o acesso rápido a esses dados (cada servidor armazena um intervalo de dados) .

Uma desvantagem dessa abordagem aos dados é que a pesquisa é uma tarefa muito difícil. Você precisa ler todos os registros no seu balde de dados ou então construir você mesmo os índices secundários .

Existem alguns motivos pelos quais você pode querer usar um banco de dados de chave / valor:

• Quando o desempenho de gravação é a sua maior prioridade. O Mozilla Test Pilot usa um banco de dados de chave / valor para registrar dados rapidamente.
• Quando as leituras são garantidas, apenas ocorrem por PK.
• Quando você está trabalhando com um modelo de dados simples.
• Quando você está trabalhando com um modelo de dados rico e complexo que não pode ser modelado em um RDBMS.

Existem tantas razões para usar um banco de dados de chave / valor quanto o uso de um RDBMS e existem tantos argumentos para justificar um sobre o outro. É importante dar uma olhada em como você está consultando seus dados e entender como esse padrão de acesso a dados orienta como você inserirá e armazenará dados.

Lembre-se de que um banco de dados de chave / valor é apenas um tipo de banco de dados NoSQL.

Se você possui um banco de dados relacional, pode experimentar facilmente isso:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

É assim que costumavam ser todos os bancos de dados, com o Berkeley DBM sendo um bom exemplo, desde 1979. Desde então, as coisas avançaram (você pode ter muitos valores por chave em qualquer RDBMS). Para muitos aplicativos, um armazenamento de valores-chave é suficiente (por exemplo, é assim que o sendmail armazena seus aliases). Mas se você se pré-processar o valor em seu próprio código (ou concatenar cadeias para criar sua "chave"), talvez dividindo o valor em um delimitador ou analisando-o, antes de poder usá-lo, provavelmente estará melhor com um RDBMS e realmente armazená-lo dessa maneira.