Tous les produits
Search
Centre de documentation

AnalyticDB:Tiered storage for hot and cold data

Dernière mise à jour :Aug 21, 2026

AnalyticDB for PostgreSQL prend en charge le stockage hiérarchisé. Cette fonctionnalité vous permet de déplacer les tables chaudes rarement consultées vers Object Storage Service (OSS) sous forme de tables froides afin de réduire les coûts de stockage.

Remarque

Dans cette rubrique, les tables stockées sur des disques locaux sont appelées « tables chaudes », tandis que les tables stockées dans Object Storage Service (OSS) distant sont appelées « tables froides ».

Prérequis

Remarque

AnalyticDB PostgreSQL V6.0 ne prend pas en charge le stockage hiérarchisé des données chaudes et froides.

  • AnalyticDB for PostgreSQL V7.0 exécutant la version mineure 7.0.3.0 ou ultérieure.

Remarque

Vous pouvez consulter la version mineure sur la page Basic Information d'une instance dans la console AnalyticDB for PostgreSQL. Si votre instance ne répond pas aux exigences de version, mettez à jour la version mineure de l'instance.

Limites

  • Le mode Serverless n'est pas pris en charge.

  • Vous pouvez convertir des tables non partitionnées en tables froides.

  • Vous pouvez convertir des tables partitionnées en tables froides ou convertir des sous-partitions spécifiques en partitions froides.

  • La lecture et l'écriture de données dans les tables froides et les partitions froides sont possibles. En revanche, les opérations de suppression et de mise à jour ne sont pas prises en charge. Les opérations DDL sur les tables froides, telles que ALTER COLUMN et DROP COLUMN, sont disponibles uniquement sur invitation. Pour utiliser ces fonctionnalités, soumettez un ticket pour contacter le support technique.

  • L'instruction COPY ne permet ni d'écrire des données dans des tables froides ou des tables partitionnées contenant des partitions froides, ni d'exporter des données depuis ces mêmes tables. Utilisez l'instruction INSERT pour importer des données.

  • Une fois qu'une sous-partition d'une table partitionnée est convertie en partition froide, vous ne pouvez pas exécuter l'instruction TRUNCATE ni effectuer d'opérations DDL (telles que ALTER COLUMN et DROP COLUMN) sur la table partitionnée parente.

  • La conversion en partitions froides des sous-partitions d'une table partitionnée dotée d'une clé primaire ou d'un index unique n'est pas possible. Cette limitation ne s'applique pas aux tables partitionnées disposant uniquement d'index standards.

  • Après la conversion d'une table chaude en table froide, les clés primaires, les index, les séquences, les règles et les commentaires associés à la table d'origine sont automatiquement supprimés et ne peuvent pas être récupérés.

  • La reconversion directe d'une table froide ou d'une partition froide en table chaude n'est pas possible. Vous pouvez utiliser l'instruction CREATE TABLE AS SELECT pour créer une table chaude et migrer les données de la table froide vers la table chaude.

Facturation

Après avoir converti une table chaude en table froide, les données sont stockées dans OSS et engendrent des frais de stockage selon les règles suivantes :

  • Le stockage froid est facturé selon le modèle de paiement à l'utilisation.

  • L'utilisation du stockage froid est mesurée toutes les 5 minutes et facturée à l'heure.

  • Le tarif est identique à celui du stockage OSS Standard. Pour plus d'informations, consultez les Tarifs OSS.

    Par exemple, dans les régions de Chine continentale, le prix pour OSS est de 0 017 USD par Go/mois. Le tarif horaire est de 0,0000236111 USD par Go. Le prix réel indiqué sur votre facture fait foi.

Vous pouvez consulter les détails de facturation du stockage froid sur la page Billing > Bill Details.

Procédure

