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/)を参照してください。 # 圧縮エンコード *圧縮エンコード*は、行がテーブルに追加されるときにデータ値の列に適用される圧縮のタイプを指定します。 ENCODE AUTO は、テーブルのデフォルトです。テーブルが ENCODE AUTO に設定されると、Amazon Redshift は、テーブル内のすべての列の圧縮エンコードを自動的に管理します。詳細については、「[CREATE TABLE](r_CREATE_TABLE_NEW.md)」および「[ALTER TABLE](r_ALTER_TABLE.md)」を参照してください。 ただし、テーブル内のいずれかの列に圧縮エンコードを指定すると、テーブルは ENCODE AUTO に設定されなくなります。Amazon Redshift は、テーブルにあるすべての列の圧縮エンコードを自動的に管理しないようになりました。 CREATE TABLE を使用すると、テーブル内の列の圧縮エンコードを指定するとき、ENCODE AUTO は無効です。ENCODE AUTO が無効なとき、Amazon Redshift は、ユーザーが ENCODE タイプを指定していない列について、次のように圧縮エンコードを自動的に割り当てます。 + ソートキーとして定義されている列には、RAW 圧縮が割り当てられます。 + BOOLEAN、REAL、または DOUBLE PRECISION データ型として定義されている列には、RAW 圧縮が割り当てられます。 + SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP、または TIMESTAMPTZ データ型として定義された列には AZ64 圧縮が割り当てられます。 + CHAR または VARCHAR データ型として定義された列には、LZO 圧縮が割り当てられます。 テーブルのエンコードは、作成後に ALTER TABLE を使用して変更できます。ALTER TABLE を使用して ENCODE AUTO を無効にした場合、Amazon Redshift は列の圧縮エンコードを自動的に管理しなくなります。すべての列の圧縮エンコードタイプは、ユーザーが変更するか、ENCODE AUTO を再び有効にするまで、ENCODE AUTO を無効にしたときの圧縮エンコードタイプのままです。 Amazon Redshift は、以下の圧縮エンコーディングをサポートしています。 ------ #### [ Raw ] Raw エンコードは、ソートキー、および BOOLEAN、REAL、または DOUBLE PRECISION データ型として定義された列として指定された列のエンコードのデフォルトです。raw エンコードでは、データは非圧縮の raw 形式で格納されます。 ------ #### [ AZ64 ] AZ64 は、高い圧縮率とクエリ処理能力の改善を実現するために Amazon によって設計された独自の圧縮エンコードアルゴリズムです。Z64 アルゴリズムは、より小さなデータ値のグループを圧縮し、並列処理に SIMD (Single Instruction Multiple Data) 命令を使用します。AZ64 を使用すると、数値、日付、および時刻データ型のストレージを大幅に節約し、高いパフォーマンスを実現できます。 次のデータ型の CREATE TABLE および ALTER TABLE ステートメントを使用して列を定義する場合、AZ64 を圧縮エンコードとして使用できます。 + SMALLINT + INTEGER + BIGINT + DECIMAL + DATE + TIMESTAMP + TIMESTAMPTZ ------ #### [ Byte-dictionary ] バイトディクショナリエンコードでは、ディスク上の列値のブロックごとに、一意の値の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) ディクショナリには、元のデータ値のインデックスとして格納されている最大 256 個の 1 バイト値が含まれます。単一のブロックに 256 個を超える値が格納されている場合は、余分な値が非圧縮の raw 形式でブロックに書き込まれます。ディスクブロックごとに、このプロセスが繰り返されます。 このエンコードは、低カーディナリティ文字列の列に対して非常に効果的です。このエンコードは、列のデータドメインが一意の値 256 個未満である場合に最適です。 BYTEDICT でエンコードされた文字列データ型 (CHAR と VARCHAR) の列の場合、Amazon Redshift は圧縮されたデータを直接処理するベクタースキャンと述語評価を実行します。これらのスキャンでは、ハードウェア固有の単一命令複数データ (SIMD) 命令が使用されて、並列処理が行われます。これにより、文字列列のスキャンが大幅に加速されます。バイトディクショナリエンコードは、CHAR/VARCHAR 列に長い文字列が含まれる場合に特にスペース効率が高まります。 テーブルに、CHAR(30) データ型の COUNTRY 列があるとします。データがロードされると、Amazon Redshift はディクショナリを作成し、COUNTRY 列にインデックス値を入力します。ディクショナリには、インデックス作成された一意の値が含まれ、テーブル自体には、対応する値の 1 バイトのサブスクリプトのみが含まれます。 **注記** 固定長文字の列には末尾の空白が格納されます。したがって CHAR(30) 列では、バイトディクショナリエンコードを使用すると、圧縮値ごとに 29 バイトのストレージが節約されます。 次の表は、COUNTRY 列のディクショナリを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) 次の表は、COUNTRY 列の値を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) この例の合計圧縮サイズは、次のように計算されます。ディクショナリに 6 つの異なるエントリが格納され (6 \$1 30 = 180)、テーブルに 10 個の 1 バイト圧縮値が含まれて、合計 190 バイトとなります。 ------ #### [ Delta ] デルタエンコードは、日時列にとって非常に有用です。 デルタエンコードは、列内の連続する値間の差を記録することにより、データを圧縮します。この差は、ディスク上の列値の各ブロックに対する個別のディクショナリに記録されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) 例えば、列に 1 から 10 までの 10 個の整数が順番に含まれているとします。最初の値は 4 バイトの整数 (\$1 1 バイトのフラグ) として保存されます。次の 9 つはそれぞれ値 1 のバイトとして保存され、前の値より 1 大きいことを示します。 デルタエンコードには、次の 2 つのバージョンがあります。 + 差を 1 バイト値 (8 ビット整数) として記録する DELTA + 差を 2 バイト値 (16 ビット整数) として記録する DELTA32K 1 バイトを使用して列内のほとんどの値を圧縮できる場合は、1 バイトの変形が非常に効果的です。しかし、最悪の場合、デルタがより大きいと、このエンコードは非圧縮データを保存する場合よりも多少効果が低くなる可能性もあります。16 ビットバージョンにも同様の論理が当てはまります。 2 つの値間の差が 1 バイトの範囲 (DELTA) または 2 バイトの範囲 (DELTA32K) を超える場合は、先頭に 1 バイトのフラグが付けられて元の完全な値が格納されます。1 バイトの範囲は -127～127、2 バイトの範囲は -32K～32K です。 次の表は、デルタエンコードが数値列に対してどのように機能するかを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ LZO ] LZO エンコードは、非常に高い圧縮率と良好なパフォーマンスを実現します。LZO エンコードは、非常に長い文字列を格納する CHAR 列および VARCHAR 列に対して使用すると特に効果的です。製品説明、ユーザーコメント、JSON 文字列などの自由形式テキストに適しています。 ------ #### [ Mostly ] Mostly エンコードは、列のデータ型が、格納された大部分の値で必要なサイズより大きい場合に有用です。このタイプの列に Mostly エンコードを指定して、列内の大部分の値を、より小さい標準ストレージサイズに圧縮することができます。圧縮できない残りの値は、raw 形式で格納されます。例えば、INT2 列などの 16 ビット列を 8 ビットストレージに圧縮できます。 一般的に、Mostly エンコードは次のデータ型に対して使用します。 + SMALLINT/INT2 (16 ビット) + INTEGER/INT (32 ビット) + BIGINT/INT8 (64 ビット) + DECIMAL/NUMERIC (64 ビット) 列のデータ型のサイズに見合う Mostly エンコードの適切なバージョンを選択します。例えば、16 ビット整数列として定義された列に MOSTLY8 を適用します。MOSTLY16 を 16 ビットデータ型の列に適用したり、MOSTLY32 を 32 ビットデータ型の列に適用したりすることはできません。 列内の比較的多くの値を圧縮できない場合、Mostly エンコードは非圧縮の場合よりも効果が低くなります。これらのエンコードの 1 つを列に適用する前に、確認してください。現在ロードしようとしている (そして今後ロードする可能性が高い) 値の*ほとんど*は、次のテーブルに示す範囲に収まるはずです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) **注記** 10 進値では、値が範囲内にあるかどうかを判断する場合に小数点を無視します。例えば、1,234.56 は 123,456 として扱われ、MOSTLY32 列で圧縮できます。 例えば、VENUE テーブルの VENUEID 列が raw 整数列として定義されている場合は、その値が 4 バイトのストレージを消費することを意味します。しかし、列の値の現在の範囲は **0**～**309** です。したがって、VENUEID に対して MOSTLY16 エンコードを使用してこのテーブルを再作成および再ロードすると、その列の各値のストレージが 2 バイトに減少します。 別のテーブルで参照される VENUEID 値のほとんどが 0～127 の範囲内にある場合、その外部キー列を MOSTLY8 としてエンコードすることは妥当と言えます。選択を行う前に、参照テーブルデータに対していくつかのクエリを実行して、ほとんどの値が 8 ビット、16 ビット、または 32 ビットの範囲内にあるかどうかを確認する必要があります。 次の表は、MOSTLY8、MOSTLY16、および MOSTLY32 エンコードが使用される場合の特定の数値の圧縮サイズを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Run length ] ランレングスエンコードは、連続して繰り返される値を、値と連続発生数 (実行の長さ) から成るトークンに置き換えます。ディスク上の列値のブロックごとに、一意の値の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) このエンコードは、データ値が連続して頻繁に繰り返されるテーブル (例えば、テーブルがこれらの値でソートされる場合) に最も適しています。 例えば、大きなディメンションテーブルの列に、予測どおりに小さなドメイン (10 個未満の可能な値を持つ COLOR 列など) があるとします。これらの値は、データがソートされていない場合でも、テーブル全体で長いシーケンスに分類される可能性があります。 ソートキーとして指定された列に、ランレングスエンコードを適用することは推奨されません。範囲が制限されたスキャンは、ブロックに同様の数の行が含まれる場合にパフォーマンスが向上します。ソートキー列が、同じクエリ内の他の列よりもかなり高度に圧縮される場合、範囲が制限されたスキャンはパフォーマンスが低下する可能性があります。 次の表は、COLOR 列の例を使用して、ランレングスエンコードがどのように機能するかを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Text255 and Text32k ] text255 および text32k エンコードは、同じ単語が頻繁に出現する VARCHAR 列を圧縮する場合に有用です。ディスク上の列値のブロックごとに、一意の単語の個別のディクショナリが作成されます (Amazon Redshift のディスクブロックは 1 MB を占有します。) ディクショナリには、列内の最初の 245 個の一意の単語が含まれます。これらの単語は、ディスク上で、245 個の値の 1 つを表す 1 バイトインデックス値に置き換えられ、ディクショナリに表されていないすべての単語は非圧縮で格納されます。このプロセスは、1 MB のディスクブロックごとに繰り返されます。インデックス作成された単語が列内に頻繁に出現する場合、列の圧縮率は非常に高くなります。 text32k エンコードでも原理は同じですが、各ブロックのディクショナリは特定数の単語をキャプチャすることはありません。代わりにディクショナリは、結合されたエントリが、32K から多少のオーバーヘッドを減算した長さに達するまで、検出した一意の各単語のインデックスを作成します。インデックス値は 2 バイトで格納されます。 例えば、VENUE テーブルの VENUENAME 列を考えてみます。この列には **Arena**、**Center**、**Theatre** などの単語が繰り返し出現し、text255 圧縮が適用された場合、各ブロックに出現する最初の 245 個の単語内にこれらが含まれると考えられます。その場合、この列は圧縮の利点を利用できます。その場合、これらの単語が出現するたびに 1 バイトのストレージ (それぞれ 5、6、または 7 バイトではなく) を占めるにすぎないのが理由です。 ------ #### [ ZSTD ] Zstandard (ZSTD) エンコードは、多様なデータセット間で非常にパフォーマンスのいい高圧縮比率を提供します。ZSTD は、製品説明、ユーザーのコメント、ログ、JSON 文字列など、長さがさまざまな文字列を保存する CHAR および VARCHAR 列に対して、特に効果を発揮します。一部のアルゴリズム (デルタエンコードや Mostly エンコードなど) では非圧縮時よりもストレージスペースの使用量が増える場合がありますが、ZSTD ではディスク使用量が増えることはありません。 ZSTD は、SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ データ型をサポートします。 ------ 次の表は、サポートされる圧縮エンコード、およびエンコードをサポートするデータ型を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Compression_encodings.html)