整理自Github的一个issue,也正好解答了我的疑惑
https://github.com/elastic/elasticsearch/issues/17159
提问
是否可以避免搜索的fetch阶段并仅返回文档ID?查询阶段结束时是否有_id,这样当我只需要_id时,fetch就多余了?可以通过当前API完成此操作吗?
最终,我希望能够比目前所见的速度更快地从搜索中检索文档ID。我已经尝试了所有文档中记录的各种方法来获得更好的性能,但没有找到令人满意的结果。我所取得的最佳成果只是通过并行查询每个5个分片中的每个分片而获得了25%的速度提升。一个可接受的速度提升应该快90%。了解这是否合理以及如果不合理的原因将会很有帮助。很难理解为什么我可以快速得到a)前100个结果,b)总计数,以及c)快速排序它们,但检索结果却非常慢。
此外,通过开发插件是否有可能提高此(仅限ID)场景的性能?是否有其他选项,无论是记录在案还是未记录在案,可以减少开销?
强调一下这一点的重要性,这对我们的实施至关重要,很可能是我们决定采用Elastic以替换当前庞大的持久性层的关键因素。
回答
搜索阶段获取 Lucene的文档 ID(整数),而不是 elasticsearch 的 ID(字符串)。fetch阶段使用 Lucene 的存储字段机制查找文档 ID。存储字段以压缩块的形式存储在一起。由于 _source 是一个存储字段,因此您必须解压缩大量 _source 才能获得 ID 字段。由于它是分块的,因此您还必须解压缩未命中的文档的存储字段。
聚合速度很快,因为它们使用文档值(doc values),这是一种非分块的列式结构。它经过压缩,但使用的是数值技巧,而不是通用的压缩算法。如果能够将您的工作重新设计为一个聚合操作,通过将感兴趣的工作推送到 Elasticsearch,那么您的操作速度可以提升数个数量级。