Press "Enter" to skip to content

重构实践:基于腾讯云Elasticsearch搭建QQ邮箱全文检索

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

​导语 | 随着用户邮件数量越来越多,邮件搜索已是邮箱的基本功能。QQ 邮箱于 2008 年推出的自研搜索引擎面临着存储机器逐渐老化,存储机型面临淘汰的境况。因此,需要搭建一套新的全文检索服务,迁移存储数据。本文将介绍 QQ 邮箱全文检索的架构、实现细节与搜索调优。文章作者:干胜,腾讯后台研发工程师。

 

一、重构背景

 

QQ 邮箱的全文检索服务于2008年开始提供,使用中文分词算法和倒排索引结构实现自研搜索引擎。设计有二级索引,热数据存放于正排索引支持实时检索,冷数据存放于倒排索引支持分词搜索。在使用旧全文检索过程中存在以下问题:

机器老化、磁盘损坏导致丢数据;
业务逻辑复杂,代码庞大晦涩,难以维护;
使用定制化kv存储,已无人维护;
不存储原文,无法实现原生高亮;
未索引超大附件名。

旧的全文检索在使用中长期存在上述问题,恰逢旧的存储机器裁撤,借此机会重构 QQ 邮箱的全文检索后台服务。

 

二、新全文检索架构

 

Elasticsearch 是一个分布式的搜索引擎,支持存储、搜索和数据分析,有良好的扩展性、稳定性和可维护性,在搜索引擎排名中蝉联第一。

 

ES 的底层存储引擎是 Lucene,ES 在 Lucene 的基础上提供分布式集群的能力以确保可靠性、提供 REST API 以确保可用性。

 

Lucene 底层使用倒排索引提供搜索能力,使用 LSM tree 合并处理 Doc 加快索引速度,使用 Translog 持久化数据,实现方式与邮箱旧全文检索相似。

 

为了快速搭建出一套新全文检索后台并完成迁移,QQ 邮箱全文检索的重构选择 Elasticsearch 作为搜索引擎,同时响应自研上云号召,一步到位直接使用腾讯云 ES 构建搜索服务。

 

1. 邮件搜索特点

 

邮箱的发信和收信行为都会触发写全文检索,而搜索行为会触发读全文检索,呈现明显的写多读少。

 

区别于互联网搜索,邮件检索有自己的特点:

 

搜索范围

 

准确度

 

排序

 

互联网搜索

 

整个互联网

 

容忍少量漏搜或多搜

 

按相关度排序

 

邮件检索

 

用户自己的邮箱

 

要求精确结果

 

按时间排序,同时支持按发件人、时间、已读未读进行分类

 

2. 全文检索后台架构

 

邮箱全文检索模块 fullsearch 的整体架构如上图所示,fullsearch 承担的功能是收录用户的邮件、记事等内容并提供查询。fullsearch 模块下游直接对接腾讯云 ES,内网通过 http 请求访问 ES 的 REST API。模块上游的请求分为两类:

 

(1)增、删、改

 

入信、发信、删信等行为会触发更改 ES 内的 doc,入信、发信对实时性要求一般但可靠性要求较高,而删信行为不要求实时性。这类操作都可以异步处理。

 

(2)查

 

搜索行为包括邮件普通搜索、邮件高级搜索,将来还有邮箱内全品类搜索。这类搜索行为要求较高的实时性和准确性,需要同步处理。

 

 

fullsearch 内部设计如下:

使用 HTTP 协议与腾讯云ES通讯,传输 json 格式数据,邮箱后台广泛使用的 protobuf 数据结构能轻松转换为 json 格式;
esproxy 使用 curl 连接池代理邮箱后台与ES的http连接,以提升网络连接速度;
使用 MQ 对增、删、改这类异步请求进行削峰,以保护下游 ES。同时利用 MQ 延时和重试功能,确保请求被成功处理;
对搜索结果进行过滤,避免搜索结果列表出现已删除邮件。在 ES 故障时,提供另一种搜索机制兜底。

三、新全文检索的实现细节

 

利用邮箱后台现有的组件库,如 svrkit rpc 框架、protobuf 数据结构、自研 MQ 等能快速将上述 fullsearch 模块搭建出来,但实现过程中遇到以下几个实际问题。

 

