深入浅出搜索架构引擎、方案与细节(上)
主要内容如下,本篇(上)会重点介绍:
(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:将离线的数据合并到高一级别的索引中去
小时库,一小时一次,合并到天库中去;
天库,一天一次,合并到全量库中去;
这样就保证了小时库和天库的数据量都不会特别大;
如果数据量和并发量更大,还能增加星期库,月库来缓冲。