倒排索引-搜索引擎的基石

短命女 2022-01-10 09:29 266阅读 0赞

##     ##

## 本文转自：[http://blog.csdn.net/hguisu/article/details/7969757][http_blog.csdn.net_hguisu_article_details_7969757] ##

## 1.概述 ##

**      **在关系数据库系统里，索引是检索数据最有效率的方式,。但对于搜索引起，他它并不能满足其特殊要求：

1）海量数据：搜索引擎面对的是海量数据，像Google，百度这样大型的商业搜索引擎索引都是亿级甚至几千的网页数量 ，面对如此海量数据 ,使得数据库系统很难有效的管理。

2）数据操作简单：搜索引擎使用的数据操作简单 ,一般而言 ,只需要增、 删、 改、 查几个功能 ,而且数据都有特定的格式 ,可以针对这些应用设计出简单高效的应用程序。而一般的数据库系统则支持大而全的功能 ,同时损失了速度和空间。最后 ,搜索引擎面临大量的用户检索需求 ,这要求搜索引擎在检索程序的设计上要分秒必争 ,尽可能的将大运算量的工作在索引建立时完成 ,使检索运算尽量的少。一般的数据库系统很难承受如此大量的用户请求 ,而且在检索响应时间和检索并发度上都不及我们专门设计的索引系统。

## 2.倒排索引 ##

来自维基百科定义：

**       倒排索引（英语：Inverted index）**，也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。  
       倒排索引有两种不同的反向索引形式：  
        一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。  
        一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。  
后者的形式提供了更多的兼容性（比如短语搜索），但是需要更多的时间和空间来创建。  
        现代搜索引起的索引都是基于倒排索引。相比“签名文件”、“后缀树”等索引结构，**“倒排索引”**是实现单词到文档映射关系的最佳实现方式和最有效的索引结构.  
       [倒排索引的简单实例：][Link 1] [搜索引擎-倒排索引基础知识][-]

## 3.倒排列表 ##

倒排列表用来记录有哪些文档包含了某个单词。一般在文档集合里会有很多文档包含某个单词，每个文档会记录文档编号（DocID），单词在这个文档中出现的次数（TF）及单词在文档中哪些位置出现过等信息，这样与一个文档相关的信息被称做倒排索引项（Posting），包含这个单词的一系列倒排索引项形成了列表结构，这就是某个单词对应的倒排列表。图1是倒排列表的示意图，在文档集合中出现过的所有单词及其对应的倒排列表组成了倒排索引。

![1347414141_1861.jpg][]

**图1 倒排列表**

在实际的搜索引擎系统中，并不存储倒排索引项中的实际文档编号，而是代之以文档编号差值（D-Gap）。文档编号差值是倒排列表中相邻的两个倒排索引项文档编号的差值，一般在索引构建过程中，可以保证倒排列表中后面出现的文档编号大于之前出现的文档编号，所以文档编号差值总是大于0的整数。如图2所示的例子中，原始的 3个文档编号分别是187、196和199，通过编号差值计算，在实际存储的时候就转化成了：187、9、3。  
        ![1347414537_7310.jpg][]  
   
                       图2  文档编号差值

之所以要对文档编号进行差值计算，主要原因是为了更好地对数据进行压缩，原始文档编号一般都是大数值，通过差值计算，就有效地将大数值转换为了小数值，而这有助于增加数据的压缩率。

## 4.建立倒排索引 ##

**4.1 简单索引构建**

索引的构建相当于从正排表到倒排表的建立过程。当我们分析完网页时 ,得到的是以网页为主码的索引表。当索引建立完成后 ,应得到倒排表 ,具体流程如图3所示：

![1347434861_4520.jpg][]

图3  索引构建

流程：

1）将文档分析称单词term标记，  
2）使用hash去重单词term  
3）对单词生成倒排列表  
倒排列表就是文档编号DocID，没有包含其他的信息（如词频，单词位置等），这就是简单的索引。  
这个简单索引功能可以用于小数据，例如索引几千个文档。然而它有两点限制：  
1）需要有足够的内存来存储倒排表，对于搜索引擎来说， 都是G级别数据，特别是当规模不断扩大时 ,我们根本不可能提供这么多的内存。  
2）算法是顺序执行，不便于并行处理。

