MaxCompute は、標準ストレージ、低頻度アクセス(IA)ストレージ、長期ストレージの 3 つのストレージ階層をサポートしています。 デフォルトでは、データは標準ストレージ階層に保存されます。 データへのアクセス頻度に基づいて、特定のテーブルまたはパーティションのストレージ階層を IA または長期のいずれかに指定できます。 これにより、コールドデータ(アクセス頻度の低いデータ)とホットデータ(アクセス頻度の高いデータ)が個別に保存され、データストレージコストが削減されます。
制限事項
サポートされているリージョン:中国(杭州)、中国(上海)、中国(北京)、中国(張家口)、中国(ウランチャブ)、中国(深セン)、中国(成都)、中国(香港)、中国東部 2 金融、中国北部 2 金融、中国南部 1 金融、シンガポール、マレーシア(クアラルンプール)、インドネシア(ジャカルタ)、日本(東京)、ドイツ(フランクフルト)。
ストレージ階層
ストレージタイプ | 説明 |
標準ストレージ | デフォルトのストレージタイプで、データへのアクセス頻度が高く、頻繁な読み取りおよび書き込み操作が必要なシナリオに適しています。 |
IA ストレージ | IA ストレージと長期ストレージは、アクセス頻度の低いデータに適しています。 IA ストレージと長期ストレージを使用すると、ストレージコストを大幅に削減できます。 説明
|
長期ストレージ |
階層型ストレージの料金
ストレージ料金の詳細については、「ストレージ料金」をご参照ください。
費用とコスト コンソール にログインし、左側のナビゲーションウィンドウで [Bills] > [Bill Details] を選択します。 [請求の詳細] ページで、さまざまなストレージ階層でのデータの保存とアクセスに対して発生した料金を表示します。 詳細については、「請求の詳細を表示する」をご参照ください。
注意事項
Hologres は、IA ストレージ階層または長期ストレージ階層のデータに直接アクセスできません。 さらに、Hologres が MaxCompute から直接読み取る場合、MaxCompute のテーブルまたはパーティションの last_access_time は現時点では更新されません。 そのため、last_access_time に基づく条件を使用して階層型ストレージライフサイクルでルールを設定すると、Hologres によってのみ継続的に読み取られている特定のテーブルまたはパーティションもこれらのルールで定義された基準を満たす可能性があります。
テーブルまたはパーティションのストレージ階層を IA ストレージまたは長期ストレージに設定する場合は、データ量とデータアクセス頻度に注意してください。 データが大量に、または頻繁にアクセスされる場合、発生する料金は標準ストレージ階層のデータよりも高くなる可能性があります。
IA ストレージ階層のテーブルまたはパーティション内のすべてのデータに月に 1 回アクセスする場合、データアクセス料金とストレージ料金の合計は、標準ストレージ階層のデータのストレージ料金と同じです。
長期ストレージ階層のテーブルまたはパーティション内のすべてのデータに 6 か月に 1 回アクセスする場合、データアクセス料金とストレージ料金の合計は、標準ストレージ階層のデータのストレージ料金と同じです。
ストレージタイプの指定
ストレージタイプは相互に変換できます。 変換はデータアクセス パフォーマンスに悪影響を与えません。
変換プロセス | 説明 |
標準ストレージから IA ストレージ | 手動変換と自動変換の両方をサポートし、I/O アクセス料金は発生しません。 「最終データ更新時刻」や「最終データアクセス時刻」などのテーブルまたはパーティションのフィールドは更新されません。 |
標準ストレージから長期ストレージ | |
IA ストレージから長期ストレージ | 手動変換と自動変換の両方をサポートします。 手動変換では I/O アクセス料金が発生しますが、自動変換では発生しません。 「最終データ更新時刻」や「最終データアクセス時刻」などのテーブルまたはパーティションのフィールドは更新されません。 |
IA ストレージから標準ストレージ | 手動変換のみをサポートし、I/O アクセス料金が発生します。 「最終データ更新時刻」や「最終データアクセス時刻」などのテーブルまたはパーティションのフィールドは更新されます。 |
長期ストレージから IA ストレージ | |
長期ストレージから標準ストレージ |
手動構成
パーティション化されていないテーブルまたはパーティション化されたテーブルのパーティションの場合、IA ストレージ階層または長期ストレージ階層を手動で指定できます。 設定は、手動構成後すぐに有効になります。
構文
ALTER TABLE <TABLE_NAME> [PARTITION(<PARTITION_SPEC>)]
SET <TBLPROPERTIES|PARTITIONPROPERTIES>("storagetier"="standard|lowfrequency|longterm");
パラメーターの説明
TABLE_NAME:テーブルの名前。 このパラメーターは、テーブルまたはパーティションのストレージ階層を指定する場合に関係なく必須です。
PARTITION_SPEC:パーティションのストレージ階層を指定する場合に必須です。
TBLPROPERTIES|PARTITIONPROPERTIES:ストレージ階層を指定するテーブルまたはパーティションのプロパティ。
TBLPROPERTIES:テーブルのプロパティ。
PARTITIONPROPERTIES:パーティションのプロパティ。
storagetier:必須。 ストレージ階層。 有効な値:
standard:標準ストレージ。 ストレージ料金のみが課金されます。
lowfrequency:IA ストレージ。 ストレージ料金と、IA ストレージ階層のデータへのアクセスに対して発生した料金が課金されます。
longterm:長期ストレージ。 ストレージ料金と、長期ストレージ階層のデータへのアクセスに対して発生した料金が課金されます。
パーティション化されたテーブルの場合、ストレージ階層はパーティションレベルでのみ指定でき、テーブルレベルでは指定できません。
例
例 1:パーティション化されていないテーブルのストレージ階層として IA ストレージを指定します。
ALTER TABLE tablename SET TBLPROPERTIES("storagetier"="lowfrequency");
テーブルプロパティの
StorageTier
フィールドを表示して、現在のストレージ階層を確認します。-- テーブルプロパティを表示します。 DESC extended tablename; -- 次の結果が返されます。 +-------------------------------------------------------------------+ | Owner: ALIYUN$mofan_****@test.aliyunid.com | | Project: mf_mc_**** | | TableComment: | +-------------------------------------------------------------------+ | CreateTime: 2021-11-18 15:14:00 | | LastDDLTime: 2023-09-11 14:34:55 | | LastModifiedTime: 2023-09-13 15:02:28 | | LastAccessTime: 2023-09-14 10:50:57 | +-------------------------------------------------------------------+ | InternalTable: YES | Size: 1923683131 | +-------------------------------------------------------------------+ | Native Columns: | +-------------------------------------------------------------------+ | Field| Type| Label |ExtendedLabel| Nullable| DefaultValue|Comment | +-------------------------------------------------------------------+ | empno | bigint | | | true | NULL | | | ename | string | | | true | NULL | | | job | string | | | true | NULL | | | mgr | bigint | | | true | NULL | | | hiredate | datetime | | | true | NULL | | | sal | bigint | | | true | NULL | | | comm | bigint | | | true | NULL | | | deptno | bigint | | | true | NULL | | +-------------------------------------------------------------------+ | Extended Info: | +-------------------------------------------------------------------+ | TableID: 8e0cc78c81ab4ad7af30bff7a8e**** | | IsArchived: false | | PhysicalSize: 5771049393 | | FileNum: 3 | | StoredAs: AliOrc | | CompressionStrategy: normal | | odps.timemachine.retention.days: 1 | | ColdStorageStatus: N/A | | encryption_enable: false | | StorageTier: lowfrequency | | StorageTierLastModifiedTime: 2023-09-11 14:34:55 | +-------------------------------------------------------------------+
例 2:bank_data_pt という名前のパーティション化されたテーブルのパーティションのストレージ階層として IA ストレージを指定します。
ALTER TABLE bank_data_pt PARTITION (credit='yes') SET PARTITIONPROPERTIES ("storagetier" = 'lowfrequency');
パーティションプロパティの
StorageTier
フィールドを表示して、現在のストレージ階層を確認します。-- パーティションプロパティを表示します。 DESC extended bank_data_pt PARTITION(credit='yes'); -- 次の結果が返されます。 +------------------------------------------------------------------------------------+ | PartitionSize: 0 | +------------------------------------------------------------------------------------+ | CreateTime: 2024-05-10 10:28:16 | | LastDDLTime: 2024-05-10 10:31:01 | | LastModifiedTime: 2024-05-10 10:28:16 | +------------------------------------------------------------------------------------+ | IsExstore: false | | IsArchived: false | | PhysicalSize: 0 | | FileNum: 0 | | ColdStorageStatus: N/A | | StorageTier: LowFrequency | | StorageTierLastModifiedTime: 2024-05-10 10:31:01 | +------------------------------------------------------------------------------------+
ライフサイクルフールの基づく自動構成
プロジェクトまたはパーティション化されたテーブルの場合、ストレージ階層のライフサイクルのルールを定義できます。 システムは、ライフサイクルフールに基づいて、ストレージ階層間の自動変換をトリガーできます。
プロジェクトのストレージ階層ライフサイクルフールを定義した後、プロジェクト内のすべてのパーティション化されていないテーブルまたはパーティションがルールを満たしている場合、システムはパーティション化されていないテーブルまたはパーティションのストレージ階層変換を自動的に実行します。
パーティション化されたテーブルのストレージ階層ライフサイクルフールを定義した後、テーブル内のすべてのパーティションがルールを満たしている場合、システムはパーティションのストレージ階層変換を自動的に実行します。
使用上の注意
各パーティションまたはパーティション化されていないテーブルに個別にストレージ階層ライフサイクルフールを構成することはできません。
パーティション化されたテーブルのストレージ階層ライフサイクルフールは、パーティション化されたテーブルが属するプロジェクトのストレージ階層ライフサイクルフールよりも優先されます。
テーブルまたはパーティションのライフサイクルが長期ストレージ階層と IA ストレージ階層の両方のルールを満たしている場合、ストレージ階層は優先的に長期ストレージに変換されます。
テーブルまたはパーティションのライフサイクルが IA ストレージのルールを満たしている場合、ストレージ階層は IA ストレージに変換されます。 その後、テーブルまたはパーティションのライフサイクルが長期ストレージのルールを満たしている場合、ストレージ階層は長期ストレージに変換されます。 IA ストレージから長期ストレージへの変換では、IA ストレージ階層のデータへのアクセスに対して料金が発生します。 料金の詳細については、このトピックの階層型ストレージの料金を参照してください。
プラットフォームは 1 日 2 回ルールを定期的にスキャンします。 そのため、ルールが満たされた後、変換がすぐに実行されない場合があります。
構文
プロジェクトレベルでライフサイクルフールを構成する
SETPROJECT odps.table.lifecycle.config=<lifecycle_config_json_string>;
MaxCompute コンソールからも構成できます。
MaxCompute コンソール にログインします。 上部のナビゲーションバーで、リージョンを選択します。
左側のナビゲーションウィンドウで、[ワークエリア] > [プロジェクト管理] を選択し、管理するプロジェクトを見つけて、[操作] 列の [管理] をクリックします。
[パラメーター設定] タブの [ライフサイクル設定] セクションで、[最近のアクセス設定ポリシー] と [最近変更された設定ポリシー] のパラメーターを構成します。
最終アクセス構成ポリシー:
DaysAfterLastAccessGreaterThan
パラメーターに対応します。最終変更構成ポリシー:
DaysAfterLastModificationGreaterThan
パラメーターに対応します。
パーティションテーブルレベルでライフサイクルフールを構成する
テーブルの作成中にルールを構成する:
CREATE [EXTERNAL] TABLE [IF NOT EXISTS] <table_name> [PRIMARY KEY (<pk_col_name>, <pk_col_name2>),(<col_name> <data_type> [NOT NULL] [DEFAULT <default_value>] [comment <col_comment>], ...)] PARTITIONED BY (<col_name> <data_type> [comment <col_comment>], ...) tblproperties ('lifecycle_config' = '<lifecycle_config_json_string>') ;
テーブル設定を変更してルールを構成する:
ALTER TABLE <TABLE_NAME> SET TBLPROPERTIES ('lifecycle_config' = '<lifecycle_config_json_string>');
パーティションテーブルの階層型ストレージライフサイクルの構成を表示する
SHOW CREATE TABLE <table_name>;
パラメーターの説明
このセクションでは、主なパラメーターについて説明します。 その他のパラメーターの詳細については、「テーブル操作」の「パラメーター」をご参照ください。
lifecycle_config_json_string:
次のコードは、プロジェクトレベルでのライフサイクルフールの定義を示しています。
{ "TierToLowFrequency": { "DaysAfterLastModificationGreaterThan": <days>, // 最終変更時刻の xx 日後 "DaysAfterLastAccessGreaterThan": <days>, // 最終アクセス時刻の xx 日後 }, "TierToLongterm": { "DaysAfterLastModificationGreaterThan": <days>, "DaysAfterLastAccessGreaterThan": <days> } // 各条件はオプションであり、複数の条件は OR 関係にあります。 }
次のコードは、パーティションテーブルレベルでのライフサイクルフールの定義を示しています。
{ \"TierToLowFrequency\": { \"DaysAfterLastModificationGreaterThan\": <days>, // 最終変更時刻の xx 日後 \"DaysAfterLastAccessGreaterThan\": <days>, // 最終アクセス時刻の xx 日後 }, \"TierToLongterm\": { \"DaysAfterLastModificationGreaterThan\": <days>, \"DaysAfterLastAccessGreaterThan\": <days> } // 各条件はオプションであり、複数の条件は OR 関係にあります。 }
TierToLowFrequency:IA ストレージ階層。
TierToLongterm:長期ストレージ階層。
DaysAfterLastModificationGreaterThan:最終変更時刻の N 日後に自動変換がトリガーされます。 N はこのパラメーターで指定されます。 このパラメーターは、テーブルまたはパーティションの LastModifiedTime に対応します。
DaysAfterLastAccessGreaterThan:最終アクセス時刻の N 日後に自動変換がトリガーされます。 N はこのパラメーターで指定されます。 テーブルまたはパーティションの LastAccessTime が空のままになっている場合は、次の原則が適用されます。
2023 年 10 月 1 日より前に作成したテーブルまたはパーティションの場合、
2023.10.01 00:00:00
UTC+0 が最終アクセス時刻と見なされます。2023 年 10 月 1 日以降に作成したテーブルまたはパーティションの場合、データにアクセスしない場合、テーブルまたはパーティションの作成時刻が最終アクセス時刻と見なされます。
例
例 1:プロジェクトレベルでストレージ階層ライフサイクルフールを構成します。
setproject odps.table.lifecycle.config={"TierToLongterm":{"DaysAfterLastAccessGreaterThan":180},"TierToLowFrequency":{"DaysAfterLastAccessGreaterThan":120}};
例 2:プロジェクトレベルでストレージ階層ライフサイクルフールの構成を削除します。
setproject odps.table.lifecycle.config=;
例 3:パーティションテーブルレベルでストレージ階層ライフサイクルフールを構成します。
-- パーティションテーブルの作成中にルールを構成します。 CREATE TABLE lifecycle_part_t (key string) PARTITIONED BY (ds STRING) tblproperties ('lifecycle_config' = '{\"TierToLowFrequency\": {\"DaysAfterLastModificationGreaterThan\": 2,\"DaysAfterLastAccessGreaterThan\": 2},\"TierToLongterm\": {\"DaysAfterLastModificationGreaterThan\": 4,\"DaysAfterLastTierModificationGreaterThan\": 7}}') ; -- テーブル設定を変更してルールを構成します。 ALTER TABLE lifecycle_part_t SET tblproperties ('lifecycle_config'='{\"TierToLowFrequency\": {\"DaysAfterLastModificationGreaterThan\": 90,\"DaysAfterLastAccessGreaterThan\": 30},\"TierToLongterm\": {\"DaysAfterLastModificationGreaterThan\": 180,\"DaysAfterLastTierModificationGreaterThan\": 7}}');
例 4:パーティションテーブルの階層型ストレージライフサイクルの構成を削除します。
ALTER TABLE lifecycle_part_t SET tblproperties ('lifecycle_config'='{}');
階層型ストレージデータのアクセス権限の構成
IA ストレージ階層またはコールドストレージ階層からデータを取得する場合、アクセスには料金が発生します。 GET_PARTITION_META 関数を利用して、行レベルアクセス制御機能に基づいて IA ストレージ階層またはコールドストレージ階層内のデータの権限を管理し、それによってデータアクセスを効果的に制御できます。
GET_PARTITION_META
GET_PARTITION_META は特殊な関数であり、行レベルの権限でのみ使用でき、標準 SQL クエリでは使用できません。
構文
struct GET_PARTITION_META(<tableName>, <pt_col1>, <pt_col2>, ..., <pt_col_n>);
パラメーターの説明
パラメーター | 説明 |
tableName | テーブルの名前。 パーティションテーブルである必要があります。 値は String タイプで、 |
pt_col | pt_col1 から pt_col_n までの各パラメーターは、パーティションテーブルのパーティションレベルに対応します。 各パラメーターは列参照である必要があります。 |
戻り値の説明
Struct (struct<storagetier:string>
) タイプの値を返します。 Struct には、対応するパーティションのストレージクラスを記述する 1 つの String フィールドが含まれています。
注意事項
テーブルに行レベルのルールを追加する場合は、他のユーザーのアクセス動作を考慮する必要があります。他のユーザーがテーブルにアクセスしている場合は、予期しないアクセス拒否を防ぐために、明示的なルールを設定します。詳細については、「行レベルのアクセス制御」をご参照ください。
MaxCompute テーブルには、SQL および Spark や Flink などの外部エンジンを介してアクセスできます。ただし、GET_PARTITION_META 関数は現在、MaxCompute SQL エンジンでのみサポートされています。行レベルのアクセス制御で GET_PARTITION_META 関数を使用するテーブルには、他のエンジンからアクセスできません。
データにアクセスするには、行レベルの権限に加えて、データへの SELECT 権限などのデータアクセス権限が必要です。
GET_PARTITION_META のフィルター条件は、シナリオによって異なるパーティションプルーニング効果をもたらします。
フィルター条件には、パーティションフィールドのみが含まれます。たとえば、1 レベル目のパーティション値が
2024
である標準ストレージへのアクセスを許可します。GET_PARTITION_META('storage_table', pt1, pt2).storagetier == 'standard') AND pt1='2024'
SQL を使用して
storage_table
をクエリする場合、WHERE 句にパーティション条件がないと、システムは自動的にパーティションプルーニングをサポートして、フルテーブルスキャンを防ぎます。これにより、読み取り専用モードでは、storage_table
の要件を満たすパーティションのみにアクセスします。フィルター条件にはパーティション以外のフィールド値が含まれており、AND 演算を使用して 2 つのフィルター条件を接続します。たとえば、標準ストレージへのアクセスを許可すると同時に、
a > 100
のパーティション以外の値に AND 演算を適用します。GET_PARTITION_META('storage_table', pt1, pt2).storagetier == 'standard') AND a > 100
SQL を使用して
storage_table
をクエリする場合、WHERE 句にパーティション条件がない場合、パーティションプルーニングがサポートされます。この場合、standard
として指定されたパーティションのみにアクセスします。フィルター条件にはパーティション以外のフィールド値が含まれており、OR 演算を使用して 2 つのフィルター条件を接続します。たとえば、標準ストレージへのアクセスを許可すると同時に、
a>100
のパーティション以外の値に OR 演算を適用します。get_partition_meta('storage_table', pt1, pt2).storagetier == 'standard') OR a > 100
SQL を使用して
storage_table
をクエリする場合、次の 2 つのシナリオのいずれかが発生する可能性があります。WHERE 句にパーティション条件がない場合、
a>100
の条件を満たすデータを取得するためにフルテーブルスキャンが行われます。WHERE 句にパーティション条件が含まれている場合、
standard
またはa>100
の条件を満たす関連パーティション内のデータのみがスキャンされます。
例
パーティションテーブル storage_table
を定義します。
CREATE TABLE storage_table(a BIGINT, b BIGINT) PARTITIONED BY (pt1 STRING, pt2 STRING);
例 1:
policy01
権限をデフォルトユーザーに付与して、storage_table
内の標準ストレージデータにアクセスできるようにします。 ユーザーは IA データまたは長期ストレージデータにアクセスできず、null 値が返されます。CREATE ROW ACCESS POLICY policy01 ON storage_table TO DEFAULT FILTER USING (get_partition_meta('storage_table', pt1, pt2).storagetier == 'standard');
例 2:
policy02
権限をユーザーuser_x
に付与して、storage_table
内の IA データと長期ストレージデータにアクセスできるようにします。CREATE ROW ACCESS POLICY policy02 ON storage_table TO USER (user_x) -- TO role rolename 句を使用してロールに権限を付与し、そのロールをユーザーに付与することもできます。 FILTER USING (get_partition_meta('storage_table', pt1, pt2).storagetier IN ('lowfrequency','longterm'));
2 つの考えられるシナリオ:
policy01
権限がプロジェクトに設定されている場合、すべてのユーザー (user_x を除く) はstorage_table
内の標準ストレージデータへのアクセス権が付与されます。 ただし、IA データまたは長期ストレージデータを取得するアクセス権限がないため、null 戻り値が返されます。 ユーザー user_x はstorage_table
内の IA データと長期ストレージデータへのアクセス権限がありますが、標準ストレージデータへのアクセス権限は拒否されるため、null 値も返されます。policy01
権限がプロジェクトに設定されていない場合、すべてのユーザー (user_x を除く) はstorage_table
内のストレージデータへのアクセスが拒否され、null 戻り値が返されます。 user_x のみが IA データと長期ストレージデータへのアクセス権限が付与されますが、標準ストレージデータへのアクセスは拒否されるため、null 値も返されます。
例 3:
policy03
権限をユーザーuser_y
に付与して、storage_table
内のすべてのデータにアクセスできるようにします。CREATE ROW ACCESS POLICY policy03 ON storage_table TO USER (user_y) -- TO role rolename 句を使用してロールに権限を付与し、そのロールをユーザーに付与することもできます。 FILTER USING (true); -- 定数 true は、テーブル内のすべてのデータにアクセスできることを示します。
2 つの考えられるシナリオ:
policy01
権限がテーブルに設定されている場合、すべてのユーザー (user_y を除く) はstorage_table
内の標準ストレージデータへのアクセス権が付与されます。 ただし、IA データまたは長期ストレージデータを取得するアクセス権限がないため、null 戻り値が返されます。 ユーザーuser_y
は、storage_table
内のすべてのストレージクラスにアクセスできます。policy01
権限がテーブルに設定されていない場合、すべてのユーザー (user_y を除く) はstorage_table
内のストレージデータへのアクセスが拒否され、null 戻り値が返されます。user_y
のみがstorage_table
内のすべてのストレージクラスデータへのアクセス権限が付与されます。