[BUG] Simple `top` queries on high-cardinality fields are very slow

Đang mở
  • Có gì không ổn?
#5,673 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, sql
Lĩnh vực
backend-api-design, performance

Hướng nghiên cứu

Điểm vào được báo cáo là một truy vấn top của PPL; hãy bắt đầu với các kế hoạch logic và vật lý của ppl --explain cùng với việc đẩy phép tổng hợp xuống, đặc biệt là request composite_buckets được tạo ra. So sánh nó với request terms/top_values đã cho; hoàn thành khi các truy vấn top đơn giản tránh được việc quét coordinator và trả về các kết quả top như mong đợi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug calcite performance PPL pushdown

What is the bug?
Simple top queries can take more than 30s if done on fields with high cardinality (>1mil distinct values). This happens even if there's a small top limit such as the default top 10.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Index data with lots of distinct request_id values (>1mil, keyword-typed)
  2. source=idx | top request_id
  3. Measure

Explain plan:

> echo 'source=logs | top request_id' | ppl --explain
= Calcite Plan =
== Logical ==
LogicalSystemLimit(fetch=[10000], type=[QUERY_SIZE_LIMIT])
  LogicalProject(request_id=[$0], count=[$1])
    LogicalFilter(condition=[=($2, 10)])
      LogicalProject(request_id=[$0], count=[$1], _row_number_rare_top_=[ROW_NUMBER() OVER (ORDER BY $1 DESC, $0)])
        LogicalAggregate(group=[{0}], count=[COUNT()])
          LogicalProject(request_id=[$60])
            CalciteLogicalIndexScan(table=[[OpenSearch, logs]])


== Physical ==
EnumerableLimit(fetch=[10000])
  EnumerableCalc(expr#0..2=[{inputs}], expr#3=[10], expr#4=[=($t2, $t3)], proj#0..1=[{exprs}], $condition=[$t4])
    EnumerableWindow(window#0=[window(order by [1 DESC, 0] rows between UNBOUNDED PRECEDING and CURRENT ROW aggs [ROW_NUMBER()])])
      CalciteEnumerableIndexScan(table=[[OpenSearch, logs]], PushDownContext=[[AGGREGATION-rel#50:LogicalAggregate.NONE.[](input=RelSubset#49,group={0},count=COUNT())], OpenSearchRequestBuilder(sourceBuilder={
        "aggregations": {
          "composite_buckets": {
            "composite": {
              "size": 10000,
              "sources": [
                {
                  "request_id": {
                    "terms": {
                      "field": "request_id",
                      "missing_bucket": true,
                      "missing_order": "first",
                      "order": "asc"
                    }
                  }
                }
              ]
            }
          }
        },
        "from": 0,
        "size": 0,
        "timeout": "1m"
      }, requestedTotalSize=2147483647, pageSize=null, startFrom=0)])

The inner DSL in this case takes ~300ms (index cache disabled), while the PPL takes ~43800ms on my machine. However, it's also ordering keys lexically instead of by count using OpenSearch's own top_values aggregation.

What is the expected behavior?

At least this case of a trivial top aggregation (without trailing consuming commands) should be fast. OpenSearch itself can do this quickly (133 ms) with straightforward DSL, including returning an accurate size for the "other" bucket (sum_other_doc_count):

{
  "size": 0,
  "aggs": {
    "top_values": {
      "terms": {
        "field": "request_id",
        "size": 10
      }
    }
  }
}

{
    "took": 99,
    "timed_out": false,
    "terminated_early": true,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 10000,
            "relation": "gte"
        },
        "max_score": null,
        "hits": []
    },
    "aggregations": {
        "top_values": {
            "doc_count_error_upper_bound": 4,
            "sum_other_doc_count": 999990,
            "buckets": [
                {
                    "key": "00000067-142d-4d90-8a2c-28409600adbd",
                    "doc_count": 1
                },
                {
                    "key": "00001910-7d05-4e6a-9716-2c74137475e6",
                    "doc_count": 1
                },
                {
                    "key": "00002676-4f8c-428a-a29a-b862ca672cb7",
                    "doc_count": 1
                },
                {
                    "key": "00003943-8463-46f2-a92b-641b4afbafb1",
                    "doc_count": 1
                },
                {
                    "key": "00003f95-b049-41de-b9be-03aae071ad99",
                    "doc_count": 1
                },
                {
                    "key": "00005502-587d-4b00-865c-86f2af5502c2",
                    "doc_count": 1
                },
                {
                    "key": "00005754-ad22-4894-a9b5-dba3007ff19a",
                    "doc_count": 1
                },
                {
                    "key": "00005c50-97d3-4c11-ad74-90a3219ca815",
                    "doc_count": 1
                },
                {
                    "key": "000066c7-0301-45aa-98b1-d4997a590214",
                    "doc_count": 1
                },
                {
                    "key": "00007501-890e-4f0b-a688-2653ade97f8b",
                    "doc_count": 1
                }
            ]
        }
    }
}

What is your host/environment?

  • mainline, also tested 3.5
  • linux (AL2023), jdk 25

Do you have any screenshots?
N/A

Do you have any additional context?
Seems to be that we don't have any top_values aggregation pushdown at all, so this query turns into a coordinator scan.

Ngôn ngữ chính
Java
Star
175
Fork
233
Merge trung bình
3 ngày 36 phút
Pull request đã merge (30 ngày)
41

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của opensearch-project/sql

Tất cả issue của opensearch-project/sql

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.