我们正在系统中的许多不同资源上构建“统一”搜索。我们的索引模式包括大约10个索引的通用字段，以及在返回结果时识别系统中适当资源位置所需的5个字段。
索引字段通常包含敏感数据，因此我们根本不希望它们存储，仅为匹配编制索引，因此我们将_source设置为FALSE。
我确实希望返回5个ident字段，因此可以将ident字段设置为store = yes，但整体索引_source设置为FALSE并在结果中获得我正在寻找的东西？
答案 0 :(得分：3)
还要看看其他answer。如前所述，在大多数情况下_source字段有很大帮助。即使它看起来像浪费，因为elasticsearch有效地存储了整个文档，这非常方便（例如，当需要更新文档而不发送整个更新的文档时）。在一天结束时，它隐藏了一个lucene实现细节，如果你想让它们恢复，你需要显式存储字段这一事实，而用户通常希望收回他们发送给搜索引擎的内容。令人惊讶的是，_source也有助于提高性能，因为它需要单个磁盘搜索而不是可能由检索多个存储字段引起的更多磁盘搜索。在一天结束时，_source字段只是一个包含json的大型lucene存储字段，可以对其进行解析以获取特定字段并对其进行一些操作，而无需单独存储它们。
那就是说，根据你的用例（你检索了多少个字段），查看_source field reference底部的源包含/排除可能是有用的，它允许你防止部分（例如来自存储的源字段的敏感部分）。如果你想继续依赖_source但不希望返回部分输入文档，那么这将非常有用，但你确实希望搜索这些字段，因为它们将被编入索引（但是没有存储！）在底层的lucene索引中。
在这两种情况下（完全禁用_source或排除某些部分），如果您计划更新文档，请记住您需要使用索引api发送整个更新的文档。实际上，您不能依赖更新api提供的部分更新，因为您在索引中没有首先编制索引的完整文档，您需要将更改应用到该文档。
答案 1 :(得分：1)
是的，存储的字段不依赖于_source字段，反之亦然。它们是分开的，改变或禁用它们不应该影响另一个。