别再靠堆机器了！Doris 高并发点查让我的系统起飞还降本

❝每位数据员都有一个大促梦，梦里系统性能炸裂，响应秒回，老板笑逐颜开。 可现实中，双十一零点刚到，既要处理业务数据又要做数据分析，电商系统就像堵车的高速公路，数据库 CPU 飙升，响应时间从毫秒飞升到秒级，客服电话被打爆... 直到 Apache Doris 2.0 横空出世，带来了高并发点查"神器"。直接给数据库装上了"火箭推进器"，让系统性能一飞冲天。 一位资深数据架构师笑言："以前我们靠堆机器扛并发，现在有了 Doris 高并发点查优化，服务器都闲得长草了。" 如果你也在为系统性能发愁，不妨跟我一起来看看Doris这个"性能杀手锏"是如何炼成的。

Doris高并发点查实战：从理论到实践

创业公司小张正在开发一个电商系统，每到大促活动时，系统面临着海量用户同时查询商品详情，还需要做数据的实时统计分析。这时，一款OLAP的并发性能就显得尤为重要。

Apache Doris 2.0引入了一系列高并发点查优化特性，让这类场景有了新的解决方案。作为一名数据库工程师，深入理解这些优化机制对提升系统性能至关重要。

在深入优化细节之前，我们先看看高并发点查场景的典型特征：

小张的电商系统中，当用户浏览商品时，系统需要根据商品ID快速查询商品详情（大宽表）。这类查询虽然数据量不大，但并发量高，且要求响应时间极短。

传统的MPP分析型数据库在这类场景下会遇到瓶颈。列式存储虽然适合OLAP场景，但在查询整行数据时需要读取多个列文件，IO开销大。查询规划流程复杂，解析SQL和生成执行计划的开销也不容忽视。

Doris 2.0针对这些问题推出四大优化：

行存优化：在列存之外额外存储一份行格式数据。创建表时指定"store_row_column" = "true"即可开启。对于宽表场景特别有效，一次IO就能读取完整行数据。

查询短路径：FE识别到点查模式后，生成轻量级执行计划，避免复杂的MPP调度开销。前提是查询条件必须包含完整主键。

预处理语句：支持MySQL协议的PreparedStatement，SQL解析结果缓存在会话中重复使用，显著降低CPU开销。

行级缓存：在BE节点引入独立的行级缓存，避免与分析型查询竞争Page Cache资源。通过参数"row_cache_mem_limit"控制缓存大小。

这些优化组合使用，让Doris在高并发点查场景下表现出色。在同等硬件配置下，优化后的系统可以轻松支撑数万QPS，响应时间控制在毫秒级别。

优化实践与性能调优

小张在实施Doris高并发点查优化时，首先升级到Doris最新的Release稳定版本，接着需要从表设计、参数配置和查询优化三个层面入手：

1. 表设计是优化的基础

创建商品表时需要注意：选择Unique Key MOW模型，指定商品ID作为主键；开启行存、MOW模型和轻量级Schema变更。

典型建表语句如下：

CREATE TABLE product_info (
    product_id BIGINT,
    nameVARCHAR(100),
    price DECIMAL(10,2),
    stock INT,
    description TEXT
) ENGINE=OLAP
UNIQUEKEY(product_id)
DISTRIBUTEDBYHASH(product_id) BUCKETS 10
PROPERTIES (
    "store_row_column" = "true",
    "enable_unique_key_merge_on_write" = "true",
    "light_schema_change" = "true"
);

2. 参数配置也很关键

FE节点需要调整最大连接数，BE节点开启行缓存并分配合适内存（按需优化，默认可以先不调整）：

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

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

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

3. 查询优化

在应用层，小张采用PreparedStatement方式发送查询。

Java代码示例：

String url = "jdbc:mysql://doris:9030/mall?useServerPrepStmts=true";
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM product_info WHERE product_id = ?"
);

// 重复使用PreparedStatement执行查询
stmt.setLong(1, productId);
ResultSet rs = stmt.executeQuery();
...

压测结果显示，优化后的系统在16核32G配置下轻松达到6万+QPS，P99延迟控制在200ms以内。内存使用率平稳，CPU使用率约50%，还有很大提升空间。

最后，小张总结了下遇到的典型问题及解决方案：

1️⃣ QPS忽高忽低：检查参数分布是否均匀，调整分区分桶数量。

2️⃣ latency不稳定：配置JDBC负载均衡，将请求分散到多个FE节点。

3️⃣ 资源利用不足：适当增加并发线程数，但要注意不要超过系统承载能力。

据说，有其他Doris用户基于高并发点查特性的实现70W+的QPS了，且在生产稳定运行至今！

生产环境建议：先小范围试点，逐步扩大优化范围；保持监控告警，及时发现和解决问题；定期评估Doris性能，根据业务数据增长调整资源配置。

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！