ClickHouse与Elasticsearch压测实践 | 京东物流技术团队-六虎

1 需求剖析

1.1 剖析压测方针

1）什么是ClickHouse 和Elasticsearch

ClickHouse 是一个真正的列式数据库办理系统（DBMS)。在 ClickHouse 中，数据始终是按列存储的，包括矢量（向量或列块）履行的进程。只需有或许，操作都是基于矢量进行分配的，而不是单个的值，这被称为矢量化查询履行，它有利于降低实践的数据处理开销。

Elasticsearch是一个开源的分布式、RESTful 风格的查找和数据剖析引擎，它的底层是开源库Apache Lucene。它能够被这样准确地描述：

一个分布式的实时文档存储，每个字段能够被索引与查找
一个分布式实时剖析查找引擎
能担任上百个服务节点的扩展，并支撑 PB 级别的结构化或者非结构化数据

2）为什么要对他们进行压测

众所周知，ClickHouse在根本场景表现非常优异，功能优于ES，但是咱们实践的事务查询中有很多是杂乱的事务查询场景，乃至是大数量的查询，所以为了在双十一事务峰值来到前，保证大促活动峰值事务稳定性，针对ClickHouse 和Elasticsearch在咱们实践事务场景中是否拥有优异的抗压能力，经过这次功能压测，探测系统中的功能瓶颈点，进行针对性优化，然后提高系统功能。

1.2 制定压测方针

为什么会选择这个（queryOBBacklogData）接口呢？

1）从杂乱度来看，接口（queryOBBacklogData）查询了5次，代码如下：

/**
 * 切ck-queryOBBacklogData
 * @param queryBO
 * @return
 */
public OutboundBacklogRespBO queryOBBacklogDataCKNew(OutboundBacklogQueryBO queryBO) {
    log.info(" queryOBBacklogDataCK入参：{}", JSON.toJSONString(queryBO));
    // 公共条件-卡最近十天时间
    String commonStartTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, -10);
    String commonEndTime = DateUtils.getTime(DateUtil.format(new Date(), DateUtil.FORMAT_DATE), DateUtils.ELEVEN_AM, 1, 1);
    // 越库信息-待越库件数&待越库使命数
    WmsObCrossDockQueryBo wmsObCrossDockQueryBo = wmsObCrossDockQueryBoBuilder(queryBO,commonStartTime, commonEndTime);
    log.info("queryOBBacklogDataCK-wmsObCrossDockQueryBo: {}", JSON.toJSONString(wmsObCrossDockQueryBo));
    CompletableFuture<OutboundBacklogRespBO> preCrossDockInfoCF = CompletableFuture.supplyAsync(
            () -> wmsObCrossDockMapper.preCrossDockInfo(wmsObCrossDockQueryBo), executor);
    // 调集使命信息-待分配订单
    WmsObAssignOrderQueryBo wmsObAssignOrderQueryBo = wmsObAssignOrderQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
    log.info("queryOBBacklogDataCK-wmsObAssignOrderQueryBo: {}", JSON.toJSONString(wmsObAssignOrderQueryBo));
    CompletableFuture<Integer> preAssignOrderQtyCF = CompletableFuture.supplyAsync(
            () -> wmsObAssignOrderMapper.preAssignOrderInfo(wmsObAssignOrderQueryBo), executor);
    // 拣货信息-待拣货件数&待拣货使命数
    WmsPickTaskQueryBo wmsPickTaskQueryBo = wmsPickTaskQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
    log.info("queryOBBacklogDataCK-wmsPickTaskQueryBo: {}", JSON.toJSONString(wmsPickTaskQueryBo));
    CompletableFuture<OutboundBacklogRespBO> prePickingInfoCF = CompletableFuture.supplyAsync(
            () -> wmsPickTaskMapper.pickTaskInfo(wmsPickTaskQueryBo), executor);
    // 分播信息-待分播件数&待分播使命
    WmsCheckTaskDetailQueryBo wmsCheckTaskDetailQueryBo = wmsCheckTaskDetailQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
    log.info("queryOBBacklogDataCK-wmsCheckTaskDetailQueryBo: {}", JSON.toJSONString(wmsCheckTaskDetailQueryBo));
    CompletableFuture<OutboundBacklogRespBO> preSowInfoCF = CompletableFuture.supplyAsync(
            () -> wmsCheckTaskDetailMapper.checkTaskDetailInfo(wmsCheckTaskDetailQueryBo), executor);
    // 发货信息-待发货件数
    WmsOrderSkuQueryBo wmsOrderSkuQueryBo = wmsOrderSkuQueryBoBuilder(queryBO, commonStartTime, commonEndTime);
    log.info("queryOBBacklogDataCK-wmsOrderSkuQueryBo: {}", JSON.toJSONString(wmsOrderSkuQueryBo));
    CompletableFuture<Integer> preDispatchCF = CompletableFuture.supplyAsync(
            () -> wmsOrderSkuMapper.preDispatchInfo(wmsOrderSkuQueryBo), executor);
    return processResult(preCrossDockInfoCF, preAssignOrderQtyCF, prePickingInfoCF, preSowInfoCF, preDispatchCF);
}

