通用建议

Elasticsearch 被设计为搜索引擎，这使得它非常擅长返回与查询匹配的顶部文档。但是，它不太适合数据库领域的工作负载，例如检索与特定查询匹配的所有文档。如果需要这样做，请务必使用 Scroll API。

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

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

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