Your SlideShare is downloading. ×
Redshift Compression Encodings(圧縮アルゴリズム)についてもっと調べてみた
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,673
views

Published on

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

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

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,673
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
8
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×