范围搜索查询导致弹性搜索中的垃圾收集

Question

我有一个包含 16 个节点（13 个数据节点/3 个主节点/24 GB RAM/12 GB 堆）的 Elastic Search 5.2 集群。我正在对查询进行性能测试，并在 Elastic 集群上每秒调用 50 次搜索查询。我的查询如下所示 -

{
    "query": {
        "bool": {
            "must": [
                {
                    "term": {
                        "cust_id": "AC-90-464690064500"
                    }
                },
                {
                    "range": {
                        "yy_mo_no": {
                            "gt": 201701,
                            "lte": 201710
                        }
                    }
                }
            ]
        }
    }
}

我的索引映射如下-

cust_id      Keyword
smry_amt     Long
yy_mo_no     Integer    // doc_values enabled
mkt_id       Keyword
. . .
. . .
currency_cd  Keyword   // Total 10 field with 8 Keyword type

索引包含 2 亿条记录，对于每个 cust_id，可能有 100 条记录。索引有 2 个副本。记录大小小于 100 字节。

当我运行性能测试 10 分钟时，查询响应和性能似乎很慢。在对 Kibana 监控选项卡中的更多细节进行调查后，似乎发生了很多垃圾收集活动（请参见下图）-

我有几个问题在我脑海中浮现。我对 Range 查询进行了一些研究，但在与我的情况类似的情况下没有发现什么会导致 GC 活动。我还研究了内存使用和 GC 活动，但大多数 Elastic 文档都提到年轻代 GC 在索引时是正常的，而搜索活动主要使用操作系统维护的文件系统缓存。这就是为什么在上面的图表中，由于搜索使用的是文件系统缓存，所以堆的使用并不多。

所以-

1. 什么可能导致垃圾收集在这里发生？
2. 图表显示，堆仍可用于 Elastic Search，与可用堆相比，已用堆仍然非常少。那么是什么触发了 GC 呢？
3. 查询类型是否会导致创建任何内部数据结构被释放，从而导致 GC？
4. CPU 峰值可能是由于 GC 活动造成的。
5. 在 Elastic Search 5.5 之前的版本中是否有其他有效的方法来运行 Range 查询？
6. 分析查询表明 Elastic 正在运行 TermQuery 和 BooleanQuery，后者的成本最高。

知道这里发生了什么吗？

提前致谢，

• SGSI。

Answer 1

正确答案取决于索引设置，但我猜您使用的是启用了 docValues 的整数类型。该数据结构应该支持聚合和排序，但不支持范围查询。正确的数据类型是range。

如果 DocValues elastic/lucene 迭代所有文档（即全扫描）以匹配范围查询 - 这需要读取和解码 DV 列中的每个值 - 此操作非常昂贵，尤其是当索引不能被操作系统缓存。