官方文档：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支持嵌套类型。
希望本文会对你有所帮助。