文档声称：
10–25% slower than in-memory fielddata
和
It is possible that doc values will become the default format in the near future
除了速度的轻微降低之外，在所有属性中使用doc值的缺点是什么？
谢谢！
答案 0 :(得分：11)
趋势是尽可能使用doc_values，因为它们的性能越来越高于现场数据（特别是自ES 1.4以来）。现在的缺点之一是你不能将它们与分析的字符串字段和布尔字段一起使用。另一个缺点是，如果你仍然使用facet，resp。 Kibana 3，因为两者都没有利用文档值，但您可以迁移到聚合，也可以转换为聚合。升级到Kibana 4，所以这不是一个真正的问题。
查看Chris Earle的excellent blog post，其中解释了doc值与fielddata的来龙去脉。
答案 1 :(得分：2)
来自Elasticsearch The Definitive Guide [1.x]
Doc值现在仅比内存中的fielddata慢约10-25％， 并有两大优势：
它们存在于磁盘而不是堆内存中。这允许您处理通常太大的fielddata数量 适合记忆。实际上，您的堆空间（$ ES_HEAP_SIZE）现在可以 设置为较小的尺寸，这提高了垃圾收集的速度 因此，节点稳定性。 Doc值是在索引时建立的，而不是在搜索时建立的。虽然内存中的fielddata必须在搜索时动态构建 在反转索引的情况下，doc值是预先构建的并且很多 更快地初始化。
权衡是一个更大的索引大小和稍慢的fielddata 访问。 Doc值非常有效，因此对于许多查询而言 甚至可能没有注意到速度稍慢的速度。结合它 更快的垃圾收集和改进的初始化时间和你 可能会注意到净收益。
您可用的文件系统缓存空间越多越好 doc值将执行。如果包含doc值的文件是 驻留在文件系统缓存中，然后几乎访问文件 相当于从RAM读取。文件系统缓存由。管理 内核而不是JVM。
可以为数字，日期，布尔值，二进制和 地理位置字段和not_analyzed字符串字段。他们不 目前使用分析的字符串字段。 Doc值已启用 字段映射中的字段，表示您可以在内存中组合 具有doc值的fielddata：
PUT /music/_mapping/song
{
"properties" : {
"tag": {
"type": "string",
"index" : "not_analyzed",
"doc_values": true
}
}
}
我们将doc_values与布尔值一起使用，但您不能将它们与分析字段一起使用。他们正在谈论它，但不知道正确的数据结构应该是什么。请参阅Add Support for doc values for analyzed fields。