Yelp は、人々を地元の優れたビジネスと結びつけます。Yelp は 2004 年に立ち上げて以来、本拠地を置くサンフランシスコ 1 都市でサービスを提供するに過ぎなかったのが、30 か国以上の主要都市にまたがる多国籍企業へと成長しました。同社のパフォーマンスベースの広告およびトランザクションビジネスモデルにより、2015 年の収益は 5 億ドルを超え、前年比 46% 増加しました。Yelp はモバイル中心の企業へと進化し、検索の 70% 以上、コンテンツの 58% 以上がモバイルデバイスを基にしています。
Yelp は Amazon Redshift を使用して、モバイルアプリの使用状況データと、顧客コホート、オークション、および広告指標に関する広告データを分析しています。Yelp はすぐに新しい Amazon Redshift のスキーマストレージクォータ機能の恩恵を受けました。
「Amazon Redshift は、Yelp がデータベース管理に時間を費やすことなくデータ分析に集中することを可能にするマネージドデータウェアハウスサービスです」と、Yelp の Metrics Platform のリードエンジニアである Steven Moy 氏は言います。Metrics Platform により、Yelp のエンジニアリングチームは長期の永続的なデータストレージと SQL-on-anything クエリ機能を享受できます。「当社のデータウェアハウスユーザーがすばやく繰り返すための重要な戦略は、「tmp」と呼ばれる書き込み可能なスキーマを用意することです。これにより、ユーザーはさまざまなテーブルスキーマのプロトタイプを作成できます。ただし、クエリの実行中に十分な空き容量がないと、データウェアハウスのクエリ操作全体のパフォーマンスが低下するという課題に直面することがあります。新しいスキーマクォータ機能を使用すると、「tmp」スキーマにストレージクォータ上限をプロビジョニングして、ストレージの容量不足を未然に防ぐことができます。Amazon Redshift が提供するすべての自律型の機能を心待ちにしています」。
多くの組織がセルフサービス分析に移行しており、さまざまなペルソナが進化するデータの量、多様性、速度について独自の洞察を得て、加速するビジネスに対応しています。このデータの民主化により、データガバナンスを実施し、コストを管理し、データの誤管理を防ぐ必要が生じます。さまざまなペルソナのストレージクォータを制御することは、データガバナンスとデータストレージ運用にとって大きな課題です。この記事では、異なるペルソナごとに Amazon Redshift ストレージクォータを設定する方法を示します。
前提条件
このチュートリアルを開始する前に、次のものが必要です。
スキーマクォータの設定とテスト
環境をセットアップしてユースケースを実装するには、以下の手順を実行します。
- スーパーユーザーまたは CREATE SCHEMA 権限を持つユーザーとして選好する SQL クライアントを使用して、Amazon Redshift クラスターに接続します。
- 次のコードを使用してユーザー
sales
を作成します。
CREATE USER sales WITH password 'Abcd1234!';
上記のコードのユーザーは、このチュートリアルの目的のためにのみ用意されたものです。企業ユーザーを手動で作成することなく使用するには、AWS Identity and Access Management (IAM) の ID フェデレーションを使用する必要があります。詳細については、「認証」を参照してください。
- CREATE SCHEMA を使用してスキーマクォータを設定します。次のコードを参照してください。
CREATE SCHEMA [ IF NOT EXISTS ] schema_name [ AUTHORIZATION username ]
[ QUOTA {quota [MB | GB | TB] | UNLIMITED} ] [ schema_element [ ... ]
CREATE SCHEMA AUTHORIZATION username[ QUOTA {quota [MB | GB | TB] | UNLIMITED} ] [ schema_element [ ... ] ]
QUOTA
パラメータは、指定されたスキーマが使用できる最大ディスク容量を定義します。
- ユーザー
sales
に対して 2 GB のクォータを持つスキーマ sales_schema
を作成します。次のコードを参照してください。
CREATE SCHEMA sales_schema AUTHORIZATION sales QUOTA 2 GB;
- 次のコードを使用して、ユーザー
sales
を偽装します。
SET SESSION AUTHORIZATION 'sales';
SELECT CURRENT_USER;
- 次のコードを使用して、テーブル
region
および lineitem
を作成します。
CREATE TABLE sales_schema.region (
r_regionkey int4,
r_name char(25),
r_comment varchar(152)
) DISTSTYLE EVEN;
CREATE TABLE sales_schema.lineitem (
l_orderkey int8,
l_partkey int8,
l_suppkey int4,
l_linenumber int4,
l_quantity numeric(12,2),
l_extendedprice numeric(12,2),
l_discount numeric(12,2),
l_tax numeric(12,2),
l_returnflag char(1),
l_linestatus char(1),
l_shipdate date,
l_commitdate date,
l_receiptdate date,
l_shipinstruct char(25),
l_shipmode char(10),
l_comment varchar(44)
) DISTSTYLE EVEN;
単一ステートメントトランザクション
単一ステートメントトランザクションのユースケースをテストするには、次の手順を実行します。
- 次のコードを使用して、データをテーブル
region
にロードします。
COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
<Your-IAM-Role>
は、Amazon Redshift クラスターに関連付けられた必要なアクセス許可を持つ IAM ロールの ARN です。
COPY
コマンドは、5 行が読み込まれた状態で完了するはずです。次のコードを参照してください。
dev=> COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'region' completed, 5 record(s) loaded successfully.
COPY
- システムビュー svv_schema_quota_state からスキーマのクォータとディスク使用量を確認してください。次のコードを参照してください。
SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
このステートメントは、4 ノードの DC2.large クラスターでの 2,048 MB のクォータと 30 MB のディスク使用量を示しています。ディスク使用量は、インスタンスタイプとノード数によって異なります。次のコードを参照してください。
dev=> SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
schema_name | quota | disk_usage | disk_usage_pct
--------------+-------+------------+----------------
sales_schema | 2048 | 30 | 1.46
(1 row)
- 次のコードを使用して、テーブル
lineitem
にデータをロードします。
COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
ディスク領域のクォータを超えたためにトランザクションが中止されたというエラーが表示されます。次のコードを参照してください。
dev=> COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'lineitem' completed, 59986052 record(s) loaded successfully.
ERROR: Transaction 40895 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 2048, Current Disk Usage: 2798).
Free up disk space or request increased quota for the schema(s).
Amazon Redshift は、トランザクションをコミットする前に、クォータ違反がないか各トランザクションをチェックします。トランザクションの最後にクォータ違反チェックが行われるため、コミットされる前に、サイズ制限がトランザクション内で一時的にクォータを超える可能性があります。最初にテーブル lineitem
へのメッセージの読み込みが正常に完了したことが表示されるのは、このためです。トランザクションがクォータを超過すると、Amazon Redshift はトランザクションを中止し、以降の取り込みを禁止し、ディスク領域が解放されるまで変更を一切受け付けなくなります。
クォータ違反の発生は、システムテーブル stl_schema_quota_violations に格納されます。
- 違反の有無を確認するには、次のコードを実行します。
SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
クォータ、ディスク使用量、設定されたクォータからのディスク使用率、および違反が発生したときのタイムスタンプが表示されます。次のコードを参照してください。
dev=> SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
userid | schema_name | quota | disk_usage | disk_usage_pct | timestamp
--------+--------------+-------+------------+----------------+----------------------------
104 | sales_schema | 2048 | 2798 | 136.62 | 2020-04-20 20:09:25.494723
(1 row)
- ALTER SCHEMA を使用してスキーマクォータを 4 GB に変更します。次のコードを参照してください。
RESET SESSION AUTHORIZATION;
ALTER SCHEMA sales_schema QUOTA 4 GB;
SET SESSION AUTHORIZATION 'sales';
SELECT CURRENT_USER;
スキーマの作成中にスキーマクォータを設定するには、データベースのスーパーユーザーまたは CREATE SCHEMA
権限を持つユーザーである必要があります。ただし、スキーマクォータを変更できるのはスーパーユーザーだけです。ユーザーの偽装を元のスーパーユーザーにリセットするには、RESET SESSION AUTHORIZATION
を使用します。
- スキーマのクォータとディスク使用量を確認するには、次のコードを使用します。
SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
このステートメントは、4 ノードの DC2.large クラスターでの 4,096 MB のクォータと 30 MB のディスク使用量を返します。先に失敗した COPY
ステートメントは、初期のテーブルのトランザクションが中止されると、自動的にディスク領域を解放します。次のコードを参照してください。
dev=> SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
schema_name | quota | disk_usage | disk_usage_pct
--------------+-------+------------+----------------
sales_schema | 4096 | 30 | 0.73
(1 row)
- 次のコードを使用して、
COPY
コマンドを再実行し、データをテーブル lineitem
にロードします。
COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
次のメッセージが返されます。
Load into table 'lineitem' completed, 59986052 record(s) loaded successfully
- スキーマのクォータとディスク使用量を確認するには、次のコードを使用します。
SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
このステートメントは、4 ノードの DC2.large クラスターでの 4,096 MB のクォータと 2798 MB のディスク使用量を返します。ディスク使用量は、インスタンスタイプとノード数によって異なります。次のコードを参照してください。
dev=> SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
schema_name | quota | disk_usage | disk_usage_pct
--------------+-------+------------+----------------
sales_schema | 4096 | 2798 | 68.31
(1 row)
-
COPY
コマンドを再実行して、大量のデータをテーブル lineitem
に読み込み、クォータを超過します。次のコードを参照してください。
COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
ディスク領域のクォータを超えたためにトランザクションが中止されたというエラーが返されます。次のコードを参照してください。
dev=# COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'lineitem' completed, 59986052 record(s) loaded successfully.
ERROR: Transaction 86438 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 5486).
Free up disk space or request increased quota for the schema(s).
- 次のコードを実行して、クォータ違反後に後続の小さな COPY/INSERT/UPDATE を実行します。
COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 100;
すべてのステートメントは、ディスク領域のクォータを超過しためにエラートランザクションが中止されたことを返します。次のコードを参照してください。
dev=# COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'region' completed, 5 record(s) loaded successfully.
ERROR: Transaction 86478 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 5486).
Free up disk space or request increased quota for the schema(s).
dev=# INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
ERROR: Transaction 86479 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 5486).
Free up disk space or request increased quota for the schema(s).
dev=# UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 100;
ERROR: Transaction 86483 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 5486).
Free up disk space or request increased quota for the schema(s).
初期テーブル以外のテーブルの場合、クォータを超過した問題のあるトランザクションは中止されましたが (たとえば、COPY
から lineitem
)、トランザクションは依然としてスペースを消費し、スキーマはディスク領域が解放されるまでブロックされます。そのため、region
テーブルへの後続の COPY/INSERT/UPDATE
も中止されます。
- システムテーブルのクォータ違反を再確認するには、次のコードを使用します。
SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
5,486 MB のディスク使用量と 4 ノードの DC2.large クラスターが返されます。次のコードを参照してください。
dev=> SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
userid | schema_name | quota | disk_usage | disk_usage_pct | timestamp
--------+--------------+-------+------------+----------------+----------------------------
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.653489
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.469287
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.197434
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 20:28:01.344333
104 | sales_schema | 2048 | 2798 | 136.62 | 2020-04-20 20:09:25.494723
(5 rows)
単一ステートメントの縮小のみのトランザクション
縮小のみのトランザクションは、DELETE、TRUNCATE、DROP TABLE、VACUUM など、使用するディスク容量を直接的または間接的に削減する可能性のあるステートメントのみで設定されるトランザクションです。
単一ステートメントの縮小のみのトランザクションのユースケースをテストするには、次の手順を実行します。
- 次のコードを使用して、lineitem テーブルからすべてのデータを削除します。
DELETE sales_schema.lineitem;
SELECT COUNT(*) FROM sales_schema.lineitem;
次のように、ゼロのレコードカウントを返すはずです。
dev=> DELETE sales_schema.lineitem;
DELETE 59986052
dev=> SELECT COUNT(*) FROM sales_schema.lineitem;
count
-------
0
(1 row)
スキーマクォータを超えましたが、縮小のみのトランザクションはクォータ違反チェックの例外であるため、DELETE
トランザクションがコミットされます。
TRUNCATE コマンドは、すべてのデータを削除する上で DELETE よりもはるかに効率的で、VACUUM および ANALYZE コマンドを必要としません。上記のコードは、説明目的に限られます。
- 次のコードを使用して、
COPY
コマンドを再実行し、データをテーブル lineitem
にロードします。
COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
次のエラーメッセージが返されます。
Transaction is aborted due to exceeding the disk space quota
次のコードを参照してください。
dev=> COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'lineitem' completed, 59986052 record(s) loaded successfully.
ERROR: Transaction 87024 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 8150).
Free up disk space or request increased quota for the schema(s).
DELETE
は自動的にディスク領域を解放しないため、前の COPY
コマンドはクォータを超え、トランザクションは中止されます。
- 次のコードを使用して、システムテーブルのクォータ違反を再確認します。
SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
最新の行は、8,150 MB のディスク使用量と 4 ノードの DC2.large クラスターを返します。これは、トランザクションが中止されるとディスク使用量が増加することを示しています。次のコードを参照してください。
dev=> SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
userid | schema_name | quota | disk_usage | disk_usage_pct | timestamp
--------+--------------+-------+------------+----------------+----------------------------
104 | sales_schema | 4096 | 8150 | 198.97 | 2020-04-20 21:30:54.354669
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.653489
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.469287
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 21:27:29.197434
104 | sales_schema | 4096 | 5486 | 133.94 | 2020-04-20 20:28:01.344333
104 | sales_schema | 2048 | 2798 | 136.62 | 2020-04-20 20:09:25.494723
(6 rows)
- 次のように
VACUUM
を実行して、ディスク領域を解放します。
VACUUM sales_schema.lineitem;
スキーマクォータを超えていますが、Amazon Redshift はクォータ違反を無視し、VACUUM
のような特定のケースでトランザクションをコミットするため、これはエラーなしで完了します。
これで Amazon Redshift はバックグラウンドで VACUUM DELETE 操作を自動的に実行して、ディスク領域を解放します。
- 次のコードを使用して、
COPY
コマンドを再実行し、データをテーブル lineitem
にロードします。
COPY sales_schema.lineitem FROM 's3://redshift-downloads/TPC-H/10GB/lineitem/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
次のメッセージが返されます。
Load into table 'lineitem' completed, 59986052 record(s) loaded successfully
VACUUM
がディスク領域を解放したため、COPY
コマンドは正常に実行されました。
CREATE TABLE AS (CTAS)、ALTER TABLE APPEND ステートメント、および一時スキーマのトランザクション
一時スキーマのユースケースで CREATE TABLE AS (CTAS)、ALTER TABLE APPEND ステートメント、およびトランザクションをテストするには、次の手順を実行します。
- CTAS ステートメントを実行して、クエリを使用して別のテーブルを作成します。次のコードを参照してください。
CREATE TABLE sales_schema.lineitem_ctas AS SELECT * FROM sales_schema.lineitem;
ディスク領域のクォータを超えたためにトランザクションが中止されたことを返します。CTAS は、同じスキーマで同様のクォータチェックの対象となります。次のコードを参照してください。
dev=> CREATE TABLE sales_schema.lineitem_ctas AS SELECT * FROM sales_schema.lineitem;
ERROR: Transaction 112229 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 4096, Current Disk Usage: 5624).
Free up disk space or request increased quota for the schema(s).
- 一時テーブルを作成し、データに次のコードを入力します。
CREATE TEMP TABLE lineitem_temp AS SELECT * FROM sales_schema.lineitem;
SELECT COUNT(*) from lineitem_temp;
59,986,052 行を返します。スキーマクォータは、一時的な名前空間またはスキーマの一部として作成された一時テーブルを考慮しません。
- 同じテーブル
lineitem
を public
スキーマに作成し、次のコードを使用してデータをロードします。
CREATE TABLE public.lineitem_ctas AS SELECT * FROM sales_schema.lineitem;
SELECT COUNT(*) FROM lineitem_ctas;
59,986,052 行を返します。
異なるスキーマへの取り込みは効果がなく、トランザクションがコミットされます。
- ALTER TABLE APPEND を使用して、別のテーブルから
sales_schema
のテーブル lineitem
にデータを追加します。次のコードを参照してください:
ALTER TABLE sales_schema.lineitem APPEND FROM lineitem_ctas;
ディスク領域のクォータを超えたためにトランザクションが中止されたというエラーが返されます。クォータ違反は完全なスキーマに適用されます。
- 次のコードを使用して、
sales_schema lineitem
テーブルのデータを public
スキーマの別のテーブルに追加します。
ALTER TABLE lineitem_ctas APPEND FROM sales_schema.lineitem;
SELECT COUNT(*) FROM sales_schema.lineitem;
SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
SELECT COUNT
ステートメントとディスク使用量の低下からゼロのレコードカウントが返されます。ALTER TABLE APPEND
ステートメントはテーブルをすぐに空にし、トランザクションが完了するとディスク領域を解放します。次のコードを参照してください。
dev=> ALTER TABLE lineitem_ctas APPEND FROM sales_schema.lineitem;
INFO: ALTER TABLE APPEND "lineitem_ctas" from "lineitem" is complete.
ALTER TABLE APPEND and COMMIT TRANSACTION
dev=> SELECT COUNT(*) FROM sales_schema.lineitem;
count
-------
0
(1 row)
dev=> SELECT TRIM(SCHEMA_NAME) "schema_name", QUOTA, disk_usage, disk_usage_pct FROM svv_schema_quota_state WHERE SCHEMA_NAME = 'sales_schema';
schema_name | quota | disk_usage | disk_usage_pct
--------------+-------+------------+----------------
sales_schema | 4096 | 30 | 0.73
(1 row)
同時トランザクション
同時トランザクションのユースケースをテストするには、次の手順を実行します。
- 次のコードを使用して、クォータを 6 GB に増やします。
RESET SESSION AUTHORIZATION;
ALTER SCHEMA sales_schema QUOTA 6 GB;
SET SESSION AUTHORIZATION 'sales';
次のテストでは、Amazon Redshift クラスターに接続された 2 つの個別の SQL クライアントセッションが必要であり、コードを同時に実行します。
- 最初のセッションで、次のコードを入力します。
CREATE TABLE sales_schema.lineitem_txn1 AS SELECT * FROM lineitem_ctas;
- 最初のセッションがまだ実行されている間に、2 番目のセッションで次のコードを入力します。
CREATE TABLE sales_schema.lineitem_txn2 AS SELECT * FROM lineitem_ctas;
最初のセッションのステートメントは、次の警告メッセージを返すはずです。
Schema(s) close to reaching their allocated disk space quotas
これは、スキーマがクォータに近づいているが、ステートメントはまだ完了していないという警告メッセージです。次のコードを参照してください。
dev=> CREATE TABLE sales_schema.lineitem_txn1 AS SELECT * FROM lineitem_ctas;
WARNING: Schema(s) close to reaching their allocated disk space quotas: (Schema: sales_schema, Quota: 6144, Current Disk Usage: 5606).
Free up disk space or request increased quota for the schema(s).
SELECT
2 番目のセッションのステートメントは、ディスク領域のクォータを超過したためにトランザクションが中止されたというエラーを返すはずです。最初のセッションの最初のトランザクションが最初にコミットされたため、ディスク領域の使用量がクォータに近くなったのです。2 番目のトランザクションは、トランザクションをコミットする前にクォータ違反をチェックし、トランザクションを中止します。
既存のディスク領域の使用量を下回るようにクォータをリセットする
既存のディスク領域の使用量を下回るようにクォータをリセットするユースケースをテストするには、次の手順を実行します。
- 次のコードを実行して、クォータを 2 GB にリセットします。
RESET SESSION AUTHORIZATION;
ALTER SCHEMA sales_schema QUOTA 2 GB;
SET SESSION AUTHORIZATION 'sales';
CREATE TABLE sales_schema.test AS SELECT 1;
クォータは、既存のディスク領域の使用量より低く設定できます。ただし、ディスク領域を解放するまで、以降の取り込みトランザクションはすべて中止されます。 次のコードを参照してください。
dev=> RESET SESSION AUTHORIZATION;
RESET
dev=# ALTER SCHEMA sales_schema QUOTA 2 GB;
ALTER SCHEMA
dev=# SET SESSION AUTHORIZATION 'sales';
SET
dev=> CREATE TABLE sales_schema.test AS SELECT 1;
ERROR: Transaction 112557 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 2048, Current Disk Usage: 5610).
Free up disk space or request increased quota for the schema(s).
複数ステートメントのトランザクション
複数ステートメントトランザクションのユースケースをテストするには、次の手順を実行します。
- 次のコードを入力して、複数ステートメントのトランザクションをテストします。
BEGIN;
DELETE FROM sales_schema.region WHERE r_regionkey = 0;
INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
COMMIT;
BEGIN;
DELETE FROM sales_schema.region WHERE r_regionkey = 0;
UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 1;
COMMIT;
BEGIN;
DELETE FROM sales_schema.region WHERE r_regionkey = 0;
COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
COMMIT;
クォータを超過しているため、すべての INSERT/UPDATE/COPY
トランザクションを中止する必要があります。次のコードを参照してください。
dev=> BEGIN;
BEGIN
dev=> DELETE FROM sales_schema.region WHERE r_regionkey = 0;
DELETE 0
dev=> INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
INSERT 0 1
dev=> COMMIT;
ERROR: Transaction 114291 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 2048, Current Disk Usage: 5606).
Free up disk space or request increased quota for the schema(s).
dev=> BEGIN;
BEGIN
dev=> DELETE FROM sales_schema.region WHERE r_regionkey = 0;
DELETE 0
dev=> UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 1;
UPDATE 1
dev=> COMMIT;
ERROR: Transaction 114295 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 2048, Current Disk Usage: 5606).
Free up disk space or request increased quota for the schema(s).
dev=> BEGIN;
BEGIN
dev=> DELETE FROM sales_schema.region WHERE r_regionkey = 0;
DELETE 0
dev=> COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'region' completed, 5 record(s) loaded successfully.
COPY
dev=> COMMIT;
ERROR: Transaction 114303 is aborted due to exceeding the disk space quota in schema(s): (Schema: sales_schema, Quota: 2048, Current Disk Usage: 5624).
Free up disk space or request increased quota for the schema(s).
- 次のコードを入力して、同じトランザクションで DROP TABLE を使用して複数ステートメントのトランザクションをテストします。
BEGIN;
INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 100;
COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
DROP TABLE sales_schema.region;
COMMIT;
トランザクションは正常にコミットされるはずです。COPY/INSERT/DELETE
トランザクションをテーブルに挿入し、トランザクションがコミットされると同時に削除されます。次のコードを参照してください。
dev=> BEGIN;
BEGIN
dev=> INSERT INTO sales_schema.region VALUES(100, 'Test','This is a test');
INSERT 0 1
dev=> UPDATE sales_schema.region SET r_name = 'Fail' WHERE r_regionkey = 100;
UPDATE 3
dev=> COPY sales_schema.region FROM 's3://redshift-downloads/TPC-H/10GB/region/' iam_role '<Your-IAM-Role>' gzip delimiter '|' region 'us-east-1';
INFO: Load into table 'region' completed, 5 record(s) loaded successfully.
COPY
dev=> DROP TABLE sales_schema.region;
DROP TABLE
dev=> COMMIT;
COMMIT
- 次のコードを使用して、複数ステートメントのトランザクションで縮小のみのステートメントを実行します。
BEGIN;
DELETE FROM sales_schema.lineitem WHERE l_orderkey = 53924162;
DROP TABLE sales_schema.lineitem;
COMMIT;
トランザクションは正常にコミットされるはずです。縮小のみのステートメントを含むトランザクションは成功するはずです。次のコードを参照してください。
dev=> BEGIN;
BEGIN
dev=> DELETE FROM sales_schema.lineitem WHERE l_orderkey = 53924162;
DELETE 0
dev=> DROP TABLE sales_schema.lineitem;
DROP TABLE
dev=> COMMIT;
COMMIT
ベストプラクティス
次の推奨プラクティスは、ストレージクォータを使用してワークロードを最適化するのに役立ちます。
- スキーマ機能は、ユーザーがスキーマと整合している場合に最もよく機能 – スキーマを使用してユーザーを論理的に分離しましょう。たとえば、データエンジニアが所有するベーステーブルと集計テーブルには MAIN スキーマを使用します。データアナリストが所有するストレージクォータで制御される
ANALYST
スキーマは、MAIN
スキーマから ANALYST
に基本データをクエリすることにより、独自の集計を実行します。データアナリストは、MAIN
スキーマについては読み取り権限のみがありますが、ANALYST
スキーマについては読み取りおよび書き込み権限があります。
- パブリックスキーマの使用を取り消す – すべてのユーザーは、デフォルトでデータベースの
PUBLIC
スキーマに対する CREATE
および USAGE
権限を持っています。ストレージクォータはデフォルトで PUBLIC
スキーマに適用できないため、すべてのユーザーがデータベースの PUBLIC
スキーマにオブジェクトを作成することを禁止する必要があります。そのようにオブジェクトを作成するのではなく、以前のベストプラクティスに従って、独自の整合スキーマを使用する必要があります。REVOKE コマンドを使用して、その権限を取り消します。
- 一時テーブルの代わりに物理テーブルを使用する – 一時テーブルはストレージクォータの対象ではないため、代わりに物理テーブルを使用します。ただし、トランザクションの最後に物理テーブルを削除することを忘れないでください。他に、ストレージクォータを持つ一時的な物理テーブルに対応する別のスキーマを作成する方法もあります。その方法では、一時テーブルを使用する代わりに、専用スキーマに物理テーブルを作成します。これにより、管理が容易になり、自動化を実行して、この専用スキーマのテーブルを定期的にクリーンアップできます。
- データの縮小操作を使用する –
DELETE
、VACUUM DELETE
、DROP
、および TRUNCATE
などのデータ縮小操作を使用して、特にクォータに近づいている場合は、ディスク領域を解放できます。
- ワークロード管理 (WLM) をクエリの優先度とともに使用して、さまざまなユーザーのリソースを制御する –さまざまなユーザーが実行するデータの取り込みと集計は、リソースを集中的に使用し、クラスターで実行されている他のミッションクリティカルな負荷またはクエリのスループットに影響を与える可能性があります。Amazon Redshift Advisor は、現在の WLM の使用量を自動的に分析し、クラスターからより多くのスループットを得るための推奨を行うことができます。Advisor からの提案を定期的に確認すると、最高のパフォーマンスを得ることができます。
モニタリング
ストレージクォータ違反がないか定期的にモニタリングして、修正措置を講じ、ビジネスの継続性を実現する必要があります。システムテーブル stl_schema_quota_violations は、クォータ違反イベントを取得するのに適したリソースです。違反情報をクエリするには、次のコードを入力します。
SELECT userid, TRIM(SCHEMA_NAME) "schema_name", quota, disk_usage, disk_usage_pct, timestamp FROM stl_schema_quota_violations WHERE SCHEMA_NAME = 'sales_schema' ORDER BY timestamp DESC;
違反が発生した場合には、次の解決策を使用して、前述のクエリの実行を自動化し、ユーザーに通知を送信できます。
クリーンアップ
テストが終了したら、次のコードでオブジェクトとユーザーを削除できます。
RESET SESSION AUTHORIZATION;
DROP TABLE IF EXISTS sales_schema.lineitem_txn1;
DROP TABLE IF EXISTS lineitem_temp;
DROP TABLE IF EXISTS lineitem_ctas;
DROP SCHEMA sales_schema;
DROP USER IF EXISTS sales;
まとめ
Amazon Redshift は、追加のコストなしで厳しいコンプライアンスおよびセキュリティ要件をサポートするため、規制の厳しい業界に最適です。クォータを使用したデータストレージ操作は、コンプライアンスと操作の効率性を実現する重要なデータガバナンスフレームワークの一部です。CREATE/ALTER SCHEMA
ステートメントの単純な QUOTA
パラメータは、Amazon Redshift スキーマでディスク使用量のクォータを有効にします。組織内のペルソナを表す Amazon Redshift データベースユーザーを、クォータを持つさまざまなスキーマに割り当てて、消費できるディスク容量を制御できます。これは、データガバナンスとコスト管理にとって非常に重要です。また、特にオブジェクトの作成とデータの取り込みを継続することで、他のミッションクリティカルな分析操作が停止する可能性がある場合は、ディスクフルエラーなどの操作上の問題が発生することを回避できます。
この記事では、スキーマを使用して Amazon Redshift のストレージクォータを簡単に制御できることを示しました。スキーマのクォータを作成および変更し、特定のユーザーがスキーマを操作するのを承認する手順を説明しました。また、スキーマにデータを取り込み、システムビューを使用してさまざまな結果とディスク使用量をモニタリングするさまざまなユースケースについても詳しく見てきました。こうした機能を活用することで、ビジネスニーズをサポートできます。
著者について
BP Yau は AWS のデータウェアハウススペシャリストソリューションアーキテクトです。彼は、お客様がビッグデータソリューションを構築して大規模なデータを処理するのを支援する役割を担っています。AWS に加わる前は、Amazon.com の Supply Chain Optimization Technologies が Oracle Data Warehouse を Amazon Redshift に移行するのを支援し、AWS テクノロジーを使用して次世代のビッグデータ分析プラットフォームを構築しました。
Ahmad Barghout は、Amazon Redshift ストレージチームのソフトウェア開発エンジニアです。彼はクラスターのサイズ変更の最適化に取り組み、現在はスキーマクォータなどの使いやすい機能に取り組んでいます。それ以前は、Cisco のフルスタック開発者でした。オタワ大学で修士号を取得しています。
Himanshu Raja は、Amazon Redshift の主席プロダクトマネージャーです。Himanshu は、データによる困難な問題を解決するのが大好きで、データが直感に反している瞬間を大事にしています。余暇には、インド料理を食べたり、アクション映画を見たりして楽しんでいます。