blog.k11i.biz: 10月 2014

2014-10-22

最近 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 を選ぶのがよい
時間経過とともに使われる値の種類が増えるが、ソートキーを考慮すると使われる値の種類が少数に限定されると想定できる場合
- bytedict でよさそう
値の種類数は多いが、出現する値に偏りがある場合
- 0 近辺に偏っているなら、 mostly8/16/32 などを選ぶのがよい
- それ以外なら bytedict がよさそう
ソートキーを考慮したときに値が昇順に並ぶ場合
- delta/delta32k を選ぶのがよい
それ以外の場合
- 諦めて、圧縮エンコードは設定しない (raw にする)

正直言って、数値データは実際のデータで性能を確認してみないとわからないと思う…