为什么在elasticsearch中需要“存储”：“是”？
我真的不明白为什么在核心types链接它说在属性描述（例如一个数字）：
- 存储 – 设置为是将实际字段存储在索引中，否则不存储。 默认为no（注意， JSON文档本身是存储的，可以从中检索 ）
- index – 如果不应该索引该值，则设置为no。 在这种情况下，应该将商店设置为“是”，因为如果它没有被索引并且没有被存储， 则与它无关
两个大胆的部分似乎相矛盾。 如果"index":"no", "store":"no"我仍然可以从源头获得价值。 例如，如果我有一个包含URL的字段，这可能是一个很好的用法。 没有？
我有一个小实验，在那里我有两个映射，一个字段被设置为"store":"yes" ，另一个字段被设置为"store":"yes" "store":"no" 。
在这两种情况下，我仍然可以在我的查询中指定：
{"query":{"match_all":{}}, "fields":["my_test_field"]}
我得到了同样的答案，返回领域。
我认为如果"store"被设置为"no"那么就意味着我无法检索到特定的字段，但是必须得到整个资源并在客户端进行parsing。
那么，将"store"设置为"yes"有什么好处呢？ 如果我明确地从"_source"字段中排除字段，这只是相关的吗？
我认为如果“store”设置为“no”，这意味着我无法检索特定字段，但必须获取整个_source并在客户端parsing它。
这正是elasticsearch在没有存储字段时（默认）和_source字段被启用（默认）的function。
您通常会将字段发送给elasticsearch，因为您要么search它，要么检索它。 但是的确，如果你没有明确的存储这个字段，而且你也没有禁用这个源代码，你仍然可以使用_source来检索这个字段。 这意味着，在某些情况下，实际上可能有一个没有索引或存储的字段。
当你存储一个字段时，这是在底层的lucene中完成的。 Lucene是一个倒排索引，它允许快速的全文search，并给出文本查询后面的文档ID。 除了倒排索引之外，Lucene还有一些存储区域，可以存储字段值，以便在给定文档ID的情况下进行检索。 您通常在lucene中存储要作为search结果返回的字段。 Elasticsearch不需要存储你想要返回的每个字段，因为它总是默认存储你发送给它的每个文档，因此它总是能够返回你发送给它的所有东西作为search结果。
在less数情况下，在lucene中显式地存储字段可能是有用的：当_source字段被禁用时，或者当我们想要避免parsing时，即使parsing是由elasticsearch自动完成的。 请记住，从lucene中检索许多存储的字段可能需要一个磁盘寻道每个字段，而从lucene只检索_source并parsing它以检索所需的字段只是一个单一的磁盘寻道，在大多数情况下。
默认情况下，在elasticsearch中，存储_source（索引的文档）。 这意味着当你search，你可以得到实际的文件来源。 此外，elasticsearch会自动从_source中提取字段/对象，如果你明确地询问它（还可能在其他组件中使用它，比如突出显示），则会返回它们。
您可以指定还存储特定的字段。 这意味着该字段的数据将被“自行存储”。 这意味着如果你询问“field1”（存储的），elasticsearch会识别它的存储，并从索引中加载它，而不是从_source中获取（假设_source被启用）。
你想什么时候启用存储特定的字段？ 大多数时候，你没有。 获取_source的速度很快，解压也很快。 如果你有非常大的文档，存储_source的代价或者parsing_source的代价很高，你可以显式映射一些被存储的字段。
请注意，检索每个存储的字段是有成本的。 所以，例如，如果你有一个具有10个合理大小字段的json，并且把它们全部映射为存储的，并且要求所有这些字段，这意味着加载每个字节（更多的磁盘寻找），而不是加载_source （这是一个领域，可能被压缩）。
我在下面的链接中得到了这个答案，由shay.banon回答，你可以阅读这整个线程得到很好的理解 。 在这里input链接描述
