lecture1布尔检索.pptVIP

更大的文档集 假定N = 1 百万篇文档(1M), 每篇有1000个词(1K) 假定每个词平均有6个字节(包括空格和标点符号) 那么所有文档将约占6GB 空间. 假定 词汇表的大小(即词项个数) M = 500K * 词项-文档矩阵将非常大 矩阵大小为 500K x 1M=500G 但是该矩阵中最多有10亿(1G)个1 词项-文档矩阵高度稀疏(sparse). 稀疏矩阵 应该有更好的表示方式 比如我们仅仅记录所有1的位置 * Why? 倒排索引(Inverted index) 对每个词项t, 记录所有包含t的文档列表. 每篇文档用一个唯一的 docID来表示，通常是正整数，如1,2,3… 能否采用定长数组的方式来存储docID列表 * Brutus Calpurnia Caesar 1 2 4 5 6 16 57 132 1 2 4 11 31 45 173 2 31 文档14中加入单词Caesar时该如何处理? 174 54 101 倒排索引(续) 通常采用变长表方式 磁盘上，顺序存储方式比较好，便于快速读取 内存中，采用链表或者可变长数组方式 存储空间/易插入之间需要平衡 * Dictionary Postings 按docID排序 (原因后面再讲) Posting Brutus Calpurnia Caesar 1 2 4 5 6 16 57 132 1 2 4 11 31 45 173 2 31 174 54 101 词典 倒排(记录)表 倒排记录 Tokenizer 词条流 Friends Romans Countrymen 倒排索引构建 Linguistic modules 修改后的词条 friend roman countryman Indexer 倒排索引 friend roman countryman 2 4 2 13 16 1 待索引文档 Friends, Romans, countrymen. 词条化工具 语言分析工具 索引构建过程: 词条序列 词条，docID二元组 I did enact Julius Caesar I was killed i the Capitol; Brutus killed me. Doc 1 So let it be with Caesar. The noble Brutus hath told you Caesar was ambitious Doc 2 索引构建过程: 排序 按词项排序 然后每个词项按docID排序 索引构建的核心步骤 索引构建过程: 词典 倒排记录表 某个词项在单篇文档中的多次出现会被合并 拆分成词典和倒排记录表两部分 每个词项出现的文档数目(doc. frequency, DF)会被加入 为什么加入？后面会讲 存储开销计算 * 指针 词项及文档频率 后续章节: 如何快速构建索引? 如何减少存储开销? 倒排索引 docID表 提纲 信息检索概述 倒排索引 布尔查询的处理 * 假定索引已经构建好 如何利用该索引来处理查询? 后面会讲 – 如何处理不同类型的查询? 比如带通配符的查询 “信息*检索” * 今天主要内容 AND查询的处理 考虑如下查询（从简单的布尔表达式入手）: Brutus AND Caesar 在词典中定位 Brutus 返回对应倒排记录表(对应的docID) 在词典中定位Caesar 再返回对应倒排记录表 合并(Merge)两个倒排记录表，即求交集 * 128 34 2 4 8 16 32 64 1 2 3 5 8 13 21 Brutus Caesar 合并过程 每个倒排记录表都有一个定位指针，两个指针同时从前往后扫描, 每次比较当前指针对应倒排记录，然后移动某个或两个指针。合并时间为两个表长之和的线性时间 * 34 128 2 4 8 16 32 64 1 2 3 5 8 13 21 128 34 2 4 8 16 32 64 1 2 3 5 8 13 21 Brutus Caesar 2 8 假定表长分别为x 和y, 那么上述合并算法的复杂度为 O(x+y) 关键原因: 倒排记录表按照docID排序 上述合并算法的伪代码描述 * 其它布尔查询的处理 OR表达式：Brutus OR Caesar 两个倒排记录表的并集 NOT表达式： Brutus AND NOT Caesar 两个倒排记录表的减 一般的布尔表达式 (Brutus OR Caesar) AND NOT (Antony OR Cleopatra) 查询处理的效率问题！ * 查询优化 查询处理中是否存在处理的顺序问题？ 考虑n 个词项的 AND 对每个词项，取出其倒排记录表，然后两两合并 Brutus Caesar Calpurnia 1 2 3