为什么全局序数是基于字段数据而不是doc_values构建的？

Question

我有一个字段"location“，如下所示

 "location": {
        "type": "string",
        "index": "not_analyzed",
        "store": true,
        "fielddata": {
          "format": "doc_values"
        }
      },

但是，当我在此字段中使用术语聚合时，我会看到这种日志

[2015-05-13 15:42:56.210][DEBUG][index.fielddata.plain] Global-ordinals[location][361372] took 206 ms
[2015-05-13 17:55:44.692][DEBUG][index.fielddata.plain] Global-ordinals[location][461584] took 230 ms
[2015-05-13 17:56:21.907][DEBUG][index.fielddata.plain] Global-ordinals[location][263096] took 1205 ms

我还可以看到Java堆的大小增加了，这导致了长时间的旧垃圾回收。

为什么doc_values字段使用java堆?因为我把它们也存储起来了？我可以避免垃圾回收吗？

Answer 1

全局序号是将字段中的每个唯一项映射到唯一数字的结构。这需要生成，以便内存指纹和计算更好。

您可以了解有关全局序数here的更多信息。

以下是此信息的摘要，以防此链接在某一天失效：

全局序数

用于减少字符串字段数据的内存使用的技术之一称为序数。

假设我们有十亿个文档，每个文档都有一个status字段。只有三种状态：status_pending、status_published、status_deleted。如果我们在内存中保存每个文档的完整字符串状态，那么每个文档将使用14到16个字节，即大约15 GB。

相反，我们可以识别三个唯一的字符串，对它们进行排序，并对它们进行编号: 0，1，2。

Ordinal | Term
-------------------
0       | status_deleted
1       | status_pending
2       | status_published

原始字符串只在序号列表中存储一次，并且每个文档只使用编号的序号来指向它包含的值。

Doc     | Ordinal
-------------------------
0       | 1  # pending
1       | 1  # pending
2       | 2  # published
3       | 0  # deleted

这将内存使用从15 GB减少到不到1 GB！