Quais são as principais diferenças entre os quatro tipos de bancos de dados nosql (armazenamento de keyvalue, armazenamento orientado a colunas, banco de dados orientado a documentos e gráfico)?

Acabei de escrever um artigo sobre os diferentes tipos de banco de dados NoSQL (

Os principais tipos de bancos de dados NoSQL | Studio 3T

) com exemplos e casos de uso para cada um, mas em poucas palavras:

  • Wide-Column Store - usa colunas para armazenar dados
  • Armazenamento de documentos - usa documentos JSON, XML ou BSON
  • Armazenamento de dados de valor-chave - armazena dados em pares de valor-chave exclusivos
  • Armazenamento de gráfico - usa nós que contêm listas de registros de relacionamento

Também cobri o que é chamado de

Multi-Model

banco de dados (exemplo: Microsoft Azure Cosmos DB), que combina as vantagens dos quatro tipos acima.

Espero que isto ajude!

  • KeyValue Store: o início do nosql. As pessoas só querem usar a chave para armazenar e recuperar dados. Uma chave é um ID e value é um objeto que codifica o que o usuário deseja. O aplicativo precisa analisar os dados depois de obter o objeto do armazenamento KeyValue. Um dos principais problemas da loja KV é como expandir gradualmente. Ou seja, à medida que o volume de dados aumenta, como você adiciona mais máquinas e ajusta as partições de dados gradualmente. consulte um documento técnico sobre o Dynamo para explicar isso https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
  • Armazenamento Orientado a Documentos: Isso é principalmente para armazenamento de semi-estrutura JSON / XML sem esquema. Ainda é o armazenamento KV, mas adiciona os conceitos de coleção para ter uma melhor organização hierárquica dos dados, e o valor do objeto geralmente está no formato JSON. Veja uma boa comparação com a loja KV aqui Simplicidade do banco de dados de valor-chave NoSQL vs. Flexibilidade do banco de dados de documentos e uma demonstração concreta
  • Loja ColumnOriented: é um formato de armazenamento para responder com eficiência a determinadas consultas. Assim, por exemplo, no formato de armazenamento orientado a linhas, cada registro é um conjunto de atributos, como (nome, sexo, idade). O registro é a unidade de armazenamento. Para o formato de armazenamento orientado a colunas, uma coluna (atributo) é armazenada como um arquivo. Por exemplo, armazenamos a coluna de nome para a tabela inteira como um arquivo, a coluna de gênero para a tabela inteira como outro arquivo, envelhecendo o terceiro. Esse formato economiza muitas E / S desnecessárias para determinadas cargas de trabalho de consulta e oferece melhores benefícios da localidade do cache. Por exemplo, “Contar quantas fêmeas na coluna de gênero?”, O banco de dados verifica apenas o arquivo da coluna de gênero. Muitos bancos de dados, incluindo bancos de dados de armazenamento orientados a linhas, podem aproveitar esse layout de armazenamento para acelerar a consulta. Veja mais DBMS orientado a colunas - Wikipedia
  • Banco de dados de gráficos: este é um novo software de gerenciamento de dados, mais poderoso que o modelo relacional. O banco de dados relacional organiza os dados como um conjunto de tabelas lógicas. Faça um gráfico dos dados do modelo de banco de dados como tipos de vértices e arestas interconectados, um modelo de estilo de rede. Há um ótimo ebook sobre a nova geração de banco de dados de gráficos. Você pode baixar a nova geração do e-book de banco de dados de gráficos aqui TigerGraph Graph Database eBook

Boas respostas: mas todas elas são fundamentalmente enganosas em um aspecto: confundir um armazenamento de colunas com um armazenamento orientado a colunas (de fato, a terminologia “armazenamento orientado a colunas” é tão errada). Eu tentei limpar o ar aqui.

Confusão de terminologia: armazenamentos de colunas e bancos de dados orientados a colunas

. (Leia as seções de referência)

TL; DR

- O recurso "famílias de colunas" introduzido nos armazenamentos de dados como Cassandra e HBASE leva a essa confusão e toda a nova terminologia "armazenamento orientado a colunas". Embora os “armazenamentos de colunas” existam para sempre agora, nada mais é do que armazenamentos relacionais que armazenam dados fisicamente em colunas para otimizar consultas agregadas.

Veredito: "

Armazenamentos de colunas ", como sabíamos, não pertencem ao grupo de armazenamentos NoSQL. GreenPlum, Vertica e Teradata Aster são bons exemplos que suportam um mecanismo de armazenamento opcional para criar uma tabela como armazenamento de colunas. "Armazenamento orientado a colunas" é uma terminologia ruim. De fato, o datastax chama o cassandra como um armazenamento de linhas patenteado.

Armazenamento de valor-chave

O valor é armazenado no banco de dados no formulário em uma tupla de dois valores. Um é o identificador (chave) e o outro são os dados reais (Valor) e, portanto, são chamados de Armazenamento de Valor-Chave. Normalmente, isso pode ser usado quando você tem um aplicativo em que precisa de hash. Por exemplo. BookId (Key) e Book Details (value). Portanto, se você souber o valor da chave, não precisará percorrer todo o banco de dados para obter as informações necessárias.

