Hologres:Set up storage tiering

Introduction

Hologres propose deux types de stockage : Standard et Infrequent Access.

• Le stockage Standard repose entièrement sur des SSD (stockage chaud). Il s'agit du type de stockage par défaut dans Hologres et il répond aux exigences d'accès aux données à faible latence et haute performance. Pour la plupart des scénarios, le stockage Standard constitue l'option la plus efficace et la plus rentable. Ce document le désigne sous le terme de stockage chaud.

• Le stockage Infrequent Access repose entièrement sur des disques durs (HDD) (stockage froid). Il répond aux besoins de stockage à faible coût pour les données rarement consultées et convient aux très grands ensembles de données qui ne sont pas sensibles à la latence ou qui sont rarement accessibles. Ce document le désigne sous le terme de stockage froid.

• Pour les instances primaire/secondaire, mettez à niveau vers Hologres V1.3.55 ou une version ultérieure pour activer le stockage froid.

Hologres prend également en charge la hiérarchisation du stockage au niveau des tables. Définissez dynamiquement le support de stockage pour les tables enfants de partition à l'aide de la fonctionnalité CREATE PARTITION TABLE.

À partir de Hologres V2.1, l'accélération par cache basée sur des SSD améliore la vitesse d'accès au stockage froid. Seul l'espace de cache alloué par défaut est pris en charge. L'accélération par cache est activée par défaut et multiplie les performances d'accès par plus de deux.

Prérequis

• Seules les versions Hologres V1.3.37 et ultérieures prennent en charge la hiérarchisation du stockage chaud et froid. Si votre instance exécute une version antérieure, consultez le guide Common upgrade preparation failure errors ou rejoignez le groupe DingTalk Hologres pour fournir vos commentaires. Pour plus d'informations, consultez la rubrique How do I get more online support?.

• Pour les instances par abonnement exécutant des versions antérieures, le quota de stockage Infrequent Access est défini par défaut sur 0 Go après la mise à niveau vers Hologres V1.3.37.

Notes

• Le stockage des tables Hologres se compose des parties Data et Meta. La partie Data stocke vos données utilisateur, tandis que la partie Meta stocke les métadonnées de la table. Dans le cadre de la hiérarchisation du stockage, vous ne pouvez définir le support de stockage que pour la partie Data. Pour des raisons de performance, la partie Meta est toujours stockée dans le stockage chaud. Par conséquent, même si vous définissez la politique de stockage d'une table sur le stockage froid, celle-ci consomme toujours une petite quantité de stockage chaud et engendre des frais mineurs liés au stockage chaud.

• Afin d'éviter tout impact sur vos services, les tâches de migration des données du stockage chaud vers le stockage froid s'exécutent avec une priorité faible. Après avoir modifié la politique de stockage Data d'une table, le changement ne prend pas effet immédiatement. Hologres effectue la migration des données de manière asynchrone en arrière-plan. Par défaut, la migration commence à minuit. À partir de Hologres V2.2, vous pouvez personnaliser l'heure de migration. Pour plus d'informations, consultez la rubrique Dynamic partition management.

• Lors de l'écriture de nouvelles données dans une table de stockage froid, les données sont d'abord écrites dans le stockage chaud. Une tâche en arrière-plan les migre ensuite de manière asynchrone vers le stockage froid, ce qui engendre certains frais de stockage chaud.

• En raison des limitations liées au temps de recherche sur disque, n'utilisez pas les tables de stockage froid pour des scénarios de requêtes ponctuelles, tels que les tables de dimension Flink ou les scénarios de service. Les tables de stockage froid offrent un débit en lecture inférieur de deux ordres de grandeur à celui des tables de stockage chaud.

• Ne configurez pas les tables orientées ligne pour utiliser le stockage froid.

• Lors de la conversion par lot des données du stockage chaud vers le stockage froid, tous les tablets de la table sont ouverts, ce qui augmente l'utilisation de la mémoire. Ne convertissez pas plus de 200 tables à la fois.

Créer des tables avec hiérarchisation du stockage

Lors de la création d'une table, spécifiez la politique de stockage des données en définissant le paramètre storage_mode dans SET_TABLE_PROPERTY. Pour plus d'informations, consultez la rubrique 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');
                

Gérer dynamiquement le support de stockage pour les tables partitionnées

Pour gérer intelligemment les supports de stockage des partitions, utilisez le partitionnement dynamique afin de définir des règles de transformation des données du stockage chaud vers le stockage froid. Cela permet une hiérarchisation intelligente du stockage qui équilibre efficacement le coût et la performance. Pour plus d'informations sur la gestion dynamique des partitions, consultez la rubrique 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;