AnalyticDB for PostgreSQL は階層型ストレージをサポートしています。これにより、アクセス頻度の低いホットテーブルを Object Storage Service (OSS) にコールドテーブルとして移動させ、ストレージコストを削減できます。
このトピックでは、ローカルディスクに保存されているテーブルをホットテーブル、リモートの Object Storage Service (OSS) に保存されているテーブルをコールドテーブルと呼びます。
前提条件
AnalyticDB for PostgreSQL V6.0 は、ホットデータとコールドデータの階層型ストレージをサポートしていません。
マイナーバージョン 7.0.3.0 以降を実行している AnalyticDB for PostgreSQL V7.0 インスタンス。
インスタンスのマイナーバージョンは、AnalyticDB for PostgreSQL コンソールの [基本情報] ページで確認できます。ご利用のインスタンスが要件を満たしていない場合は、インスタンスのマイナーバージョンを更新してください。
制限事項
サーバーレスモードはサポートされていません。
非パーティション化テーブルをコールドテーブルに変換できます。
パーティションテーブルをコールドテーブルに変換したり、特定のサブパーティションをコールドパーティションに変換したりできます。
コールドテーブルおよびコールドパーティションからのデータの読み取りと書き込みは可能ですが、削除および更新操作はサポートされていません。コールドテーブルに対する DDL 操作 (例:
ALTER COLUMN、DROP COLUMN) は、招待制でのみ利用可能です。これらの機能を使用するには、チケットを送信してテクニカルサポートにご連絡ください。`COPY` 文を使用して、コールドテーブルやコールドパーティションを含むパーティションテーブルにデータを書き込むことはできません。また、`COPY` 文を使用して、コールドテーブルやコールドパーティションを含むパーティションテーブルからデータをエクスポートすることもできません。データのインポートには `INSERT` 文を使用してください。
パーティションテーブルのサブパーティションがコールドパーティションに変換された後、親パーティションテーブルに対して `TRUNCATE` 文を実行したり、DDL 操作 (例:
ALTER COLUMN、DROP COLUMN) を実行したりすることはできません。プライマリキーまたは一意なインデックスを持つパーティションテーブルのサブパーティションをコールドパーティションに変換することはできません。この制限は、通常のインデックスのみを持つパーティションテーブルには適用されません。
ホットテーブルがコールドテーブルに変換されると、元のテーブルに関連付けられていたプライマリキー、インデックス、シーケンス、ルール、コメントは自動的に削除され、回復することはできません。
コールドテーブルまたはコールドパーティションを直接ホットテーブルに戻すことはできません。
CREATE TABLE AS SELECT文を使用してホットテーブルを作成し、コールドテーブルからホットテーブルにデータを移行することができます。
課金
ホットテーブルをコールドテーブルに変換すると、データは OSS に保存され、以下のルールに基づいてストレージ料金が発生します。
コールドストレージは従量課金制です。
コールドストレージの使用量は 5 分ごとに測定され、1 時間ごとに課金されます。
料金は OSS 標準ストレージと同じです。詳細については、「OSS 料金」をご参照ください。
例えば、OSS の料金は 0.017 USD/GB/月です。時間単位の料金は 0.0000236111 USD/GB です。実際の料金は請求書に記載されたものが適用されます。
コールドストレージの請求明細は、 ページで確認できます。
操作手順
変換プロセスでは、一時テーブルが作成され、データが書き込まれ、OSS にアップロードされます。これらの操作はローカルおよびネットワークの I/O リソースを消費するため、実行中のクエリに影響を与える可能性があります。続行する前に、潜在的な影響を評価してください。
ホットテーブルがコールドテーブルに変換されると、占有していたローカルディスク領域が解放されます。
変換に必要な合計時間は、インスタンスの仕様、同時変換数、データ量によって異なります。詳細については、「パフォーマンスデータ」をご参照ください。
以下の手順に従って、ホットテーブルをコールドテーブルに変換します。
非パーティション化テーブルの変換
構文
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 の階層化ストレージは、バックアップと復元をサポートしています。データを復元する際には、以下のルールが適用されます:
完全バックアップが利用可能な場合、指定した時点にデータを復元できます。復元されたデータのストレージステータス (ホットまたはコールド) は、バックアップ時のステータスと一致します。AnalyticDB for PostgreSQL V7.0 には、以下の制限事項があります:
テーブルがコールドテーブルに変換された後、データが書き込まれていない場合、そのテーブルを任意の時点に復元できます。
テーブルがコールドテーブルに変換された後、データが書き込まれた場合、変換前の任意のバックアップポイントにテーブルを復元できます。変換後の時点への復元については、直近の書き込み操作時点の状態にのみテーブルを復元できます。
バックアップと復元をサポートするため、システムは、ドロップされたテーブルの OSS スペースをすぐには解放しません。 代わりに、このスペースは データバックアップ保持日 設定と等しい期間保持されます。 この延長された保持期間中、OSS スペースは課金対象となります。
詳細については、「バックアップと復元」をご参照ください。
スケーリング
スケーリングはコールドストレージのデータに影響を与えません。データの再分散やローカル記憶域への復元は不要であるため、コールドストレージが使用するディスク領域を考慮する必要はありません。
パフォーマンスデータ
パフォーマンステストは、それぞれ 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);AnalyticDB for PostgreSQL V7.0 インスタンスの場合は、SELECT pg_tiered_storage_move_table_to_storage_cold('public', 't333'); 文を実行します。
次の表に、単一テーブルの変換時間を示します。
ホットテーブルのサイズ (GB) | 4 ノードの変換時間 (秒) | 8 ノードの変換時間 (秒) |
1 | 5 | 2.8 |
10 | 48 | 25.2 |
100 | 490 | 243 |