Elasticsearch中的store field跟non-store field的区别

在定义index的mapping的时候，我们可以指定某些fields是否要store（默认是不store), 那么他们有什么区别呢？

PUT /my_index
{
"mappings": {
"my_type": {
"properties": {
"title": {
"type": "string",
 "store": true 
},
"date": {
"type": "date",
"store": true 
},
"content": {
"type": "string"
}
}
}
}
}

其实不管你将store设置为ture or false, elasticsearch都将为我们存储这些field, 不同的是：
当store为false时(默认配置），这些field只存储在"_source" field中。
当store为true时，这些field的value会存储在一个跟_source平级的独立的field中。同时也会存储在_source中，所以有两份拷贝。

那么什么情况下需要设置store field呢？一般情况有两种情况：
_source field在索引的mapping 中disable了。这种情况下，如果不将某个field定义成store=true，那些将无法在返回的查询结果中看到这个field.
_source的内容非常大。这时候如果我们想要在返回的_source document中解释出某个field的值的话，开销会很大（当然你也可以定义source filtering将减少network overhead），比例某个document中保存的是一本书，所以document中可能有这些field: title, date, content。假如我们只是想查询书的title 跟date信息，而不需要解释整个_source（非常大），这个时候我们可以考虑将title, date这些field设置成store=true。
需要注意的是，看起来将field store可以减少查询的开销，但其实这样也会加大disk的访问频率。假如你将_source中的10个field都定义store，那么在你查询这些field的时候会将会有10次disk seek的操作。而返回_source只有一次disk seek的操作。所以这个也是我们在定义的时候需要blance的。