搜索系统—搜索引擎的原理，架构与细节

缺乏、安全感 2021-09-16 07:52 682阅读 0赞

### **1、全网搜索引擎架构与流程** ###

![这里写图片描述][SouthEast]

全网搜索引擎的宏观架构如上图，**核心系统**主要分为三部分（粉色部分）：

1.  spider爬虫系统；
2.  search&index建立索引与查询索引系统，这个系统又主要分为两部分：
    
     *  一部分用于生成索引数据build\_index；
     *  一部分用于查询索引数据search\_index。   
         
3.  rank打分排序系统。

**核心数据**主要分为两部分（紫色部分）：

1.  web网页库；
2.  index索引数据。

**全网搜索引擎的业务特点决定了，这是一个“写入”和“检索”完全分离的系统：**

**【写入】**   
**系统组成**：由spider与search&index两个系统完成   
**输入**：站长们生成的互联网网页   
**输出**：正排倒排索引数据

**流程**：如架构图中的1，2，3，4

1.  spider把互联网网页抓过来；
2.  spider把互联网网页存储到网页库中（这个对存储的要求很高，要存储几乎整个“万维网”的镜像）；
3.  build\_index从网页库中读取数据，完成分词；
4.  build\_index生成倒排索引。

**【检索】**   
**系统组成**：由search&index与rank两个系统完成   
**输入**：用户的搜索词   
**输出**：排好序的第一页检索结果

**流程**：如架构图中的a，b，c，d

1.  search\_index获得用户的搜索词，完成分词；
2.  search\_index查询倒排索引，获得“字符匹配”网页，这是初筛的结果；
3.  rank对初筛的结果进行打分排序；
4.  rank对排序后的第一页结果返回。

### **2、站内搜索引擎架构与流程** ###

做全网搜索的公司毕竟是少数，绝大部分公司要实现的其实只是一个站内搜索，**站内搜索引擎的宏观架构和全网搜索引擎的宏观架构有什么异同？**

以58同城100亿帖子的搜索为例，**站内搜索系统架构长啥样？站内搜索流程是怎么样的？**

![这里写图片描述][SouthEast 1]

站内搜索引擎的宏观架构如上图，与全网搜索引擎的宏观架构相比，差异只有写入的地方：

1.  全网搜索需要spider要被动去抓取数据；
2.  站内搜索是内部系统生成的数据，例如“发布系统”会将生成的帖子主动推给build\_data系统。

看似“很小”的差异，架构实现上难度却差很多：全网搜索如何“实时”发现“全量”的网页是非常困难的，而站内搜索容易实时得到全部数据。

对于spider、search&index、rank三个系统：

1.  spider和search&index是相对独立的系统；
2.  rank是和业务、策略紧密、算法相关的系统，搜索体验的差异主要在此，而业务、策略的优化是需要时间积累的，这里的启示是：
    
     *  Google的体验比Baidu好，根本在于前者rank牛逼；
     *  国内互联网公司（例如360）短时间要搞一个体验超越Baidu的搜索引擎，是很难的，真心需要时间的积累。

### **3、搜索原理与核心数据结构** ###

**3.1、什么是正排索引（forward index）?**

由key查询实体的过程，是正排索引。

用户表：t\_user(uid, name, passwd, age, sex)，由uid查询整行的过程，就是正排索引查询。   
网页库：t\_web\_page(url, page\_content)，由url查询整个网页的过程，也是正排索引查询。

网页内容分词后，page\_content会对应一个**分词后的集合list<item>**。   
简易的，**正排索引可以理解为Map<url, list<item>>，能够由网页快速（时间复杂度O(1)）找到内容的一个数据结构。**

**3.2、什么是倒排索引（inverted index）？**

由item查询key的过程，是倒排索引。

对于网页搜索，倒排索引可以理解为Map<item, list<url>>，能够由查询词快速（时间复杂度O(1)）找到包含这个查询词的网页的数据结构。

--------------------

举个例子，假设有3个网页：

