Question

使用Elasticsearch 1.4.3

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

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

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

不返回字段。

所以我假设我必须使用“store”：每个字段都为true。从我读到的内容来看，搜索速度会更快，但我想空间方面它与_source相同或者我们还能节省空间吗？

Answer 1

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

您将无法进行部分更新
您将无法从您的JSON中重新索引数据 Elasticsearch集群，您必须从数据源重新编制索引（这通常要慢得多）。

Answer 2

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

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

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

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

我在shay.banon回答的以下链接上得到了这个答案，你可以阅读这整个帖子以便对它有所了解。 enter link description here

Answer 3

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

Answer 4

Clinton Gormley在下面的链接中说道

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

默认情况下，ES将您的JSON文档存储在_source字段中，即设置为＆＃34;存储＆＃34;
默认情况下，JSON文档中的字段设置为不存储＆＃34;存储＆＃34; （即存储为单独的字段）
所以当ES返回你的doc（搜索或获取）时，它只需加载_source 字段并返回，即单个磁盘搜索

有些人认为通过存储单个字段会更快而不是从_source字段加载整个JSON文档。他们没有做什么实现的是每个存储的字段都需要磁盘搜索（每次寻找10ms！），那些寻求的总和远远超过了公正的成本发送_source字段。

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

Answer 5

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

我可能只引用_source：

用户经常禁用_source字段而无需考虑   后果，然后过后悔。如果_source字段不是   可用，则不支持许多功能：



update，update_by_query，   和reindex API。



动态突出显示。



从一个Elasticsearch索引重新索引到另一个索引的能力   更改映射或分析，或将索引升级到新的专业   版本。



通过查看原始内容调试查询或聚合的功能   索引时使用的文档。



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



提示：如果需要磁盘空间，请增加   压缩级别，而不是禁用_source。

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

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

Elasticsearch商店字段vs _source

5 个答案: