Processamento de dados em grande escala Hbase vs Cassandra [fechado]

Estou quase caindo no Cassandra depois de minha pesquisa sobre soluções de armazenamento de dados em grande escala. Mas geralmente se diz que o Hbase é a melhor solução para processamento e análise de dados em grande escala.

Embora ambos tenham o mesmo armazenamento de chave / valor e ambos sejam / possam executar (Cassandra recentemente) a camada do Hadoop, o que torna o Hadoop um candidato melhor quando o processamento / análise é necessário em grandes dados.

Também encontrei bons detalhes sobre ambos em http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

mas ainda estou procurando vantagens concretas do Hbase.

Embora eu esteja mais convencido sobre o Cassandra por causa de sua simplicidade para adicionar nós e replicação contínua e sem pontos de falha. E também mantém o recurso de índice secundário, então é uma boa vantagem.

Tentar determinar qual é o melhor para você realmente depende do que você vai usar, cada um tem suas vantagens e sem mais detalhes torna-se mais uma guerra religiosa. Essa postagem que você referenciou também tem mais de um ano e ambos passaram por muitas mudanças desde então. Lembre-se também de que não estou familiarizado com os desenvolvimentos mais recentes do Cassandra.

Dito isso, vou parafrasear o committer do HBase Andrew Purtell e adicionar algumas de minhas próprias experiências:

• O HBase está em ambientes de produção maiores (1000 nós), embora isso ainda esteja no estádio de instalação de ~ 400 nós do Cassandra, então é realmente uma diferença marginal.

• HBase e Cassandra oferecem suporte à replicação entre clusters / datacenters. Acredito que o HBase expõe mais para o usuário, então parece mais complicado, mas você também obtém mais flexibilidade.

• Se o seu aplicativo precisa de consistência forte, o HBase é provavelmente uma opção melhor. Ele é projetado desde o início para ser consistente. Por exemplo, permite uma implementação mais simples de contadores atômicos (acho que Cassandra acabou de obtê-los), bem como operações de verificação e colocação.

• O desempenho de gravação é ótimo, pelo que entendi, esse foi um dos motivos pelos quais o Facebook escolheu o HBase como mensageiro.

• Não tenho certeza do estado atual do particionador ordenado de Cassandra, mas no passado ele exigia um rebalanceamento manual. O HBase cuida disso para você, se quiser. O particionador ordenado é importante para o processamento de estilo Hadoop.

• Cassandra e HBase são ambos complexos, Cassandra apenas esconde isso melhor. O HBase o expõe mais por meio do uso de HDFS para seu armazenamento, se você olhar para a base de código, o Cassandra também tem camadas. Se você comparar os artigos do Dínamo e do Bigtable, verá que a teoria da operação de Cassandra é, na verdade, mais complexa.

• HBase tem mais testes de unidade FWIW.

• Todo o Cassandra RPC é Thrift, o HBase tem Thrift, REST e Java nativo. O Thrift e o REST oferecem apenas um subconjunto da API total do cliente, mas se você quiser velocidade pura, o cliente Java nativo está lá.

• Há vantagens em ponto a ponto e mestre a escravo. A configuração mestre-escravo geralmente torna mais fácil depurar e reduz um pouco a complexidade.

• O HBase não está vinculado apenas ao HDFS tradicional, você pode alterar seu armazenamento subjacente de acordo com suas necessidades. O MapR parece bastante interessante e tenho ouvido coisas boas, embora não o tenha usado pessoalmente.

Como desenvolvedor do Cassandra, sou melhor respondendo ao outro lado da pergunta:

• Cassandra escala melhor. O Cassandra é conhecido por escalar para mais de 400 nós em um cluster ; quando o Facebook implantou o Messaging em cima do HBase, eles tiveram que fragmentá-lo em subclusters de HBase de 100 nós .
• Cassandra suporta centenas, até milhares de ColumnFamilies. "O HBase atualmente não se dá bem com nada acima de duas ou três famílias de colunas ."
• Como um sistema totalmente distribuído, sem nós ou processos "especiais" , o Cassandra é mais simples de configurar e operar , mais fácil de solucionar problemas e mais robusto.
• O suporte do Cassandra para replicação multimestre significa que você não apenas obtém o poder óbvio de vários datacenters - redundância geográfica, latências locais - mas também pode dividir cargas de trabalho analíticas e em tempo real em grupos separados, com replicação bidirecional em tempo real entre eles . Se você não dividir essas cargas de trabalho, elas se enfrentarão de maneira espetacular.
• Como cada nó do Cassandra gerencia seu próprio armazenamento local, o Cassandra tem uma vantagem de desempenho substancial que provavelmente não será reduzida significativamente. (Por exemplo, é prática padrão colocar o commitlog do Cassandra em um dispositivo separado para que ele possa fazer suas gravações sequenciais sem ser impedido por i / o aleatório de solicitações de leitura.)
• O Cassandra permite que você escolha o quão forte você deseja que exija consistência por operação. Às vezes, isso é mal interpretado como "Cassandra não lhe dá consistência forte", mas está incorreto.
• Cassandra oferece RandomPartitioner, bem como OrderedPartitioner, mais parecido com Bigtable. RandomPartitioner é muito menos sujeito a pontos de acesso.
• O Cassandra oferece cache no heap ou fora do heap com desempenho comparável ao memcached, mas sem os problemas de consistência do cache ou a complexidade de exigir partes móveis extras
• Clientes não Java não são cidadãos de segunda classe

Até onde sei, a principal vantagem que o HBase tem agora (HBase 0.90.4 e Cassandra 0.8.4) é que o Cassandra ainda não oferece suporte à compactação de dados transparente. (Isso foi adicionado para o Cassandra 1.0 , previsto para o início de outubro, mas hoje é uma vantagem real para o HBase.) O HBase também pode ser melhor otimizado para os tipos de varreduras de intervalo feitas pelo processamento em lote do Hadoop.

Existem também algumas coisas que não são necessariamente melhores ou piores, apenas diferentes. O HBase adere mais estritamente ao modelo de dados Bigtable, em que cada coluna tem versão implicitamente. Cassandra descarta o controle de versão e adiciona SuperColumns.

Espero que ajude!

O motivo para usar clusters hBase de 100 nós não é porque o HBase não é escalonado para tamanhos maiores. É porque é mais fácil fazer atualizações de software hBase / HDFS de forma contínua, sem desativar todo o serviço. Outro motivo é evitar que um único NameNode seja um SPOF para todo o serviço. Além disso, o HBase está sendo usado para vários serviços (não apenas mensagens FB) e é prudente ter uma abordagem padronizada para configurar vários clusters de HBase com base em uma abordagem de pod de 100 nós. O número 100 é ad hoc, não nos concentramos em se 100 é o ideal ou não.