2）接口（queryOBBacklogData），一共查询了5个表，如下：

wms.wms_ob_cross_dock
wms.wms_ob_assign_order
wms.wms_picking_task.
wms.wms_check_task_detail
wms.wms_order_sku

3）查询的数据量，如下：

select
   (ifnull(sum(m.shouldBeCrossedDockQty),
   0) -
        ifnull(sum(m.satisfiedCrossedDockQty),
   0)) as preCrossStockSkuQty,
   count(m.docId) as preCrossStockTaskQty
from
   wms.wms_ob_cross_dock m final
    prewhere
        m.createTime >= '2021-12-03 11:00:00'
   and m.createTime <= '2021-12-14 11:00:00'
   and m.warehouseNo = '279_1'
   and m.orderType = '10'
   and tenantCode = 'TC90230202'
where
   m.deleted = 0
   and m.deliveryDestination = '2'
   and m.shipmentOrderDeleted = 0
   and m.status = 0

从上面SQL截图能够看出，查询待越库件数&待越库使命数，共读了720817行数据

select count(distinct m.orderNo) as preAssignedOrderQty
from wms.wms_ob_assign_order m final
    prewhere
        m.createTime >= '2021-12-03 11:00:00'
        and m.createTime <= '2021-12-14 11:00:00'
        and m.warehouseNo = '361_0'
        and tenantCode = 'TC90230202'
where m.taskassignStatus = 0
  and m.deliveryDestination = 2
  and m.stopProductionFlag = 0
  and m.deleted = 0
  and m.orderType = 10

从上面SQL截图能够看出，查询调集使命信息-待分配订单，共读了153118行数据

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))),
             toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty,
       count(distinct m.taskNo) as prePickingTaskQty
from wms.wms_picking_task m final
    prewhere
        m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
        and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
        and m.warehouseNo = '286_1'
        and tenantCode = 'TC90230202'
where m.pickingTaskDeleted = 0
  and m.deliveryDestination = 2
  and m.pickLocalDetailDeleted = 0
  and m.shipmentOrderDeleted = 0
  and m.orderType = 10
  and (m.operateStatus = 0 or m.operateStatus = 1)

从上面SQL截图能够看出，查询拣货信息-待拣货件数&待拣货使命数，共读了2673536行数据

select minus(toInt32(ifnull(sum(m.locateQty), toDecimal64(0, 4))),
             toInt32(ifnull(sum(m.pickedQty), toDecimal64(0, 4)))) as prePickingSkuQty,
       count(distinct m.taskNo) as prePickingTaskQty
from wms.wms_picking_task m final
prewhere
        m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
        and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
        and m.warehouseNo = '279_1'
        and tenantCode = 'TC90230202'
where m.pickingTaskDeleted = 0
  and m.deliveryDestination = 2
  and m.pickLocalDetailDeleted = 0
  and m.shipmentOrderDeleted = 0
  and m.orderType = 10
  and (m.operateStatus = 0 or m.operateStatus = 1)

从上面SQL截图能够看出，查询分播信息-待分播件数&待分播使命，共读了1448149行数据

select ifnull(sum(m.unTrackQty), 0) as unTrackQty
from wms.wms_order_sku m final
    prewhere
        m.shipmentOrderCreateTime >= '2021-12-03 11:00:00'
        and m.shipmentOrderCreateTime <= '2021-12-14 11:00:00'
        and m.warehouseNo = '280_1'
        and m.orderType = '10'
        and m.deliveryDestination = '2'
        and tenantCode = 'TC90230202'
where m.shipmentOrderDeleted <> '1'
  and m.ckDeliveryTaskDeleted <> '1'
  and m.ckDeliveryTaskDetailDeleted <> '1'
  and m.ckDeliveryTaskStatus in ('1','0','2')

从上面SQL截图能够看出，查询发货信息-待发货件数，共读了99591行数据

2 测验环境预备

为了尽或许发挥功能压测作用，功能压测环境应当尽或许同线上环境一致，所以咱们运用了和线上相同的环境

3 收集东西预备

监控东西

origin.jd.com/：监控JVM，办法级别监控（供给秒级支撑）
console.jex.jd.com/：供给反常仓库监控，火焰图监控、线程仓库剖析
x.devops.jdcloud.com/：支撑检查clickhouse/Elasticsearch数据库服务每个节点的cpu运用率
dashboard.fireeye.jdl.cn/：监测应用服务器cpu运用率、内存运用率

4 压测履行及结果剖析

4.1 编写压测脚本东西

Forcebot（forcebot.jd.com）是专门为开发人员、测验人员供给的功能测验平台，经过编写脚本、装备监控、设置场景、发动使命、实时监控、日志定位、导出陈述一系列操作流程来完结功能测验，灵活的脚本装备满足同步、异步、调集点等多种发压形式。

协助文档（doc.jd.com/forcebot/he…

4.2 规划压测数据

4.2.1 前期压测中名词解释