*  url1 -> “我爱北京”
 *  url2 -> “我爱到家”
 *  url3 -> “到家美好”

这是一个正排索引Map<url, page\_content>。

分词之后：

*  url1 -> \{我，爱，北京\}
 *  url2 -> \{我，爱，到家\}
 *  url3 -> \{到家，美好\}

这是一个分词后的正排索引Map<url, list<item>>。

分词后倒排索引：

*  我 -> \{url1, url2\}
 *  爱 -> \{url1, url2\}
 *  北京 -> \{url1\}
 *  到家 -> \{url2, url3\}
 *  美好 -> \{url3\}

**由检索词item快速找到包含这个查询词的网页Map<item, list<url>>就是倒排索引。**

--------------------

正排索引和倒排索引是spider和build\_index系统提前建立好的数据结构，**为什么要使用这两种数据结构，是因为它能够快速的实现“用户网页检索”需求（业务需求决定架构实现）。**

### **3.3、搜索的过程是什么样的？** ###

假设搜索词是“我爱”，用户会得到什么网页呢？

1.  分词，“我爱”会分词为\{我，爱\}，时间复杂度为O(1)；
2.  每个分词后的item，从倒排索引查询包含这个item的网页list<url>，时间复杂度也是O(1)：
    
     *  我 -> \{url1, url2\}
     *  爱 -> \{url1, url2\}
3.  求list<url>的交集，就是符合所有查询词的结果网页，对于这个例子，\{url1, url2\}就是最终的查询结果.

看似到这里就结束了，其实不然，分词和倒排查询时间复杂度都是O(1)，**整个搜索的时间复杂度取决于“求list<url>的交集”**，问题转化为了求两个集合交集。

字符型的url不利于存储与计算，**一般来说每个url会有一个数值型的url\_id来标识**，后文为了方便描述，list<url>统一用list<url\_id>替代。

### **4、list1和list2，求交集怎么求？** ###

**4.1、方案一：for \* for，土办法，时间复杂度O(n\*n)**

每个搜索词命中的网页是很多的，O(n\*n)的复杂度是明显不能接受的。倒排索引是在创建之初可以进行排序预处理，问题转化成**两个有序的list求交集**，就方便多了。

**4.2、方案二：有序list求交集，拉链法**

![这里写图片描述][SouthEast 2]

有序集合1\{1,3,5,7,8,9\}   
有序集合2\{2,3,4,5,6,7\}

两个指针指向首元素，比较元素的大小：

1.  如果相同，放入结果集，随意移动一个指针；
2.  否则，移动值较小的一个指针，直到队尾。

这种方法的好处是：

1.  集合中的元素最多被比较一次，时间复杂度为O(n)；
2.  多个有序集合可以同时进行，这适用于多个分词的item求url\_id交集。

这个方法就像一条拉链的两边齿轮，一一比对就像拉链，故称为拉链法。

**4.3、方案三：分桶并行优化**

数据量大时，**url\_id分桶水平切分+并行运算是一种常见的优化方法**，如果能将list1<url\_id>和list2<url\_id>**分成若干个桶区间，每个区间利用多线程并行求交集**，各个**线程结果集的并集，作为最终的结果集**，能够大大的减少执行时间。

--------------------

举例：

*  有序集合1\{1,3,5,7,8,9, 10,30,50,70,80,90\}
 *  有序集合2\{2,3,4,5,6,7, 20,30,40,50,60,70\}

求交集，先进行分桶拆分：

*  桶1的范围为\[1, 9\]
 *  桶2的范围为\[10, 100\]
 *  桶3的范围为\[101, max\_int\]

于是：

1.  集合1就拆分成
    
     *  集合a\{1,3,5,7,8,9\}
     *  集合b\{10,30,50,70,80,90\}
     *  集合c\{\}
2.  集合2就拆分成
    
     *  集合d\{2,3,4,5,6,7\}
     *  集合e\{20,30,40,50,60,70\}
     *  集合e\{\}

每个桶内的数据量大大降低了，并且每个桶内没有重复元素，可以利用多线程并行计算：

