猪猪

在 Elasticsearch 中，查询数据时，每个分片会返回一定数量的文档，然后协调节点将这些结果汇总并排序，最终返回给用户。具体每个分片返回多少条数据，取决于查询的类型和分片的数量。对于聚合查询，Elasticsearch 会在每个分片上执行聚合操作，然后将结果汇总。每个分片返回的数据量取决于聚合的类型和分片上的数据分布。它类似于 SQL 中的。聚合查询的核心思想是：通过对文档进行分组和计算，提取出有价值的信息，而不是仅仅返回原始文档。每个分片会独立执行聚合操作，生成分片级别的聚合结果。

我们通过对线上集群进行分析，发现很多场景堆内内存使用率很高，而磁盘的使用率比较低。堆内存使用率为什么这么高呢？其中的 FST 即倒排索引占据了绝大部分堆内内存，而且这部分是常驻内存的。每 10 TB 的磁盘 FST 的内存消耗大概在 10 GB 到 15 GB 左右。我们能不能对 FST 这种堆内占用比较大的内存做优化？我们的想法是把它移至堆外（off-heap），按需加载，提升堆内内存利用率，降低 GC 开销，提升单个节点管理磁盘的能力。我们来看下 off-heap 相关的方案。

最近十年，Elasticsearch 已经成为了最受欢迎的开源检索引擎，其作为离线数仓、近线检索、B端检索的经典基建，已沉淀了大量的实践案例及优化总结。然而在高并发、高可用、大数据量的 C 端场景，目前可参考的资料并不多。因此，我们希望通过分享在外卖搜索场景下的优化实践，能为大家提供 Elasticsearch 优化思路上的一些借鉴。美团在外卖搜索业务场景中大规模地使用了 Elasticsearch 作为底层检索引擎。其在过去几年很好地支持了外卖每天十亿以上的检索流量。

分享一篇哈啰单车技术团队对ElasticSearch的查询性能优化的分析文章。

Elasticsearch