Elasticsearch的get操作为什么那么慢
在我们具体的业务操作过程中，我们会通过id进行get操作。 例如：
GetResponse response = client.prepareGet("twitter", "tweet", "1")
.execute().actionGet();
但是我们发现Elasticsearch1.2.2版本进行get操作非常的慢。 我们通过JVM分析工具进行分析： 通过工具的分析结果，我们可以看到节点服务器的cpu基本全部跑满，主要是因为每次es的get请求的条件都不一样，在ES集群的 queryResult caches 中获取不到结果，所以每次都得调用identityHashCode来重新计算hash值，然后放入 WeakIdentityMap 中，这些操作占用了绝大部分cpu时间，导致服务器的cpu占用率非常高。
通过对比Elasticsearch1.2.2版本和后续Elasticsearch1.5.2版本，我们发现在Elasticsearch1.5.2版本中，get操作已经弃用了bloomfilter的hash算法处理，使用 ConcurrentMap
但是通过后期业务运营发现虽然Elasticsearch1.5.2改进了get操作，但性能还是很慢。 因为在我们的业务中，通过_id去直接get索引的source信息的，而_id默认是not indexed(默认不索引)，索引导致get操作那么慢。
doc_value的使用
在我们实际的业务中，使用复杂的条件进行搜索时，经常出现Out Of Memory的错误，
主要是目前我们所有的fielddata都放在内存中计算导致的，此类问题可以通过doc_values来解决。
什么是doc_value
In-memory模式中，fielddata受到heap内存大小限制，虽然这个问题可以通过集群的横向扩容解决，可能需要经常增加节点，而且即使加了，你还是会发现在其他一些资源利用不充分的节点上，在排序和聚合查询的时候仍然会消耗你大量的heap空间。
fielddata字段数据默认下，会频繁的在内存当中加载。但这不是唯一的方法，在索引数据时，fielddata字段数据还可以被写在磁盘中，这种方式可以提供和加载到内存中的一样的功能，而不会占用heap的内存空间。
Docvalues是在1.0.0之后加入到elasticsearch中的。通过基准测试与性能分析，各类的瓶颈——无论是elasticsearch还是lucene，都已经被发现并且已经被移除了。但是直到现在还是远远慢于字段数据放内存的in-memory方式。
存放在磁盘代替存放内存，可以允许你的集群负载大量fielddata字段数据而不会超量使用内存。这样，你的heap space就可以设置小一些了，对垃圾回收的速度有所帮助，理所当然的，节点也会更稳定些。
DocValues是索引时建立的，而不是搜索的时候。当通过非反向的反向索引搜索时候，in-memory方式，内存中的字段数据必须被频繁的读写，而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应该会变成默认的参数。