Orientado a colunas

Os dados armazenados nisso são completamente diferentes, eles armazenam dados em Columns.Esta abordagem se presta bem para agregar consultas e cenários de análise nos quais você pode executar consultas de intervalo em um campo específico. Grosso modo, em termos simples para geração de relatórios com base em grandes dados.

Orientado a documentos

Os dados são armazenados novamente, par de valores-chave, onde a chave é uma String e os dados são armazenados em um documento na memória. Os dados são identificados pela string.Ele é usado quando você deseja armazenar arquivos grandes, como vídeos, músicas etc.

Banco de Dados Gráfico

Ele usa a teoria dos grafos para otimizar a pesquisa e os dados são conectados como um gráfico (gráfico usado na estrutura de dados). É usado quando você precisa processar uma carga de dados interconectados com nós diferentes. O Facebook usa esse recurso em seu novo recurso da Pesquisa por gráfico.

Por favor corrija-me se eu estiver errado.

1) Os bancos de dados orientados a colunas são mais semelhantes aos bancos de dados tradicionais baseados em linhas, pois ambos geralmente são relacionais. Os bancos de dados em colunas simplesmente armazenam dados em colunas em vez de linhas, tornando a pesquisa em cada coluna muito mais rápida. No entanto, inserções e atualizações geralmente são mais lentas nos bancos de dados da coluna.

Na prática, bancos de dados colunares geralmente armazenam dados em famílias de colunas. Nesse caso, você provavelmente não armazenaria a rua, cidade, zip em colunas completamente separadas, mas em uma família de colunas onde elas são armazenadas juntas. As diferenças entre os bancos de dados com base em linha e em coluna começam a ficar ainda mais nítidas nesse cenário.

2) Os bancos de dados de valor-chave e documento são muito semelhantes entre si. A única diferença real é que os bancos de dados de documentos armazenam seus valores de maneira mais estruturada. Um banco de dados de valor-chave pode simplesmente armazenar blobs de dados para cada chave com pouco conhecimento do que está em cada blob.

Um banco de dados de documentos ainda é basicamente um armazenamento de valores-chave, mas ele conhece informações sobre o formato de cada valor. Eles podem ser XML, JSON, RDF etc. Isso permite que o banco de dados consulte com mais facilidade as informações encontradas em cada documento.

3) Os bancos de dados gráficos são basicamente construídos sobre o modelo de entidade - atributo - valor. É uma maneira muito flexível de descrever como os dados se relacionam com outros dados. Um banco de dados de gráficos popular, o Neo4j, renomeia a terminologia para Nó - Relacionamento - Propriedade.

Os nós armazenam dados sobre cada entidade no banco de dados, os Relacionamentos descrevem um relacionamento entre os nós e uma Propriedade é simplesmente o nó no extremo oposto do relacionamento. Enquanto um banco de dados tradicional armazena uma descrição de cada relacionamento possível em campos de chave estrangeira ou tabelas de junção, os bancos de dados de gráficos permitem que praticamente qualquer relacionamento seja definido em tempo real.

------

Os bancos de dados de armazenamento de coluna geralmente são usados ​​quando o relatório é mais importante que a modificação de dados. Os bancos de dados colunares geralmente são uma ordem de magnitude mais rápida que os bancos de dados baseados em linhas para uso comum de relatórios. Eles geralmente são muito mais lentos para operações de gravação, portanto, tendem a ser usados ​​no OLAP, enquanto o baseado em linhas é usado em situações OLTP. Caso contrário, os bancos de dados colunares são muito semelhantes aos bancos de dados tradicionais.

Os bancos de dados de valor-chave são de longe os mais simples de implementar, pois são pouco mais que uma grande tabela de hash. Eles são capazes de particionar sem esforço, para que possam armazenar uma grande quantidade de dados não estruturados com facilidade. Se você apenas precisar armazenar dados estáticos e não precisar processá-los, um simples banco de dados de valores-chave pode ser o caminho a seguir.

Os bancos de dados de documentos fornecem, na minha opinião, todos os benefícios dos armazenamentos de valores-chave, mas também permitem que os dados sejam processados ​​com mais facilidade. Como os dados são armazenados em um esquema flexível, você ainda pode executar consultas, como pesquisar por cidade ou sobrenome. Esse esquema não é gerenciado como em um banco de dados tradicional, a menos que a lógica do aplicativo imponha um esquema; portanto, é mais provável que os dados sejam "mais sujos" que um RDBMS tradicional. Mas você tem a liberdade de criar novos campos rapidamente, sem modificar um esquema de banco de dados.

Os bancos de dados gráficos são usados ​​para resolver um problema que pode ser muito difícil de resolver com bancos de dados relacionais: mapeamentos complexos entre dados. Um esquema de banco de dados geralmente precisa de relacionamentos bem definidos entre tabelas, e relacionamentos complexos de muitos para muitos podem exigir um grande número de tabelas de junção que são complicadas e podem exigir junções caras. Os bancos de dados gráficos podem armazenar relacionamentos complexos e fluidos com facilidade. A desvantagem é que a consulta ou atualização de grandes quantidades de dados pode ser muito lenta, pois os nós de nós semelhantes que não são necessariamente relacionados geralmente não são armazenados próximos. Também é fácil para os aplicativos definirem relacionamentos semelhantes de maneiras muito diferentes, dificultando a organização consistente dos dados.

