一篇Starrocks查询加速特性的测试报告

本文的所有测试数据集均采用Starrocks所提供的标准TPC-H数据集测试

测试环境如下：

机器类型：性能保障型X6

机器规格：16C64G （FE 三台 ，CN 三台）

云盘类型：ESSD_PL1

Starrocks配置：存算分离

数据集：TPC-H 100G 数据集

「pipeline_dop和Pipeline_engine 并发度测试」

Pipeline是指的实例查询并发度，Pipeline 是一组算子构成的链，开始算子为 SourceOperator，末尾算子为 SinkOperator，在Starrocks中默认是开启了pipeline_engine，表示系统会启动自动调整算子的并行度，然后对于并行度的大小设置，可以通过pipeline_dop参数来指定，pipeline_dop默认为0，表示系统自动调整每个Pipeline实例的并行度，不需要使用者进行指定配置（需要V3.0版本及以上），我们也可以选择指定并发实例数。

这里就来测试一下，根据手动指定1，3，8，16个并发和通过系统自动调整（参数为：0）的情况下，整个性能对比

通过测试对比发现，手动的调大Pipline_dop的并发度不会提升查询性能，具体要看机器资源大小，以及实际执行查询的SQL的复杂度以及数据量大小等多个因素决定，所以从测试结果来看，禁用PE和PE自动调节相比手动调大并发度效果都更好一些。

日常推荐来打开系统自动调节PE，并且并发度设置为0. 

「Query Profile启用和禁用对于整体查询性能的影响多大？」

Query Profile 记录了查询中涉及的所有工作节点的执行信息。您可以通过 Query Profile 快速识别影响 StarRocks 集群查询性能的瓶颈。

启用Query Profile：

SET enable_profile = true;

针对慢查询开启Query Profile

在生产环境中，通常不推荐全面启用 Query Profile 功能。这是因为 Query Profile 的数据采集和处理过程可能会为系统带来额外的负担。然而，如果需要捕捉到耗时的慢查询，就需要巧妙地使用这一功能。为此，您可以选择只对慢查询启用 Query Profile。这可以通过设置变量 big_query_profile_threshold 为一个大于 0s 的时间来实现。例如，若将此变量设置为 30s，意味着只有那些执行时间超过 30 秒的查询会启用 Query Profile 功能。这样既保证了系统性能，又能有效监控到慢查询。

-- 30 seconds
SET global big_query_profile_threshold = '30s';

-- 500 milliseconds
SET global big_query_profile_threshold = '500ms';

-- 60 minutes
SET global big_query_profile_threshold = '60m';

「启用Runtime Query Profile」

某些查询可能需要耗费较长时间执行，从数十秒到数小时不等。在查询完成之前，经常无法判断查询是否还在进行或是系统已经死机。为解决这个问题，StarRocks 在 v3.1 及以上版本中引入了 Runtime Query Profile 功能。此功能允许 StarRocks 在查询执行过程中，按固定时间间隔收集并上报 Query Profile 数据。我们能够实时了解查询的执行进度和潜在的瓶颈点，而不必等到查询完全结束。

当 Query Profile 启用时，该功能会自动启用，默认的上报时间间隔为 10 秒。可以通过修改变量 runtime_profile_report_interval 来调整对应的时间间隔：

SET runtime_profile_report_interval = 30;

1.   单并发下启用/禁用Query Profile的SQL执行时间差异对比

2.   3并发下启用/禁用Query Profile的SQL执行时间差异对比

3.  5并发下启用/禁用Query Profile的SQL执行时间差异对比

「Query Cache对于查询性能提升有多大幅度提升？」

StarRocks 提供的 Query Cache 特性，可以帮助您极大地提升聚合查询的性能。开启 Query Cache 后，每次处理聚合查询时，StarRocks 都会将本地聚合的中间结果缓存于内存中。这样，后续收到相同或类似的聚合查询时，StarRocks 就能够直接从 Query Cache 获取匹配的聚合结果，而无需从磁盘读取数据并进行计算，大大节省查询的时间和资源成本，并提升查询的可扩展性。在大量用户同时对复杂的大数据集执行相同或类似查询的高并发场景下，Query Cache 的优势尤为明显。

根据官方文档中描述，「部分查询首次发起，因为要填充 Query Cache，可能有轻微的性能惩罚，导致延迟加大」，说明开启 query cache 后首次查询的时候，查询延时会有所升高。

经过「首次查询」之后，query cache 已经得到构建，再次进行测试，查看query cache 带来的收益，查询延时降低了 20% 左右。

「查询队列在3.2.0版本的提升」

自 v2.5 版本起，StarRocks 支持查询队列功能。启用查询队列后，StarRocks 会在并发查询数量或资源使用率达到一定阈值时自动对查询进行排队，从而避免过载加剧。待执行查询将在队列中等待直至有足够的计算资源时开始执行。自 v3.1.4 版本起，StarRocks 支持设置资源组粒度的查询队列功能。

您可以为 CPU 使用率、内存使用率和查询并发度设置阈值以触发查询队列。

查询队列的很多特性的支持都是在V3.1.4之后才支持的，比如：资源组粒度查询队列、资源组粒度阈值、查询并发数量管理、根据查询并发数量动态调整查询并发度、通过SQL查看 SHOW RUNNING QUERIES，根据V3.1.0版本的查询队列功能测试效果并不是很理想，也就是没有达到限制住查询数量。

在进行V3.2.0和V3.1.0对比测试时候，整个查询队列可以达到预期的效果，在V3.1.0之前是BE自身管控的，V3.1.4之后，由FE来统一管理和调度。

关于查询队列更多内容请参考：https://docs.starrocks.io/zh/docs/administration/management/resource_management/query_queues/

查询队列的配置参数如下：

enable_query_queue_load = true
enable_query_queue_select = true
enable_query_queue_statistic = true

配置队列只执行一个SQL查询

query_queue_concurrency_limit = 1
query_queue_cpu_used_permille_limit = 0
query_queue_mem_used_pct_limit = 0.0

通过实际提交10个并发来测试，发现只有一个是在RUNNING的，其余的9个都在pending 。

如果想进一步交流的话，欢迎加我 V：kubedata

我们宗旨：分享创造价值、交流促进成长，欢迎关注：云原生大数据技术荟