最近 Redshift を触っていて、圧縮エンコードについて調べることがあったのでメモメモしておきます。なお、2014 年 10 月時点での情報であることと、わりとざっくりとした確認だったので不正確な情報が混じっているかもしれないのでご承知おきください。
文字列データ (VARCHAR など)
- 選択肢としては、
text255,text32k,bytedict,lzoあたり- 空間効率的には
text255text32kはあんまりよろしくなさげ - また、
text255はカラムサイズが 255 を超えるカラムに適用することができない (厳密には、255 バイトを超える文字列が入っている場合に適用できない、となる)
- 空間効率的には
- 値の種類数が少なく (目安として、256 個以下ぐらい)、かつ種類が増える可能性が低い場合
bytedictもしくはlzoを選ぶのがよい- 種類数が 256 を超える場合であっても、出現頻度に偏りがある場合は
bytedictを選択するのもありっぽい - ただし、文字列の平均長が長い場合は
bytedictはあんまり性能よろしくない?
- 最初は値の種類数が少ないが、時間経過とともに使われる値の種類が徐々に増える場合
lzoを選ぶのがよい
- 時間経過とともに使われる値の種類が増えるが、ソートキーを考慮すると使われる値の種類が少数に限定されると想定できる場合
lzoを選ぶのがよい
- 値の種類数が多い場合
lzoを選ぶのがよい
というわけで、迷ったら lzo を選べばだいたいいい感じだと思う。
数値データ
- 選択肢としては、
bytedict,delta/delta32k,mostly8/16/32あたりlzoはあんまり向いてなさげ
- 値の種類数が少なく、かつ種類が増える可能性が低い場合
- 0 付近の値が頻出する場合は
mostly8を選ぶのがよい - それ以外では
bytedictを選ぶのがよい
- 0 付近の値が頻出する場合は
- 時間経過とともに使われる値の種類が増えるが、ソートキーを考慮すると使われる値の種類が少数に限定されると想定できる場合
bytedictでよさそう
- 値の種類数は多いが、出現する値に偏りがある場合
- 0 近辺に偏っているなら、
mostly8/16/32などを選ぶのがよい - それ以外なら
bytedictがよさそう
- 0 近辺に偏っているなら、
- ソートキーを考慮したときに値が昇順に並ぶ場合
delta/delta32kを選ぶのがよい
- それ以外の場合
- 諦めて、圧縮エンコードは設定しない (
rawにする)
- 諦めて、圧縮エンコードは設定しない (
正直言って、数値データは実際のデータで性能を確認してみないとわからないと思う…
その他
runlengthの使いどころがよくわからない…- 時間計算量
bytedictは時間計算量ちょっと高めな傾向がみられるlzoはバランスがとれている感じ
0 コメント:
コメントを投稿