Antes de criar um cluster do ApsaraDB for HBase, selecione as especificações dos nós mestres, as especificações e a quantidade de nós principais e o tipo de armazenamento. Alinhe essas escolhas aos requisitos de consultas por segundo (QPS), transações por segundo (TPS), volume de dados, latência de resposta e estabilidade da sua carga de trabalho.
Também é necessário definir:
A edição do ApsaraDB for HBase. Consulte Edições do ApsaraDB for HBase.
Tipo de instância do Elastic Compute Service (ECS): Utilize uma instância dedicada para alocar recursos exclusivos e evitar contenção. Para cargas de trabalho com baixa latência, combine uma instância dedicada com SSDs.
Escolha das especificações dos nós mestres
Os nós mestres executam os masters do ApsaraDB for HBase, os NameNodes do Hadoop Distributed File System (HDFS) e o ZooKeeper. Eles não armazenam dados. Por padrão, dois nós mestres são implantados no modo primário-secundário para recuperação de desastres.
CPU ou memória insuficientes nos nós mestres degradam todo o cluster. Selecione as especificações com base no número de nós principais, tabelas e regiões do HBase gerenciadas pelo cluster. Clusters com muitas tabelas ou regiões exigem nós mestres com especificações mais altas.
|
Número de nós principais |
Especificação do nó mestre |
|
Menos de 4 |
CPU de 4 núcleos, 8 GB de memória |
|
4 a 7 |
CPU de 8 núcleos, 16 GB de memória (recomendado para clusters pequenos) |
|
8 a 15 |
CPU de 8 núcleos, 32 GB de memória |
|
Mais de 16 |
CPU de 16 núcleos, 64 GB de memória ou superior |
Escolha das especificações dos nós principais
Os nós principais atuam como RegionServers no ApsaraDB for HBase. Eles processam todas as solicitações de leitura e gravação; portanto, suas especificações afetam diretamente o throughput, a latência e a estabilidade do cluster.
Faixa de especificações: De CPU de 4 núcleos com 8 GB de memória (mínimo) até CPU de 32 núcleos com 128 GB de memória (máximo).
Princípio fundamental: Mantenha todos os metadados em cache para obter desempenho ideal. Defina a memória do nó principal conforme a quantidade de dados que precisa permanecer em cache.
Para diferentes clusters do ApsaraDB for HBase, os exemplos abaixo servem como referência para a seleção de especificações dos nós principais:
Clusters pequenos: CPU de 4 núcleos e 16 GB de memória ou CPU de 8 núcleos e 32 GB de memória (recomendado).
-
Clusters médios ou grandes: Selecione os nós principais com base na quantidade de dados a serem armazenados na memória.
Grande volume de dados para armazenamento: CPU de 16 núcleos e 64 GB de memória ou CPU de 32 núcleos e 128 GB de memória.
Pequeno volume de dados para armazenamento: CPU de 16 núcleos e 32 GB de memória ou CPU de 32 núcleos e 64 GB de memória.
Caso precise de ajuda para calcular o espaço de armazenamento necessário, entre no grupo ApsaraDB for HBase Q&A do DingTalk (s0s3eg3) ou envie um ticket.
Especificações por volume de carga de trabalho
|
TPS + QPS |
Nós recomendados |
Observações |
|
Menos de 1.000 |
Dois nós: CPU de 4 núcleos, 16 GB de memória |
Mínimo para cargas leves. Mantenha menos de 600 regiões por nó. A opção de 4 núcleos/8 GB está disponível, mas evite-a — 8 GB de memória podem causar erros de falta de memória quando a carga ou o armazenamento de chave-valor tiver picos. |
|
1.000 a 20.000 |
Dois ou três nós: CPU de 8 núcleos, 32 GB de memória |
Mais econômico que a configuração de 8 núcleos/16 GB. Os 16 GB adicionais de memória oferecem uma margem de estabilidade para cargas leves a médias. |
|
Mais de 20.000 |
8 núcleos/32 GB; 16 núcleos/32 GB; 16 núcleos/64 GB; 32 núcleos/64 GB; 32 núcleos/128 GB; ou superior |
Para cargas de trabalho online, prefira nós com muita memória para maximizar a taxa de acertos de cache. Em tarefas offline de MapReduce ou Apache Spark com uso intenso de CPU, priorize uma maior quantidade de núcleos. |
Quando o volume de solicitações não é suficiente
TPS e QPS não são os únicos fatores. Mesmo com apenas algumas centenas de solicitações por segundo, aumente as especificações dos nós principais se sua carga de trabalho envolver qualquer um dos cenários abaixo:
Linhas que armazenam kilobytes ou megabytes de dados
Solicitações de varredura com filtros complexos
Baixas taxas de acerto de cache, em que cada solicitação acessa o disco
Uma grande quantidade de tabelas e regiões
Nessas condições, nós de 4 núcleos/8 GB podem causar problemas de estabilidade e aumento de latência, mesmo com baixo volume de solicitações.
Escalonamento vertical ou horizontal
Quando a carga aumenta, a latência sobe ou o cluster fica instável, adicione nós principais para fazer escalonamento horizontal. No entanto, adicionar apenas nós com especificações baixas pode gerar hotspots se a carga de trabalho for distribuída de forma desigual. As especificações de um nó principal determinam sua capacidade de absorver picos de tráfego e evitar hotspots.
Por exemplo, se um pico de tráfego atingir uma única região ou uma solicitação grande chegar a um único nó, um nó com especificação baixa pode ficar sobrecarregado ou esgotar a memória, afetando a estabilidade do cluster.
Primeiro escolha as especificações com base nos requisitos da carga de trabalho e depois ajuste a quantidade de nós conforme necessário.
Para atualizar os nós mestres ou principais, entre no grupo ApsaraDB for HBase Q&A do DingTalk (s0s3eg3) ou envie um ticket.
Escolha do tipo de armazenamento
O tipo de armazenamento não pode ser alterado após a criação do cluster. Faça essa escolha com cuidado antes de criar o cluster.
O ApsaraDB for HBase oferece suporte a três tipos de armazenamento:
|
Recurso |
Tipo de armazenamento |
Mais indicado para |
|
Alto desempenho |
SSDs, SSDs locais ou ESSDs |
Cargas de trabalho online que exigem baixa latência: publicidade, recomendação, feeds e perfilamento de usuários. Oferece latência de 1–2 ms e minimiza a variação de desempenho. SSDs são a melhor opção para baixa latência P99 (percentil 99). |
|
Alta eficiência |
Ultra disks ou HDDs locais |
Cargas de trabalho online sensíveis à latência em que ~10 ms são aceitáveis. HDDs apresentam maior variação de desempenho do que SSDs. |
|
Armazenamento de dados frios |
OSS (armazenamento frio) |
Armazenamento near-line e arquivamento de dados. O throughput de gravação equivale ao do armazenamento quente, mas o QPS de leitura é limitado e a latência de leitura fica na casa das dezenas de milissegundos. |
Discos em nuvem
Discos em nuvem são escaláveis e replicados para redundância. Eles são independentes do hardware físico, o que protege contra perda de dados por falha de hardware. Os discos em nuvem incluem SSDs e ultra disks.
Para aumentar a capacidade de armazenamento após a criação do cluster, expanda os discos em nuvem existentes ou adicione mais nós principais.
Discos locais
Discos locais são discos físicos conectados às instâncias do ECS. Custam menos que discos em nuvem, mas não têm escalabilidade independente — a especificação do nó principal determina o tamanho do disco.
Para aumentar a capacidade de armazenamento, adicione mais nós principais. Não é possível expandir a capacidade atualizando a instância do ECS.
Se um único disco falhar, não há perda de dados. Se dois ou mais discos físicos forem danificados, as cargas de trabalho serão afetadas. A equipe de suporte do ApsaraDB for HBase substitui discos danificados rapidamente.
Discos locais têm custos iniciais elevados e são adequados para cargas de trabalho com grandes volumes de dados.
Armazenamento frio
O armazenamento frio é uma camada baseada no Object Storage Service (OSS) dedicada ao ApsaraDB for HBase. Use-o junto com discos em nuvem para armazenar dados acessados com pouca frequência ou ative a separação de dados quentes e frios para arquivar automaticamente os dados frios e reduzir custos.
Diferentemente de discos em nuvem e discos locais, o armazenamento frio não precisa ser selecionado na criação do cluster. Ative e expanda o armazenamento frio a qualquer momento após a criação do cluster.