一般建议

不要返回大型结果集编辑

Elasticsearch 被设计为搜索引擎，这使得它非常擅长获取与查询匹配的排名靠前的文档。但是，对于属于数据库领域的负载，例如检索与特定查询匹配的所有文档，它并不擅长。如果您需要这样做，请确保使用 滚动 API。

避免大型文档编辑

鉴于默认的 http.max_content_length 设置为 100MB，Elasticsearch 将拒绝索引任何大于此值的文档。您可能会决定增加该特定设置，但 Lucene 仍然有大约 2GB 的限制。

即使不考虑硬性限制，大型文档通常也不实用。大型文档会给网络、内存使用和磁盘带来更大的压力，即使对于不请求 _source 的搜索请求也是如此，因为 Elasticsearch 在所有情况下都需要获取文档的 _id，并且由于文件系统缓存的工作方式，获取此字段的成本对于大型文档来说更大。索引此文档可能使用的内存量是文档原始大小的倍数。邻近搜索（例如短语查询）和 高亮显示 也变得更加昂贵，因为它们的成本直接取决于原始文档的大小。

有时重新考虑信息的单位是有用的。例如，您希望使书籍可搜索这一事实并不一定意味着文档应该包含整本书。使用章节甚至段落作为文档，然后在这些文档中具有标识它们所属书籍的属性，这可能是一个更好的主意。这不仅避免了大型文档的问题，还使搜索体验更好。例如，如果用户搜索两个单词 foo 和 bar，则跨不同章节的匹配可能非常差，而同一章节内的匹配可能很好。