本文主要分享 Apache Doris 是如何实现高并发点查的，以及如何实测单节点上万QPS。

一、背景说明

Apache Doris 是一款基于 MPP 架构的高性能、实时的分析型数据库。它可以在多个节点上并行处理查询，显著提高查询效率，且默认以列存格式引擎构建。这种格式非常适合进行数据分析，因为它可以有效地压缩数据，并且在执行查询时只需要读取相关的列。但有些高并发服务场景中，用户需要频繁获取整行数据，如果表较宽时，列存的IO也随之被放大。

Apache Doris 中 FE 是 SQL 查询的访问层服务，使用 Java 编写，分析和解析 SQL 也会导致高并发查询的高 CPU 开销，且其查询引擎和计划对于某些简单的查询（例如点查询）而言太重了。

那么，Apache Doris 是如何实现高并发查询以及如何实现高并发点查的呢？

二、原理介绍

Apache Doris 能够实现高并发查询的能力主要是通过以下几个方面：

MPP架构

基于大规模并行处理（Massively Parallel Processing, MPP）架构设计，它可以将查询分解为多个任务，在多个节点上并行执行这些任务，使得系统可以通过增加更多的计算资源来线性扩展其查询处理能力。

列式存储

使用列式存储格式，这意味着对于任何给定的查询，它只需要读取涉及到的列，而不是整行数据。这减少了磁盘I/O压力，因为只有必需的数据被加载到内存中。

数据分片

分区和分桶裁剪在 Apache Doris 中也是实现高并发查询的重要机制。这两种技术可以帮助更有效地组织数据，提高查询效率，尤其是在面对大规模数据集时。

向量化查询执行

Apache Doris 实现了向量化查询处理，这意味着在执行操作时，它可以一次处理数据列的一整块，而不是逐行处理。这样可以大大提高CPU的利用率，降低每个数据点的处理开销。

索引和物化视图

Apache Doris 支持创建索引和物化视图来加速查询，减少扫描行数和避免了大量的现场计算，例如倒排、ZoneMap、Bloom Filter和Bitmap 等索引和预计算物化。

统计信息和成本基准优化

Apache Doris 会收集表和列的统计信息，并使用这些信息来优化查询计划，选择最佳的执行路径。

...... 此处省略上万字

基于【背景说明】和上述内容，Apache Doris 可实现单节点上千 QPS 的并发支持。但在一些超高并发要求（例如上万 QPS）的 Data Serving 场景中，仍然存在瓶颈。

因此，Apache Doris 引入了如下几个2.0新特性从降低 SQL 内存 IO 开销、提升点查执行效率以及降低 SQL 解析开销这三个设计点出发，进行一系列优化：

行式存储格式（Row Store Format）

Apache Doris 支持用户在建表时，通过 store_row_column 表属性另存一份行数据（列存+行存）。在单次检索整行数据时效率更高，减少磁盘访问次数。

行存缓存（Row Cache）

Apache Doris 有针对列数据的Page Cache。但如果一行包括多列数据，这类缓存可能会被大查询给刷掉，为了增加缓存命中率、提升点查询的性能，Apache Doris 引入了行存缓存（Row Cache）。

点查询短路径优化（Short-Circuit）

通常而言，一个查询会在 FE 端进行SQL语句解析、生成执行计划后下发到 BE 进行计算获取结果。但对于高并发点查场景，则不适合这个长流程。

因此，Apache Doris 实现了点查询的短路径优化。当FE接收到此类查询时，会在规划器中生成轻量级的 Short-Circuit Plan，避免生成复杂的 Fragment Plan 并消除了在 MPP 查询框架下执行调度的性能开销。

预处理语句优化（Prepared Statement）

高并发查询中的 CPU 开销可以部分归因于 FE 层分析和解析 SQL 的 CPU 计算，为了解决这个问题，Apache Doris 在 FE 端提供了与 MySQL 协议完全兼容的预处理语句（Prepared Statement）。

通过在 Session 内存 HashMap 中缓存预先计算好的 SQL 和表达式，在后续查询时直接复用缓存对象，避免这些结构在序列化和反序列化时造成CPU热点。

基于以上一系列优化，帮助 Apache Doris 在 Data Serving 场景的性能得到进一步提升。下面就来实测一把吧。

三、环境信息

硬件信息

内存：32G
CPU：16C
CPU架构：X86_64
硬盘：SSD单盘
节点数：1

软件信息

Doris版本：2.0.3
Manager版本：23.10.3
Jmeter版本：5.6
JDK版本：1.8
Mysql Driver版本：8.0
系统：CentOS

四、Jmeter初始化

本文基于Jmeter进行高并发实测。

安装部署

非GUI使用模式。

# 官方下载包 
wget https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-5.6.tgz 

