![Page 1: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/1.jpg)
Amazon RedshiftCompression encodingsについて
もっと調べてみた
株式会社ALBERT
@iktakahiro2013-07-28
![Page 2: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/2.jpg)
自己紹介
•株式会社ALBERT•池内 孝啓 / Takahiro Ikeuchi•システム開発部•@iktakahiro
![Page 3: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/3.jpg)
Agenda
• ANALYZE COMPRESSIONは正しいのか検証してみる
• SORTKEYとRun-lengthの関係を検証してみる
![Page 4: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/4.jpg)
Analyze Compressionは正しいのか検証してみる
AmazonRedshift
![Page 5: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/5.jpg)
検証データ1id per_one per_hundred
1 Urd Urd
2 Verdandi Urd
3 Skuld Urd
4 Urd Urd
101 Verdandi Verdandi
... ... ...
250 Urd Skuld
... ... ...
399 Skuld Urd
![Page 6: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/6.jpg)
検証データ1 解説
• 1,000万レコード• id 列はINTのインクリメント• per_one 列はリスト ['Urd', 'Verdandi', 'Skuld'] から1行毎に次の値が採用される
• per_hundred 列は上記リストから100行毎に次の値が値が採用される
![Page 7: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/7.jpg)
Table & Query 1-1 CREATE TABLE test_compression ( id INTEGER, per_one VARCHAR(8), per_hundred VARCHAR(8) );
COPY test_compression FROM 's3://~略~ GZIP;
ANALYZE COMPRESSION test_compression;
※ データのCOPY前に必ずDROP TABLEを実行する条件の 元検証を実施
![Page 8: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/8.jpg)
結果 1-1カラム 期待値 結果
id Delta Delta
per_one Text255 Text255
per_hundred Run-length Run-length
• 期待値通りの結果
![Page 9: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/9.jpg)
Table & Query 1-2
CREATE TABLE test_compression ( id INTEGER, per_one VARCHAR(8) SORTKEY, per_hundred VARCHAR(8) );
COPY test_compression FROM 's3://~略~ GZIP;
ANALYZE COMPRESSION test_compression;
• SORTKEYを付与してみる
![Page 10: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/10.jpg)
結果 1-2カラム 期待値 結果
id Delta Delta
per_one Run-length Text255
per_hundred Text255 Run-length
• per_one列をSORTKEY指定しているので、Run-lengthになることを期待したがSORTKEYなし時と同じ結果に
![Page 11: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/11.jpg)
ANALYZE と SORTKEY
"ANALYZE COMPRESSION does not consider Runlength encoding encoding on any column that is designated as a SORTKEY because range-restricted scans might perform poorly when SORTKEY columns are compressed much more highly than other columns."
http://docs.aws.amazon.com/redshift/latest/dg/r_ANALYZE_COMPRESSION.html
Usage Notesにこんな記載が
![Page 12: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/12.jpg)
SORTKEYとRun-lengthの関係を検証してみる
AmazonRedshift
![Page 13: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/13.jpg)
検証データ2per_one
Urd
Verdandi
Skuld
Urd
Verdandi
...
Urd
...
Skuld
普通1列ということはないと思いますが検証ですので、、
![Page 14: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/14.jpg)
Table & Query 2
CREATE TABLE test_compression ( per_one VARCHAR(8) );
COPY test_compression FROM 's3://~略~ GZIP;
ANALYZE COMPRESSION test_compression;
![Page 15: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/15.jpg)
Table & Query 2
SELECT tbl, count(*) FROM stv_blocklist WHERE tbl in ( SELECT id FROM stv_tbl_perm WHERE name='test_compression' ) GROUP BY tbl;
ここからはブロック数を基準に検証してみます。テーブルが使用しているブロック数は次のクエリで確認できます。
※ Redshiftのブロックサイズは1MBなのでこのクエリ 結果が使用容量(=MB)となる。はず。。
![Page 16: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/16.jpg)
Table & Query 2
SELECT * FROM pg_table_def WHERE tablename = 'test_compression';
実際に作成されたテーブルのカラムに、どのCompression Encodingsが適応されているかは、次のクエリで確認できます。
![Page 17: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/17.jpg)
• このような感じで、投入する元データをソート、SORTKEYの付与、COPY時の
COMPUPDATE OFF指定など組み合わせて検証して次頁の表にまとめてみました
※ COMPUPDATEをOFFと明示するとCOPY時の自動圧縮 アルゴリズム適応が行われない。 (カラムにENCODE RAWを明示してもよい)
![Page 18: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/18.jpg)
結果 2No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
1 ソート無し F 指定しない T 104 Text255
2 ソート無し F 指定しない F 182 RAW
3 ソート無し T Run-length -- 92 Run-length
4 ソート無し F Run-length -- 182 Run-length
5 ソート無し T 指定しない T 112 Text255
6 ソート済み F 指定しない T 84 Run-length
7 ソート済み F 指定しない F 182 RAW
8 ソート済み T Run-length -- 92 Run-length
9 ソート済み F Text255 -- 104 Text255
![Page 19: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/19.jpg)
結果 考察
どちらもText255が採用されている
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
1 ソート無し F 指定しない T 104 Text255
9 ソート済み F Text255 -- 104 Text255
![Page 20: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/20.jpg)
結果 考察
SORTKEYを明示したときのほうがブロック数が増える
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
3 ソート無し T Run-length -- 92 Run-length
6 ソート済み F 指定しない T 84 Run-length
8 ソート済み T Run-length -- 92 Run-length
![Page 21: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/21.jpg)
結果 考察No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
3 ソート無し T Run-length -- 92 Run-length
5 ソート無し T 指定しない T 112 Text255
6 ソート済み F 指定しない T 84 Run-length
ソート済みデータを自動圧縮に任せた場合と、ソート無しデータをSORTKEY指定した場合で、COPY時圧縮に自動選択されるアルゴリズムが違う
![Page 22: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/22.jpg)
まとめ
• ANALYZE COMPRESSIONはSORTKEYを気にしない
• SORTKEYはCOPY時の圧縮アルゴリズムの選択に影響を与えない(?)
• SORTKEY + Run-lengthが最も圧縮率が高い場合でも他のアルゴリズム(Text255など)が選択されるケースもある
![Page 23: Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた](https://reader034.vdocuments.pub/reader034/viewer/2022042614/558940d5d8b42ab05b8b46b0/html5/thumbnails/23.jpg)
• 検証で使ったように極端なデータならアルゴリズムの選択が容易だが、実運用データではこうもいかない、、
• 明示せずにRedshiftに任せるのも手かも知れない
• ただしSORTKEY絡みで腑に落ちない挙動もあるので一応注意が必要
• 状態は確認できるので気になったら調べてみよう
まとめ