74

我真的不明白为什么在核心类型链接中它在属性描述中说（例如数字）：

  1. store - 设置为 yes 将实际字段存储在索引中，no 不存储它。默认为 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"呢"yes"？"_source"仅当我从字段中明确排除该字段时才相关吗？

4

2 回答 2

115

我认为如果“存储”设置为“否”，这意味着我无法检索特定字段，但必须获取整个 _source 并在客户端解析它。

_source当未存储字段（默认）并且启用该字段（默认也是）时，这正是 elasticsearch 为您所做的。

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

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

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

于 2013-06-14T14:31:49.167 回答
9

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

您可以指定还存储特定字段。这意味着该字段的数据将单独存储。这意味着如果您要求field1（已存储），elasticsearch 将识别其已存储，并从索引加载它，而不是从_source（假设 _source 启用）获取它。

您希望何时启用存储特定字段？大多数时候，你没有。获取 _source 很快，提取也很快。如果您有非常大的文档，存储的_source成本或解析的成本_source很高，您可以显式映射一些要存储的字段。

请注意，检索每个存储的字段是有成本的。因此，例如，如果您有一个包含 10 个大小合理的字段的 json，并且您将所有这些字段映射为已存储，并要求所有这些字段，这意味着加载每个字段（更多磁盘寻道），而不是仅加载_source(这是一个字段，可能是压缩的）。

来源链接

于 2016-08-05T10:57:55.697 回答