redshift compression encodings（圧縮アルゴリズム）についてもっと調べてみた
DESCRIPTION
RedshiftのCompression Encodingsの種類について調べていたところ、挙動に気になるところがあったので検証してみました。TRANSCRIPT
Amazon RedshiftCompression encodingsについて
もっと調べてみた
株式会社ALBERT
@iktakahiro2013-07-28
自己紹介
•株式会社ALBERT•池内 孝啓 / Takahiro Ikeuchi•システム開発部•@iktakahiro
Agenda
• ANALYZE COMPRESSIONは正しいのか検証してみる
• SORTKEYとRun-lengthの関係を検証してみる
Analyze Compressionは正しいのか検証してみる
AmazonRedshift
検証データ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
検証データ1 解説
• 1,000万レコード• id 列はINTのインクリメント• per_one 列はリスト ['Urd', 'Verdandi', 'Skuld'] から1行毎に次の値が採用される
• per_hundred 列は上記リストから100行毎に次の値が値が採用される
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を実行する条件の 元検証を実施
結果 1-1カラム 期待値 結果
id Delta Delta
per_one Text255 Text255
per_hundred Run-length Run-length
• 期待値通りの結果
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を付与してみる
結果 1-2カラム 期待値 結果
id Delta Delta
per_one Run-length Text255
per_hundred Text255 Run-length
• per_one列をSORTKEY指定しているので、Run-lengthになることを期待したがSORTKEYなし時と同じ結果に
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にこんな記載が
SORTKEYとRun-lengthの関係を検証してみる
AmazonRedshift
検証データ2per_one
Urd
Verdandi
Skuld
Urd
Verdandi
...
Urd
...
Skuld
普通1列ということはないと思いますが検証ですので、、
Table & Query 2
CREATE TABLE test_compression ( per_one VARCHAR(8) );
COPY test_compression FROM 's3://～略～ GZIP;
ANALYZE COMPRESSION test_compression;
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)となる。はず。。
Table & Query 2
SELECT * FROM pg_table_def WHERE tablename = 'test_compression';
実際に作成されたテーブルのカラムに、どのCompression Encodingsが適応されているかは、次のクエリで確認できます。
• このような感じで、投入する元データをソート、SORTKEYの付与、COPY時の
COMPUPDATE OFF指定など組み合わせて検証して次頁の表にまとめてみました
※ COMPUPDATEをOFFと明示するとCOPY時の自動圧縮 アルゴリズム適応が行われない。 (カラムにENCODE RAWを明示してもよい）
結果 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
結果 考察
どちらもText255が採用されている
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
1 ソート無し F 指定しない T 104 Text255
9 ソート済み F Text255 -- 104 Text255
結果 考察
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
結果 考察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時圧縮に自動選択されるアルゴリズムが違う
まとめ
• ANALYZE COMPRESSIONはSORTKEYを気にしない
• SORTKEYはCOPY時の圧縮アルゴリズムの選択に影響を与えない（？）
• SORTKEY + Run-lengthが最も圧縮率が高い場合でも他のアルゴリズム（Text255など）が選択されるケースもある
• 検証で使ったように極端なデータならアルゴリズムの選択が容易だが、実運用データではこうもいかない、、
• 明示せずにRedshiftに任せるのも手かも知れない
• ただしSORTKEY絡みで腑に落ちない挙動もあるので一応注意が必要
• 状態は確認できるので気になったら調べてみよう
まとめ