Como o NoSQL orientado a colunas difere do orientado a documentos?

Os três tipos de bancos de dados NoSQL sobre os quais li são valores-chave, orientados a colunas e orientados a documentos.

O valor-chave é bastante simples - uma chave com um valor simples.

Já vi bancos de dados orientados a documentos descritos como valores-chave, mas o valor pode ser uma estrutura, como um objeto JSON. Cada "documento" pode ter todas, algumas ou nenhuma das mesmas chaves de outro.

Orientado a coluna parece ser muito semelhante a orientado a documento, pois você não especifica uma estrutura.

Então, qual é a diferença entre esses dois e por que você usaria um em vez do outro?

Eu olhei especificamente para MongoDB e Cassandra. Eu basicamente preciso de uma estrutura dinâmica que pode mudar, mas não afeta outros valores. Ao mesmo tempo, preciso pesquisar / filtrar chaves específicas e executar relatórios. Com o CAP, o AP é o mais importante para mim. Os dados podem "eventualmente" ser sincronizados entre os nós, desde que não haja conflito ou perda de dados. Cada usuário teria sua própria "mesa".

No Cassandra, cada linha (endereçada por uma chave) contém uma ou mais "colunas". As próprias colunas são pares de valores-chave. Os nomes das colunas não precisam ser predefinidos, ou seja, a estrutura não é fixa. As colunas em uma linha são armazenadas em ordem de classificação de acordo com suas chaves (nomes).

Em alguns casos, você pode ter um grande número de colunas em uma linha (por exemplo, para atuar como um índice para habilitar determinados tipos de consulta). O Cassandra pode lidar com essas estruturas grandes com eficiência e você pode recuperar intervalos específicos de colunas.

Existe um outro nível de estrutura (não tão comumente usado) chamado supercolunas, onde uma coluna contém (sub) colunas aninhadas.

Você pode pensar na estrutura geral como um hashtable / dicionário aninhado, com 2 ou 3 níveis de chave.

Família de coluna normal:

row
    col  col  col ...
    val  val  val ...

Família de super coluna:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

Existem também estruturas de nível superior - famílias de colunas e espaços-chave - que podem ser usados ​​para dividir ou agrupar seus dados.

Veja também esta pergunta: Cassandra: O que é uma subcoluna

Ou os links de modelagem de dados de http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: comparação com bancos de dados orientados a documentos - os últimos geralmente inserem documentos inteiros (normalmente JSON), enquanto no Cassandra você pode endereçar colunas individuais ou supercolunas e atualizá-las individualmente, ou seja, elas funcionam em um nível diferente de granularidade. Cada coluna tem seu próprio carimbo de data / hora / versão separado (usado para reconciliar atualizações no cluster distribuído).

Os valores da coluna Cassandra são apenas bytes, mas podem ser digitados como texto ASCII, UTF8, números, datas etc.

Claro, você poderia usar o Cassandra como um armazenamento de documento primitivo inserindo colunas contendo JSON - mas você não obteria todos os recursos de um armazenamento orientado a documentos real.

A principal diferença é que os armazenamentos de documentos (por exemplo, MongoDB e CouchDB) permitem documentos arbitrariamente complexos, ou seja, subdocumentos dentro de subdocumentos, listas com documentos, etc., enquanto os armazenamentos de colunas (por exemplo, Cassandra e HBase) permitem apenas um formato fixo, por exemplo, estrito de um nível ou dicionários de dois níveis.

Em "inserir", para usar palavras rdbms, baseado em documentos é mais consistente e direto. Observe que o cassandra permite que você obtenha consistência com a noção de quorum, mas isso não se aplica a todos os sistemas baseados em colunas e isso reduz a disponibilidade. Em um sistema pesado de gravação única / leitura frequente, vá para MongoDB. Considere também se você sempre planeja ler toda a estrutura do objeto. Um sistema baseado em documentos é projetado para retornar o documento inteiro quando você o obtém e não é muito forte para retornar partes de toda a linha.

Os sistemas baseados em colunas como o Cassandra são muito melhores do que os baseados em documentos em "atualizações". Você pode alterar o valor de uma coluna sem nem mesmo ler a linha que a contém. A gravação não precisa realmente ser feita no mesmo servidor, uma linha pode estar contida em vários arquivos de vários servidores. No enorme sistema de dados em rápida evolução, vá para o Cassandra. Considere também se você planeja ter uma grande quantidade de dados por chave e não precisa carregar todos eles em cada consulta. Em "selecionar", o Cassandra deixa você carregar apenas a coluna que você precisa.

Considere também que o Mongo DB é escrito em C ++ e está em seu segundo lançamento principal, enquanto o Cassandra precisa ser executado em uma JVM, e seu primeiro lançamento principal está em candidato a lançamento apenas desde ontem (mas os lançamentos 0.X viraram produções de grande empresa já).

Por outro lado, o projeto do Cassandra foi parcialmente baseado no Amazon Dynamo, e é construído em sua essência para ser uma solução de alta disponibilidade, mas isso não tem nada a ver com o formato baseado em colunas. O MongoDB também é dimensionado, mas não tão graciosamente quanto o Cassandra.

Eu diria que a principal diferença é a maneira como cada um desses tipos de banco de dados armazena fisicamente os dados.
Com os tipos de coluna, os dados são armazenados por colunas que podem permitir operações / consultas de agregação eficientes em uma coluna específica.
Com os tipos de documento, todo o documento é logicamente armazenado em um único lugar e geralmente é recuperado como um todo (nenhuma agregação eficiente possível em "colunas" / "campos").

A parte confusa é que uma "linha" de coluna larga pode ser facilmente representada como um documento, mas, como mencionado, elas são armazenadas de forma diferente e otimizadas para finalidades diferentes.