Esta postagem do blog foi publicada no Hortonworks.com antes da fusão com a Cloudera. Alguns links, recursos ou referências podem não ser mais precisos.
Visão geral
À medida que mais e mais cargas de trabalho estão sendo trazidas para o hardware moderno na nuvem, é importante entendermos como escolher os melhores bancos de dados que podem aproveitar o melhor hardware. A Amazon introduziu instâncias com SSD (unidade de estado sólido) conectado diretamente. Tanto o Apache HBase quanto o Apache Cassandra são bancos de dados de valor-chave populares. Neste benchmark, esperamos aprender mais sobre como eles aproveitam o SSD conectado diretamente em um ambiente de nuvem.
Design do benchmark
O benchmark foi projetado para executar o Apache HBase e o Apache Cassandra em um ambiente de produção ideal. Isso significa usar uma máquina adaptada para operações de alto io com SSD conectado diretamente. Colocamos registros de gravação antecipada/registro de confirmação, bem como armazenamento de dados em SSDs. Anteriormente, vários benchmarks já confirmaram que ambas as soluções podem ser dimensionadas linearmente, portanto, o teste de dimensionamento está fora do escopo deste benchmark.
Resultados
Análise
Ao longo de nosso comparativo de mercado, vimos o HBase superando consistentemente o Cassandra em cargas de trabalho de leitura intensa. Isso se alinha bem com os principais casos de uso do HBase, como mecanismos de pesquisa, aplicativos de transação de alta frequência, análise de dados de log e aplicativos de mensagens. O HBase brilha em cargas de trabalho em que a verificação de tabelas bidimensionais enormes é um requisito. Por outro lado, Cassandra trabalhou bem na troca de carga de trabalho pesada com consistência. Assim, é mais adequado para coleta de dados analíticos ou coleta de dados de sensores quando a consistência ao longo do tempo é aceitável.
Um outro fator a ser considerado ao escolher soluções também é se existem conjuntos de ferramentas correspondentes para analisar os dados. No caso do HBase, construído sobre a plataforma Apache Hadoop, ele suporta Map Reduce e uma variedade de conectores para outras soluções, como Apache Hive e Apache Spark, para permitir consultas de agregação maiores e análises complexas.
Configuração do teste
Máquina:
O cluster de teste consiste em 5 máquinas. Detalhes da máquina:
AWS I3.xlarge
60GB GP2 para rodar o SO
Armazenamento NVMe conectado diretamente, 0,95 TB
4 vCPU, cada vCPU (CPU virtual) é um hyper-thread de hardware em um processador Intel E5-2686 v4 (Broadwell) rodando a 2,3 GHz.
30,5 GB de RAM
Para minimizar os problemas de vizinhos barulhentos, executamos os testes em instâncias dedicadas da AWS.
Software de referência:
Conjunto de dados de teste:1 TB gerado via YCSB
Suíte de teste:https://github.com/brianfrankcooper/YCSB
Script de teste: https://github.com/2bethere/hbase-cassandra-bench
Software e ambiente:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Para utilizar totalmente o hardware, alteramos o número de manipuladores por região no HBase para 120. Todas as outras configurações são deixadas como padrão. O conjunto completo de listagens de configuração está disponível no final deste post.
Durante a implantação, também seguimos o guia de otimização do Cassandra publicado aqui:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Os clientes YCSB estão localizados em cada um dos 5 nós e são executados simultaneamente para gerar a carga. Durante a geração do conjunto de dados, reduzimos a contagem de threads para 40.
Metodologia de teste
Estamos carregando o conjunto de dados com 40 threads para cada carga de trabalho, pois a distribuição do conjunto de dados é diferente para cada benchmark. Após o carregamento, esperamos que todas as operações de compactação terminem antes de iniciar o teste de carga de trabalho. Cada carga de trabalho foi executada 3 vezes com 5.000.000 operações. O número médio é retirado de 3 testes para produzir o número final.
Sobre YCSB
YCSB, ou Yahoo! O Cloud Serving Benchmark é uma ferramenta de benchmark comumente usada. Ele fornece resultados comparativos entre diferentes soluções. Executamos a carga de trabalho padrão fornecida pelo YCSB.
Carga de trabalho A:atualização pesada
Exemplo de aplicação:armazenamento de sessão, gravando ações recentes
Carga de trabalho B:leia principalmente
Exemplo de aplicação:Marcação de fotos; adicionar uma tag é uma atualização, mas a maioria das operações é para ler tags
Carga de trabalho C:somente leitura
Exemplo de aplicação:cache de perfil de usuário, onde os perfis são construídos em outro lugar (por exemplo, Hadoop)
Carga de trabalho D:leia a carga de trabalho mais recente
Exemplo de aplicação:atualizações de status do usuário; as pessoas querem ler as informações mais recentes
Carga de trabalho E:alcances curtos
Exemplo de aplicação:conversas encadeadas, em que cada varredura é para as postagens em um determinado encadeamento (supostamente agrupadas pelo ID do encadeamento)
Carga de trabalho F:Carga de trabalho de leitura-modificação-gravação
Exemplo de aplicação:banco de dados do usuário, onde os registros do usuário são lidos e modificados pelo usuário ou para registrar a atividade do usuário.
