亿级ES数据搜索性能调优实践 _数据

1
背景
2020年以来内容标注结果搜索就是社区中后台业务的核心高频使用场景之一，为了支撑复杂的后台搜索，我们将社区内容的关键信息额外存了一份到Elasticsearch中作为二级索引使用。随着标注业务的细分、迭代和时间的推移，这个索引的文档数和搜索的RT开始逐步上升。
下面是这个索引当前的监控情况。

文章插图
本文介绍社区利用IndexSorting，将亿级文档搜索性能由最开始2000ms优化到50ms的过程。如果大家遇到相似的问题和场景，相信看完之后一定能够一行代码成吨收益。
2
探索过程
2.1 初步优化
最开始需求很简单，只需要取最新发布的动态分页展示。这时候实现也是简单粗暴，满足功能即可。查询语句如下：
GET /content-alias/_search { "track_total_hits": true, "sort": [ { "publish_time": { "order": "desc" } } ], "size": 10 }由于首页加载时没加任何筛选条件，于是变成了从亿级内容库中找出最新发布的10条内容。
针对这个查询很容易发现问题出现在大结果集的排序，要解决问题，自然的想到了两条路径：

去掉sort
缩小结果集

经过用户诉求和开发成本的权衡后，当时决定“先扛住，再优化”：在用户打开首页的时候，默认增加“发布时间在最近一周内”的筛选条件，这时语句变成了：
GET /content-alias/_search { "track_total_hits": true, "query": { "bool": { "filter": [ { "range": { "publish_time": { "gte": 1678550400, "lt": 1679155200 } } } ] } }, "sort": [ { "publish_time": { "order": "desc" } } ], "size": 10 }这个改动上线后，效果可以说是立竿见影，首页加载速度立马降到了200ms以内，平均RT60ms 。这次改动也为我们减小了来自业务的压力，为后续的优化争取了不少调研的时间。
虽然搜索首页的加载速度明显快了，但是并没有实际解决根本问题—— ES大结果集指定字段排序还是很慢。对业务来说，结果页上的一些边界功能的体验依旧不能尽如人意，比如导出、全量动态的搜索等等。这一点从监控上也能够较明显的看出：慢查询还是存在，并且还伴随着少量的接口超时。

文章插图
老实说这个时期我们对于ES的了解还比较基础，只能说会用、知道分片、倒排索引、相关性打分，然后就没有了。总之我们有了方向，开始奋起直追。
2.2 细致打磨2.2.1 知识积累
带着之前遗留的问题，我们开始开始重新出发，从头学习ES 。要优化搜索性能，首先我们要知道的是搜索是怎么做的。下面我们就以一个最简单的搜索为例，拆解一下整个搜索请求的过程。
（1）搜索请求
GET /content-alias/_search { "track_total_hits":false, "query": { "bool": { "filter": [ { "term": { "category_id.keyword": "xxxxxxxx" } } ] } }, "size": 10 }