为什么我需要“商店”: “是”在 elasticsearch？

我真的不明白为什么在核心类型链接中它在属性描述(例如，对于一个数字)中说:

Store-设置为 yes 来存储索引中的实际字段，否则不存储它。默认值为 no (注意，存储 JSON 文档本身，并且可以从中检索它)
Index-如果值不应该被索引，则设置为 no。在这种情况下，store 应该被设置为 yes，因为如果它没有被索引，也没有被存储，那么它就是 跟这事没关系

这两个大胆的部分似乎相互矛盾。如果 "index":"no", "store":"no"我仍然可以从源得到值。例如，如果我有一个包含 URL 的字段，这可能是一个很好的用法。没有吗？

我做了个小实验，有两个映射，一个场设置为 "store":"yes"，另一个场设置为 "store":"no"。

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

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

我也得到了同样的答案。

我认为，如果 "store"被设置为 "no"，这将意味着我不能检索的具体领域，但必须得到整个 _source和解析它在客户端。

那么，将 "store"设置为 "yes"有什么好处呢？只有当我显式地从 "_source"字段中排除该字段时，它才是相关的吗？

33641

小开

在 elasticsearch 中，默认情况下，存储 _source(编入索引的文档)。这意味着当您搜索时，您可以得到实际的文档源。此外，elasticsearch 将自动从 _source中提取 fields / objects，并在您明确要求时返回它们(以及可能在其他组件中使用它，比如突出显示)。

可以指定还存储特定字段。这意味着该字段的数据将被存储为自己。这意味着如果您请求 field1(它被存储) ，elasticsearch 将识别它所存储的，并从索引中加载它，而不是从 _source获取它(假设启用了 _ source)。

您希望何时启用存储特定字段？大多数时候，你不知道。获取 _ source 很快，提取它也很快。如果您有非常大的文档，其中存储 _source的成本很高，或者解析 _source的成本很高，那么您可以显式地映射一些要存储的字段。

注意，检索每个存储字段都有成本。所以，举个例子，如果你有一个 json，有10个大小合理的字段，你把它们都映射成存储的，然后要求所有的字段，这意味着加载每一个字段(更多的磁盘寻找) ，相比之下，只加载 _source(一个字段，可能是压缩的)。

来源链接

最佳答案

我想，如果“商店”设置为“不”，那就意味着我不能检索特定的字段，但必须获取 whole _ source 和在客户端解析它。

这正是 elasticsearch 在没有存储字段(默认情况下)和启用 _source字段(也是默认情况下)时为您做的事情。

您通常将一个字段发送到 elasticsearch，因为您要么希望对其进行搜索，要么希望检索它。但是，如果没有显式地存储字段，也没有禁用源，那么仍然可以使用 _source检索字段。这意味着在某些情况下，拥有一个既没有索引也没有存储的字段实际上是有意义的。

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

在少数情况下，在 lucene 中显式地存储字段可能是有用的: 当 _source字段被禁用时，或者当我们想要避免解析它时，即使解析是通过 elasticsearch 自动完成的。请记住，从 lucene 检索许多存储字段可能需要每个字段一个磁盘搜索，而从 lucene 检索仅 _source并解析它以检索所需字段只是一个磁盘搜索，在大多数情况下只是更快。