Hologres:Defina o armazenamento em camadas

Introdução

O Hologres oferece dois tipos de armazenamento: Standard e Infrequent Access.

• O armazenamento Standard utiliza armazenamento quente totalmente em SSD. É o tipo de armazenamento padrão no Hologres e atende aos requisitos de acesso a dados de alta performance e baixa latência. Para a maioria dos cenários, o armazenamento Standard é a opção mais eficaz e com melhor custo-benefício. Este documento o chama de armazenamento quente.

• O armazenamento Infrequent Access utiliza armazenamento frio totalmente em HDD. Ele atende às necessidades de armazenamento de baixo custo para dados acessados com pouca frequência, sendo ideal para conjuntos de dados muito grandes que não são sensíveis à latência ou que raramente são acessados. Este documento o chama de armazenamento frio.

• Para instâncias primárias e secundárias, atualize para o Hologres V1.3.55 ou versão posterior e ative o armazenamento frio.

O Hologres também oferece suporte ao armazenamento em camadas no nível da tabela. É possível definir dinamicamente a mídia de armazenamento para tabelas filhas de partição usando o recurso CREATE PARTITION TABLE.

A partir do Hologres V2.1, há suporte para aceleração de cache baseada em SSD para melhorar a velocidade de acesso ao armazenamento frio. Atualmente, apenas o espaço de cache alocado por padrão é suportado. A aceleração de cache vem ativada por padrão e melhora a performance de acesso em mais do que o dobro.

Pré-requisitos

• Apenas o Hologres V1.3.37 e versões posteriores oferecem suporte ao armazenamento em camadas quente e frio. Se a sua instância executa uma versão anterior, utilize o guia Common upgrade preparation failure errors ou entre no grupo do DingTalk do Hologres para enviar seu feedback. Para mais informações, consulte How do I get more online support?.

• Para instâncias de assinatura que executam versões anteriores, a cota de armazenamento Infrequent Access tem o padrão de 0 GB após a atualização para o Hologres V1.3.37.

Observações

• O armazenamento de tabelas do Hologres é composto por Data e Meta. O Data armazena os dados do usuário, enquanto o Meta armazena os metadados da tabela. No armazenamento em camadas, só é possível definir a mídia de armazenamento para a parte de Data. Por motivos de performance, o Meta é sempre armazenado no armazenamento quente. Portanto, mesmo que você defina a política de armazenamento de uma tabela como armazenamento frio, ela ainda consumirá uma pequena quantidade de armazenamento quente e gerará tarifas menores de armazenamento quente.

• Para evitar impactos em seus services, o sistema executa as tarefas de migração de dados de quente para frio com baixa prioridade. Após alterar a política de armazenamento de Data de uma tabela, a alteração não entra em vigor imediatamente. O Hologres realiza a migração de dados de forma assíncrona em segundo plano. Por padrão, a migração começa à meia-noite. A partir do Hologres V2.2, é possível personalizar o horário da migração. Para mais informações, consulte Dynamic partition management.

• Ao gravar novos dados em uma tabela de armazenamento frio, o sistema primeiro grava os dados no armazenamento quente. Uma tarefa em segundo plano os migra assincronamente para o armazenamento frio, o que gera algumas tarifas de armazenamento quente.

• Devido às limitações de tempo de busca em disco, não utilize tabelas de armazenamento frio para cenários de consulta pontual, como tabelas de dimensão do Flink ou cenários de atendimento. As tabelas de armazenamento frio suportam um throughput de leitura duas ordens de magnitude inferior ao das tabelas de armazenamento quente.

• Não defina tabelas orientadas a linhas para usar o armazenamento frio.

• Durante a conversão em lote de dados de quente para frio, o sistema abre todos os tablets da tabela, o que aumenta o uso de memória. Converta no máximo 200 tabelas por vez.

Crie tabelas de armazenamento em camadas

