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

在前面的段落中我们反复提到了docID和正排索引。这里我们顺带简单介绍下他们的关系，首先Segment中的每个文档，都会被分配一个docID，docID从0开始，顺序分配。在没有IndexSorting时，docID是按照文档写入的顺序进行分配的，在设置了IndexSorting之后，docID的顺序就与IndexSorting的顺序一致。
下图描述了docID和正排索引的关系:

文章插图
那么再次回头来看看我们最开始的查询：
GET /content-alias/_search { "track_total_hits":true, "sort": [ { "publish_time": { "order": "desc" } } ], "size": 10 }在Lucene中进行查询时，发现结果集的倒排表顺序刚好是publish_time降序排序的，所以查询到前10条数据之后即可返回，这就做到了提前中断，省下了排序开销。那么代价是什么呢？
（2）代价
IndexSorting和查询时排序不一样，本质是在写入时对数据进行预处理。所以排序字段只能在创建时指定且不可更改。并且由于写入时要对数据进行排序，所以也会对写入性能也会有一定负面影响。
之前我们提到了Lucene本身对排序也有各种优化，所以如果搜索结果集本身没有那么多的数据，那么就算不开启这个功能，也能有不错的RT 。
另外由于多数时候还是要计算总数，所以开启索引排序之后只能提前中断排序过程，还是要对结果集的总数进行count 。如果能够不查总数，或者说通过另外的方式获取总数，那么能够更好的利用这个特性。
小结：

针对大结果集的排序取前N条的场景下，索引排序能显著提高搜索性能。
索引排序只能在创建索引时指定，不可更改。如果你有多个指定字段排序的场景，可能需要慎重选择排序字段。
不获取总数能更好的利用索引排序。
开启索引排序会一定程度降低写性能。这里贴一条ElaticsearchBenchmarks的数据截图供大家参考。

文章插图
见：Elasticsearch Benchmarks
2.3 效果
由于我们的业务远远没有达到ES的写入瓶颈，而且也少有频繁变更排序字段的场景。在经过短暂的权衡之后，确定索引排序正是我们需要的，于是开始使用线上真实数据对索引排序的效果进行简单的性能测试。
（1）性能测试：首页

文章插图
（2）性能测试：其他

这里开启索引排序后，随机几个常规条件和时间窗口的搜索组合测试

文章插图
【亿级ES数据搜索性能调优实践】可以看到效果非常明显，没有以前的那种尖刺，RT也很稳定，于是我们决定正式上线这个功能。
（3）线上效果
慢查询

文章插图
整体前后对比

文章插图
和我们预期的基本一样，搜索RT大幅降低，慢查询完全消失。
2.4 后续优化
在探索过程中，其实还发现了一些其他的优化手段，鉴于开发成本和收益，有些我们并没有完全应用于生产环境。这里列出其中几点，希望能给大家一些启发。

不获取总数: 大部分场景下，不查询总数都能减少开销，提高性能。ES 7.x之后的搜索接口默认不返回总数了，由此可见一斑。
自定义routing规则: 从上文的查询过程我们可以看到，ES会轮询所有分片以获取想要的数据，如果我们能控制数据的分片落点，那么也能节省不少开销。比如说：如果我们将来如果有大量的场景都是查某个用户的动态，那么可以控制按照用户分片，这样就避免了分片轮询，也能提升搜索效率。
keyword: 不是所有的数字都应该按照数值字段来存，如果你的数字值很少用于范围查询，但是经常被用作term查询，并且对搜索rt很敏感。那么keyword才是最适合的存储方式。
数据预处理：就像IndexSoting一样，如果我们能够在写入时预处理好数据，也能节省搜索时的开销。这一点配合 _ingest/pipeline 也许能发挥意想不到的效果。

3
写在最后
相信看到这里的大家都能看出，我们的优化中也没有涉及到十分高深的技术难点，我们只是在解决问题的过程中，逐步从小白转变成了一个初学者。来一个大牛也许从一开始就能直接绕过我们的弯路，不过万里之行始于足下，最后这里总结一点经验和感受分享给大家，希望能给与我们一样的初学者一些参考。