一般建议

Elasticsearch 被设计为一个搜索引擎，这使得它在获取与查询匹配的前几个文档方面非常出色。然而，它在处理属于数据库领域的工作负载时并不那么擅长，例如检索所有与特定查询匹配的文档。如果你需要这样做，请确保使用 Scroll API。

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

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

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