Important
  • La conversion crée une table temporaire, y écrit les données, puis les télécharge vers OSS. Ces opérations consomment des ressources d'E/S locales et réseau et peuvent affecter les requêtes en cours d'exécution. Évaluez l'impact potentiel avant de poursuivre.

  • Après la conversion d'une table chaude en table froide, l'espace disque local qu'elle occupait est libéré.

  • La durée totale nécessaire à la conversion dépend des spécifications de l'instance, du nombre de conversions simultanées et du volume de données. Pour plus d'informations, consultez les Données de performance.

Suivez les procédures ci-dessous pour convertir des tables chaudes en tables froides.

Convertir une table non partitionnée

Syntaxe

SELECT pg_tiered_storage_move_table_to_storage_cold('<schema_name>', '<table_name>');

Exemple

Créez une table non partitionnée nommée tiered_storage_heap_oss dans le schéma public et écrivez-y des données.

CREATE TABLE tiered_storage_heap_oss (a int, b int) DISTRIBUTED BY(a) ;
INSERT INTO  tiered_storage_heap_oss SELECT random() * 1000,1 FROM generate_series(1,100);
  • Exemple 1 : Convertir immédiatement une table entière en table froide.

    Exécutez l'instruction suivante pour convertir immédiatement la table non partitionnée entière en table froide.

    SELECT pg_tiered_storage_move_table_to_storage_cold('public', 'tiered_storage_heap_oss');
  • Exemple 2 : Utiliser pg_cron pour planifier la conversion d'une table entière.

    Supposons que vous soyez l'utilisateur etl_user et que vous souhaitiez convertir la table non partitionnée tiered_storage_heap_oss de la base de données etl en table froide à 01:00 le lendemain. Connectez-vous à la base de données postgres et exécutez l'instruction suivante.

    SELECT cron.schedule('etl_table_transfer_to_cold', '0 1 * * *', 'SELECT pg_tiered_storage_move_table_to_storage_cold(''public'', ''tiered_storage_heap_oss'');', 'etl', 'etl_user');

    Après 01:00 le lendemain, confirmez que la conversion a réussi, puis exécutez l'instruction suivante pour supprimer la tâche planifiée.

    SELECT cron.unschedule(<job_id>);
    Remarque

    L'ID de la tâche est généré automatiquement lors de sa création. Vous pouvez trouver cet ID dans la colonne jobid de la table cron.job.

Convertir des sous-partitions d'une table partitionnée

Syntaxe

SELECT pg_tiered_storage_move_table_to_storage_cold('<schema_name>', '<child_partition_name>');

Vous pouvez exécuter \d+ dans psql pour afficher les noms des sous-partitions d'une table partitionnée spécifique.

