“搜索”的原理,架构,实现,实践,面试不用再怕了(值得收藏)!!!
作者:CQITer小编 时间:2019-04-01 09:41
可能99%的同学不做搜索引擎,但99%的同学一定实现过检索功能。搜索,检索,这里面到底包含哪些技术的东西,希望本文能够给大家一些启示。
全网搜索引擎架构与流程如何?

全网搜索引擎的宏观架构如上图,核心子系统主要分为三部分(粉色部分):
(1)spider爬虫系统;
(2)search&index建立索引与查询索引系统,这个系统又主要分为两部分:
一部分用于生成索引数据build_index
一部分用于查询索引数据search_index
(3)rank打分排序系统;
核心数据主要分为两部分(紫色部分):
web网页库;
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对初筛的结果进行打分排序;
站内搜索引擎架构与流程如何?
做全网搜索的公司毕竟是少数,绝大部分公司要实现的其实只是一个站内搜索,以58同城100亿帖子的搜索为例,其整体架构如下:

站内搜索引擎的宏观架构如上图,与全网搜索引擎的宏观架构相比,差异只有写入的地方:
全网搜索需要spider要被动去抓取数据;
站内搜索是内部系统生成的数据,例如“发布系统”会将生成的帖子主动推给build_data系统;
画外音:看似“很小”的差异,架构实现上难度却差很多,全网搜索如何“实时”发现“全量”的网页是非常困难的,而站内搜索容易实时得到全部数据。
对于spider、search&index、rank三个系统:
spider和search&index是相对工程的系统;
rank是和业务、策略紧密、算法相关的系统,搜索体验的差异主要在此,而业务、策略的优化是需要时间积累的,这里的启示是:
Google的体验比Baidu好,根本在于前者rank牛逼
国内互联网公司(例如360)短时间要搞一个体验超越Baidu的搜索引擎,是很难的,真心需要时间的积累
前面的内容太宏观,为了照顾大部分没有做过搜索引擎的同学,数据结构与算法部分从正排索引、倒排索引一点点开始。
什么是正排索引(forward index)?
简言之,由key查询实体的过程,使用正排索引。
例如,用户表:
t_user(uid, name, passwd, age, sex)
由uid查询整行的过程,就时正排索引查询。
又例如,网页库:
t_web_page(url, page_content)
由url查询整个网页的过程,也是正排索引查询。
网页内容分词后,page_content会对应一个分词后的集合list。
简易的,正排索引可以理解为:
Map<url, list<item>>
能够由网页url快速找到内容的一个数据结构。
画外音:时间复杂度可以认为是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>就是倒排索引。
画外音:明白了吧,词到url的过程,是倒排索引。