# 解压包 tar -zvf apache-jmeter-5.6.tgz 
# 解压后目录结构和本地UI模式一

上传mysql-connector包到lib目录下。

参数说明

命令模版和参数说明，详情可阅：

https://jmeter.apache.org/usermanual/get-started.html#non_gui

jmeter -n -t <脚本文件名>.jmx -l <本不存在的结果文件名>.jtl -e -o <存放html报告的空目录> 

-h 帮助 
-n 非GUI模式 
-t 测试脚本.jmx的路径和文件名称 
-l 测试结果存放的路径和文件名称 (要确保之前没有运行过，即xxx.jtl不存在，不然报错)，会自动创建 
-r 启动jmeter.properties文件中指定的所有远程服务器 
-e 在脚本运行结束后生成html报告 
-o 用于存放html报告的目录（目录要为空，不然报错），会自动创建

五、参数预调

fe.conf

-- 每个 FE 的最大连接数，默认值：1024
qe_max_connection=10240

be.conf

为了增加行缓存命中率，Doris单独引入了行存缓存；行缓存复用了 Doris 中的 LRU Cache 机制来保障内存的使用。

-- 是否开启行缓存， 默认不开启
disable_storage_row_cache=false 
-- 指定 Row cache 占用内存的百分比， 默认 20% 内存
row_cache_mem_limit=40%

表属性

建表时调整即可。

-- 必须为Unique Key表 
-- 开启行存
"store_row_column" = "true" 
-- 开启mow模式
"enable_unique_key_merge_on_write" = "true" 
-- 开启light 
schema change: "light_schema_change" = "true"

会话参数

-- 查看新优化器是否开启
show variables like '%enable_nereids_planner%'; 

-- 非必选，jdbc链接配置 useServerPrepStmts=true时，会自动走短路径优化、即不走旧优化器 
-- 如：jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true 
set global experimental_enable_nereids_planner=false;

用户参数

-- 查看用户连接数
SHOW PROPERTY FOR 'root' LIKE '%max_user_connections%';
-- 设置连接数
SET PROPERTY FOR 'root' 'max_user_connections' = '10000';

六、用例准备

测试表创建

基于Star Schema Benchmark的part零件信息表调整创建，共9个字段、2个联合Key。

CREATE TABLE `row_part` (
`p_partkey` int(11) NULL,
`p_name` varchar(69) NULL,
`p_mfgr` varchar(21) NULL,
`p_category` varchar(24) NULL,
`p_brand` varchar(30) NULL,
`p_color` varchar(36) NULL,
`p_type` varchar(78) NULL,
`p_size` int(11) NULL,
`p_container` varchar(33) NULL
) ENGINE=OLAP
Unique KEY(`p_partkey`, `p_name`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`p_partkey`, `p_name`) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"light_schema_change" = "true",
"store_row_column" = "true" ,
"enable_unique_key_merge_on_write" = "true" 
);

测试表数据生成

测试表最终为3200万数据。

-- 源表为明细模型，目标表为开启了行存、mow和light_schema_change的unique模式表
-- 通过对字段+数字等方式去重快速造数
insert into row_part -- 目标测试表
select 
`p_partkey`+1, 
concat(`p_name`, '1'), 
`p_mfgr` ,
`p_category`,
`p_brand`,
`p_color`,
`p_type`L,
`p_size`,
`p_container`
from part; -- 源表

测试SQL

测试SQL如下。

select * from ssb_test.row_part
where p_partkey = ? and p_name = ?

确认是否符合高并发点查条件，即该SQL是否走短路径（当前版本需要where带上所有key才可触发）。

-- 本地client查验需要先关闭新优化器
set experimental_enable_nereids_planner=false;

--  ScanNode中是否有SHORT-CIRCUIT标识
explain 
select * from ssb_test.row_part
where p_partkey = 5 and p_name = 'blush chiffon';

如下图所示，ScanNode中有SHORT-CIRCUIT标识，符合高并发点查条件。

prepare参数生成

获取prepare的csv参数数据。

-- 
select 
p_partkey,
p_name 
from ssb_test.row_part
limit 3000;

导出查询结果集（通过dbeaver自身的功能导出csv数据作为prepare参数）。

导出后会在相应目录生成对应文件（需要手动去除第一行的字段名）。

上传至jmeter的home目录下。

JMX脚本准备

可以在本地jmeter客户端配置后保存生成.jmx再上传至jmeter的home目录下。

① JDBC连接管理器

jdbc:mysql:loadbalance://fe_ip:9030/db?characterEncoding=utf8&amp;useSSL=false&amp;useServerPrepStmts=true;cachePrepStmts=true&amp;prepStmtCacheSqlLimit=1024

直接影响效率的参数：