ClickHouse与Elasticsearch压测实践
字数 2251 2025-08-12 11:34:19

ClickHouse与Elasticsearch性能压测实践教学文档

1. 需求分析

1.1 压测对象分析

ClickHouse简介

  • 真正的列式数据库管理系统(DBMS)
  • 数据始终按列存储，包括矢量(向量或列块)执行
  • 采用"矢量化查询执行"降低数据处理开销

Elasticsearch简介

  • 开源的分布式、RESTful风格的搜索和数据分析引擎
  • 底层基于Apache Lucene
  • 特点：
    • 分布式实时文档存储
    • 每个字段可被索引与搜索
    • 支持PB级结构化/非结构化数据
    • 可扩展至上百个服务节点

压测目的

  • 验证ClickHouse和Elasticsearch在复杂业务查询场景下的抗压能力
  • 为双十一大促活动峰值业务稳定性做准备
  • 发现性能瓶颈并进行针对性优化

1.2 压测目标

选择接口原因

  • 接口queryOBBacklogData复杂度高，包含5次查询：
    1. 越库信息-待越库件数&待越库任务数
    2. 集合任务信息-待分配订单
    3. 拣货信息-待拣货件数&待拣货任务数
    4. 分播信息-待分播件数&待分播任务
    5. 发货信息-待发货件数

查询数据量

  1. 待越库信息：720,817行
  2. 待分配订单：153,118行
  3. 待拣货信息：2,673,536行
  4. 待分播信息：1,448,149行
  5. 待发货信息：99,591行

2. 测试环境准备

  • 使用与线上完全一致的环境配置
  • 确保性能压测结果具有参考价值

3. 监控工具准备

  1. JVM监控：http://origin.jd.com/

    • 监控JVM状态
    • 方法级别监控（秒级支持）

  2. 异常分析：http://console.jex.jd.com/

    • 异常堆栈监控
    • 火焰图监控
    • 线程堆栈分析

  3. 数据库监控：http://x.devops.jdcloud.com/

    • 查看ClickHouse/Elasticsearch各节点CPU使用率

  4. 服务器监控：http://dashboard.fireeye.jdl.cn/

    • 监测应用服务器CPU/内存使用率

4. 压测执行及分析

4.1 压测工具

  • Forcebot：http://forcebot.jd.com
    • 性能测试平台
    • 支持同步/异步/集合点等多种发压模式
    • 文档：http://doc.jd.com/forcebot/helper/

4.2 压测数据设计

关键名词解释

  • DBCP：数据库连接池，Apache项目

    • 预先建立连接放在内存中
    • 应用程序从连接池申请/归还连接
    • 实现连接复用，减少资源消耗

  • maxTotal：连接池中总连接的最大数量（默认8）

  • max_thread：ClickHouse处理SQL请求的最大线程数（默认等于服务器核心数）

  • coordinating：ES协调节点数

    • 负责请求转发和响应处理
    • 执行轻量级操作

  • 数据节点：ES存储索引数据的节点

    • 执行文档增删改查和聚合操作
    • 对CPU/内存/IO要求高

ClickHouse压测配置

  • 数据服务：32C128G 6节点2副本
  • 应用服务器：4核8G 2台
  • maxTotal=16

发现问题：

  • 并发用户数增加至8后，ClickHouse CPU稳定在40-50%不再增加
  • 应用服务器CPU稳定在25%
  • 原因是bigdata dbcp默认最大线程数为8

调整后测试：

  • 设置maxTotal=50
  • 调整max_thread不同值，保持数据库节点CPU使用率约50%

Elasticsearch压测配置

  • 数据服务：32C128G 6节点2副本
  • 应用服务器：4核8G 2台

测试指标调整：

  1. coordinating=2，数据节点=4，poolSize=400

    • 发现coordinating节点CPU达51.69%，负载均衡受限

  2. coordinating=4，数据节点=5，poolSize=800

    • 发现CPU使用率约40%时上不去
    • activeCount已达797，需增加poolSize

  3. coordinating=4，数据节点=5，poolSize=1200

    • coordinating节点仍需扩容

发现问题：

  1. bigdata应用线程池最大线程数8成为瓶颈
  2. warehouse集群协调节点配置低
  3. clickhouse-jdbc JavaCC解析SQL效率低

4.3 结果分析

测试结论

ClickHouse性能：

max_thread 最大TPS TP99(ms)
32 37 122
2 66 155
1 86 206
  • 支持一定并发，可通过调整max_thread提高并发
  • 并发能力与线程数设置相关

Elasticsearch性能：

  • TPS：192
  • TP99：3050ms

对比结论：

  • Elasticsearch并发支持更好但响应速度慢
  • ClickHouse响应速度快但并发能力较低
  • ClickHouse足以支撑当前业务需求