Para cada uma dessas classificações de bancos de dados, as implementações reais variarão de fornecedor para fornecedor, com algumas oferecendo diferentes esquemas e recursos de consulta, além de outros campos. Há muito cruzamento entre os diferentes tipos e, de um modo geral, todos eles são construídos para serem distribuídos e dimensionados horizontalmente.

Isso lhe dará uma visão geral das diferenças:

Valor chave

armazena pares de valores de chaves de loja, geralmente em buckets, exatamente como uma estrutura de dados da tabela de hash ... cada chave deve ser única. Eles são extremamente rápidos para escrever e extremamente rápidos para ler e atualizar ... se você tiver a chave. Eles são lentos em várias atualizações e se você precisar consultar a loja inteira. Você vê que os armazenamentos de valores-chave são muito usados ​​como armazenamentos em cache por causa de suas leituras rápidas. (consulte: Redis, Riak, memcached, tablestore do Azure etc.)

Armazenamentos de colunas

parecem armazenar dados em linhas relacionadas, mas na verdade eles serializam os dados em colunas. Com um banco de dados baseado em linha, você teria: ID, nome, sobrenome, nome do site1: bart, loews, quora2: jim, finnegan, beginagain3: don, quixote, windmill A loja de colunas armazena colunas juntas, assim: 1: bart, 2: jim , 3: don1: loews, 2: finnegan, 3: quixote1: quora, 2: beginagain, 3: windmillIsto permite consultas e processamento de dados muito mais rápidos, enquanto o armazenamento de dados é algo relacionado (o druida possui bilhões de registros por segundo). Eles são usados ​​em muitas análises de big data de alta potência, nas quais a velocidade é crítica. (Cassandra, BigTable do Google, Druida)

Lojas de Documentos

armazene dados em "documentos", geralmente documentos XML ou JSON. Eles são tipicamente sem esquema, então cada documento pode conter quaisquer dados que você deseja que eles tenham e você pode alterá-los rapidamente. Os documentos contêm pares de valores-chave, que podem ser qualquer tipo de valor, matriz ou até outro documento. Por exemplo: {Nome: "Bart", Sobrenome: "Loews", Filhos: [{Nome: "Tadd", Idade: 4}, {Nome: "Todd", Idade: 4}], Idade: 35, Endereço: {number: 1234, rua: "Fake road", Cidade: "Fake City", estado: "VA", País: "USA"}} Os armazenamentos de documentos permitem que você jogue com seus dados e os armazene da maneira que achar melhor. Eles têm gravação rápida, bons tempos de consulta com base na indexação, mas a principal vantagem é a flexibilidade e a capacidade de anulação do esquema. Você pode vê-los sendo usados ​​para praticamente qualquer coisa, alguns fornecedores permitem executar junções relacionais entre documentos, mas geralmente para a melhor flexibilidade que você terá para criar qualquer lógica de junção em seu aplicativo. Alguns exemplos incluem: MongoDB, OrientDB, CouchDB, DocumentDB do Azure, AWS DynamoDB, RethinkDB.

Lojas de Gráfico

foco em relacionamentos. A melhor maneira de visualizar uma loja de gráficos é como um gráfico matemático em que você tem arestas e vértices. Com um armazenamento de gráfico, os dados são armazenados como Nós e Relacionamentos. Um nó é basicamente um substantivo, uma pessoa, lugar, coisa, entidade, etc. Um relacionamento é uma conexão de mão única ou dupla entre dois nós. Um nó pode ser pessoas e um relacionamento pode ser uma amizade de duas vias. Você pode ter dois nós, um link para um site e um usuário, e o relacionamento pode ser uma maneira "parecida" do usuário para o site.

Geralmente, você pode aplicar documentos de metadados a nós e relacionamentos, bem como rótulos. Você pode rotular um nó como usuário ou site ou animal de estimação ou o que for. Você pode adicionar dados como nome, idade, sexo aos nós do usuário, é sem esquema e muito flexível.

As lojas de gráficos são excelentes na determinação de relacionamentos entre nós e na localização de padrões. Por exemplo, você pode usar uma loja de gráficos para determinar amigos de amigos ou amigos de amigos de amigos ou amigos de amigos até o enésimo grau. Você pode descobrir pessoas com quem não é amigo, pode encontrar pessoas que são amigos de amigos que gostam das mesmas coisas que você, pode encontrar pessoas que trabalharam com amigos de amigos que gostam das mesmas coisas que você e que ' não tem animais de estimação.

Eles lidam com essas perguntas malucas rapidamente.

Não sei quem os usa, mas eles seriam ótimos para redes sociais e para fins de marketing de varejo.

Exemplos disso incluem: neo4j e orientDB.