Exemple

  • Exemple 1 : Convertir immédiatement une sous-partition en partition froide.

    Créez une table partitionnée nommée tiered_storage_partition_oss dans le schéma public.

    CREATE TABLE tiered_storage_partition_oss(a int,b int) DISTRIBUTED BY (a) PARTITION BY range(a) (start(1) end(20) every(10));
    Remarque

    Cet exemple crée deux sous-partitions : tiered_storage_partition_oss_1_prt_1 et tiered_storage_partition_oss_1_prt_2.

    Écrivez des données dans la sous-partition tiered_storage_partition_oss_1_prt_1.

    INSERT INTO  tiered_storage_partition_oss_1_prt_1 VALUES(1, 1), (2, 2), (3, 3), (4, 4);

    Convertissez immédiatement la sous-partition en partition froide.

    SELECT pg_tiered_storage_move_table_to_storage_cold('public', 'tiered_storage_partition_oss_1_prt_1');
  • Exemple 2 : Utiliser pg_cron pour planifier la conversion des sous-partitions quotidiennes.

    Créez une table partitionnée quotidienne nommée daily_log_details dans la base de données etl.

    CREATE TABLE daily_log_details (id INT, log_message text, created_date character varying(64))
    PARTITION BY LIST (created_date)
    (
       PARTITION p20230601 VALUES ('20230601'),
       PARTITION p20230602 VALUES ('20230602'),
       PARTITION p20230603 VALUES ('20230603'),
       PARTITION p20230604 VALUES ('20230604'),
       PARTITION p20230605 VALUES ('20230605'),
       PARTITION p20230606 VALUES ('20230606'),
       PARTITION p20230607 VALUES ('20230607'),
       PARTITION p20230608 VALUES ('20230608'),
       PARTITION p20230609 VALUES ('20230609'),
       PARTITION p20230610 VALUES ('20230610'),
       PARTITION p20230611 VALUES ('20230611'),
       DEFAULT PARTITION others
    );

    Configurez une tâche qui s'exécute à 03:00 en tant qu'utilisateur etl_user pour convertir les sous-partitions âgées de plus de 10 jours en partitions froides. Suivez ces étapes :

    1. Créez une fonction de nettoyage dans la base de données etl.

      CREATE OR REPLACE FUNCTION pg_tiered_storage_move_partition_daily_table_to_cold_storage(schemaname text, tablename text) RETURNS void
      AS $$
      DECLARE
          fetch_overdue_partition_sql text;
          cold_storage_sql text;
          target record;
      BEGIN
          fetch_overdue_partition_sql := 'WITH targetpartitions AS
          (SELECT * FROM pg_partitions 
          WHERE tablename = $1
          AND schemaname = $2 
          AND partitionlevel = 1
          AND partitionisdefault = FALSE)
          SELECT partitiontablename FROM targetpartitions WHERE 
          to_date(substring(targetpartitions.partitionname FROM 2), ''YYYYMMDD'') <= current_date - INTERVAL ''10 days''';
          
          -- fetch overdue partitions
          FOR target IN EXECUTE fetch_overdue_partition_sql USING tablename, schemaname LOOP 
             cold_storage_sql := 'SELECT pg_tiered_storage_move_table_to_storage_cold($1::text, $2::text)';
             raise notice 'sql %', cold_storage_sql;
             EXECUTE cold_storage_sql USING schemaname, target.partitiontablename;
          END LOOP;
      END;
      $$
      LANGUAGE plpgsql;
    2. Connectez-vous à la base de données postgres et exécutez l'instruction de conversion.

      SELECT cron.schedule('etl_daily_transfer_to_cold', '0 3 * * *', 'SELECT pg_tiered_storage_move_partition_daily_table_to_cold_storage(''public'', ''daily_log_details'');', 'etl', 'etl_user');
  • Exemple 3 : Utiliser pg_cron pour planifier la conversion des sous-partitions mensuelles.

    Créez une table partitionnée mensuelle nommée month_log_details dans la base de données etl.

    CREATE TABLE month_log_details (id INT, log_message text, created_date character varying(64))
    PARTITION BY LIST (created_date)
    (
       PARTITION p202306 VALUES ('202306'),
       PARTITION p202307 VALUES ('202307'),
       PARTITION p202308 VALUES ('202308'),
       PARTITION p202309 VALUES ('202309'),
       PARTITION p202310 VALUES ('202310'),
       DEFAULT PARTITION others
    );

    Configurez une tâche qui s'exécute à 05:00 en tant qu'utilisateur etl_user pour convertir les sous-partitions âgées de plus de 3 mois en partitions froides. Suivez ces étapes :

    1. Créez une fonction de nettoyage dans la base de données etl.

      CREATE OR REPLACE FUNCTION pg_tiered_storage_move_partition_table_to_cold_storage(schemaname text, tablename text) RETURNS void
      AS $$
      DECLARE
          fetch_overdue_partition_sql text;
          cold_storage_sql text;
          target record;
      BEGIN
          fetch_overdue_partition_sql := 'WITH targetpartitions AS
          (SELECT * FROM pg_partitions 
          WHERE tablename = $1
          AND schemaname = $2 
          AND partitionlevel = 1
          AND partitionisdefault = FALSE)
          SELECT partitiontablename FROM targetpartitions WHERE 
          to_date(substring(targetpartitions.partitionname FROM 2), ''YYYYMM'') <= current_date - INTERVAL ''3 months''';
          
          -- fetch overdue partitions
          FOR target IN EXECUTE fetch_overdue_partition_sql USING tablename, schemaname LOOP 
             cold_storage_sql := 'SELECT pg_tiered_storage_move_table_to_storage_cold($1::text, $2::text)';
             raise notice 'sql %', cold_storage_sql;
             EXECUTE cold_storage_sql USING schemaname, target.partitiontablename;
          END LOOP;
      END;
      $$
      LANGUAGE plpgsql;
    2. Connectez-vous à la base de données postgres et exécutez l'instruction de conversion.

      SELECT cron.schedule('etl_month_transfer_to_cold', '0 5 1 * *', 'SELECT pg_tiered_storage_move_partition_table_to_cold_storage(''public'', ''month_log_details'');', 'etl', 'etl_user');