优化建议

  1. Elasticsearch优化：

    • 对协调节点进行扩容

  2. 应用层优化：

    • bigdata应用线程池最大线程数调高至200
    • bigdata应用dbcp线程池maxTotal设置为50
    • 读取配置文件工具类增加内存缓存

  3. ClickHouse优化：

    • 考虑优化clickhouse-jdbc的SQL解析效率
ClickHouse与Elasticsearch性能压测实践教学文档 1. 需求分析 1.1 压测对象分析 ClickHouse简介 真正的列式数据库管理系统(DBMS) 数据始终按列存储，包括矢量(向量或列块)执行 采用"矢量化查询执行"降低数据处理开销 Elasticsearch简介 开源的分布式、RESTful风格的搜索和数据分析引擎 底层基于Apache Lucene 特点： 分布式实时文档存储 每个字段可被索引与搜索 支持PB级结构化/非结构化数据 可扩展至上百个服务节点 压测目的 验证ClickHouse和Elasticsearch在复杂业务查询场景下的抗压能力 为双十一大促活动峰值业务稳定性做准备 发现性能瓶颈并进行针对性优化 1.2 压测目标 选择接口原因 接口 queryOBBacklogData 复杂度高，包含5次查询： 越库信息-待越库件数&待越库任务数 集合任务信息-待分配订单 拣货信息-待拣货件数&待拣货任务数 分播信息-待分播件数&待分播任务 发货信息-待发货件数 查询数据量 待越库信息：720,817行 待分配订单：153,118行 待拣货信息：2,673,536行 待分播信息：1,448,149行 待发货信息：99,591行 2. 测试环境准备 使用与线上完全一致的环境配置 确保性能压测结果具有参考价值 3. 监控工具准备 JVM监控 ：http://origin.jd.com/ 监控JVM状态 方法级别监控（秒级支持） 异常分析 ：http://console.jex.jd.com/ 异常堆栈监控 火焰图监控 线程堆栈分析 数据库监控 ：http://x.devops.jdcloud.com/ 查看ClickHouse/Elasticsearch各节点CPU使用率 服务器监控 ：http://dashboard.fireeye.jdl.cn/ 监测应用服务器CPU/内存使用率 4. 压测执行及分析 4.1 压测工具 Forcebot ：http://forcebot.jd.com 性能测试平台 支持同步/异步/集合点等多种发压模式 文档：http://doc.jd.com/forcebot/helper/ 4.2 压测数据设计 关键名词解释 DBCP ：数据库连接池，Apache项目 预先建立连接放在内存中 应用程序从连接池申请/归还连接 实现连接复用，减少资源消耗 maxTotal ：连接池中总连接的最大数量（默认8） max_ thread ：ClickHouse处理SQL请求的最大线程数（默认等于服务器核心数） coordinating ：ES协调节点数 负责请求转发和响应处理 执行轻量级操作 数据节点 ：ES存储索引数据的节点 执行文档增删改查和聚合操作 对CPU/内存/IO要求高 ClickHouse压测配置 数据服务：32C128G 6节点2副本 应用服务器：4核8G 2台 maxTotal=16 发现问题 ： 并发用户数增加至8后，ClickHouse CPU稳定在40-50%不再增加 应用服务器CPU稳定在25% 原因是bigdata dbcp默认最大线程数为8 调整后测试 ： 设置maxTotal=50 调整max_ thread不同值，保持数据库节点CPU使用率约50% Elasticsearch压测配置 数据服务：32C128G 6节点2副本 应用服务器：4核8G 2台 测试指标调整 ： coordinating=2，数据节点=4，poolSize=400 发现coordinating节点CPU达51.69%，负载均衡受限 coordinating=4，数据节点=5，poolSize=800 发现CPU使用率约40%时上不去 activeCount已达797，需增加poolSize coordinating=4，数据节点=5，poolSize=1200 coordinating节点仍需扩容 发现问题 ： bigdata应用线程池最大线程数8成为瓶颈 warehouse集群协调节点配置低 clickhouse-jdbc JavaCC解析SQL效率低 4.3 结果分析 测试结论 ClickHouse性能 ： | max_ thread | 最大TPS | TP99(ms) | |------------|---------|----------| | 32 | 37 | 122 | | 2 | 66 | 155 | | 1 | 86 | 206 | 支持一定并发，可通过调整max_ thread提高并发 并发能力与线程数设置相关 Elasticsearch性能 ： TPS：192 TP99：3050ms 对比结论 ： Elasticsearch并发支持更好但响应速度慢 ClickHouse响应速度快但并发能力较低 ClickHouse足以支撑当前业务需求 优化建议 Elasticsearch优化 ： 对协调节点进行扩容 应用层优化 ： bigdata应用线程池最大线程数调高至200 bigdata应用dbcp线程池maxTotal设置为50 读取配置文件工具类增加内存缓存 ClickHouse优化 ： 考虑优化clickhouse-jdbc的SQL解析效率