一两个infobright优化的体验

据官方文档介绍，某一些列定义为lookup columns可以减少存储空间，提高压缩率；另外对某个字段的sorting会提高某查询效率。所以我就做来试试。

所谓lookup columns相当于把具体的值定义为一个索引，一串字符串就可以只用一个数字索引来表示了。它只对显式定义为char或varchar的字段适用。定义方法是在该列定义的最后加上COMMENT ‘lookup’。注意的是这种定义只适用于行数很多但实际出现不同的值很少的字段，也即count(item)/count(distinct(item))非常大。典型的例子如类别、性别、年份字段。count(distinct(item))大于10000的则一定不要使用。

1. 先把一个旧表的数据导出来，依据旧表的结构建了一个新表，给新表的几个字段加上lookup属性，再把原数据导入到新表。用show full columns from table_name可以查看新表和旧表各个字段的实际占用空间及压缩率。我的新旧表对比结果如下：
   • 原来一个char(4)的字段，加上lookup columns定义后压缩率有较大的提升。
   • 两个char(1)的字段，压缩率稍有提升，但是不是很明显，原因可能是作为索引的数字也是一个字段来表示。
   • 原来一个tinyint字段的数字，为了能用lookup，改为用char(1)定义。查询时可以用 … where x in (’2′, ’3′)的方式，也可用… where x > 1的方式，不过应该是按照ascii码比较而不是按照数字比较。
2. 再改一下sorting的顺序，假设这次以（cat, rating, dt）三个字段排序的方式来导入数据，cat字段和rating字段是lookup columns，dt是INT。这次得到的结果比较有代表性，cat字段得到了最大的压缩，压缩率为999.9，实际表示已经超过1000。类似地rating和dt字段都得到了极大的压缩，这说明字段是否有序对压缩率影响巨大。随后我的实验表明sorting对查询效率也会有很大的影响，比如在这种排序情况下，对cat的查询效率得到最大优化，对rating和dt也有一定程度的优化。从infobright的存储与查询原理也很容易得出这点。

补充一下，如果数据量不大（比如少于百万），可能这些效果都不明显。

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=418