网站大量收购独家精品文档,联系QQ:2885784924

lecture4-indexconstruction 第4讲 索引构建 现代信息检索导论 教学课件.ppt

lecture4-indexconstruction 第4讲 索引构建 现代信息检索导论 教学课件.ppt

  1. 1、本文档共56页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
lecture4-indexconstruction 第4讲 索引构建 现代信息检索导论 教学课件

第4讲 索引构建 Index construction * SPIMI-Invert算法 * SPIMI: 压缩 如果使用压缩,SPIMI将更加高效 词项的压缩 倒排记录表的压缩 参见下一讲 * 课堂练习:计算1台机器下采用BSBI方法对Google级规模数据构建索引的时间 提纲 上一讲回顾 简介 BSBI算法 SPIMI算法 分布式索引构建 动态索引构建 * 分布式索引构建 对于Web数据级别的数据建立索引 (don’t try this at home!): 必须使用分布式计算机集群 单台机器都是有可能出现故障的 可能突然慢下来或者失效,不可事先预知 如何使用一批机器? * Google 数据中心(2007 estimates; Gartner) Google数据中心主要都是普通机器 数据中心均采用分布式架构,在世界各地分布 100万台服务器,300个处理器/核 Google每15分钟装入 100,000个服务器. 每年的支出大概是每年2-2.5亿美元 这可能是世界上计算能力的10%! 在一个1000个节点组成的无容错系统中,每个节点的正常运行概率为99.9%,那么整个系统的正常运行概率是多少? 答案: 63% 假定一台服务器3年后会失效,那么对于100万台服务器,机器失效的平均间隔大概是多少? 答案: 不到2分钟 * 分布式索引构建 维持一台主机(Master)来指挥索引构建任务-这台主机被认为是安全的 将索引划分成多组并行任务 主机将把每个任务分配给某个缓冲池中的空闲机器来执行 * 并行任务 两类并行任务分配给两类机器: 分析器(Parser) 倒排器(Inverter) 将输入的文档集分片(split) (对应于BSBI/SPIMI算法中的块) 每个数据片都是一个文档子集 * 分析器(Parser) 主节点将一个数据片分配给一台空闲的分析器 分析器一次读一篇文档然后输出 (term,docID)-对 分析器将这些对又分成j 个词项分区 每个分区按照词项首字母进行划分 E.g., a-f, g-p, q-z (这里 j = 3) * 倒排器(Inverter) 倒排器收集对应某一term分区(e.g., a-f分区)所有的 (term,docID) 对 (即倒排记录表) 排序并写进倒排记录表 * 数据流 * MapReduce 刚才介绍的索引构建过程实际上是MapReduce的一个实例 MapReduce是一个鲁棒的简单分布式计算框架. . . . . .不一定需要在分布式处理的部分编写代码 Google索引构建系统 (ca. 2002) 由多个步骤组成,每个步骤都采用 MapReduce实现 索引构建只是一个步骤 另一个步骤:将按词项分割索引转换成按文档分割的索引 * 基于MapReduce的索引构建 * 课堂练习 主节点机传给分析器的任务描述包含什么信息? 任务完成后,分析器给主节点机的回传报告中会包含哪些信息? 主节点机传给倒排器的任务描述包含什么信息? 任务完成后,倒排器给主节点机的回传报告中会包含哪些信息? 提纲 上一讲回顾 简介 BSBI算法 SPIMI算法 分布式索引构建 动态索引构建 * 动态索引构建 到目前为止,我们都假定文档集是静态的。 实际中假设很少成立:文档会增加、删除和修改。 这也意味着词典和倒排记录表必须要动态更新。 * 动态索引构建: 最简单的方法 在磁盘上维护一个大的主索引(Main index) 新文档放入内存中较小的辅助索引(Auxiliary index)中 同时搜索两个索引,然后合并结果 定期将辅助索引合并到主索引中 删除的处理: 采用无效位向量(Invalidation bit-vector)来表示删除的文档 利用该维向量过滤返回的结果,以去掉已删除文档 * 主辅索引合并中的问题 合并过于频繁 合并时如果正好在搜索,那么搜索的性能将很低 实际上: 如果每个倒排记录表都采用一个单独的文件来存储的话,那么将辅助索引合并到主索引的代价并没有那么高 此时合并等同于一个简单的添加操作 但是这样做将需要大量的文件,效率显然不高 如果没有特别说明,本讲后面都假定索引是一个大文件 现实当中常常介于上述两者之间(例如:将大的倒排记录表分割成多个独立的文件,将多个小倒排记录表存放在一个文件当中……) * 对数合并(Logarithmic merge) 对数合并算法能够缓解(随时间增长)索引合并的开销 → 用户并不感觉到响应时间上有明显延迟 维护一系列索引,其中每个索引是前一个索引的两倍大小 将最小的索引 (Z0) 置于内存 其他更大的索引 (I0, I1, . . . ) 置于磁盘 如果 Z0 变得太大 ( n), 则将它作为 I0 写到磁盘中(如果 I0 不存在) 或者和 I0 合并

文档评论(0)

qiwqpu54 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档