4索引构建

提示：
信息检索-索引构建：就是建立倒排索引的过程

---

索引构建

索引构建：建立倒排索引的过程。
索引器：构建索引的程序或计算机。
前面见过的索引：

硬件基础：

索引构建基础

先看下两个基本概念区别，下图所示：更多请戳>>点这里

（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:

动态索引构建方法

 迄今为止，我们都假设文档集是静态的，但文档集通常不是静态的:文档会不断地加入进来；文档也会被删除或者修改
 这就意味着词典和倒排记录表需要修改:
 ■对于已在词典中的词项更新倒排记录
 新的词项加入到词典中


 频繁的合并- -带来很大的开销
 合并过程效率很低
 如果每个词项的倒排记录表都单独成一个文件，那么合并主索引和辅助索引将会很高效，合并将是一个简单的添加操作
 ■但我们需要非常多的倒排文件一 对文件系统来说是低效的
 现实中:我们往往在上述两种极端机制中取一个折中方案

对数合并
■维护一系列的索引，每个都是前一个的两倍大小将最小的Z₀存储在内存中
■将最小的Z₀存储在内存中
■将较大的那些(l₀,l₁…)存储在磁盘中
当Z₀达到.上限n时，将它写入磁盘l₀中
当Z₀下一次达到上限时，它会和l₀合并,生成Z₁
●此时，如果l₁不存在，存储到l₁中
●如果l₁已存在，则Z₁与l₁合并成Z₂
●以此类推…

 辅助索引和主索引:因为每次合并都会处理倒排记录，所以索引构建时间为O(T^2)
 对数合并:每个倒排记录被合并了0(logT)次,所以复杂度为0(TlogT)
 所以对于索引构建来说，对数合并是非常高效的,但是查询过程现在需要用到合并的O(logT)个索引

其他索引类型

 包含位置信息的索引
■是同样的排序问题- -只是带来了更大的数据开销
 排名检索:倒排记录表通常是根据权重或影响排序的，最高权重的倒排记录表首先出现
■当权重已经变得很小时，查询处理通常可以提前终止