答索引构造一问

发信人: groupon (cool man), 信区: SearchEngineTech
标 题: 问一个索引构造问题
发信站: 水木社区 (Tue Jul 27 08:42:12 2010), 站内

索引构造中支持skip的机制是不是这样的,我自己琢磨不知道对否,求拍
答索引构造一问


注:其中skip_block和后面压缩部分都是物理上连续的,这里为了图示方便。

倒排表的索引部分肯定在内存中的,<term,loc>pair的结构。
但由于不同的term的compressed doc list不同,因此在大词和小词求交时代价很大,
且倒排表一般都是mmap读取的,因此是物理内存调页到虚存中进行读取的方式,

因此可以做一个skip_block,大小为物理内存page size的倍数,
compressed doc list中也划分成一个一个segment(也为page size的倍数),每个segment的首个docid不压缩,并存放在skip_block中(每个segment的第一个元素在skip_block中,第二个元素是和这个docid的距离差值),用于求交计算,segment的尾部可能会损失若干bit。

这样如果在小词和大词求交可以在大词的segment上整片整片的跳过。
长期下来的话,大词的skip_block基本都在内存中不会被换出。

粗粗想来,没有实践,不知道是否靠谱,求拍。

-----------------------------------------------------------以下是我的答复--------------------------------------------------------------

索引的构造设计可以从下面点出发去考虑
comperssion/decompression
caching
parallelism
early termination(pruning)
skipping

comperssion可能是混杂的,间距大的情况下可能会用到var-byte Compression这类字节对齐的压缩方法,解压会很快,间距小的情况下一般采用PFOR-DELTA。
压缩通常情况下是解压速度快,优先于压缩比高,很多压缩比高的算法并不会在实践中采用。由于是混杂结构,因此索引需要记住使用的压缩算法,通常压缩效果的提升都是在common term中取得的。

caching这个问题你考虑得很好,在考虑skipping的情况下能够将其紧凑的存放。另外你提到的warm up cache也是对的,这有助于将compressed doclist载入内存,但往往这样还不够,因为在并发查询的情况下,解压也需要耗时,因此外围还会需要有一层caching来存放解压后的common query的doclist。这也是搜索引擎非常耗资源的一块。cache一般都能做到90%以上的查询直接在cache中获得。

parallelism这个问题很复杂,你的设计很好的支持了doclist求交并发。

pruning 剪枝这个方面你考虑的不够,在检索时,求交往往不是从头交到尾的,会在一定程度时停下,例如收集到足够的结果,或者余下的结果质量不高等等,因此在索引中要包含丰富的信息,这一点其他人也回复得很多,比如需要有词频,甚至一些必要的上下文信息。

skipping 这个有一点你没有考虑,common term 你做了一个skip block,但那些生僻词,不常用词呢,这就没有必要了,因为总是doclist短的去和doclist长的词求交。

另外关于doclist分块,有固定大小的分块,也有固定doc数量的分块方式,这个在90年代的论文中都有讨论,各有利弊。固定大小的分块比较容易算偏移,但会有浪费,编译都是字节型的地址。但压缩和解压会有问题,因为分块尾部如何padding会是个麻烦,特别是如果还需要存poslist,那么会更麻烦需要考虑跨块问题,会有很多损耗。固定doc数量的情况下,支持skip的辅助数组得使用bit address,也会有浪费。采用固定doc数量的方法可能更常见。


关于这方面比较新的论文:
Performance of Compressed Inverted List Caching in Search Engines
Using Graphics Processors for High Performance IR Query Processing

原帖如下:http://www.newsmth.net/bbstcon.php?board=SearchEngineTech&gid=25517

有兴趣的朋友可以阅读。

你可能感兴趣的:(算法,PHP,cache,搜索引擎,performance)