In-memory模式中，fielddata受到heap内存大小限制，虽然这个问题可以通过集群的横向扩容解决——可需要经常增加节点——而且即使加了，你还是会发现在其他一些资源利用不充分的节点上，在排序和聚合查询的时候仍然会消耗你大量的heap空间。
fielddata字段数据默认下，会频繁的在内存当中加载。但这不是唯一的方法，在索引数据时，fielddata字段数据还可以被写在磁盘中，这种方式可以提供和加载到内存中的一样的功能，而不会占用heap的内存空间。
Docvalues是在1.0.0之后加入到elasticsearch中的。通过基准测试与性能分析，各类的瓶颈——无论是elasticsearch还是lucene，都已经被发现并且已经被移除了。但是直到现在还是远远慢于字段数据放内存的in-memory方式。
1、存放在磁盘代替存放内存，可以允许你的集群负载大量fielddata字段数据而不会超量使用内存。这样，你的heap space就可以设置小一些了，对垃圾回收的速度有所帮助，理所当然的，节点也会更稳定些。
2、DocValues是索引时建立的，而不是搜索的时候。当通过非反向的反向索引搜索时候，in-memort方式，内存中的字段数据必须被频繁的读写，而doc vales 是预先建立的，并能更快的初始化。
像trade-off这种索引量大的搜索，访问fielddata会比较缓慢，设置docvalues会有显著的效果，在大量请求的时候，你甚至不会注意到你的搜索会变慢。结合更快的垃圾回收机制和初始化时间，你会留意到搜索性能会得到有效提升。
文件系统的缓存空间越多，docvalue的性能会越好。如果文件都是docvalues并且都位于文件系统的缓存中，那么访问这些文件的速度几乎与访问内存媲美的。而文件系统缓存由内核控制而非JVM。
启动DocValues
numeric, date, Boolean, binary, and geo-point这些字段以及not_analyzed的字符串可以设置Docvalues属性。一般不处理analyze的字符串字段。 Docvalues在mapping重的每个字段属性中定义，这样对于不同的字段，可以结合in-memory与docvalues使用。
PUT /music/_mapping/song
{
“properties” : {
“tag”: {
“type”: “string”,
“index” : “not_analyzed”,
“doc_values”: true
}
}
}
设置了docvalues之后，字段创建时，就是用磁盘存储fielddata而不是内存存储fielddata了。
就这样！不需要再配置其他东西，查询，聚合，排序，以及一般的功能脚本；他们现在都会用到docvalues了。
你可以随便的使用docvalues这参数。用得越多，你使用的heap内存空间就可以越少。在不久的将来，docvalues应该会变成默认的参数。
原文来自:http://www.elastic.co/guide/en/elasticsearch/guide/current/doc-values.html#_enabling_doc_values