Diferença entre hbase e cassandra

Se você pesquisar na Internet sobre as diferenças entre os dois, obterá muitas respostas. Como a maioria é parecida, leia vários deles para ter uma boa ideia.

Para mim, a chave de linha do HBase está classificada. Em um mundo de big data em que o índice é difícil de construir, isso é enorme para alguns casos de uso. A ordem das chaves de linha serve como um índice para algumas colunas, tornando certos padrões de recuperação de dados eficientes para executar.

E o HBase suporta a varredura de várias colunas (graças à ordem das chaves das linhas). Isso torna a tarefa em lote (MapReduce) eficiente para executar.

Mas Cassandra suporta sintaxe SQL.

Para escolher algo em detrimento de outro, deve-se conhecer a diferença básica entre as escolhas.

Uma diferença básica entre o HBase e o Casandra é: O HBase é um sistema de CP e o Cassandra é um sistema de AP.

De acordo com o teorema da CAP, qualquer sistema pode fornecer no máximo duas das três propriedades ... Consistência (C), Disponibilidade (A) e Tolerância de Partição (P).

No mundo do big data, tolerância a partições é algo que não podemos pagar (a maioria dos bancos de dados NoSQL é projetada para isso). Portanto, temos que escolher Disponibilidade ou Consistência, dependendo do caso de uso.

Cassandra fornece Disponibilidade sobre consistência e HBase vice-versa.

Exemplo: os aplicativos com transações financeiras preferem a consistência ao HBase e os aplicativos para bate-papo, etc. preferem a disponibilidade ao invés da consistência.

Poucas outras diferenças incluem suporte para scripts do lado do servidor (Cassandra - Sim, HBase - Não), Tipos definidos pelo usuário (Cassandra - Sim, Hbase - Não), etc

Mais diferenças podem ser encontradas aqui:

Comparação Cassandra vs. HBase vs. MongoDB

Uma comparação pode ser encontrada aqui:

Confronto de big data: Cassandra x HBase

. E

https://www.linkedin.com/pulse/real-comparison-nosql-databases-hbase-cassandra-mongodb-sahu

. A isso eu acrescentaria:

  1. O HBase permite varreduras de alcance global (no Cassandra, você só pode fazer varreduras de alcance eficientemente dentro de uma partição, ou algumas delas realizadas uma a uma ou simultaneamente com diferentes solicitações de banco de dados; há sintaxe para fazer varreduras globais, mas as partições não são ordenadas entre elas pela chave de partição, pelo menos pelos particionadores existentes, então não há eficiência). No entanto, ter uma chave de partição fictícia como uma constante ou alguns buckets nos quais hashes consistentes podem ser aplicados para segmentar os dados inteiros em vários intervalos. Portanto, não é um impedimento para Cassandra.
  2. O Apache Phoenix adiciona uma camada SQL sobre o HBase, de maneira eficiente (usando coprocessadores, código implantado nos servidores da região, semelhante aos procedimentos armazenados, algo muito incipiente no cassandra, mas com seus próprios riscos se uma versão instável do phoenix ou a implantação vários coprocessadores podem explodir o processo do servidor) Claro que o CQL é uma boa competição aqui.
  3. Também existem versões mais rápidas do HBase (outras implementações do mesmo protocolo de conexão, em idiomas nativos) e outros softwares sobre o HBase, não apenas o Phoenix: Impala, Hindex, Hive, portanto, existe um bom ecossistema que pode compensar o nível mais baixo API e modelo em comparação com o que o Cassandra oferece. Novamente, C * também tem um bom ecossistema.

À primeira vista, acho que, assim como você, não há nada que você possa fazer no HBase que não possa fazer no Cassandra.