企业网站界面seo没什么作用了

整理自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，那么您的操作速度可以提升数个数量级。