官方文檔：Managing Elasticsearch Fields When Searching

Elasticsearch返回值字段設置

要想最大限度提高Elasticsearch的性能，控制搜索要求返回的字段數量是很重要的。在這1章，我們將講授如何優化我們的利用，在每個搜索結果中唯一選擇地返回那些我們需要的字段。

介紹

在搜索中，使用參數fields允許限制每個查詢命中項（查詢結果 hit）返回的列（fields）。這個特性通常被用來優化大批量數據傳輸，當Elasticsearch查詢結果中有大量返回列時，使其只返回相干的列。固然它聽起來很簡單（實際上它確切很簡單），但是它卻對性能有極大的影響，查詢性能與返回文檔的數量和每個文檔大小兩個因素成反比。

斟酌這樣1種情況，當每個文檔的平均大小是20KB，那末每次查詢要求返回10個查詢結果則是平均200KB的數據。如果每秒要求100次，那末我們就需要20M的帶寬。作1個公道的假定，假設我們如果只返回有用的字段，可以下降文檔大小到800字節，那末每次要求大致就只返回8KB的數據量，每秒要求100次則只需要800KB的帶寬。如果想要大范圍使用， 那末保證返回結果盡量小確切是非常重要且非常實用的。

默許情況下，開啟的是_source字段，它包括的是解析后的文檔內容，并會在每次查詢后返回。當我們其實不是需要查找并解析文檔所有的內容時，我們通過限制返回的字段（fields）可以節省寶貴的服務器CPU時間和磁盤IO。上面講到的fields便足以實現這1點。如果我們需要同時返回源文檔（document）和1些列（fields），我們可使用參數_source過濾，后面將會介紹它的用法。

關于fields的另外一個特性其實不廣為人知，它也能夠用在查詢元字段中（metadata-fields）。這里特指用它查詢_ttl字段的值，它可以在毫秒級別返回查詢結果，而不是查詢原文檔需要的時間。這確切是1個非常實用的技能。

嵌套數據和嵌套列（Nested Fields and Nested Data）

有些時候，僅僅查詢1些簡單的字段是不夠的，這時候我們可能需要動態地查詢1些嵌套字段中的數據。在這類情況下，我們不能使用fields，否則只會得到下面這樣的失敗信息：
譯者注：這此信息是在Elasticsearch日志中的，1般情況下在控制臺看不到的。

拋出的這個異常是由于fields只能用于葉子節點的數據（即：這個節點沒有子節點）。為了能夠加載出非葉子節點，我們需要在查詢時使用_source參數，它可以激活過濾源文檔的特性（它可以用來過濾源文檔），下面將詳細講授。

源文檔過濾（Source Filtering）

源文檔過濾可以在查詢中控制原始JSON文檔中的哪1部份會被返回。我們可以設置包括列或排除列，通過模式匹配來過濾列名的訪問路徑便可。請記住，這僅僅可以節省從查詢節點到調用客戶真個帶寬，而不能節省cpu時間和磁盤IO，除非使用fields的時候。這是由于當使用源文檔過濾時，對每個查詢結果我們依然需要解析源文檔，根據提供的模式去匹配，以確切返回值中應當包括這1列，或排除這1列。但是在我們的優化計劃中，它依然是1個非常重要的方式，并且它使用非常容易，我們可以從它開啟優化的第1步。

在1.0版本之前，有1個更廣為人知的查詢方式――partial fields，現在它已過時了，已被本文的源文檔過濾替換。

后面還有兩段，但是由于我沒有使用過，所以對內容的翻譯掌握不好。暫時不翻譯了。
未完待續……

譯者附：fields和_source的使用方式

其實沒甚么區分，只不過兩個的機制不同，且只有_source支持嵌套類型。
希望本文會對你有所幫助。