**4.3 合并法建立索引**  
      归并法,即每次将内存中数据写入磁盘时，包括词典在内的所有中间结果信息都被写入磁盘，这样内存所有内容都可以被清空，后续建立索引可以使用全部的定额内存。

如图4 归并示意图：

![1347437846_2463.jpg][]

图4：归并索引

合并流程如图5：

1）页面分析，生成临时倒排数据索引A，B，当临时倒排数据索引A，B占满内存后，将内存索引A，B写入临时文件生成临时倒排文件，  
2)  对生成的多个临时倒排文件 ,执行多路归并 ,输出得到最终的倒排文件 ( inverted file)。

![1347438065_5137.jpg][]

图5 合并流程

索引创建过程中的页面分析 ,特别是中文分词为主要时间开销。算法的第二步相对很快。这样创建算法的优化集中在中文分词效率上。

**4.2 并行与分布式建立索引**

**     在 [搜索引擎-网络爬虫][- 1]**, 已经提到云存储文档，使用Map/Reduce并行计算模型，对文档生成倒排索引列：

对于建立倒排索引这个任务来说，如图6所示，输入数据也是网页，以网页的DOCID作为输入数据 的Key, 网页中出现的单词集合是输入数据的 Value; Map 操作将输入数据转化为 (word，DOCID)的形式，即某个单词作为Key， DOCID作为中间数据的value，其含义是单词 word在DOCID这个网页出现过；Reduce操作将中间数据中相同Key的记录融合，得到某 个单词对应的网页ID列表： <word，List(DodD:pos)>。这就是单词word对应的倒排列表。通过 这种方式就可以建立简单的倒排索引，在Reduce阶段也可以做些复杂操作，获得形式更为复杂的倒排索引。

![1347439889_1153.jpg][]

**图6**

## 5.索引更新策略 ##

更新策略有四种：完全重建、再合并策略、原地更新策略以及混合策略。

1.  **完全重建策略：**当新增文档到达一定数量，将新增文档和原先的老文档整合，然后利用静态索引创建方法对所有文档重建索引，新索引建立完成后老索引会被遗弃。此法代价高，但是目前主流商业搜索引擎一般是采用此方式来维护索引的更新（这句话是书中原话）
2.  再合并策略：当新增文档进入系统，解析文档，之后更新内存中维护的临时索引，文档中出现的每个单词，在其倒排表列表末尾追加倒排表列表项；一旦临时索引将指定内存消耗光，即进行一次索引合并，这里需要倒排文件里的倒排列表存放顺序已经按照索引单词字典顺序由低到高排序，这样直接顺序扫描合并即可。其缺点是：因为要生成新的倒排索引文件，所以对老索引中的很多单词，尽管其在倒排列表并未发生任何变化，也需要将其从老索引中取出来并写入新索引中，这样对磁盘消耗是没必要的。
3.  原地更新策略：试图改进再合并策略，在原地合并倒排表，这需要提前分配一定的空间给未来插入，如果提前分配的空间不够了需要迁移。实际显示，其索引更新的效率比再合并策略要低。
4.  混合策略：出发点是能够结合不同索引更新策略的长处，将不同索引更新策略混合，以形成更高效的方法。

参考文献：

《这就是搜索引擎:核心技术详解》

《搜索引擎—信息检索实践》

[http_blog.csdn.net_hguisu_article_details_7969757]: http://blog.csdn.net/hguisu/article/details/7969757
[Link 1]: http://blog.csdn.net/hguisu/article/details/7962350#t2
[-]: http://blog.csdn.net/hguisu/article/details/7962350
[1347414141_1861.jpg]: https://img-my.csdn.net/uploads/201209/12/1347414141_1861.jpg
[1347414537_7310.jpg]: https://img-my.csdn.net/uploads/201209/12/1347414537_7310.jpg
[1347434861_4520.jpg]: https://img-my.csdn.net/uploads/201209/12/1347434861_4520.jpg
[1347437846_2463.jpg]: https://img-my.csdn.net/uploads/201209/12/1347437846_2463.jpg
[1347438065_5137.jpg]: https://img-my.csdn.net/uploads/201209/12/1347438065_5137.jpg
[- 1]: http://blog.csdn.net/hguisu/article/details/7949844
[1347439889_1153.jpg]: https://img-my.csdn.net/uploads/201209/12/1347439889_1153.jpg