我真的不明白为什么在core types link中它在属性描述中说(例如,对于数字):
两个大胆的部分似乎相互矛盾。如果"index":"no", "store":"no"
我仍然可以从源获取值。如果我有一个包含URL的字段,这可能是一个很好的用法。否?
我有一个小实验,我有两个映射,其中一个字段设置为"store":"yes"
,另一个字段设置为"store":"no"
。
在这两种情况下,我仍然可以在我的查询中指定:
{"query":{"match_all":{}}, "fields":["my_test_field"]}
我得到了同样的答案,回到了现场。
我认为如果将"store"
设置为"no"
,则意味着我无法检索特定字段,但必须获取整个_source
并在客户端解析它。
那么,将"store"
设置为"yes"
会有什么好处?仅当我明确地从"_source"
字段中排除字段时,它才有意义吗?
答案 0 :(得分:103)
我认为如果“商店”设置为“否”,那就意味着我不能 检索特定字段,但必须得到整个_source和 在客户端解析它。
这正是elasticsearch在未存储字段(默认)且启用_source
字段时也为您所做的事情(默认情况下)。
您通常会向elasticsearch发送一个字段,因为您要么搜索它,要么检索它。但是,如果您没有明确存储该字段并且未禁用该源,则仍然可以使用_source
检索该字段。这意味着在某些情况下,拥有一个未编入索引或存储的字段实际上是有意义的。
存储字段时,在底层lucene中完成。 Lucene是一个倒排索引,允许快速全文搜索,并在给定文本查询的情况下返回文档ID。除了倒排索引之外,Lucene还有一些存储空间,可以存储字段值,以便在给定文档ID的情况下进行检索。您通常在lucene中存储要作为搜索结果返回的字段。 Elasticsearch不需要存储您想要返回的每个字段,因为它始终默认存储您发送给它的每个文档,因此它始终能够将您发送给它的所有内容作为搜索结果返回。
在少数情况下,在lucene中显式存储字段可能很有用:当_source
字段被禁用时,或者当我们想要避免解析它时,即使解析是由elasticsearch自动完成的。
请记住,虽然从lucene检索许多存储的字段可能需要每个字段一次磁盘搜索,而只检索lucene中的_source
并解析它以便检索所需的字段只是一个磁盘搜索而且速度更快大多数情况。
答案 1 :(得分:3)
默认情况下,弹性搜索会存储_source
(索引的文档)。这意味着当您搜索时,您可以获得实际的文档源。此外,elasticsearch将自动从fields / objects
中提取_source
并在您明确要求时返回它们(以及可能在其他组件中使用它,如突出显示)。
您可以指定还存储特定字段。这意味着该字段的数据将存储在中。这意味着如果你要求field1
(存储),elasticsearch将识别它的存储,并从索引加载而不是从_source
获取它(假设_source已启用)。
您希望何时启用存储特定字段?大多数时候,你没有。获取_source很快,并且提取它也很快。如果您有非常大的文档,其中存储_source
的成本或解析_source
的成本很高,您可以显式映射一些要存储的字段。
注意,检索每个存储的字段需要付出代价。因此,例如,如果你有一个包含10个大小合理的字段的json,并且你将所有这些字段映射为存储,并要求所有这些字段,这意味着加载每个字段(更多的磁盘搜索),而只是加载{ {1}}(这是一个字段,可能已压缩)。
我在shay.banon回答的下面的链接上得到了这个答案,你可以阅读这整个帖子以便更好地理解它。 enter link description here