为什么我需要"存储":弹性搜索中的"是"？

Question

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

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"明确地从字段中排除字段时,它才有意义吗？

Answer 1

我认为如果"store"设置为"no",则意味着我无法检索特定字段,但必须获取整个_source并在客户端解析它.

这正是elasticsearch在未存储字段(默认)并且_source字段已启用时(默认情况下)为您执行的操作.

您通常会向elasticsearch发送一个字段,因为您要么搜索它,要么检索它.但是,如果你没有明确地存储字段并且你没有禁用源代码,那么你仍然可以使用_source.这意味着在某些情况下,拥有一个未编入索引或存储的字段实际上是有意义的.

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

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

Answer 2

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

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

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

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

源链接