怎样做摄影网站,民用网络架构,网站建设专员一定要会网站建设吗,视屏网站制作【Apache Doris】如何实现高并发点查#xff1f;#xff08;原理实践全析#xff09; 一、背景说明二、原理介绍三、环境信息四、Jmeter初始化五、参数预调六、用例准备七、高并发实测八、影响因素九、总结 本文主要分享 Apache Doris 是如何实现高并发点查的#xff0c;以… 【Apache Doris】如何实现高并发点查原理实践全析 一、背景说明二、原理介绍三、环境信息四、Jmeter初始化五、参数预调六、用例准备七、高并发实测八、影响因素九、总结 本文主要分享 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 场景的性能得到进一步提升。下面就来实测一把吧。
三、环境信息
硬件信息
内存32GCPU16CCPU架构X86_64硬盘SSD单盘节点数1
软件信息
Doris版本2.0.3Manager版本23.10.3Jmeter版本5.6JDK版本1.8Mysql 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_connection10240 be.conf
为了增加行缓存命中率Doris单独引入了行存缓存行缓存复用了 Doris 中的 LRU Cache 机制来保障内存的使用。
-- 是否开启行缓存 默认不开启
disable_storage_row_cachefalse
-- 指定 Row cache 占用内存的百分比 默认 20% 内存
row_cache_mem_limit40% 表属性
建表时调整即可。
-- 必须为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链接配置 useServerPrepStmtstrue时会自动走短路径优化、即不走旧优化器
-- 如jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmtstrue
set global experimental_enable_nereids_plannerfalse;用户参数
-- 查看用户连接数
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
) ENGINEOLAP
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_partkey1,
concat(p_name, 1),
p_mfgr ,
p_category,
p_brand,
p_color,
p_typeL,
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_plannerfalse;-- 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?characterEncodingutf8amp;useSSLfalseamp;useServerPrepStmtstrue;cachePrepStmtstrueamp;prepStmtCacheSqlLimit1024直接影响效率的参数
useServerPrepStmts truecachePrepStmts 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进程的内存使用率较低。 八、影响因素
常规配置
未按【参数预调】进行调整未按【JMX脚本准备】进行合理设置数据分区分桶太大并行度过高或太小并发过小都会影响效率
jdbc参数
仅去除 jdbc url 中的useServerPrepStmtstrue; 参数时降为3W/S。 仅去除 jdbc url 中的cachePrepStmtstrue; 参数时降为2W/S。 线程数
不宜过高例如 1W线程数时降为2W/S。 不宜过少例如5个线程数时降为1W/S。 具体线程数设置需要根据【环境信息】进行对比调整。
fe个数
合理范围内1个fe可提高一定的并发量。如果多加fe、QPS都没有增长需要定位是否存在其它影响因素。
prepare参数分布
【prepare参数生成】过于集中、可能导致集中查某几台be影响效率需要足够分散。
资源瓶颈
如果上述原因都符合预期且CPU还相对空闲的情况下QPS依旧无法提升需要排查网络或IO等资源是否遇到了瓶颈。
其它
欢迎各位看官补充。
九、总结
Apache Doris 基于MPP架构、列存、分区分桶、向量化引擎、索引视图和基准优化等方面实现了高性能并发查询。在此基础上引入了行存、短查询路径和Prepared Statement特性实现了高并发点查询效果俱佳。如果有相关场景的同学欢迎实测交流。
至此【Apache Doris】如何实现高并发点查 分享结束查阅过程中若遇到问题欢迎留言交流。
