深入浅出搜索架构引擎、方案与细节

深入浅出搜索架构引擎、方案与细节（上）

主要内容如下，本篇（上）会重点介绍：

（1）全网搜索引擎架构与流程

（2）站内搜索引擎架构与流程

（3）搜索原理、流程与核心数据结构

一、全网搜索引擎架构与流程

全网搜索的宏观架构长啥样？

全网搜索的宏观流程是怎么样的？

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

（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

（a）search_index获得用户的搜索词，完成分词

（b）search_index查询倒排索引，获得“字符匹配”网页，这是初筛的结果

（c）rank对初筛的结果进行打分排序

（d）rank对排序后的第一页结果返回

二、站内搜索引擎架构与流程

站内搜索系统架构长啥样？站内搜索流程是怎么样的？

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

（1）全网搜索需要spider要被动去抓取数据

（2）站内搜索是内部系统生成的数据，例如“发布系统”会将生成的帖子主动推给build_data系统

 

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

 

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

（1）spider和search&index是相对工程的系统

（2）rank是和业务、策略紧密、算法相关的系统，搜索体验的差异主要在此，而业务、策略的优化是需要时间积累的，这里的启示是：

a）Google的体验比Baidu好，根本在于前者rank牛逼

b）国内互联网公司（例如360）短时间要搞一个体验超越Baidu的搜索引擎，是很难的，真心需要时间的积累

三、搜索原理与核心数据结构

提问：什么是正排索引（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)）找到内容的一个数据结构。

 

提问：什么是倒排索引（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>>就是倒排索引。

（1）正排索引（forward index）是由网页url_id快速找到分词后网页内容list<item>的过程

（2）倒排索引（inverted index）是由分词item快速寻找包含这个分词的网页list<url_id>的过程

（3）用户检索的过程，是先分词，再找到每个item对应的list<url_id>，最后进行集合求交集的过程

（4）有序集合求交集的方法有

         a）二重for循环法，时间复杂度O(n*n)

         b）拉链法，时间复杂度O(n)

         c）水平分桶，多线程并行

         d）bitmap，大大提高运算并行度，时间复杂度O(n)

         e）跳表，时间复杂度为O(log(n))

深入浅出搜索架构引擎、方案与细节（中）

本章重点介绍：

（1）流量数据量由小到大，常见搜索方案与架构变迁

（2）数据量、并发量、扩展性方案

一、检索需求的满足与架构演进

原始阶段-LIKE

数据在数据库中可能是这么存储的：

t_tiezi(tid, title, content)

满足标题、内容的检索需求可以通过LIKE实现：

select tid from t_tiezi where content like ‘%天通苑%’

能够快速满足业务需求，存在的问题也显而易见：

（1）效率低，每次需要全表扫描，计算量大，并发高时cpu容易100%

（2）不支持分词

初级阶段-全文索引

如何快速提高效率，支持分词，并对原有系统架构影响尽可能小呢，第一时间想到的是建立全文索引：

alter table t_tiezi add fulltext(title,content)

使用match和against实现索引字段上的查询需求。

全文索引能够快速实现业务上分词的需求，并且快速提升性能（分词后倒排，至少不要全表扫描了），但也存在一些问题：

（1）只适用于MyISAM

（2）由于全文索引利用的是数据库特性，搜索需求和普通CURD需求耦合在数据库中：检索需求并发大时，可能影响CURD的请求；CURD并发大时，检索会非常的慢；

（3）数据量达到百万级别，性能还是会显著降低，查询返回时间很长，业务难以接受

（4）比较难水平扩展

中级阶段-开源外置索引

为了解决全文索的局限性，当数据量增加到大几百万，千万级别时，就要考虑外置索引了。外置索引的核心思路是：索引数据与原始数据分离，前者满足搜索需求，后者满足CURD需求，通过一定的机制（双写，通知，定期重建）来保证数据的一致性。

