AnalyticDB for PostgreSQL は、ストレージコストの削減に役立つ階層化ストレージを提供します。アクセス頻度の低いデータをホットテーブルから Object Storage Service (OSS) にコールドテーブルとして移動できます。このトピックでは、階層化ストレージの制限事項と使用方法について説明します。
このトピックでは、ローカルディスクに保存されているテーブルをホットテーブル、リモート OSS に保存されているテーブルをコールドテーブルと呼びます。
前提条件
マイナーバージョンが 6.3.11.1 以降の AnalyticDB for PostgreSQL V6.0 インスタンス。
マイナーバージョンが 7.0.3.0 以降の AnalyticDB for PostgreSQL V7.0 インスタンス。
インスタンスの マイナーバージョン は、AnalyticDB for PostgreSQL コンソールの [基本情報] ページで確認できます。ご利用のインスタンスが要件を満たしていない場合は、インスタンスのマイナーバージョンを更新してください。
制限事項
サーバーレスモードはサポートされていません。
階層化ストレージ機能の制限事項は、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
非パーティションテーブルをコールドテーブルに変換できます。
パーティションテーブル全体をコールドテーブルに変換したり、特定のサブパーティションをコールドパーティションに変換したりできます。
SELECTおよびINSERT操作はコールドテーブルおよびコールドパーティションで許可されています。DELETEおよびUPDATE操作はサポートされていません。ALTER COLUMNやDROP COLUMNなど、コールドテーブルに対する一部の DDL 操作は、招待制のベータ版です。この機能を使用するには、チケットを送信してください。通常のインデックスを持つパーティションテーブルのサブパーティションはコールドサブパーティションに変換できますが、プライマリキーまたは一意なインデックスを持つものは変換できません。
ホットテーブルをコールドテーブルに変換すると、プライマリキー、インデックス、シーケンス、ルール、コメントなどの関連オブジェクトは自動的に削除され、回復できません。
AnalyticDB for PostgreSQL は、コールドテーブルまたはコールドパーティションをホットテーブルに直接変換することをサポートしていません。
CREATE TABLE AS SELECT文を実行して新しいホットテーブルを作成し、コールドテーブルから新しいホットテーブルにデータを移行できます。
課金
ホットテーブルをコールドテーブルに変換すると、データは OSS に保存され、ストレージ料金が発生します。課金ルールは次のとおりです:
コールドストレージは従量課金制で課金されます。
コールドストレージの使用量は 5 分ごとに収集され、1 時間ごとに課金されます。
価格は OSS 標準ストレージの価格と同じです。詳細については、「OSS の価格」をご参照ください。
例えば、中国本土リージョンでは、OSS の価格は 月額 0.017 米ドル/GB です。1 時間あたりの価格は 0.0000236111 米ドル/GB です。請求書の価格が最終的な価格となります。
コールドストレージの課金詳細は、 を選択して確認できます。
使用方法
ホットテーブルをコールドテーブルに変換するプロセスには、一時テーブルの作成、データの書き込み、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 にコールドストレージに移動されます。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 に ALTER TABLE 文を実行すると、tiered_storage_partition_hdfs_1_prt_1 サブパーティションは 3 日後の 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 );10 日より古いサブパーティションをコールドストレージに変換するジョブを設定します。ジョブは 03:00 に実行され、
etl_userによって実行されます。次の手順に従います。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'''; -- 期限切れのパーティションをフェッチします 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 );3 か月より古いサブパーティションをコールドストレージに変換するジョブを設定します。ジョブは毎月 1 日の 05:00 に実行され、
etl_userによって実行されます。次の手順に従います。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'''; -- 期限切れのパーティションをフェッチします 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 コンソールにログインします。[基本情報] ページで、インスタンス実行ステータス カードにある Hot Storage と Cold Storage を確認します。
バックアップと復元
AnalyticDB for PostgreSQL の階層化ストレージは、バックアップと復元をサポートしています。データ復元は、以下のルールに従います。
v6.0
完全バックアップが利用可能な場合、データを任意の時点に復元できます。復元時のデータのストレージステータス (ホットまたはコールド) は、バックアップ時のステータスと一致します。
v7.0
完全バックアップが利用可能な場合、データを指定した時点に復元できます。復元時のデータのストレージステータス (ホットまたはコールド) は、バックアップ時のステータスと一致します。AnalyticDB for PostgreSQL V7.0 には、以下の制限事項があります。
テーブルがコールドテーブルに変換された後、データが書き込まれていない場合、テーブルを任意の時点に復元できます。
テーブルがコールドテーブルに変換された後、データが書き込まれた場合、変換前に作成された任意のバックアップポイントにテーブルを復元できます。変換後のポイントインタイムに復元する場合、最後の書き込み時点にのみ復元できます。
バックアップと復元をサポートするため、削除されたテーブルが使用していた OSS スペースはすぐには解放されません。代わりに、データバックアップ保持期間 の設定で指定された期間保持されます。この保持期間中、OSS スペースに対して課金されます。
バックアップと復元の詳細については、「バックアップと復元」をご参照ください。
スケーリング
AnalyticDB for PostgreSQL V6.0 インスタンスをスケールインすると、データ再配布のためにコールドテーブルがローカル一時テーブルに移動されます。スケールインが完了すると、データは OSS に再アップロードされ、ローカル一時テーブルはクリアされます。スケールインを成功させるには、操作後のすべてのノードにおける残りの合計ディスク領域が、コールドテーブルが占有する合計領域よりも大きい必要があります。スケールインプロセス中、データは OSS からダウンロードされます。スケールインの所要時間は、OSS のダウンロード帯域幅によって制限されます。そのため、スケールインにかかる時間を慎重に評価する必要があります。
AnalyticDB for PostgreSQL V7.0 インスタンスの場合、スケーリングはコールドストレージ内のデータに影響を与えません。データ再配布や、ローカルストレージへのデータ転送は不要です。コールドストレージによって占有されるディスク領域を考慮する必要はありません。
パフォーマンス
テストは、いずれも 2 コア 8 GB のノードで構成される 4 ノードインスタンスと 8 ノードインスタンスで、以下の文を使用して実行されました。
CREATE TABLE t333 (a int, b int);
INSERT INTO t333 SELECT random() * 1000000, random()*1000000 FROM generate_series(1,3000000000);v6.0 インスタンスでは、次の文が実行されました: ALTER TABLE t333 SET ttl interval '-3days' move to storage_cold;
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 |