DBCP：数据库衔接池，是 apache 上的一个Java衔接池项目。DBCP经过衔接池预先同数据库建立一些衔接放在内存中(即衔接池中)，应用程序需求建立数据库衔接时直接到从接池中申请一个衔接运用，用完后由衔接池收回该衔接，然后到达衔接复用，减少资源耗费的目的。
maxTotal：是衔接池中总衔接的最大数量，默许值8
max_thread：clickhouse中底层装备，处理SQL恳求时运用的最大线程数。默许值是clickhouse服务器的核心数量。
coordinating：和谐节点数，首要作用于恳求转发，恳求呼应处理等轻量级操作
数据节点：首要是存储索引数据的节点，首要对文档进行增修改查操作，聚合操作等。数据节点对cpu，内存，io要求较高，在优化的时候需求监控数据节点的状况，当资源不够的时候，需求在集群中添加新的节点

4.2.2 压测数据

clickhouse数据服务：32C_128G_6节点_2副本
应用服务器：4核8G_2
maxTotal=16

注：每次压测前，一定要调查每个数据节点的cpu运用率

注：从上面压测进程中，序号6-12能够看出，并发用户数在添加，但tps没有起伏变化，检查发现bigdata dbcp数据库链接池最大线程数未装备，默许最大线程数是8，并发用户数添加至8以后，clickhouse cpu稳定在40%~50%之间不再添加，应用服务器CPU稳定在25%左右。

之后咱们调整maxTotal=50，经过调整max_thread不同的值，数据库节点CPU运用率坚持在50%左右，来检查相应的监测数据目标：应用服务CPU运用率、TPS、TP99、并发用户数。

clickhouse数据节点，CPU运用率：

Elasticsearch数据服务：32C_128G_6节点_2副本
应用服务器：4核8G_2

Elasticsearch同样坚持数据库服务CPU运用率到达（50%左右），再监控数据目标tps、tp99

调整目标如下：coordinating和谐节点数、数据节点、poolSize

目标1：coordinating=2，数据节点=4，poolSize=400

注：在压测的进程中发现，coordinating节点的cpu运用率到达51.69%，负载均衡的作用受限，所以和谐节点需扩容2个节点

目标2：coordinating=4，数据节点=5，poolSize=800

注：在压测的进程中，发现CPU运用率（数据库）ES数据节点在40%左右的时候，一直上不去，检查日志发现activeCount已经到达797，需求添加poolSize值

目标3：coordinating=4，数据节点=5，poolSize=1200

注：压测进程中，发现coordinating和谐节点仍是需求扩容，不能支撑现在数据节点cpu运用率到达50%

Elasticsearch数据节点及和谐节点，CPU运用率：

咱们在压测的进程中发现一些之前在开发进程中没发现的问题，首要bdcp数bigdata应用服务器，运用的线程池最大线程数为8时，成为瓶颈，用户数添加至8以后， clickhouse的cpu稳定在40%~50%之间不在添加，应用服务器CPU稳定在25%左右，其次warehouse集群和谐节点装备低，和谐节点CPU运用率高，最后是clickhouse-jdbc JavaCC解析sql效率低。

4.3 结果剖析

4.3.1 测验定论

1）clickhouse对并发有一定的支撑，并不是不支撑高并发，能够经过调整max_thread提高并发

max_thread=32时，支撑最大TPS 是37，相应TP99是122
max_thread=2时，支撑最大TPS 是66，相应TP99是155
max_thread=1时，支撑最大TPS 是86，相应TP99是206

2）在并发方面Elasticsearch比clickhouse支撑的更好，但是相应的呼应速度慢很多

Elasticsearch：对应的TPS是192，TP99是3050
clickhouse：对应的TPS 是86，TP99是206

综合考量，咱们以为clickhouse足以支撑咱们的事务诉求

4.3.2 优化主张

对ES和谐节点进行扩容
bigdata应用线程池最大线程数调高至200
bigdata应用 dbcp线程池maxTotal设置成50
读取装备文件东西类添加内存缓存

作者：京东物流潘雪艳

来源：京东云开发者社区自猿其说Tech

ClickHouse与Elasticsearch压测实践 | 京东物流技术团队

1 需求剖析

1.1 剖析压测方针

1.2 制定压测方针

2 测验环境预备

3 收集东西预备

4 压测履行及结果剖析

4.1 编写压测脚本东西

4.2 规划压测数据

4.2.1 前期压测中名词解释

4.2.2 压测数据

4.3 结果剖析

4.3.1 测验定论

4.3.2 优化主张

作者信息

推广

ClickHouse与Elasticsearch压测实践 | 京东物流技术团队

1 需求剖析

1.1 剖析压测方针

1.2 制定压测方针

2 测验环境预备

3 收集东西预备

4 压测履行及结果剖析

4.1 编写压测脚本东西

4.2 规划压测数据

4.2.1 前期压测中名词解释

4.2.2 压测数据

4.3 结果剖析

4.3.1 测验定论

4.3.2 优化主张

相关文章

求知 | 聊聊Android资源加载那些事 – Resource的初始化

详细易懂的线程入门2

【云原生】Ceph 在 k8s中应用

如何构建一个高可靠系统（上）

作者信息

推广