1. 号段索引 or uin索引

 

第一个要解决的是如何分配索引的问题。最初为了实现 ES 内的数据按 uin 进行隔离,每个 uin 建一个索引。

 

随着用户数量上来后,ES 提示分片数量达到上限,不可创建新的索引。这是因为 ES 集群对每个索引都会维护映射和状态信息,索引和分片数量过多会导致占用大量内存。详情可参考_ 文档 。_

 

ES 官方建议将结构相同的数据放入一个索引,既然不能按 uin 建索引,那可不可以建一个索引容纳全量用户的数据呢?答案是否定的,分片数量过多也会对内存有很大的开销。

 

ES 的索引概念相当于 MySql 的表概念,一个索引对应一张表,类似 MySql 可以分表,ES 也可以拆分索引。

 

所以一个折中的方案是(如下图),按 uin 尾号号段(如果号段数据不均匀可以按 uin 哈希)分别建立若干个索引,每个索引内设置少量分片。随着邮件数量上涨,每个索引内的数据量也将上涨,将来可以通过扩展分片数量解决。

 

 

所有搜索操作都带上号段索引,如”428/_search”,可达到相对较快的搜索速度,但无法达到按 uin 建索引的搜索速度,因为搜索速度取决于每个索引内的 doc 数量。有没有办法让号段索引的搜索速度媲美 uin 索引的速度呢?

 

ES 官方提供了一个 索引设置 选项”index.sort”,该选项可以使索引内的 doc 在存储时按照某几个字段的升序或降序进行顺序存储。如果设置 doc 按 uin 顺序存储,在搜索时就能将搜索范围缩小到属于某个 uin 的 doc 存储范围,这将显着提升搜索速度。

 

与此同时会带来一个负面影响,在增、删、改 doc 时,由于要重排 doc 顺序,这些操作的速度将下降 1/3,需要根据业务特点做权衡。

 

值得注意的是,这个选项只能在新建索引的时候开启,开启后不可改变,故需要提前压测来权衡是否开启该选项。

 

2. 邮件正文 to ES字段

 

如果想让邮件内容被索引到,一般会将邮件主题、正文、附件等分别添加到 doc 的一个字段,并将该字段设置为 type:text。邮件正文被放进 ES 的 text 字段之前,需要做一些预处理,来保证将来的检索质量。

 

邮箱全文检索会收录邮件、记事本和在线文档的数据。如下图以邮件正文为例,邮件正文一般是一段 html,如果将 html 收录进 ES 太浪费存储空间,而且会干扰高亮的识别,所以需要 提取邮件正文的纯文本 。

 

同时,邮件的超大附件信息被放在了正文里,如果搜索超大附件名则需要去搜正文而不是搜附件,这不符合用户使用常识。

 

另外,有一些 html 节点内包含大量乱码或 url,属性为 display:none,比如邮箱的超大附件,这些乱码文本也是需要剔除掉的。

 

<span>:http://wx.mail.qq.com/ftn/download?
func=3&k=c7991f38b1d109adf4ea5216042ca62df1e0f2a0b6a2ba26e6a261631539efd62535&key=c7991f38b1d109adf4ea4d38603464390ec0623866a2ba26e6a261631539efd62535&code=8f
c8b4d9</span>

 

要解决上述问题,可以从解析 html 节点入手:

提取纯文本节点并累加,即可过滤所有 html 标签;
识别含有超大附件的节点,并提取超大附件名;
过滤属性为 display:none 的节点。

此时问题就变成寻找一个符合要求的html解析器,把 htmlbody 解析为 dom 树。常见的 xml 解析器有 rapidxml、tinyxml 和 pugixml。

 

笔者选择的是pugixml,优点是速度快、易于使用且支持 xpath,缺点是解析较为严格、遇到不规范的 html 会抛异常。

 

如下图所示,笔者对 pugixml 进行了一番改造,使之增强对 html 的兼容性。在 pugixml 出现异常时,使用速度稍慢些的 ekhtml 解析器作为兜底。

 

 

3. ProtoBuf to Json

 

