搜索引擎的索引一般都是倒排数据。在海量数据中,索引本身的规模也是很可观的。例如对于一种比较复杂的索引数据,其保存了词语的文档标志、词频和位置序列,在30万规模的全文中,有些词语的索引数据达到100M级别。
例如“汽车”在某篇文本中的信息为:
文本号 = 332
权值 = 0.001456
- 位置0 - { 段号= 0, 句号= 0, 词号= 15 }
- 位置1 - { 段号= 0, 句号= 4, 词号= 27 }
- 位置2 - { 段号= 0, 句号= 5, 词号= 1 }
- 位置3 - { 段号= 0, 句号= 5, 词号= 7 }
- 位置4 - { 段号= 0, 句号= 35, 词号= 89 }
- 位置5 - { 段号= 7, 句号= 31, 词号= 16 }
- 位置6 - { 段号= 224, 句号= 2, 词号= 23 }
- 位置7 - { 段号= 224, 句号= 2, 词号= 24 }
- 位置8 - { 段号= 224, 句号= 19, 词号= 18 }
这给搜索计算带来了很大的压力。所以搜索引擎一般会对索引数据进行压缩,而一般的看,这其中最突出的是整数序列的压缩问题。
现在有一些成熟的压缩算法,典型如Golomb算法、Fixed Binary Codewords算法等。其中后者的压缩、解压速度以及压缩比都相当不错,对检索比较有利。但对整数序列的压缩思想一般都是求其差值以获得小整数为主的分布,然后再在这个基础上进行压缩。但对于偶给出的数据为例,位置信息本身是个向量(向量的每个元素存储空间都是已定且可能不相等),而这个向量不宜分解(否则检索时计算复杂度大大增加),那么应该如何进行压缩呢?
这是一个非常有意思的问题。偶设计了一个算法,目前还没有测试数据。当然也欢迎大家讨论。
2196

被折叠的 条评论
为什么被折叠?