原始数据可以继续使用Mysql来存储，外置索引如何实施？Solr，Lucene，ES都是常见的开源方案。

楼主强烈推荐ES（ElasticSearch），原因是Lucene虽好，但始终有一些不足：

（1）Lucene只是一个库，潜台词是，需要自己做服务，自己实现高可用/可扩展/负载均衡等复杂特性

（2）Lucene只支持Java，如果要支持其他语言，还是得自己做服务

（3）Lucene不友好，这是很致命的，非常复杂，使用者往往需要深入了解搜索的知识来理解它的工作原理，为了屏蔽其复杂性，一个办法是自己做服务

…

为了改善Lucene的各项不足，解决方案都是“封装一个接口友好的服务，屏蔽底层复杂性”，于是有了ES：

（1）ES是一个以Lucene为内核来实现搜索功能，提供REStful接口的服务

（2）ES能够支持很大数据量的信息存储，支持很高并发的搜索请求

（3）ES支持集群，向使用者屏蔽高可用/可扩展/负载均衡等复杂特性

高级阶段-自研搜索引擎

当数据量进一步增加，达到10亿、100亿数据量；并发量也进一步增加，达到每秒10万吞吐；业务个性也逐步增加的时候，就需要自研搜索引擎了，定制化实现搜索内核了。

二、、数据量、并发量、扩展性方案

到了定制化自研搜索引擎的阶段，超大数据量、超高并发量为设计重点，为了达到“无限容量、无限并发”的需求，架构设计需要重点考虑“扩展性”，力争做到：增加机器就能扩容（数据量+并发量）。

58同城的自研搜索引擎E-search初步架构图如下：

（1）上层proxy（粉色）是接入集群，为对外门户，接受搜索请求，其无状态性能够保证增加机器就能扩充proxy集群性能

（2）中层merger（浅蓝色）是逻辑集群，主要用于实现搜索合并，以及打分排序，业务相关的rank就在这一层实现，其无状态性也能够保证增加机器就能扩充merger集群性能

（3）底层searcher（暗红色大框）是检索集群，服务和索引数据部署在同一台机器上，服务启动时可以加载索引数据到内存，请求访问时从内存中load数据，访问速度很快

（3.1）为了满足数据容量的扩展性，索引数据进行了水平切分，增加切分份数，就能够无限扩展性能，如上图searcher分为了4组

（3.2）为了满足一份数据的性能扩展性，同一份数据进行了冗余，理论上做到增加机器就无限扩展性能，如上图每组searcher又冗余了2份

如此设计，真正做到做到增加机器就能承载更多的数据量，响应更高的并发量

深入浅出搜索架构（下篇）

大数据量、高并发量情况下的搜索引擎为了保证实时性，架构设计上的两个要点：

（1）索引分级

（2）dump&merge

既然索引数据不能实时修改，如何保证最新的网页能够被索引到呢？

索引分为 全量库、日增量库、小时增量库。

如下图所述：

（1）300亿数据在全量索引库中

（2）1000万1天内修改过的数据在天库中

（3）50万1小时内修改过的数据在小时库中

当有修改请求发生时，只会操作最低级别的索引，例如小时库。

当有查询请求发生时，会同时查询各个级别的索引，将结果合并，得到最新的数据：

（1）全量库是紧密存储的索引，无碎片，速度快

（2）天库是紧密存储，速度快

（3）小时库数据量小，速度也快

数据的写入和读取都是实时的，所以58同城能够检索到1秒钟之前发布的帖子，即使全量库有300亿的数据。

新的问题来了：小时库数据何时反映到天库中，天库中的数据何时反映到全量库中呢？

dump&merge

这是由两个异步的工具完成的：

dumper：将在线的数据导出

merger：将离线的数据合并到高一级别的索引中去

小时库，一小时一次，合并到天库中去；

天库，一天一次，合并到全量库中去；

这样就保证了小时库和天库的数据量都不会特别大；

如果数据量和并发量更大，还能增加星期库，月库来缓冲。