使用 NaN 值对百分位数聚合进行排序

Sorting percentiles aggregation with NaN values

我使用的是 ElasticSearch 2.3.3,我有以下聚合:

"aggregations": {
        "mainBreakdown": {
            "terms": {
                "field": "location_i",
                "size": 10,
                "order": [
                    {
                        "comments>medianTime.50": "asc"
                    }
                ]
            },
            "aggregations": {
                "comments": {
                    "filter": {
                        "term": {
                            "type_i": 120
                        }
                    },
                    "aggregations": {
                        "medianTime": {
                            "percentiles": {
                                "field": "time_l",
                                "percents": [
                                    50.0
                                ]
                            }
                        }
                    }
                }
            }
        }
    }

为了更好地理解,我在字段名称中添加了一个后缀,它告诉字段映射:

聚合响应为:

"aggregations": {
    "mainBreakdown": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": 100,
          "doc_count": 2,
          "comments": {
            "doc_count": 1,
            "medianTime": {
              "values": {
                "50.0": 20113
              }
            }
          }
        },
        {
          "key": 121,
          "doc_count": 14,
          "comments": {
            "doc_count": 0,
            "medianTime": {
              "values": {
                "50.0": "NaN"
              }
            }
          }
        }
      ]
    }
}

我的问题是 medianTime 聚合有时具有 NaN 的值,因为父聚合 comments 有 0 个匹配的文档,然后结果为 NaN 将始终在 "asc" 和 "desc" 订单上排在最后。
我试过在 percentiles 聚合中添加 "missing": 0 但它仍然是 returns NaN.

你能帮我按 medianTime 对我的桶进行排序吗?当它 "asc" 排序时,NaN 值将排在第一位,而它的 "desc" 值将排在最后?

NaN 不是数字,所以它们永远排在最后。
在对 elasticsearch github 进行了简短的讨论后,我们决定它是处理 NaN 的合适方法。
https://github.com/elastic/elasticsearch/issues/36402