AnalyticDB for PostgreSQL は階層型ストレージをサポートしており、アクセス頻度が低いホットテーブルを Object Storage Service (OSS) 上のコールドテーブルとして移動することで、ストレージコストを削減できます。
本トピックでは、ローカルディスク上に保存されたテーブルを「ホットテーブル」、リモートの Object Storage Service (OSS) 上に保存されたテーブルを「コールドテーブル」と呼びます。
前提条件
-
AnalyticDB for PostgreSQL V6.0 インスタンスで、マイナーバージョンが 6.3.11.1 以降であること。
-
AnalyticDB for PostgreSQL V7.0 インスタンスで、マイナーバージョンが 7.0.3.0 以降であること。
インスタンスの 基本情報 ページで マイナーバージョン を確認できます。必要なバージョン要件を満たしていない場合は、インスタンスのマイナーバージョンを更新してください。
制限事項
-
Serverless モードはサポートされていません。
-
階層型ストレージの制限事項は、AnalyticDB for PostgreSQL V6.0 および AnalyticDB for PostgreSQL V7.0 インスタンスで異なります。ご利用のインスタンスバージョンに該当する制限事項をご確認ください。
V6.0 インスタンス
-
非パーティション化テーブルをコールドテーブルに変換できます。
-
パーティションテーブル全体をコールドテーブルに変換するか、特定のサブパーティションをコールドパーティションに変換できます。
-
インデックス付きパーティションテーブルのサブパーティションをコールドパーティションに変換することはできません。また、コールドパーティションを含むパーティションテーブルに対してインデックスを作成することもできません。
-
ホットテーブルをコールドテーブルに変換すると、プライマリキー、インデックス、シーケンス、ルール、コメントなどの関連オブジェクトは自動的に削除され、復元できません。
-
コールドテーブルまたはコールドパーティション内のデータは読み取り専用です。書き込み、削除、更新操作および
ALTER COLUMNやDROP COLUMNなどのほとんどのデータ定義言語 (DDL) 操作はサポートされていません。ただし、DROP TABLE文を使用してコールドテーブルを削除することは可能です。 -
AnalyticDB for PostgreSQL では、コールドテーブルまたはコールドパーティションを直接ホットに戻すことはサポートされていません。回避策として、
CREATE TABLE AS SELECT文を使用して新しいホットテーブルを作成し、データを移行できます。
V7.0 インスタンス
-
非パーティション化テーブルをコールドテーブルに変換できます。
-
パーティションテーブル全体をコールドテーブルに変換するか、特定のサブパーティションをコールドパーティションに変換できます。
-
コールドテーブルおよびコールドパーティションからのデータ読み取りおよび書き込みが可能です。ただし、削除および更新操作はサポートされていません。
ALTER COLUMNやDROP COLUMNなどのコールドテーブルに対する DDL 操作は、招待制でのみ利用可能です。これらの機能を利用するには、チケットを送信してテクニカルサポートにお問い合わせください。 -
プライマリキーまたは一意なインデックスを持つパーティションテーブルのサブパーティションをコールドパーティションに変換することはできません。通常のインデックスのみを持つパーティションテーブルにはこの制限は適用されません。
-
ホットテーブルをコールドテーブルに変換すると、プライマリキー、インデックス、シーケンス、ルール、コメントなどの関連オブジェクトは自動的に削除され、復元できません。
-
AnalyticDB for PostgreSQL では、コールドテーブルまたはコールドパーティションを直接ホットに戻すことはサポートされていません。回避策として、
CREATE TABLE AS SELECT文を使用して新しいホットテーブルを作成し、データを移行できます。
-
課金
ホットテーブルをコールドテーブルに変換すると、データは OSS に保存され、以下のルールに基づいてストレージ料金が発生します。
-
コールドストレージは従量課金で請求されます。
-
コールドストレージの使用量は 5 分ごとに計測され、1 時間単位で請求されます。
-
料金は OSS 標準ストレージと同額です。詳細については、「OSS 料金」をご参照ください。
例として、中国本土リージョンにおける OSS の料金は、1 GB/月あたり USD 0.017 です。時間単価は 1 GB あたり USD 0.0000236111 です。実際の請求金額は請求書に記載された金額が優先されます。
コールドストレージの請求明細は、 ページで確認できます。
操作手順
-
変換処理では一時テーブルが作成され、データが書き込まれた後、OSS にアップロードされます。これらの操作によりローカルおよびネットワーク I/O リソースが消費され、実行中のクエリに影響を与える可能性があります。実施前に潜在的な影響を評価してください。
-
ホットテーブルをコールドテーブルに変換すると、そのテーブルが占有していたローカルディスク領域が解放されます。
-
AnalyticDB for PostgreSQL V6.0 インスタンスでは、変換は指定時刻にスケジュールされて開始されます。スケジューリングおよびキューイングプロセスにより遅延が発生する場合があります。AnalyticDB for PostgreSQL V7.0 インスタンスでは、文を実行した直後に変換が開始されます。変換に必要な総時間は、インスタンスの仕様、同時変換数、データ量に依存します。詳細については、「パフォーマンスデータ」をご参照ください。
階層型ストレージの操作手順は、AnalyticDB for PostgreSQL V6.0 および AnalyticDB for PostgreSQL V7.0 インスタンスで異なります。ご利用のインスタンスバージョンに対応するタブを選択してください。
V6.0 インスタンス
非パーティション化テーブルの変換
構文
ALTER TABLE <tableName> SET ttl interval '<scheduling_interval>' move to storage_cold;
例
tiered_storage_heap という名前の非パーティション化テーブルを作成し、データを書き込みます。
CREATE TABLE tiered_storage_heap (a int, b int);
INSERT INTO tiered_storage_heap SELECT random() * 1000,1 FROM generate_series(1,1000);
-
例 1:標準テーブル
tiered_storage_heapを 3 日後 (3days) にコールドストレージに移動します。たとえば、2023 年 7 月 17 日 09:00:00 に ALTER TABLE 操作を実行した場合、3 日後の 2023 年 7 月 20 日 09:00:00 にtiered_storage_heapテーブル全体がコールドストレージに移動されます。ALTER TABLE tiered_storage_heap SET ttl interval '3days' move to storage_cold; -
例 2:非パーティション化テーブル
tiered_storage_heapを特定の時刻 (2023 年 7 月 28 日 16:53:58) にコールドテーブルに変換するようスケジュールします。ALTER TABLE tiered_storage_heap SET ttl '2023-07-28 16:53:58'::Timestamp move to storage_cold; -
例 3:過去の時刻を設定してテーブルを即座に変換します。
-
変換時刻を 3 日前 (-3days) に設定します。次のコマンドを実行してテーブルを即座に変換します。
ALTER TABLE tiered_storage_heap SET ttl interval '-3days' move to storage_cold; -
過去の日付と時刻を指定します。現在時刻が 2023 年 7 月 17 日 16:53:58 の場合、次のコマンドを実行してテーブルを即座に変換できます。
ALTER TABLE tiered_storage_heap SET ttl '2022-07-16 16:53:58'::Timestamp move to storage_cold;
-
パーティションテーブルのサブパーティション変換
構文
ALTER TABLE <child_partition_name> SET ttl interval '<scheduling_interval>' move to storage_cold;
psql で \d+ を実行して、特定のパーティションテーブルのサブパーティション名を確認できます。
例
tiered_storage_partition_hdfs という名前のパーティションテーブルを作成します。
CREATE TABLE tiered_storage_partition_hdfs(a int,b int) distributed by (a) partition by range(a) (start(1) end(20) every(10));
この例では、tiered_storage_partition_hdfs_1_prt_1 および tiered_storage_partition_hdfs_1_prt_2 の 2 つのサブパーティションが作成されます。
サブパーティション tiered_storage_partition_hdfs_1_prt_1 にデータを書き込みます。
INSERT INTO tiered_storage_partition_hdfs_1_prt_1 values(1, 1), (2, 2), (3, 3), (4, 4);
サブパーティション tiered_storage_partition_hdfs_1_prt_1 を 3 日後にコールドパーティションに変換するようスケジュールします。たとえば、2023 年 7 月 17 日 09:00:00 に文を実行した場合、tiered_storage_partition_hdfs_1_prt_1 サブパーティションは 2023 年 7 月 20 日 09:00:00 に変換されます。他のサブパーティションには影響しません。
ALTER TABLE tiered_storage_partition_hdfs_1_prt_1 SET ttl interval '3days' move to storage_cold;
テーブルのストレージステータスの照会
次のいずれかの方法でテーブルのストレージステータスを照会できます。クエリ結果は、コールドテーブルの場合は cold、ホットテーブルの場合は hot を返します。
-
方法 1:
SELECT pg_tiered_storage_relation_status('<table_name>'::regclass::oid::bigint); -
方法 2:
SELECT pg_tiered_storage_relation_status(<table_oid>::bigint);SELECT oid FROM pg_class where relname='<table_name>';を実行してテーブル OID を取得します。
V7.0 インスタンス
非パーティション化テーブルの変換
構文
SELECT pg_tiered_storage_move_table_to_storage_cold('<schema_name>', '<table_name>');
例
public スキーマに tiered_storage_heap_oss という名前の非パーティション化テーブルを作成し、データを書き込みます。
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);
-
例 1:テーブル全体を即座にコールドテーブルに変換する
次の文を実行して、非パーティション化テーブル全体を即座にコールドテーブルに変換します。
SELECT pg_tiered_storage_move_table_to_storage_cold('public', 'tiered_storage_heap_oss'); -
例 2:pg_cron を使用してテーブル全体の変換をスケジュールする
etl_userユーザーとして、etlデータベース内のtiered_storage_heap_ossという非パーティション化テーブルを翌日 01:00 にコールドテーブルに変換するとします。postgresデータベースに接続し、次の文を実行します。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');翌日 01:00 を過ぎたら、変換が成功したことを確認し、次の文を実行してスケジュールされたジョブを削除します。
SELECT cron.unschedule(<job_id>);説明ジョブ ID はジョブ作成時に自動的に生成されます。ID は
cron.jobテーブルのjobid列で確認できます。
パーティションテーブルのサブパーティションの変換
構文
SELECT pg_tiered_storage_move_table_to_storage_cold('<schema_name>', '<child_partition_name>');
psql で \d+ を実行すると、特定のパーティションテーブルのサブパーティション名を確認できます。
例
-
例 1:サブパーティションを即座にコールドパーティションに変換する
publicスキーマにtiered_storage_partition_ossという名前のパーティションテーブルを作成します。CREATE TABLE tiered_storage_partition_oss(a int,b int) DISTRIBUTED BY (a) PARTITION BY range(a) (start(1) end(20) every(10));説明この例では、
tiered_storage_partition_oss_1_prt_1およびtiered_storage_partition_oss_1_prt_2の 2 つのサブパーティションが作成されます。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);サブパーティションを即座にコールドパーティションに変換します。
SELECT pg_tiered_storage_move_table_to_storage_cold('public', 'tiered_storage_partition_oss_1_prt_1'); -
例 2:pg_cron を使用して日次サブパーティションの変換をスケジュールする
etlデータベースにdaily_log_detailsという名前の日次パーティションテーブルを作成します。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 );etl_userユーザーとして 03:00 に実行されるジョブを設定し、10 日以上経過したサブパーティションをコールドパーティションに変換します。以下の手順に従います。-
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; -
postgresデータベースに接続し、変換文を実行します。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');
-
-
例 3:pg_cron を使用して月次サブパーティションの変換をスケジュールする
etlデータベースにmonth_log_detailsという名前の月次パーティションテーブルを作成します。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 );etl_userユーザーとして 05:00 に実行されるジョブを設定し、3 ヶ月以上経過したサブパーティションをコールドパーティションに変換します。以下の手順に従います。-
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; -
postgresデータベースに接続し、変換文を実行します。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');
-
テーブルのストレージステータスのクエリ
次の文を実行してテーブルのストレージステータスをクエリします。クエリ結果は、コールドテーブルの場合は cold、ホットテーブルの場合は hot を返します。
SELECT pg_tiered_storage_table_status('<schema_name>', '<table_name>|<child_partition_name>')
ホットストレージおよびコールドストレージの使用量
AnalyticDB for PostgreSQL コンソール にログインします。基本情報 ページの インスタンス実行ステータス カードで、ホットストレージ容量の合計 および コールドストレージ容量の合計 の使用量を確認できます。
バックアップおよびリストア
AnalyticDB for PostgreSQL の階層型ストレージはバックアップおよびリストアをサポートしています。データをリストアする際、以下のルールが適用されます。
V6.0 インスタンス
完全バックアップが利用可能な場合、任意の時点にデータをリストアできます。リストアされたデータのストレージステータス (ホットまたはコールド) は、バックアップ時のステータスと一致します。
V7.0 インスタンス
完全バックアップが利用可能な場合、指定した時点にデータをリストアできます。リストアされたデータのストレージステータス (ホットまたはコールド) は、バックアップ時のステータスと一致します。AnalyticDB for PostgreSQL V7.0 には以下の制限があります。
-
テーブルをコールドテーブルに変換した後、データが書き込まれていない場合、任意の時点にテーブルをリストアできます。
-
テーブルをコールドテーブルに変換した後、データが書き込まれている場合、変換前の任意のバックアップポイントにテーブルをリストアできます。変換後の時点へのリストアでは、最新の書き込み操作時点のテーブル状態にのみ復元できます。
バックアップおよびリストアをサポートするため、削除されたテーブルの OSS 領域は即座に解放されません。代わりに、データバックアップ保持日 設定と同等の期間、領域が保持されます。この延長された保持期間中は OSS 領域に対して料金が発生します。
バックアップおよびリストアの詳細については、「バックアップおよびリストア」をご参照ください。
スケーリング
AnalyticDB for PostgreSQL V6.0 インスタンスをスケールインする際、コールドテーブルはデータ再分配のためにローカルの一時テーブルに移動されます。スケールイン完了後、データは再度 OSS にアップロードされ、ローカルの一時テーブルは削除されます。スケールインを成功させるには、すべてのノードに残っているディスク領域がコールドテーブルの合計サイズを超える必要があります。操作時間は OSS のダウンロード帯域幅によって制限されます。実施前にスケールインに要する時間を評価してください。
AnalyticDB for PostgreSQL V7.0 インスタンスでは、スケーリングによるコールドストレージデータへの影響はありません。データ再分配およびローカルストレージへの復元が不要なため、コールドストレージが使用するディスク領域を考慮する必要はありません。
パフォーマンスデータ
パフォーマンステストは、4 ノードインスタンスおよび 8 ノードインスタンス (いずれも 2 コア 8 GB ノード) で実施されました。テストテーブルは次の文で作成およびデータ投入されました。
CREATE TABLE t333 (a int, b int);
INSERT INTO t333 SELECT random() * 1000000, random()*1000000 FROM generate_series(1,3000000000);
AnalyticDB for PostgreSQL V6.0 インスタンスでは、ALTER TABLE t333 SET ttl interval '-3days' move to storage_cold; 文を実行しました。
AnalyticDB for PostgreSQL V7.0 インスタンスでは、SELECT pg_tiered_storage_move_table_to_storage_cold('public', 't333'); 文を実行しました。
次の表は、単一テーブルの変換時間を示しています。
|
ホットテーブルサイズ (GB) |
4 ノード変換時間 (秒) |
8 ノード変換時間 (秒) |
||
|
V6.0 インスタンス |
V7.0 インスタンス |
V6.0 インスタンス |
V7.0 インスタンス |
|
|
1 |
10 |
5 |
5 |
2.8 |
|
10 |
96 |
48 |
42 |
25.2 |
|
100 |
848 |
490 |
333 |
243 |