*  桶1内的集合a和集合d的交集是x\{3,5,7\}
 *  桶2内的集合b和集合e的交集是y\{30, 50, 70\}
 *  桶3内的集合c和集合d的交集是z\{\}

最终，集合1和集合2的交集，是x与y与z的并集，即集合\{3,5,7,30,50,70\}

--------------------

**4.4、方案四：bitmap再次优化**

数据进行了水平分桶拆分之后，**每个桶内的数据一定处于一个范围之内**，如果集合符合这个特点，**就可以使用bitmap来表示集合**：

![这里写图片描述][SouthEast 3]

如上图，假设set1\{1,3,5,7,8,9\}和set2\{2,3,4,5,6,7\}的**所有元素都在桶值\[1, 16\]的范围之内，可以用16个bit来描述这两个集合**，原集合中的元素x，在这个16bitmap中的第x个bit为1，此时两个bitmap求交集，只需要将两个bitmap进行“与”操作，结果集bitmap的3，5，7位是1，表明原集合的交集为\{3,5,7\}

水平分桶，bitmap优化之后，能极大提高求交集的效率，但时间复杂度仍旧是O(n)   
bitmap需要大量连续空间，占用内存较大。

**4.5、方案五：跳表skiplist**

有序链表集合求交集，跳表是最常用的数据结构，它可以将有序集合求交集的复杂度由O(n)降至O(log(n))

![这里写图片描述][SouthEast 4]

集合1\{1,2,3,4,20,21,22,23,50,60,70\}   
集合2\{50,70\}

要求交集，如果用拉链法，会发现1,2,3,4,20,21,22,23都要被无效遍历一次，每个元素都要被比对，时间复杂度为O(n)，能不能每次比对“跳过一些元素”呢？

跳表就出现了：

![这里写图片描述][SouthEast 5]

集合1\{1,2,3,4,20,21,22,23,50,60,70\}建立跳表时，一级只有\{1,20,50\}三个元素，二级与普通链表相同   
集合2\{50,70\}由于元素较少，只建立了一级普通链表

如此这般，在实施“拉链”求交集的过程中，**set1的指针能够由1跳到20再跳到50**，中间能够跳过很多元素，无需进行一一比对，跳表求交集的时间复杂度近似O(log(n))，这是搜索引擎中常见的算法。

### **5、总结** ###

文字很多，有宏观，有细节，对于大部分不是专门研究搜索引擎的同学，记住以下几点即可：

1.  全网搜索引擎系统由spider， search&index， rank三个子系统构成；
2.  站内搜索引擎与全网搜索引擎的差异在于，少了一个spider子系统；
3.  spider和search&index系统是两个工程系统，rank系统的优化却需要长时间的调优和积累；
4.  正排索引（forward index）是由网页url\_id快速找到分词后网页内容list<item>的过程；
5.  倒排索引（inverted index）是由分词item快速寻找包含这个分词的网页list<url\_id>的过程；
6.  用户检索的过程，是先分词，再找到每个item对应的list<url\_id>，最后进行集合求交集的过程；
7.  有序集合求交集的方法有
    
     *  二重for循环法，时间复杂度O(n\*n)；
     *  拉链法，时间复杂度O(n)；
     *  水平分桶，多线程并行；
     *  bitmap，大大提高运算并行度，时间复杂度O(n)；
     *  跳表，时间复杂度为O(log(n))。

[SouthEast]: /images/20210720/be2ea3a1e3784375b47f78a6dda7fb87.png
[SouthEast 1]: /images/20210720/4645ae5585d047dca55b59e7b1234822.png
[SouthEast 2]: /images/20210720/b75f02d911254ebfb450f8784e290205.png
[SouthEast 3]: /images/20210720/a71b2888506c4390a0b958b8f612b380.png
[SouthEast 4]: /images/20210720/0e970c9ee3474dc88ccbf918e22c01e0.png
[SouthEast 5]: /images/20210720/a4176798ab94438494008a937aa7945d.png