数据量较大的情况,排序明细查询该如何优化

【详述】
CREATE TABLE dw_nas_n1 (
request_time datetime NULL COMMENT “请求时间”,
src_asset_id int(11) NULL COMMENT “”,
dst_asset_id int(11) NULL COMMENT “”,
id bigint(20) NULL COMMENT “”,
ran_ip varchar(128) NULL COMMENT “”,
src_asset_name varchar(255) NULL COMMENT “”,
ran_port int(11) NULL COMMENT “”,
src_mac varchar(255) NULL COMMENT “”,
src_network_element_type bigint(20) NULL COMMENT “”,
amf_ip varchar(128) NULL COMMENT “”,
dst_asset_name varchar(255) NULL COMMENT “”,
amf_port int(11) NULL COMMENT “”,
dst_mac varchar(255) NULL COMMENT “”,
dst_network_element_type bigint(20) NULL COMMENT “”,
procedure1 int(11) NULL COMMENT “”,
msg_bimap int(11) NULL COMMENT “”,
cause_type int(11) NULL COMMENT “”,
cause_value int(11) NULL COMMENT “”,
ue_id_type tinyint(4) NULL COMMENT “”,
ue_id varchar(128) NULL COMMENT “”,
response_time datetime NULL COMMENT “”,
ran_ue_ngap_id bigint(20) NULL COMMENT “”,
amf_ue_ngap_id bigint(20) NULL COMMENT “”,
request_body varchar(65533) NULL COMMENT “”,
response_body varchar(65533) NULL COMMENT “”,
md5 varchar(32) NULL COMMENT “md5值(src_ip、src_ue_id、dst_ip、dst_ue_id)”,
ingestion_time datetime NULL COMMENT “表示数据进入starRocks的时间”,
INDEX idx_procedure1 (procedure1) USING BITMAP COMMENT ‘’,
INDEX idx_cause_type (cause_type) USING BITMAP COMMENT ‘’,
INDEX idx_cause_value (cause_value) USING BITMAP COMMENT ‘’,
INDEX idx_src_network_element_type (src_network_element_type) USING BITMAP COMMENT ‘’,
INDEX idx_dst_network_element_type (dst_network_element_type) USING BITMAP COMMENT ‘’
) ENGINE=OLAP
DUPLICATE KEY(request_time)
COMMENT “NAS话单”
PARTITION BY RANGE(request_time)(
PARTITION p20211110 VALUES [(‘2021-11-10 00:00:00’), (‘2021-11-11 00:00:00’)),
PARTITION p20211111 VALUES [(‘2021-11-11 00:00:00’), (‘2021-11-12 00:00:00’)),
PARTITION p20211112 VALUES [(‘2021-11-12 00:00:00’), (‘2021-11-13 00:00:00’)
)
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
“replication_num” = “2”,
“bloom_filter_columns” = “src_asset_id, dst_asset_id, md5”,
“colocate_with” = “nas”,
“dynamic_partition.enable” = “true”,
“dynamic_partition.time_unit” = “DAY”,
“dynamic_partition.time_zone” = “Asia/Shanghai”,
“dynamic_partition.start” = “-2147483648”,
“dynamic_partition.end” = “10”,
“dynamic_partition.prefix” = “p”,
“dynamic_partition.buckets” = “32”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”
);
【背景】
dw_nas_n1 数据量为20亿

select * from dw_nas_n1 limit 10
可以很快的出数据,个人理解为随机上一个分区的随机一个桶取了10条数据出来,所以很快

select * from dw_nas_n1 order by request_time limit 10
则要很长时间才能出数据,个人想法应该是判断第一个分区的数据量是不是大于10了,如果是则直接从第一个分区的32个桶里各取10条,合并数据后再取前10条。如果是这个逻辑耗时应该还好,但是实际效果肯定不是我想的这样。

哪位大佬可以给小弟指一条明路!!!这个表针对这个需求,要怎么优化!!谢谢!!

【StarRocks版本】例如:1.19.1

帮忙提供下profile信息

请问,profile是啥?
be.conf只加了push_write_mbytes_per_sec = 50
fe.conf只修改了-Xmx 大小

explain 结果如下
WORK ON CBO OPTIMIZER
PLAN FRAGMENT 0
OUTPUT EXPRS:1: request_time | 2: src_asset_id | 3: dst_asset_id | 4: id | 5: ran_ip | 6: src_asset_name | 7: ran_port | 8: src_mac | 9: src_network_element_type | 10: amf_ip | 11: dst_asset_name | 12: amf_port | 13: dst_mac | 14: dst_network_element_type | 15: procedure1 | 16: msg_bimap | 17: cause_type | 18: cause_value | 19: ue_id_type | 20: ue_id | 21: response_time | 22: ran_ue_ngap_id | 23: amf_ue_ngap_id | 24: request_body | 25: response_body | 26: md5 | 27: ingestion_time
PARTITION: UNPARTITIONED

RESULT SINK

2:MERGING-EXCHANGE
limit: 10
use vectorized: true

PLAN FRAGMENT 1
OUTPUT EXPRS:
PARTITION: RANDOM

STREAM DATA SINK
EXCHANGE ID: 02
UNPARTITIONED

1:TOP-N
| order by: <slot 1> 1: request_time ASC
| offset: 0
| limit: 10
| use vectorized: true
|
0:OlapScanNode
TABLE: dw_nas_n1
PREAGGREGATION: ON
partitions=2/17
rollup: dw_nas_n1
tabletRatio=64/64
tabletList=12890,12892,12894,12896,12898,12900,12902,12904,12906,12908 …
cardinality=2713900000
avgRowSize=176.09729
numNodes=0
use vectorized: true

参考https://forum.mirrorship.cn/t/topic/730

profile.txt (14.0 KB)
麻烦帮忙分析下,Fragment 0 的 EXCHANGE_NODE 耗时最长,其实每个Fragment里都有耗时长的 :joy:

看了下主要时间都花在了scan数据阶段,scan最快的节点7s+,另外两个节点都是花在io上,建议观察下其中两台节点的io负载是不是很高?下图中的时间是所有线程累加起来的

好的,感谢,我重点观察下 :pray:

明显是扫全表了啊