最近 Redshift を触っていて、圧縮エンコードについて調べることがあったのでメモメモしておきます。なお、2014 年 10 月時点での情報であることと、わりとざっくりとした確認だったので不正確な情報が混じっているかもしれないのでご承知おきください。
文字列データ (VARCHAR など)
- 選択肢としては、
text255
,text32k
,bytedict
,lzo
あたり- 空間効率的には
text255
text32k
はあんまりよろしくなさげ - また、
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 コメント:
コメントを投稿