fullsearch 模块调用腾讯云 ES 的 REST API 使用json数据包进行交互,有大量的打包 json 和解析 json 的操作。而邮箱后台广泛使用的数据结构是 protobuf,这就需要完成 protobuf 到 json 的互相转换。

 

如果手动判断 protobuf/json 是否存在某个字段,再使用 rapidjson 或 jsoncpp 进行解包和封包,则太繁琐且容易出错。

 

 

这里选择直接让 protobuf 字段与 json 字段进行映射,使用 protobuf 自带的工具 MessageToJsonString JsonStringToMessage 进行 protobuf 和 json 的相互转换,使用起来十分方便。

 

 

四、搜索调优

 

1. 调优背景

 

新全文检索搭建上线后测试迁移了一批邮件,收到一些关于搜索结果不精确的反馈:

搜出大量有关邮件,但想找的邮件不在列表第一页;
搜不出邮件;
无法通过订单号精确查找邮件。

初步分析,主要由以下几个原因造成:

模糊搜索结果虽能按相关度排序,但前端显示结果按时间倒序排序,导致相关度高的结果不一定排在第一页;
将模糊搜索替换为精确搜索后,搜索过于严格,导致搜不出邮件;
无法知道用户的意图是精确搜索还是模糊搜索,导致不能用一种搜索模式满足所有用户搜索意图;
订单号一般由字母+数组组成,分词器处理订单号时,由于默认的分词规则,会丢弃单字母或单数字,导致无法精确匹配。

下面首先详细介绍 ES 的搜索机制,然后通过案例分析对 ES 搜索做一定的优化。

 

2. ES搜索机制

 

ES 的全文搜索查询主要分为两种:match 和 match_phrase,它们的搜索机制是:

入信时,ES 分词器先对 doc 中 type:text 字段进行分词,默认记录下每个分词的词频和词语在原文中的位置,存在倒排索引中;
搜索时,对搜索关键字进行分词,根据关键字分词在倒排索引中查到每个分词的 docid 列表。如果 match(operator=or),则停止搜索并返回 docid 列表;
对第二步每个分词的 docid 列表求交集得到新的 docid 列表,使得列表中每个 docid 都出现所有分词。如果是 match 搜索,则停止搜索并返回 docid 列表;
比较第三步每个 docid 中所有分词的相对位置,是否与第一步中原文分词的相对位置相同,过滤掉相对位置不同的 docid,结束搜索。这一步是 match_phrase 才有的,且会小幅增加搜索耗时。

 

来看一个例子,搜索关键字”银行账单”,ik_smart 分词列表为[“银行”, “账单”]。

match_phrase 搜索最严格,要求”银行”、“账单”同时出现且相邻,只能匹配一篇文章;
match(operator=or) 只要求出现”银行”、“账单”即可,能匹配所有文章;
match(operator=and) 要求同时出现”银行”、“账单”,但对词语间隔不做要求,匹配数量介于两者之间,搜索结果精度优于 match(operator=or)。

3. 两级搜索

 

fullsearch 模块使用 match_phrase 处理精确搜索,使用 match(operator=and) 处理模糊搜索。

 

为了最大化满足不同用户对精确搜索和模糊搜索的需求,先用 match_phrase 精确搜索,搜不到内容再用 match 模糊搜索。

 

统计显示精确搜索搜到内容占搜索请求的比例达到 90%,且模糊搜索的耗时远小于精确搜索,两次搜索不会增加太多等待时间。

 

模糊搜索可能搜到大量结果,按时间倒序后,相关度高的结果可能排在后面,造成不好的搜索体验。这里可以对模糊搜索的结果进行剪枝,去除低评分的结果,使得相关度高的结果适当靠前。

 

另外,可通过调整不同字段的权值(boost)来调整搜索评分。按照多数用户的搜索习惯,适当调高主题搜索权重。

 

未来,邮箱还将在搜索框集成查询语法,让用户自定义搜索条件(and、or、not)。

 

4. 调整match_phrase

 

使用 Kibana 的调试工具可以很方便地获取一段文字被分词器处理后的 token 列表,如下图,token 列表中每个 token 都是一个分词。在上文 ES 搜索机制中提到,match_phrase 会确保搜索关键字 token 列表中的词语、词语间隔和词语顺序,与原文分词后的 token 列表相同。

 

