Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# SUPER データ型とマテリアライズドビュー
Amazon Redshift では、マテリアライズドビューを使用して、SUPER データ型に対して実行されるクエリのパフォーマンスと柔軟性を強化できます。SUPER データ型を使用すると、ベーステーブルからの列のスーパーセットをマテリアライズドビューに保存し、ベーステーブルを結合せずにマテリアライズドビューを直接クエリできます。以下のセクションでは、Amazon Redshift で SUPER データ型を使ってマテリアライズドビューを作成し、使用する方法を説明します。
Amazon Redshift は、SUPER データ型列を組み込んだマテリアライズドビューと PartiQL をサポートしています。マテリアライズドビューは段階的に更新できますが、Amazon Redshift は前回の更新オペレーション以降にベーステーブルで変更されたデータのみを更新します。この選択的更新アプローチにより、完全な再計算よりも更新プロセスがより効率的になります。マテリアライズドビューの詳細については、「[Amazon Redshift でのマテリアライズドビュー](materialized-view-overview.md)」を参照してください。
## PartiQL クエリの高速化
マテリアライズドビューを使用して、SUPER 列内の階層データをナビゲートするか、またはネストを解除する PartiQL クエリを高速化できます。1 つ以上のマテリアライズドビューを作成して、SUPER 値を複数の列にシュレッダー処理し、Amazon Redshift 分析クエリの列構造を利用することで、ネストされたデータを本質的に抽出して正規化できます。正規化のレベルは、SUPER データを従来の列指向データに変換するためにどれだけの労力を費やしたかによって異なります。
以下のトピックでは、複雑なデータを小さな列に分割またはシュレッダー処理する例と、パフォーマンスを向上させるためにシュレッダー処理されたデータからスカラー列を作成する例を示します。
**Topics**
+ [PartiQL クエリの高速化](#r_accelerate_mv)
+ [マテリアライズドビューを使用して、半構造化データを SUPER 列にシュレッダー処理する](r_shred_super.md)
+ [細断されたデータからの Amazon Redshift スカラー列の作成](r_create_scalar.md)
# マテリアライズドビューを使用して、半構造化データを SUPER 列にシュレッダー処理する
Amazon Redshift では、マテリアライズドビューを使用してデータを SUPER 列にシュレッダー処理することで、クエリのパフォーマンスを向上させることができます。シュレッダー処理とは、半構造化 JSON や XML などの複雑なデータ型を、より小さくフラットな列に分割するプロセスを指します。SUPER 列は、シュレッダー処理されたデータを高速スキャンできるよう最適化された特殊な形式の列型ストレージです。
以下のセクションでは、Amazon Redshift でマテリアライズドビューを使用してデータを SUPER 列にシュレッダー処理する手順と考慮事項について説明します。
次の例は、ネストされたデータをシュレッディングするマテリアライズドビュー定義を示しています。結果の列は引き続き SUPER データ型です。
```
SELECT c.c_name, o.o_orderstatus
FROM customer_orders_lineitem c, c.c_orders o;
```
以下の例は、シュレッドされたデータから従来の Amazon Redshift スカラー列を作成するマテリアライズドビュー定義を示しています。
```
SELECT c.c_name, c.c_orders[0].o_totalprice
FROM customer_orders_lineitem c;
```
単一のマテリアライズドビュー super\$1mv を作成して、両方のクエリを高速化できます。
最初のクエリに応答するには、属性 o\$1orderstatus を実体化する必要があります。ネストされたナビゲーションやネスト解除を伴わないため、属性 c\$1name を省略できます。また、ベーステーブルをマテリアライズドビューと結合できるようにするには、customer\$1orders\$1lineitem の属性 c\$1custkey をマテリアライズドビューに含める必要があります。
2 番目のクエリに答えるには、c\$1orders の属性 o\$1totalprice と配列インデックス o\$1idx も実体化する必要があります。したがって、c\$1orders のインデックス 0 にアクセスすることができます。
```
CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey) AS (
SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx
FROM customer_orders_lineitem c, c.c_orders o AT o_idx
);
```
マテリアライズドビュー super\$1mv の属性 o\$1orderstatus および o\$1totalprice は SUPER です。
マテリアライズドビュー super\$1mv は、ベーステーブル customer\$1orders\$1lineitem が変更されると、増分的に更新されます。
```
REFRESH MATERIALIZED VIEW super_mv;
INFO: Materialized view super_mv was incrementally updated successfully.
```
最初の PartiQL クエリを通常の SQL クエリとして書き換えるには、次のように customer\$1orders\$1lineitem と super\$1mv を結合します。
```
SELECT c.c_name, v.o_orderstatus
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey;
```
同様に、2 番目の PartiQL クエリを書き換えることができます。次の例では、o\$1idx = 0 のフィルターを使用します。
```
SELECT c.c_name, v.o_totalprice
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey
WHERE v.o_idx = 0;
```
CREATE MATERIALIZED VIEW コマンドで、ディストリビューションキーとして c\$1custkey を指定し、super\$1mv のソートキーを指定します。Amazon Redshift は、c\$1custkey が customer\$1orders\$1lineitem のディストリビューションキーおよびソートキーでもあると仮定して、効率的なマージ結合を実行します。そうでない場合は、c\$1custkey を customer\$1orders\$1lineitem のソートキーおよびディストリビューションキーとして次のように指定できます。
```
ALTER TABLE customer_orders_lineitem
ALTER DISTKEY c_custkey, ALTER SORTKEY (c_custkey);
```
EXPLAIN ステートメントを使用して、書き換えられたクエリに対して Amazon Redshift がマージ結合を実行することを確認します。
```
EXPLAIN
SELECT c.c_name, v.o_orderstatus
FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey;
QUERY PLAN
------------------------------------------------------------------------------------------------------
XN Merge Join DS_DIST_NONE (cost=0.00..34701.82 rows=1470776 width=27)
Merge Cond: ("outer".c_custkey = "inner".c_custkey)
-> XN Seq Scan on mv_tbl__super_mv__0 derived_table2 (cost=0.00..14999.86 rows=1499986 width=13)
-> XN Seq Scan on customer_orders_lineitem c (cost=0.00..999.96 rows=99996 width=30)
(4 rows)
```
# 細断されたデータからの Amazon Redshift スカラー列の作成
SUPER に保存されているスキーマレスデータは、Amazon Redshift のパフォーマンスに影響を与える可能性があります。例えば、範囲が制限されたスキャンではゾーンマップを効果的に使用できないため、述語や結合条件をフィルタリングします。ユーザーと BI ツールは、データの従来の表示としてマテリアライズドビューを使用し、分析クエリのパフォーマンスを向上させることができます。
次のクエリは、マテリアライズドビュー `super_mv` をスキャンし、`o_orderstatus` でフィルタリングします。
```
SELECT c.c_name, v.o_totalprice
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey
WHERE v.o_orderstatus = 'F';
```
`stl_scan` を調べて、Amazon Redshift が `o_orderstatus` の範囲制限スキャンでゾーンマップを効果的に使用できないことを確認します。
```
SELECT slice, is_rrscan FROM stl_scan
WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%';
slice | is_rrscan
-------+-----------
0 | f
1 | f
5 | f
4 | f
2 | f
3 | f
(6 rows)
```
次の例では、マテリアライズドビュー `super_mv` を使用して、細断されたデータからスカラー列を作成します。この場合、Amazon Redshift は `o_orderstatus` を SUPER から VARCHAR にキャストします。さらに、`super_mv` のソートキーとして `o_orderstatus` を指定します。
```
CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey, o_orderstatus) AS (
SELECT c_custkey, o.o_orderstatus::VARCHAR AS o_orderstatus, o.o_totalprice, o_idx
FROM customer_orders_lineitem c, c.c_orders o AT o_idx
);
```
クエリを再実行した後、Amazon Redshift がゾーンマップを使用できることを確認します。
```
SELECT v.o_totalprice
FROM super_mv v
WHERE v.o_orderstatus = 'F';
```
次のように、範囲が制限されたスキャンでゾーンマップが使用されるようになったことを確認できます。
```
SELECT slice, is_rrscan FROM stl_scan
WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%';
slice | is_rrscan
-------+-----------
0 | t
1 | t
2 | t
3 | t
4 | t
5 | t
(6 rows)
```