Ao criar uma tabela, especifique a política de armazenamento de dados e defina o parâmetro storage_mode em SET_TABLE_PROPERTY. Para mais informações, consulte CREATE TABLE.

-- Specify cold storage when creating the table
BEGIN;
CREATE TABLE tbl1 (
 "id" INT NOT NULL,
 "name" TEXT NOT NULL
);
CALL set_table_property('tbl1', 'storage_mode', 'cold');
COMMIT;

-- Change storage medium to hot storage after table creation
CALL set_table_property('tbl1', 'storage_mode', 'hot');

-- Specify cold storage when creating the table
BEGIN;
CREATE TABLE tbl2(
  c1 TEXT NOT NULL,
  c2 TEXT
)
PARTITION BY LIST(c2);
CALL set_table_property('tbl2', 'storage_mode', 'cold');
CREATE TABLE tbl2_v1 PARTITION OF tbl2 FOR VALUES IN ('v1');
COMMIT;

-- Change storage policy to hot storage after table creation
CALL set_table_property('tbl2', 'storage_mode', 'hot');

-- Create multiple child partitions

CREATE TABLE tbl2_v2 PARTITION OF tbl2 FOR VALUES IN ('v2');
CREATE TABLE tbl2_v3 PARTITION OF tbl2 FOR VALUES IN ('v3');

-- Query table properties; they currently inherit the parent's hot storage setting

SELECT * FROM hg_table_storage_status('public', 'tbl2');

-- Change a child partition to cold storage

CALL set_table_property('tbl2_v3', 'storage_mode', 'cold');
                

Gerencie dinamicamente a mídia de armazenamento para tabelas particionadas

Gerencie de forma inteligente as mídias de armazenamento de partição usando o particionamento dinâmico para definir regras de transformação de dados de quente para frio. Isso permite um armazenamento em camadas inteligente que equilibra eficazmente custo e performance. Para mais informações sobre o gerenciamento dinâmico de partições, consulte Dynamic partition management.

SELECT * FROM hg_table_storage_status('<schema_name>', '<table_name>');

-- Non-partitioned table
SELECT * FROM hg_table_storage_status('public', 'tbl1');-- returns size in bytes
 table_name | hot_size |   cold_size   | status
------------+----------+---------------+--------
 tbl1       |  145643  |      3685     | transferring

-- Parent partition table
SELECT * FROM hg_table_storage_status('public', 'tbl2');-- returns size in bytes
   table_name    | hot_size | cold_size | status
-----------------+----------+-----------+--------
 tbl2_2022062222 |        0 |         0 | hot
 tbl2_2022062221 |     1125 |         0 | hot
 tbl2_2022062220 |     1245 |         0 | hot
 tbl2_2022062219 |     1358 |         0 | hot
 tbl2_2022062218 |        0 |      1875 | cold
 tbl2_2022062217 |        0 |      1143 | cold
 tbl2_2022062216 |        0 |      1299 | cold

SELECT a.table_name,
       (a.total_read_count - b.total_read_count) AS read_count,
       (a.total_write_count - b.total_write_count) AS write_count,
       a.hot_storage_size
FROM (SELECT * FROM hologres.hg_table_info
      WHERE type='TABLE' AND collect_time::DATE = CURRENT_DATE - interval '1 day') a
JOIN
    (SELECT * FROM hologres.hg_table_info
    WHERE type='TABLE' AND collect_time::DATE = CURRENT_DATE - interval '${days} day') b
ON a.table_name = b.table_name
ORDER BY hot_storage_size DESC;

SELECT parent_table_name,COUNT(*) AS partition_cnt, 
       sum(hot_storage_size)/1024/1024/1024 AS hot_size_gb 
FROM hologres.hg_table_info
WHERE type = 'PARTITION' AND collect_time::DATE = CURRENT_DATE - interval '1 day'
GROUP BY parent_table_name
ORDER BY hot_size_gb DESC;