Doris——高并发点查实践

一.参数预调

1. fe.conf

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

2. be.conf

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

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

3. 表属性

建表时调整即可。

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

4. 会话参数

-- 查看新优化器是否开启
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;

5. 用户参数

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

二.用例准备

1. 测试表创建

基于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" 
);

2. 测试表数据生成

测试表最终为4000万数据。

-- 源表为明细模型，目标表为开启了行存、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; -- 源表

3. 测试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标识，符合高并发点查条件。

4. prepare参数生成

获取prepare的csv参数数据。

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

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

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

上传至jmeter的home目录下。

5. JMX脚本准备

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

① JDBC连接管理器

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

直接影响效率的参数：

• useServerPrepStmts = true

• cachePrepStmts = true

② 线程组

主要用于控制压测的循环测试、线程数和压测时间等；本文默认设置的是100线程数压60秒。

③ CSV数据文件设置

需要注意文件名、即对应 [prepare参数生成] 的csv文件存放路径， 以及csv列对应的字段名称和分隔符的填写。

④ SQL测试脚本

选择Prepare模式随机传参，其中[Parameter values]和[Parameter types]需要和SQL中的[?]缺省值完全对齐。

三.高并发实测

Jmeter执行脚本（简易模式）。

./bin/jmeter -n -t row_part.jmx

最终随机压测结果的平均QPS为6W+/S。

压测过程中，BE的CPU大致使用50%（其中包括Jmeter进程的），内存使用率较低。

四.影响并发因素

1.预调参数：fe最大连接数，be的行缓存，建表开启行列并存等等
2.数据分区分桶太大（并行度过高）或太小（并发过小）都会影响效率
3.去除 jdbc url 中的useServerPrepStmts=true降为3W+/S
4.去除 jdbc url 中的cachePrepStmts=true; 参数时降为2W/S
5.线程数不宜过高，> 1W线程数时，降为2W+/S
6.fe的个数，合理增加fe可以增加qps