Interroger le statut de stockage d'une table

Exécutez l'instruction suivante pour interroger le statut de stockage d'une table. La requête renvoie cold pour une table froide et hot pour une table chaude.

SELECT pg_tiered_storage_table_status('<schema_name>', '<table_name>|<child_partition_name>')

Utilisation du stockage chaud et froid

Connectez-vous à la console AnalyticDB for PostgreSQL. Sur la page Basic Information, vérifiez la carte Instance Status pour consulter l'utilisation de Hot Storage et de Cold Storage.

Sauvegarde et restauration

AnalyticDB for PostgreSQL Tiered storage prend en charge la sauvegarde et la restauration. Lors de la restauration des données, les règles suivantes s'appliquent :

Si une sauvegarde complète est disponible, vous pouvez restaurer les données à un instant précis. Le statut de stockage (chaud ou froid) des données restaurées correspond à leur statut au moment de la sauvegarde. AnalyticDB for PostgreSQL V7.0 présente les limitations suivantes :

  • Si aucune donnée n'a été écrite dans une table après sa conversion en table froide, vous pouvez restaurer la table à n'importe quel instant.

  • Si des données ont été écrites dans une table après sa conversion en table froide, vous pouvez restaurer la table à n'importe quel point de sauvegarde antérieur à la conversion. Pour les restaurations à un instant postérieur à la conversion, vous ne pouvez récupérer la table que dans l'état correspondant à la dernière opération d'écriture.

Pour prendre en charge la sauvegarde et la restauration, le système ne libère pas immédiatement l'espace OSS d'une table supprimée. L'espace est plutôt conservé pendant une période égale au paramètre Data Backup Retention Period (Days). Vous êtes facturé pour l'espace OSS durant cette période de conservation prolongée.

Pour plus d'informations sur la sauvegarde et la restauration, consultez Sauvegarde et restauration.

Mise à l'échelle

La mise à l'échelle n'affecte pas les données du stockage froid. Aucune redistribution des données ni restauration vers le stockage local n'est requise, vous n'avez donc pas besoin de prendre en compte l'espace disque utilisé par le stockage froid.

Données de performance

Des tests de performance ont été effectués sur une instance à 4 nœuds et une instance à 8 nœuds, toutes deux équipées de nœuds à 2 cœurs et 8 Go de RAM. La table de test a été créée et remplie à l'aide des instructions suivantes.

CREATE TABLE t333 (a int, b int);
INSERT INTO t333 SELECT random() * 1000000, random()*1000000 FROM generate_series(1,3000000000);

Pour les instances AnalyticDB for PostgreSQL V7.0, exécutez l'instruction SELECT pg_tiered_storage_move_table_to_storage_cold('public', 't333');.

Le tableau suivant indique le temps de conversion pour une seule table.

Taille de la table chaude (Go)

Temps de conversion sur 4 nœuds (s)

Temps de conversion sur 8 nœuds (s)

1

5

2,8

10

48

25,2

100

490

243