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.
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
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.
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 COLUMNetDROP 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 COLUMNetDROP 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 SELECTpour 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 .
Procédure
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_useret que vous souhaitiez convertir la table non partitionnéetiered_storage_heap_ossde la base de donnéesetlen table froide à 01:00 le lendemain. Connectez-vous à la base de donnéespostgreset 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>);RemarqueL'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_ossdans le schémapublic.CREATE TABLE tiered_storage_partition_oss(a int,b int) DISTRIBUTED BY (a) PARTITION BY range(a) (start(1) end(20) every(10));RemarqueCet exemple crée deux sous-partitions :
tiered_storage_partition_oss_1_prt_1ettiered_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_detailsdans la base de donnéesetl.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_userpour convertir les sous-partitions âgées de plus de 10 jours en partitions froides. Suivez ces étapes :-
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; -
Connectez-vous à la base de données
postgreset 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_detailsdans la base de donnéesetl.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_userpour convertir les sous-partitions âgées de plus de 3 mois en partitions froides. Suivez ces étapes :-
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; -
Connectez-vous à la base de données
postgreset 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 |