再次优化完成一个infobright表

小编辑 发布于 2010/02/03 06:19
阅读 1K+
收藏 1

用infobright来存储log,原来的结构是以date、uid、time来排序存储,毫无疑问date得到了最大的压缩比与查询优 化,uid的压缩比也很高。但很快发现我的分析工作里根据nurl的查询要比根据uid的查询多得多,而且uid的跨度通常不大(比一个pack的量 64K个item要少),于是nurl就散落在各个pack里,这样的排序方式导致所有对nurl或url的查询都异常地慢。于是尝试着改为以date、 nurl、uid、time为sort,同样date得到最大的优化,nurl的优化也体现出来了,而且由于同一个nurl的量比较大,后面的uid也有 一定程度的优化。这种sort方式,对nurl、url、uid查询,综合得到的效果都比之前的设计要好。

另外一个就是把nurl从数字恢复为原来的字符串(varchar),做成lookup columns以减少存储空间,当然导入前要做些预处理,把出现频率少的置空,因为lookup columns的distinct个数不能超过10000个。这下子就可以对nurl字段作like ‘/pattern/%’这类前缀查询了。

自我感觉,这两个SORT和LOOKUP优化相当成功。又得要花几天的时间来重导数据啦!

加载中
返回顶部
顶部