导语 | 随着用户邮件数量越来越多，邮件搜寻已是邮箱的基本功能。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 style="display:none;">：http://wx.mail.qq.com/ftn/download?func=3&k=c7991f38b1d109adf4ea5216042ca62df1e0f2a0b6a2ba26e6a261631539efd62535&key=c7991f38b1d109adf4ea4d38603464390ec0623866a2ba26e6a261631539efd62535&code=8fc8b4d9</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 匹配。有两种实现计划：
- 将搜寻关键字做个预处理，从 al0927 变为 al 空格 0927；
- 寻找一个新的分词器，使得 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分词器做革新，或更换别的分词器。