为什么我在elasticsearch中需要“store”：“yes”？

我真的不明白为什么核心类型链接 http://www.elasticsearch.org/guide/reference/mapping/core-types/它在属性描述中说（例如，对于数字）：

1. store - 设置为 yes 将实际字段存储在索引中，设置为 no 则不存储它。默认为否（注意，JSON 文档本身被存储，并且可以从中检索)
2. index - 如果不应为该值建立索引，则设置为 no。在这种情况下，store 应该设置为 yes，因为如果它没有被索引并且没有被存储，与此无关

这两个粗体部分似乎是矛盾的。如果"index":"no", "store":"no"我仍然可以从源头获得价值。例如，如果我有一个包含 URL 的字段，这可能是一个很好的用途。不？

我做了一个小实验，其中有两个映射，其中一个字段设置为"store":"yes"并在另一个"store":"no".

在这两种情况下，我仍然可以在查询中指定：

{"query":{"match_all":{}}, "fields":["my_test_field"]}

我得到了同样的答案，返回了字段。

我想如果"store"被设定为"no"这意味着我无法检索特定字段，但必须获取整个字段_source并在客户端解析它。

那么设置有什么好处呢"store" to "yes"？仅当我将该字段排除在外时才相关吗？"_source"明确字段？

我认为如果“商店”设置为“否”，则意味着我不能 检索特定字段，但必须获取整个 _source 和 在客户端解析它。

这正是当未存储字段（默认）并且_source字段已启用（也是默认值）。

您通常将一个字段发送到elasticsearch，因为您想要搜索它或检索它。但确实，如果您没有显式存储该字段并且没有禁用源，您仍然可以使用_source。这意味着在某些情况下，拥有未索引或未存储的字段实际上可能是有意义的。

当您存储字段时，这是在底层 lucene 中完成的。 Lucene 是一个倒排索引，允许快速全文搜索并根据给定的文本查询返回文档 ID。除了倒排索引之外，Lucene 还具有某种存储功能，可以存储字段值，以便在给定文档 id 的情况下检索字段值。您通常将要作为搜索结果返回的字段存储在 lucene 中。 Elasticsearch 不需要存储您想要返回的每个字段，因为默认情况下它总是存储您发送给它的每个文档，因此它始终能够返回您发送给它的所有内容作为搜索结果。

在少数情况下，在 lucene 中显式存储字段可能会很有用：_source字段被禁用，或者当我们想避免解析它时，即使解析是由elasticsearch自动完成的。 请记住，从 lucene 检索许多存储的字段可能需要每个字段进行一次磁盘查找，而仅检索_source从 lucene 读取数据并解析它以检索所需的字段只是一次磁盘查找，并且在大多数情况下速度更快。