Hologres:Conceitos

Conceitos principais

Shard

Um shard é uma partição de dados. No Hologres, os dados residem no Apsara Distributed File System. Cada shard possui um ID exclusivo no nível da instância. Durante a gravação, o mecanismo de armazenamento distribui os dados entre os shards com base em uma chave de distribuição. Se nenhuma chave de distribuição for definida, a distribuição ocorrerá de forma aleatória.

Table group

O table group é um conceito de armazenamento lógico exclusivo do Hologres e não existe no PostgreSQL. Ele gerencia um conjunto fixo de shards. Ao criar uma tabela, o sistema a associa a um table group e armazena seus dados nos shards desse grupo.

Os table groups diferem de outros conceitos relacionados:

Tabelas em schemas diferentes podem pertencer ao mesmo table group, mas cada tabela pode integrar apenas um table group. Para mover uma tabela para outro table group, recrie-a no novo grupo ou utilize uma função de migração.

Contagem de shards

A contagem de shards representa o número de shards em um table group. Defina esse valor ao criar o table group, pois ele é imutável após a criação. Para utilizar uma contagem diferente, crie um novo table group com o valor desejado.

Banco de dados e table groups

Um banco de dados (DB) pode conter um ou mais table groups, mas apenas um é considerado o padrão. Se você não especificar explicitamente um table group e sua contagem de shards, o Hologres cria automaticamente um table group padrão com uma contagem de shards predefinida durante a criação do banco de dados. É possível adicionar novos table groups ou alterar o padrão conforme necessário. Os shards de table groups distintos nunca se sobrepõem.

O sistema exclui automaticamente qualquer table group sem tabelas.

A figura a seguir ilustra o layout de um table group.

Funcionamento

O Hologres utiliza dois componentes essenciais para processar dados:

• Storage engine (SE): Gerencia e processa dados nos shards. Para operações de Data Manipulation Language (DML), cada SE oferece interfaces para acesso CRUD (crie, read, atualize e exclua) individual ou em lote. Cada SE é responsável por exatamente um shard.

• Query engine (QE): Utiliza as interfaces do SE para ler e gravar dados com alta performance.

O fluxo abaixo descreve o processo de gravação de dados ou execução de consulta:

1. Ao criar um table group com uma determinada contagem de shards, cada nó worker cria múltiplos SEs internos — um para cada shard atribuído.

2. O Hologres distribui os SEs uniformemente entre todos os workers para equilibrar os recursos de computação.

3. Durante a gravação, o SE encaminha os dados ao shard apropriado conforme a chave de distribuição.

4. Na execução de uma consulta, o QE aciona os SEs relevantes, que leem os dados de seus shards em paralelo e retornam os resultados.

A figura a seguir apresenta o layout dos nós workers, SEs e shards.

Gerenciamento automático pelo Hologres:

• Distribuição uniforme dos SEs entre os workers

• Manutenção dos shards de um table group dispersos por vários workers (nenhum worker concentra todos os shards de um único table group)

• Reatribuição de shards para workers saudáveis em caso de falha (por exemplo, devido a um erro de out-of-memory (OOM))

Decisões sob sua responsabilidade:

• Definição da contagem de shards na criação do table group (valor imutável posteriormente)

Exemplo de failover: Em uma instância com 4 workers e 8 shards (2 table groups, onde cada worker mantém 2 SEs), se o Worker 4 falhar e for responsável pelo Shard 7 e pelo Shard 8, esses dois shards serão reatribuídos automaticamente aos três workers restantes para restabelecer o equilíbrio.

Defina a contagem de shards

A contagem de shards impacta diretamente o paralelismo das consultas, o uso de memória e a sobrecarga de I/O. O valor mínimo é 1. Consulte a tabela abaixo para escolher o valor adequado.

Por que a contagem deve ser um múltiplo do número de workers: Se a quantidade de shards não for divisível pelo número de workers, alguns nós acumularão mais SEs que outros. Isso provoca desbalanceamento de recursos e latência de longa duração. Por exemplo, se um table group tiver 3 shards e a instância possuir 2 workers, um deles sempre processará uma carga maior. Definir a contagem como um múltiplo do número de workers garante uma distribuição equitativa.

Motivos para não exceder o número de núcleos de computação: Cada shard requer pelo menos um núcleo de CPU durante uma consulta. Quando a contagem de shards supera o número de núcleos disponíveis, alguns shards não recebem alocação consistente de CPU, resultando em latência elevada e sobrecarga por troca de contexto.

Para valores padrão de contagem de shards por tamanho de instância, consulte Gerenciamento de instâncias.

Compensações de desempenho

Considere as seguintes compensações ao configurar table groups e a contagem de shards.