提示:
信息检索-索引构建:就是建立倒排索引的过程
索引构建
索引构建:建立倒排索引的过程。
索引器:构建索引的程序或计算机。
前面见过的索引:
硬件基础:
索引构建基础
先看下两个基本概念区别,下图所示:更多请戳>>点这里
(1)先找一下我们需要构建索引的相关信息:
(2)根据信息,初步处理:索引构建中的临时文件
N=800000,文档ID需要32bits
T=100000000,词条ID需要32bits
存储文档和词条ID需要:
此处补充个小知识:
(3)词典、倒排记录的大小
M=400000,词项ID需要32bits
词典大小:M32bits=16000000bytes=1.6mbytes
N=800000,文档ID需要32bits
L N=160000000
倒排表:L * N * 32bits=640000000bytes=0.64gbytes
(4)将每篇文档转换成词条列表并加上文档ID
->转换后按词项字母排序。
基于块的排序索引算法
基于块的排序索引方法
内存式单遍扫描索引构建方法
SPIMI:内存式单遍扫描索引算法
核心思想1:为每个块单独生成一个词典不需要维护全局的<词项,词项ID>映射表
核心思想2:不进行排序,有新的<词项,文档ID> 对时直接在倒排记录表中增加一项
根据这两点思想,可以为每个块生成一个完整的倒排索引,然后将这些单独的索引合并为一个大的索引
压缩技术会使该算法更加高效:压缩词项,压缩倒排记录表
分布式索引构建方法
》大规模的索引构建必须使用一个分布式的计算机集群,比如Web
》利用集群中的主控节点来指挥索引构建工作
》将索引构建过程分解成一组并行的任务
》主控计算机从集群中选取一台空闲的机器并将任务分配给它
文档集分割:基于词项,文档
分析器Parsers .
主节点将一个数据片分配给一台空闲的分析服务器
分析器依次读取文档并生成<词项,文档>对
分析器将这些<词项,文档>对分成j个段
每一段是按照词项首字母划分的一个区间,例如: a-f, g-p, q-z,这里j=3
然后可以进行索引的倒排
倒排器:
对于一个词项分区,倒排器收集所有的<词项,文档>对(也就是“倒排记录")排序,并写入最终的倒排记录表
MapReduce
Google索引系统由各个不同的阶段组成,每个阶段都是MapReduce的一个应用,索引构建只是其中的一个阶段,另一个阶段是:将基于词项划分的索引表转换成基于文档划分的索引表
■基于词项划分的:一台机器处理所有词项的一个子区间
■基于文档划分的:一台机器处理所有文档的一个子区间
大部分搜索引擎都是采用基于文档划分的索引表-为什么?
更好的负载平衡
Map和Reduce函数的架构
■Map:输入->list(k,v) Reduce:(k,list(v))->输出
索引构建中上述架构的实例化
■Map: Web文档集—> list(词项,文档1D)
■Reduce: (<词项1 ,list(文档ID)>,<词项2,list(文档1D)…)—> (倒排记录表1,倒排记录表2…)
MAP:
Reduce:
动态索引构建方法
迄今为止,我们都假设文档集是静态的,但文档集通常不是静态的:文档会不断地加入进来;文档也会被删除或者修改
这就意味着词典和倒排记录表需要修改:
■对于已在词典中的词项更新倒排记录
新的词项加入到词典中
频繁的合并- -带来很大的开销
合并过程效率很低
如果每个词项的倒排记录表都单独成一个文件,那么合并主索引和辅助索引将会很高效,合并将是一个简单的添加操作
■但我们需要非常多的倒排文件一 对文件系统来说是低效的
现实中:我们往往在上述两种极端机制中取一个折中方案
对数合并
■维护一系列的索引,每个都是前一个的两倍大小将最小的Z0存储在内存中
■将最小的Z0存储在内存中
■将较大的那些(l0,l1…)存储在磁盘中
当Z0达到.上限n时,将它写入磁盘l0中
当Z0下一次达到上限时,它会和l0合并,生成Z1
●此时,如果l1不存在,存储到l1中
●如果l1已存在,则Z1与l1合并成Z2
●以此类推…
辅助索引和主索引:因为每次合并都会处理倒排记录,所以索引构建时间为O(T^2)
对数合并:每个倒排记录被合并了0(logT)次,所以复杂度为0(TlogT)
所以对于索引构建来说,对数合并是非常高效的,但是查询过程现在需要用到合并的O(logT)个索引
其他索引类型
包含位置信息的索引
■是同样的排序问题- -只是带来了更大的数据开销
排名检索:倒排记录表通常是根据权重或影响排序的,最高权重的倒排记录表首先出现
■当权重已经变得很小时,查询处理通常可以提前终止