在定義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的。
————————————————
版權聲明：本文爲CSDN博主「林大蟲子」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/west_609/article/details/74906485