Amazon Redshift
Compression encodingsについて
もっと調べてみた
株式会社ALBERT
@iktakahiro
2013-07-28
自己紹介
•株式会社ALBERT
•池内 孝啓 / Takahiro Ikeuchi
•システム開発部
•@iktakahiro
Agenda
• ANALYZE COMPRESSIONは正しいのか
検証してみる
• SORTKEYとRun-lengthの関係を検証して
みる
Analyze Compressionは正しいのか
検証してみる
Amazon
Redshift
検証データ1
id per_one per_hundred
1 Urd Urd
2 Verdandi Urd
3 Skuld Urd
4 Urd Urd
101 Verdandi Verdandi
... ... ...
250 Urd Sku...
検証データ1 解説
• 1,000万レコード
• id 列はINTのインクリメント
• per_one 列はリスト ['Urd', 'Verdandi', 'Skuld'] から
1行毎に次の値が採用される
• per_hundred 列は上記...
Table & Query 1-1
CREATE TABLE test_compression (
id INTEGER,
per_one VARCHAR(8),
per_hundred VARCHAR(8)
);
COPY test_comp...
結果 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 t...
結果 1-2
カラム 期待値 結果
id Delta Delta
per_one Run-length Text255
per_hundred Text255 Run-length
• per_one列をSORTKEY指定しているので、
Run...
ANALYZE と SORTKEY
"ANALYZE COMPRESSION does not consider Runlength
encoding encoding on any column that is designated as a...
SORTKEYとRun-lengthの関係を
検証してみる
Amazon
Redshift
検証データ2
per_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 C...
Table & Query 2
SELECT tbl, count(*) FROM stv_blocklist
WHERE tbl in (
SELECT id FROM stv_tbl_perm
WHERE name='test_compre...
Table & Query 2
SELECT * FROM pg_table_def WHERE tablename = 'test_compression';
実際に作成されたテーブルのカラムに、どの
Compression Encoding...
• このような感じで、投入する元データを
ソート、SORTKEYの付与、COPY時の
COMPUPDATE OFF指定など組み合わせて検証
して次頁の表にまとめてみました
※ COMPUPDATEをOFFと明示するとCOPY時の自動圧縮
アルゴ...
結果 2
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
1 ソート無し F 指定しない T 104 Text255
2 ソート無し F 指定しない F 182 RAW
3 ソート無し ...
結果 考察
どちらもText255が採用されている
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
1 ソート無し F 指定しない T 104 Text255
9 ソート済み F Tex...
結果 考察
SORTKEYを明示したときのほうがブロック数が増える
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
3 ソート無し T Run-length -- 92 Run-leng...
結果 考察
No 元データ SORTKEY ENCODING指定 COPY時 圧縮 ブロック数 ENCODING結果
3 ソート無し T Run-length -- 92 Run-length
5 ソート無し T 指定しない T 112 Tex...
まとめ
• ANALYZE COMPRESSIONはSORTKEYを気にしない
• SORTKEYはCOPY時の圧縮アルゴリズムの選択に
影響を与えない(?)
• SORTKEY + Run-lengthが最も圧縮率が高い場合で
も他のアルゴリ...
• 検証で使ったように極端なデータならアルゴリズ
ムの選択が容易だが、実運用データではこうもい
かない、、
• 明示せずにRedshiftに任せるのも手かも知れない
• ただしSORTKEY絡みで腑に落ちない挙動もあるの
で一応注意が必要
• ...
Upcoming SlideShare
Loading in …5
×

Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた

2,942 views

Published on

RedshiftのCompression Encodingsの種類について調べていたところ、挙動に気になるところがあったので検証してみました。

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,942
On SlideShare
0
From Embeds
0
Number of Embeds
121
Actions
Shares
0
Downloads
11
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた

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

×