Melhores práticas de gerenciamento de dados quentes e frios
Cenários
Em cenários massivos de Big Data, com o crescimento dos dados, o armazenamento e o consumo de dados aumentam rapidamente. A necessidade de dados pode variar em diferentes períodos de tempo, portanto, os dados são gerenciados de maneira hierárquica, melhorando o desempenho da análise de dados e reduzindo os custos do serviço. Em alguns cenários de uso de dados, os dados podem ser classificados em dados quentes e dados frios acessando a frequência.
Os dados quentes e frios são classificados com base na frequência de acesso aos dados e na frequência de atualização.
- Dados quentes: dados que são acessados e atualizados com frequência e exigem resposta rápida.
- Dados frios: dados que não podem ser atualizados ou raramente são acessados e não exigem resposta rápida
Você pode definir tabelas de gerenciamento frias e quentes para alternar dados frios que atendam às regras especificadas para o OBS para armazenamento. Dados frios e quentes podem ser automaticamente determinados e migrados por partição.
As partições quentes e frias podem ser comutadas com base nas políticas LMT (Tempo de última modificação) e HPN (Número de partição quente). LMT indica que a alternância está executada baseado no tempo da última atualização da divisória, e HPN indica que a alternância está executada baseado no número de partições quentes reservadas.
- LMT: alterne os dados da partição quente que não foram atualizados nos últimos [day] dias para o espaço de tabela do OBS como dados da partição fria. [day] é um número inteiro que varia de 0 a 36500, em dias.
- HPN: indica o número de partições quentes a serem reservadas. Durante a alternância de frio e quente, os dados precisam ser migrados para o OBS. HPN é um número inteiro que varia de 0 a 1600.
Restrições
- Se uma tabela tiver partições frias e quentes, a consulta torna-se lenta porque os dados frios são armazenados no OBS e a velocidade de leitura/gravação é menor do que a das consultas locais.
- Atualmente, as tabelas frias e quentes suportam apenas tabelas particionadas de armazenamento de colunas da versão 2.0. Tabelas estrangeiras não suportam partições frias e quentes.
- Somente dados quentes podem ser trocados por dados frios. Dados frios não podem ser alternados para dados quentes.
Procedimento
Essa prática leva cerca de 30 minutos. O processo básico é o seguinte:
Criação de um cluster
- Faça logon no console de gerenciamento da Huawei Cloud.
- Escolha Service List > Analytics > Data Warehouse Service. Na página exibida, clique em Create Cluster no canto superior direito.
- Configure parâmetros de acordo com Tabela 1.
Tabela 1 Configuração de software Parâmetro
Configuração
Region
Selecione CN-Hong Kong.
NOTA:CN-Hong Kong é usada como exemplo. Você pode selecionar outras regiões, conforme necessário. Certifique-se de que todas as operações sejam realizadas na mesma região.
AZ
AZ2
Product
Standard data warehouse
CPU Architecture
X86
Node Flavor
dws2.m6.4xlarge.8 (16 vCPUs | 128 GB | 2000 GB SSD)
NOTA:Se esse flavor estiver esgotado, selecione outras AZs ou flavors.
Nodes
3
Cluster Name
dws-demo
Administrator Account
dbadmin
Administrator Password
-
Confirm Password
-
Database Port
8000
VPC
vpc-default
Subnet
subnet-default(192.168.0.0/24)
Security Group
Automatic creation
EIP
Buy now
Bandwidth
1Mbit/s
Advanced Settings
Default
- Confirme as informações, clique em Next e, em seguida, clique em Submit.
- Espere cerca de 6 minutos. Depois que o cluster for criado, clique em
ao lado do nome do cluster. Na página de informações do cluster exibida, registre o valor de Public Network Address, por exemplo, dws-demov.dws.huaweicloud.com.
Usar o cliente de CLI gsql para conectar-se a um cluster
- Faça logon remotamente no servidor Linux onde o gsql deve ser instalado como usuário root e execute o seguinte comando na janela de comando do Linux para fazer o download do cliente gsql:
1wget https://obs.ap-southeast-1.myhuaweicloud.com/dws/download/dws_client_8.1.x_redhat_x64.zip --no-check-certificate
- Descompacte o cliente.
1cd <Path_for_storing_the_client> unzip dws_client_8.1.x_redhat_x64.zip
Onde,
- <Path_for_storing_the_client>: Substitua-o pelo caminho real.
- dws_client_8.1.x_redhat_x64.zip: Este é o nome do pacote de ferramentas cliente do RedHat x64. Substitua-o pelo nome real.
- Configure o cliente de GaussDB(DWS).
1source gsql_env.sh
Se as seguintes informações forem exibidas, o cliente gsql será configurado com êxito:
1All things done.
- Use o cliente gsql para conectar-se a um banco de dados do GaussDB(DWS) (usando a senha você definiu ao criar o cluster).
1gsql -d gaussdb -p 8000 -h 192.168.0.86 -U dbadmin -W password -r
Se as informações a seguir forem exibidas, a conexão foi bem-sucedida.
1gaussdb=>
Criar tabelas quentes e frias
1 2 3 4 5 6 7 8 9 |
CREATE TABLE lifecycle_table(i int, val text) WITH (ORIENTATION = COLUMN, storage_policy = 'LMT:100') PARTITION BY RANGE (i) ( PARTITION P1 VALUES LESS THAN(5), PARTITION P2 VALUES LESS THAN(10), PARTITION P3 VALUES LESS THAN(15), PARTITION P8 VALUES LESS THAN(MAXVALUE) ) ENABLE ROW MOVEMENT; |
Alternância de dados quentes e frios
- Alternância automática: o agendador aciona automaticamente a alternância às 00:00 todos os dias.
Você pode usar a função pg_obs_cold_refresh_time(table_name, time) para personalizar o tempo de alternância automática. Por exemplo, defina o horário de disparo automático para 06:30 todas as manhãs com base nos requisitos de serviço.
1 2 3 4 5
SELECT * FROM pg_obs_cold_refresh_time('lifecycle_table', '06:30:00'); pg_obs_cold_refresh_time -------------------------- SUCCESS (1 row)
- Manual
Execute a instrução ALTER TABLE para alternar manualmente uma única tabela.
1 2
ALTER TABLE lifecycle_table refresh storage; ALTER TABLE
Use a função pg_refresh_storage() para alternar todas as tabelas quentes e frias em lotes.
1 2 3 4 5
SELECT pg_catalog.pg_refresh_storage(); pg_refresh_storage -------------------- (1,0) (1 row)
Visualizar a distribuição de dados em tabelas quentes e frias
- Veja a distribuição de dados em uma única tabela:
1 2 3 4 5 6 7
SELECT * FROM pg_catalog.pg_lifecycle_table_data_distribute('lifecycle_table'); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes (3 rows)
- Veja a distribuição de dados em todas as tabelas quentes e frias:
1 2 3 4 5 6 7
SELECT * FROM pg_catalog.pg_lifecycle_node_data_distribute(); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 98304 | 0 | 0 (3 rows)
