Hologres:Primeiros passos com índices do Hologres

Como o Hologres funciona

O Hologres é um data warehouse distribuído que utiliza computação paralela e vetorial para fornecer respostas de consulta em segundos. Devido a essa arquitetura, a distribuição de dados é fundamental para o desempenho. Isso inclui o balanceamento de dados entre os nós distribuídos, regido pela distribution key, e a ordenação dos dados dentro dos arquivos em um único nó, regida pela event time column (também conhecida como segment key). Por padrão, o Hologres usa armazenamento colunar em cenários de processamento analítico online (OLAP). Nesse contexto, a ordem dos dados dentro de um arquivo também é essencial e segue a clustering key. Dominar esses três conceitos é fundamental para otimizar o desempenho. Como essas propriedades de layout são definidas na gravação e têm alto custo de alteração, recomendamos projetar as tabelas com esses três atributos desde o início. Atributos que não afetam diretamente o layout dos dados, como bitmap indexes e dictionary encoding, podem ser ajustados posteriormente conforme necessário.

O Hologres utiliza uma estrutura de metadados de três níveis: Database > Schema > Table. Para evitar consultas entre bancos de dados, agrupe tabelas logicamente relacionadas no mesmo schema. Um database é uma unidade básica para isolamento de metadados, não de recursos.

Fundamentos de otimização de SQL

Projetar tabelas com uma estratégia adequada de distribuição de dados permite que as consultas SQL localizem rapidamente as informações necessárias. Essa prática reduz a E/S, consome menos recursos de computação e proporciona maior desempenho nas consultas. Uma distribuição equilibrada também garante o uso eficiente de recursos concorrentes e evita gargalos em pontos únicos. O diagrama a seguir ilustra como uma consulta SQL recupera dados e reduz a E/S.

• Poda de partição: ao consultar uma tabela particionada, o otimizador usa a poda de partição para localizar as partições relevantes. Se as condições de filtro não incluírem a chave de partição, a consulta precisará verificar todas as partições, causando E/S excessiva. Como regra geral, o particionamento por dia é uma boa prática. Tabelas não particionadas ignoram a poda de partição.

• Poda de shard: utilize a chave de distribuição para localizar rapidamente o shard que contém os dados necessários. Isso reduz o consumo de recursos em consultas individuais e aumenta o throughput em consultas concorrentes. Caso não seja possível localizar um shard específico, o framework distribuído agenda todos os shards para participar da computação. Embora isso aumente o paralelismo da consulta individual, consome mais recursos e diminui a concorrência geral. Operadores que exigem execução centralizada também podem gerar sobrecarga extra de shuffle. Como melhor prática, escolha colunas com distribuição uniforme de dados (como IDs de pedidos, usuários ou eventos) como chave de distribuição. Se várias tabelas unidas compartilharem a mesma chave de distribuição, os dados relacionados ficarão no mesmo shard, permitindo operações de junção local eficientes.

• Poda de segment key: use a segment key (coluna de tempo de evento) para localizar rapidamente o arquivo de dados específico dentro de um nó e evitar o acesso a arquivos desnecessários. Sem filtragem nesse nível, todos os arquivos precisarão ser verificados.

• Poda de clustering key: empregue a clustering key para localizar rapidamente segmentos de dados dentro de um único arquivo. Esse recurso melhora a eficiência de consultas de intervalo e a ordenação de colunas.

Otimização de SQL na prática

Esta seção utiliza consultas TPC-H para demonstrar como configurar índices do Hologres visando melhor desempenho. Para obter mais informações sobre o TPC-H, consulte Test plan overview.

--TPC-H Q1
SELECT
        l_returnflag,
        l_linestatus,
        SUM(l_quantity) AS sum_qty,
        SUM(l_extendedprice) AS sum_base_price,
        SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
        SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
        AVG(l_quantity) AS avg_qty,
        AVG(l_extendedprice) AS avg_price,
        AVG(l_discount) AS avg_disc,
        COUNT(*) AS count_order
FROM
        lineitem
WHERE
        l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
        l_returnflag,
        l_linestatus
ORDER BY
        l_returnflag,
        l_linestatus;

Resultados do teste de desempenho

Esta seção compara o desempenho das consultas antes e depois da definição das propriedades recomendadas da tabela (índices).

• Ambiente de teste

  • Especificação da instância: 32 núcleos

  • Tipo de rede: VPC

  • Execute cada consulta duas vezes usando um cliente PSQL e registre a latência da segunda execução.

• Conclusão

  • Em consultas filtradas de tabela única, definir a coluna de filtro como clustering key acelera efetivamente a consulta.

  • Em consultas de junção de múltiplas tabelas, definir as colunas de junção como chave de distribuição melhora significativamente a eficiência da junção.

  Consulta	Latência com índices	Latência sem índices
  Q1	48.293 ms	59.483 ms
  Q4	822.389 ms	3.027,957 ms

Referências

• Hologres TPC-H performance test

• Hologres distribution key

• Hologres clustering key

Mais informações