Elasticsearch商店字段vs _source

Question

使用Elasticsearch 1.4.3

我正在构建一种"报告"系统.客户端可以选择并选择他们想要在结果中返回的字段.

在90%的情况下,客户端永远不会选择所有字段,所以我想我可以在映射中禁用_source字段以节省空间.但后来我了解到了

GET myIndex/myType/_search/
{
    "fields": ["field1", "field2"]
    ...
}

不返回字段.

所以我假设我必须使用"store":每个字段都为true.从我读到的内容来看,搜索速度会更快,但我想空间方面它与_source相同或者我们仍然可以节省空间吗？

Answer 1

该_source字段存储您发送给Elasticsearch的JSON,您可以选择仅在需要时返回某些字段,这非常适合您的用例.我从未听说过搜索存储的字段会更快._source磁盘空间上的字段可能更大,但如果必须存储每个字段,则无需在字段上使用存储的_source字段.如果您禁用源字段,则表示:

• 您将无法进行部分更新
• 您将无法从Elasticsearch集群中的JSON重新索引数据,您必须从数据源重新编制索引(这通常要慢得多).

Answer 2

克林顿葛姆雷在下面的链接中说

https://groups.google.com/forum/#!topic/elasticsearch/j8cfbv-j73g/discussion

• 默认情况下，ES 将您的 JSON 文档存储在 _source 字段中，该字段设置为“已存储”

• 默认情况下，JSON 文档中的字段设置为“不存储”（即存储为单独的字段）

• 因此，当 ES 返回您的文档（搜索或获取）时，它只加载 _source 字段并返回该字段，即单个磁盘搜索

有些人认为通过存储单个字段会比从 _source 字段加载整个 JSON 文档更快。他们没有意识到每个存储的字段都需要一个磁盘查找（每次查找 10 毫秒！），并且这些查找的总和远远超过仅发送 _source 字段的成本。

换句话说，它几乎总是错误的优化。

Answer 3

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

您可以指定还存储特定字段.这意味着,该字段的数据将被存储在它自己的.这意味着如果你要求field1(存储),elasticsearch将识别它存储的内容,并从索引中加载它而不是从中获取它_source(假设_source已启用).

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

注意,检索每个存储的字段需要付出代价.因此,例如,如果你有一个包含10个字段大小合理的json,并且你将所有这些字段映射为存储,并且要求所有这些字段,这意味着加载每个字段(更多磁盘搜索),而只是加载_source(这是一个字段,可能是压缩的).

我在shay.banon回答的下面链接上得到了这个答案,你可以阅读这整个帖子以便对它有所了解. 在此输入链接描述

Answer 4

启用_source会将整个 JSON 文档存储在索引中，而store只会存储标记为这样的单个字段。因此，如果您想节省磁盘空间，使用store可能比使用更好_source。

Answer 5

作为ES 7.3的参考，答案变得更加清晰。在现实生产条件下有充分的测试理由之前，不要尝试优化。

我可能只是引用_source：

用户经常_source不考虑后果就禁用该字段，然后活着就后悔了。如果该_source字段不可用，则不支持许多功能：

• 的update，update_by_query和reindexAPI的。

• 在飞行中突出显示。

• 能够从一个 Elasticsearch 索引重新索引到另一个索引，以更改映射或分析，或者将索引升级到新的主要版本。

• 通过查看索引时使用的原始文档来调试查询或聚合的能力。

• 将来可能会自动修复索引损坏的能力。

提示：如果需要考虑磁盘空间，请提高压缩级别而不是禁用_source.

此外，使用stored_fields您可能想到的并没有明显的优势。

如果您只想检索单个字段或几个字段的值，而不是整个 _source，则可以使用source filtering.