Hologres:Melhores práticas para configuração de table group

SELECT * FROM hologres.hg_table_group_properties;

-- Sample output
 tablegroup_name | property_key  | property_value
-----------------+---------------+----------------
 test_tg_default | is_default_tg | 1
 test_tg_default | shard_count   | 40
 test_tg_default | tg_version    | 1
 test_tg_default | table_num     | 1
(4 rows)

Etapa 1: O table group padrão atende ao seu volume de dados?

Compare o shard count atual com os intervalos recomendados acima. Se ele atender ao volume de dados atual e projetado, use o table group padrão, desde que todas as três condições a seguir se apliquem:

• O volume total de dados em todas as tabelas é controlável e previsível.

• Não há expectativa de mudança significativa no padrão de uso.

• As tabelas do grupo precisam executar operações de local join eficientes.

Após upgrade ou downgrade das especificações da instância, o shard count do table group padrão não muda automaticamente. Verifique o shard count após qualquer alteração de especificação.

Se o table group padrão não for adequado, prossiga para a próxima etapa.

Etapa 2: É necessário criar um novo table group?

Crie um novo table group se alguma das condições a seguir se aplicar:

• Incompatibilidade de volume de dados: O shard count existente é muito alto para o volume de dados da tabela (gerando muitos arquivos pequenos com alta sobrecarga de I/O) ou muito baixo (limitando a concorrência de consultas).

• Isolamento de carga de escrita: Muitas tabelas no table group existente exigem escritas simultâneas, causando alta carga na instância. Isolar tabelas em um table group dedicado torna escritas e consultas mais independentes.

• Correlação entre tabelas: Um conjunto de tabelas compartilha um padrão exclusivo de escrita ou consulta e tem requisitos de local join entre si, mas apresenta pouca correlação com as tabelas do table group existente. O local join exige que a chave de junção seja a chave de distribuição e que todas as tabelas envolvidas estejam no mesmo table group.

• Dimensionamento da instância: Se a instância teve seu dimensionamento horizontal alterado (scale in ou scale out) em mais de cinco vezes, o shard count original pode não ser mais apropriado. O novo shard count deve ser maior que o número de nós de computação e menor que 60% do total de núcleos de CPU.

Se nenhuma das condições acima se aplicar, continue usando o table group existente.

Volume de dados

Alinhe o shard count à quantidade de dados armazenados no table group. Table groups com muitos shards são adequados para tabelas grandes; table groups com poucos shards são indicados para tabelas pequenas e médias.

Throughput de escrita

O shard count tem efeito direto e positivo no throughput de escrita. Cada shard possui uma capacidade máxima de escrita: com 100% de utilização de CPU, um único shard grava entre 3.000 e 5.000 registros por segundo (RPS) para registros de 1 KB.

Para estimar o shard count necessário com base em uma meta de throughput de escrita, considere que um shard operando com um terço da utilização de CPU sustenta 1.000 RPS para registros de 1 KB. Se sua meta for 60.000 RPS com registros de 1 KB, serão necessários pelo menos 60 shards (60.000 / 1.000 = 60). Esse valor pode ser ajustado posteriormente.

Os shards também atendem a requisições de leitura, portanto a CPU disponível para escritas é sempre inferior a 100%. Leve em conta a carga de leitura ao estimar o shard count.

Carga do table group

Se um table group contiver muitas tabelas acessadas frequentemente de forma concorrente, um shard count baixo pode não suportar a concorrência de consultas necessária. Considere o número esperado de tabelas e seus padrões de acesso ao definir o shard count.

Tenho uma instância de 512 núcleos para OLAP em tempo real em uma tabela de eventos com 20–40 bilhões de linhas. Como configurar o table group e o shard count?

Este é um cenário de carga única, portanto um único table group é suficiente. O shard count padrão para uma instância de 512 núcleos é 160. Se a tabela de eventos possuir centenas de colunas, aumente o shard count para 200 ou mais para suportar maior concorrência OLAP.

Tenho uma instância de 256 núcleos com várias tabelas orientadas a colunas, cada uma com dezenas de milhões de linhas, e preciso de OLAP em nível de milissegundos com consultas group-by e filter. Como devo configurar o shard count?

Este também é um cenário de carga única; um único table group é suficiente. O shard count padrão para uma instância de 256 núcleos é 120. Para tabelas com dezenas de milhões de linhas, 10–20 shards são mais adequados, pois mais shards aumentam a sobrecarga de shuffle e dificultam a obtenção de análises em nível de milissegundos. Altere o shard count do table group padrão para um valor entre 16 e 40 e valide com um teste de estresse.

Como verificar se uma consulta lenta é causada por um shard count inadequado?

Execute EXPLAIN ANALYZE na consulta lenta e examine a saída em busca dos seguintes indicadores:

• Shard count muito alto: Alta sobrecarga de inicialização da consulta (verifique a linha start query cost) ou alta sobrecarga de shuffle (verifique Max_GetNext_Time de Redistribution Motion). No Hologres V0.10 e versões posteriores, essas métricas também estão disponíveis nos logs de consultas lentas.

• Shard count muito baixo: A utilização de CPU permanece abaixo de 100% durante computações longas, a sobrecarga de varredura de dados é alta (verifique Max_GetNext_Time de Scan Node) ou o desempenho de escrita é baixo. Compare o RPS real com a linha de base de 3.000–5.000 RPS por shard para avaliar se o shard count é insuficiente.

O QPS de point query não está atingindo minha meta. O shard count é a causa?

Antes de ajustar o shard count, descarte outras causas: a consulta pode ser analítica em vez de uma verdadeira point query, os índices podem não estar em uso, os shards podem não estar divididos ou a CPU pode estar com 100% de utilização. Se nenhuma dessas situações se aplicar e uma única instrução SQL já estiver com desempenho otimizado, aumente o shard count para elevar a concorrência no backend para point queries.

Como detectar e corrigir data skew?

O Hologres fornece o campo interno hg_shard_id, que identifica o shard onde cada linha reside. Execute a consulta a seguir para verificar a existência de skew:

SELECT hg_shard_id, COUNT(1) FROM <table_name> GROUP BY hg_shard_id ORDER BY COUNT(1) DESC;

Se um shard contiver significativamente mais dados que os demais, há data skew. Ajuste a chave de distribuição para obter uma distribuição mais uniforme.