As instâncias do Hologres são dimensionadas em incrementos de Compute Unit (CU). Como o Hologres utiliza uma arquitetura de separação entre computação e armazenamento, o armazenamento escala de forma independente — escolher uma especificação de instância é essencialmente selecionar a capacidade de computação adequada para sua carga de trabalho.
Esta página explica como a quantidade de CUs se relaciona com conexões, contagens de shards e desempenho de consultas, para que você possa escolher uma especificação inicial e saber quando ajustá-la.
Conceitos principais
CU (Compute Unit) — A unidade de recurso base para instâncias do Hologres. Cada 16 CUs corresponde a um nó de computação.
Shard — A unidade de particionamento de dados no Hologres. Cada shard processa as requisições de leitura e gravação de uma parte dos dados. Os shards dentro do mesmo Table Group distribuem os dados de cada tabela de modo que os joins entre tabelas co-localizadas evitam movimentação de dados entre shards (um local join). Quando os dados abrangem múltiplos shards, um operador de redistribuição os move pela rede, adicionando overhead de agendamento.
Table Group — Um agrupamento lógico que determina como os shards são organizados. Todas as tabelas no mesmo Table Group compartilham o mesmo layout de shards, permitindo local joins entre essas tabelas.
Frontend node — A camada de acesso que gerencia as conexões de entrada. O total de conexões de uma instância é igual a: máximo de conexões por frontend node × número de frontend nodes.
Como a contagem de shards afeta o desempenho
O comportamento dos shards varia conforme o tipo de carga de trabalho:
| Carga de trabalho | Efeito de mais shards |
|---|---|
| Gravações e atualizações de dados | Maior throughput — as gravações são paralelizadas entre os shards |
| Consultas pontuais (com shard pruning) | Maior concorrência — cada consulta acessa um único shard |
| Consultas OLAP (Online Analytical Processing) | Retornos decrescentes — múltiplos shards precisam coordenar, aumentando o overhead de agendamento |
| Tabelas orientadas a linhas | Melhor desempenho de leitura — distribuição natural entre os shards |
Após escalar horizontalmente uma instância, mais recursos de computação por si só melhoram a concorrência de consultas. Na maioria dos casos, mantenha a contagem de shards inalterada, a menos que você precise especificamente de maior throughput de gravação. Se você escalar horizontalmente em menos de cinco vezes o tamanho original, não ajuste a contagem de shards.
O número máximo de conexões não pode ser modificado. Quando uma instância escala horizontalmente ou é reduzida, os limites de conexão são ajustados automaticamente. No entanto, a contagem padrão de shards para bancos de dados existentes não muda durante o dimensionamento — atualize-a manualmente se necessário. Novos bancos de dados utilizam a contagem padrão de shards para a nova especificação.
Quando ajustar sua especificação
Antes de consultar a tabela de recomendações, verifique se sua especificação atual é realmente o gargalo. Os seguintes sinais indicam que uma mudança de especificação provavelmente é necessária:
| Sinal | Ação provável |
|---|---|
| A contagem de conexões está próxima ou no limite da instância | Escale horizontalmente (adiciona frontend nodes e aumenta o limite de conexões) |
| O throughput de gravação não consegue acompanhar a taxa de ingestão | Escale horizontalmente e, em seguida, aumente a contagem de shards para bancos de dados existentes |
| A latência de consultas OLAP é alta, mas a concorrência é baixa | Escale horizontalmente para mais nós de computação; não aumente a contagem de shards |
| A concorrência de consultas pontuais atingiu um platô | Escale horizontalmente e, em seguida, aumente a contagem de shards se o shard pruning estiver ativo |
Execute a instrução a seguir para verificar o uso atual de conexões em relação ao limite:
-- Returns the maximum connections for a single frontend node.
-- Multiply by the number of frontend nodes to get the instance total.
show max_connections;Se nenhum desses sinais estiver presente, sua especificação atual provavelmente é suficiente.
Especificações recomendadas por volume de dados
A especificação correta depende de mais do que apenas a contagem de linhas. A frequência de acesso, o volume de dados acessados, a carga de trabalho de computação (consultas pontuais vs. análises), o throughput de gravação e a contagem de tabelas dentro de um Table Group são todos fatores relevantes. Use a tabela a seguir como ponto de partida.
Estas recomendações são diretrizes, não limites rígidos. Uma tabela com pequeno volume de dados pode ser executada em uma instância com alto número de shards; uma tabela grande pode ser executada em uma instância de shard único. Ajuste a contagem de shards ao seu objetivo de concorrência, mantendo os dados suficientemente concentrados para evitar overhead desnecessário de redistribuição.
| Tamanho total dos dados | Especificação recomendada | Contagem de shards recomendada | Adequação à carga de trabalho |
|---|---|---|---|
| Menos de 40 milhões de linhas | 32 núcleos ou mais | 10–20 | Desenvolvimento e testes. Não adequado para testes de carga. |
| 40 milhões a 400 milhões de linhas | 64 núcleos ou mais | 20–40 | Cargas de trabalho simples: throughput de gravação moderado, sem concorrência mista de OLAP + consultas pontuais. |
| 400 milhões a 4 bilhões de linhas | 128 núcleos ou mais | 40–80 | Gravações e consultas equilibradas. Ponto de partida padrão para produção. |
| 4 bilhões a 40 bilhões de linhas | 256 núcleos ou mais | 80–240 | Gravação de alto throughput ou OLAP em grande escala. Use múltiplos Table Groups; divida por coesão de negócio ou volume de dados; especifique o Table Group explicitamente ao criar tabelas. |
| 40 bilhões a 400 bilhões de linhas | 512 núcleos ou mais | 160–400 | OLAP em escala muito grande ou cargas de trabalho multi-tenant. Use múltiplos Table Groups (mesmas orientações acima). Reserve contagens altas de shards apenas para tabelas muito grandes — tabelas padrão não se beneficiam. |
Recursos padrão por especificação de instância
Desde 25 de abril de 2022, as instâncias de uso geral suportam de 512 CUs a 1.024 CUs. Para especificações mais altas, abra um ticket. Antes de fazer upgrade para uma especificação maior, atualize a instância para a versão V1.1.58 ou posterior.
As instâncias de grupo de computação suportam qualquer especificação de 32 CUs a 8.192 CUs sem necessidade de ticket.
Cada 16 CUs corresponde a um nó de computação.
Para especificações de 512 CUs ou menos: o número de nós de computação é igual ao número de frontend nodes.
Para especificações de 1.600 CUs ou mais: a contagem de frontend nodes é limitada a 100.
Total máximo de conexões = máximo de conexões por frontend node × número de frontend nodes. Os valores entre parênteses mostram o valor por nó seguido da contagem de nós.
| Especificação da instância | Nós de computação | Contagem padrão de shards | Máx. de conexões (V2.1 e anteriores) | Máx. de conexões (V2.2 e posteriores) | Conexões reservadas para Superuser (V1.1 e posteriores) |
|---|---|---|---|---|---|
| 32 CUs | 2 | 20 | 256 (128 × 2) | 512 (256 × 2) | 10 (5 × 2) |
| 48–80 CUs | 3–5 | 40 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 96–112 CUs | 6–7 | 60 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 128–192 CUs | 8–12 | 80 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 208–352 CUs | 13–22 | 120 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 368–992 CUs | 23–62 | 160 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 1.008–1.584 CUs | 63–99 | 200 | 128 × número de nós de computação | 256 × número de nós de computação | 5 × número de nós de computação |
| 1.600–2.272 CUs | 100–142 | 200 | 12.800 (128 × 100) | 25.600 (256 × 100) | 500 (5 × 100) |
| 2.288–4.000 CUs | 143–250 | 240 | 12.800 (128 × 100) | 25.600 (256 × 100) | 500 (5 × 100) |
| 4.016–8.000 CUs | 251–500 | 320 | 12.800 (128 × 100) | 25.600 (256 × 100) | 500 (5 × 100) |
| 8.016–8.192 CUs | 501–512 | 400 | 12.800 (128 × 100) | 25.600 (256 × 100) | 500 (5 × 100) |
O que muda automaticamente ao dimensionar
Ao escalar horizontalmente ou reduzir uma instância, as seguintes mudanças ocorrem automaticamente:
| Configuração | Comportamento durante o dimensionamento |
|---|---|
| Máximo de conexões | Ajustado automaticamente para corresponder à nova especificação |
| Contagem padrão de shards (novos bancos de dados) | Utiliza o padrão da nova especificação |
| Contagem padrão de shards (bancos de dados existentes) | Não muda — atualize manualmente se necessário |
Isso significa que, após um scale-out, os bancos de dados existentes retêm sua contagem original de shards. Os nós de computação adicionais ainda melhoram a concorrência de consultas, pois mais núcleos processam cada consulta. Atualize a contagem de shards manualmente apenas se precisar de maior throughput de gravação ou se planeja adicionar significativamente mais dados.
Visualizar e gerenciar conexões
Verificar o limite atual de conexões
Após conectar-se a uma ferramenta de desenvolvedor, execute a instrução a seguir para ver o máximo de conexões para um único frontend node:
-- View the maximum connections for a single frontend node.
-- Connections are balanced across all frontend nodes.
show max_connections;Multiplique o valor retornado pelo número de frontend nodes para obter o limite total de conexões da instância.
Gerenciar conexões quando o limite é atingido
Cada instância reserva conexões para a função Superuser. Quando o limite de conexões é atingido, um Superuser pode se conectar e usar SQL para visualizar e liberar conexões ociosas, ou fazer upgrade da instância. Para mais detalhes, consulte Conexões.
Visualizar e modificar a contagem de shards
Escalar horizontalmente uma instância não altera a contagem de shards para bancos de dados existentes — ajuste-a manualmente se sua carga de trabalho exigir. Aumente a contagem de shards quando precisar de maior throughput de gravação. Para tabelas orientadas a linhas, mais shards também melhoram o desempenho de leitura devido à distribuição natural dos dados.
Para obter instruções, consulte Guia do usuário de Table Group e contagem de shards.
Próximos passos
Guia do usuário de Table Group e contagem de shards — Crie Table Groups e ajuste contagens de shards
Conexões — Monitore e libere conexões ociosas