(1)测试案例

 

下面来看一个案例,原文是“一品城府7-1-501”,搜索关键字“一品城府501”无法精确搜索。

 

(2)分析原因

 

如下图,搜索关键字分词 token 列表中的词语、词语顺序与原文相同,但词语间隔不对,则 match_phrase 失败。

 

 

(3)解决思路

 

match_phrase 有个参数 slop,设置 slop 值能容忍一定的 token 列表词语间隔。在4.2节第四步分词匹配时会不断变换分词位置,可以只过滤掉词语间隔超过 slop 的 docid。

 

这个案例中,match_phrase.slop 值设为 4 可解决问题。但设置 slop 值将增大匹配工作量,如果 slop 过大将严重拖慢搜索速度,一般 slop 设置为 5 以内。

 

5. 改造分词器

 

(1)测试案例

 

测试时,有一类反馈比较集中,搜索字母+数字(如订单号)搜不出结果。看一个案例,原文是“AL0927_618”,搜索关键字“AL0927”,无论使用精确搜索还是模糊搜索都搜不出内容。

 

(2)分析原因

 

因为关键字的“tokenal0927”不在原文 token 列表中,不满足 4.2 节搜索机制中第三步匹配条件。这个问题其实是分词器的缺陷,ik 分词的 github 上有人提过类似 案例 ,但无人回应。

 

 

(3)解决思路

 

对比上图中原文和关键字 token 列表,如果搜索时关键字分词 token 列表中不出现关键字本身(al0927),就能成功实现 match_phrase 匹配。有两种实现方案:

 

 

    1. 将搜索关键字做个预处理,从 al0927 变为 al 空格 0927;

 

    1. 寻找一个新的分词器,使得 al0927 的分词列表只含有 al、0927。

 

 

观察上图 ik_max_word 分词器处理后的 token 列表,token 列表中类型为 LETTER 的 token 就是关键字本身,是不是过滤 LETTER 类型 token 就能解决问题?

 

在测试验证后,笔者选择第二种方案,基于 ik 分词器进行改造,过滤 token 列表中类型为 LETTER 类型的 token,新分词器命名为 xm_ik_max_word。

 

 

新分词器的效果如上图所示,这时搜索 AL0927 就能够实现精确匹配。改造后的分词器解决了使用 ik 分词无法对字母+数字关键字精确搜索的问题。

 

6. 使用空格分词器

 

(1)测试案例

 

使用改造后的 xm_ik_max_word 分词器后解决了大部分订单号搜索的问题,但测试中出现一个无法精确搜索的案例,搜索关键字“20X07131A”。

 

(2)分析原因

 

 

使用不同分词器对 20X07131A 处理的分词 token 列表如上表所示,ik_max_word 和 xm_ik_max_word 分词器处理后会丢失末尾 a,因为字母 a 是 ES 默认的 stop words。

 

如果使用 xm_ik_max_word 分词器精确搜索,可能会匹配上 20X07131A、20X07131AB、20X07131B 等,出现很多无关结果。

 

(3)解决思路

 

由于原文被 index 到 ES 时使用的是 ik_max_word ,保留了 LETTER 类型 token,对于订单类型搜索则可以让搜索关键字分词后只剩下 LETTER 类型 token。

 

笔者使用的是 whitespace 分词器,让用户来决定分词方式。whitespace 会对搜索关键字按空格分词,并自动完成小写转换和特殊字符处理。如上表,whitespace 分词器的 token 列表能精确匹配上 20X07131A 所在的原文。

 

五、结语

 

借助腾讯云ES作为搜索平台,可以很快完成一套全文检索服务的搭建。腾讯云ES作为Paas,可以方便地进行扩缩容与维护。

 

随着ES版本迭代,ES支持越来越多的功能配置,需要根据业务特点来决定索引阶段与搜索阶段使用的配置。

 

邮箱的全文检索业务在切换到腾讯云ES后,平稳地完成了后台搜索平台的迁移,并解决了旧全文检索存在的问题。

 

ES内置的ik分词器无法满足某些业务使用需求时,可以对ik分词器做改造,或更换别的分词器。

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注