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 采集工具準備

監控工具

1. 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 設計壓測資料

4.2.1 前期壓測中名詞解釋

• DBCP：資料庫連接池，是 apache 上的一個Java連接池專案，DBCP通過連接池預先同資料庫建立一些連接放在記憶體中(即連接池中)，應用程式需要建立資料庫連接時直接到從接池中申請一個連接使用，用完后由連接池回收該連接，從而達到連接復用，減少資源消耗的目的，
• maxTotal：是連接池中總連接的最大數量，默認值8
• max_thread：clickhouse中底層配置，處理SQL請求時使用的最大執行緒數，默認值是clickhouse服務器的核心數量，
• coordinating：協調節點數，主要作用于請求轉發，請求回應處理等輕量級操作
• 資料節點：主要是存盤索引資料的節點，主要對檔案進行增刪改查操作，聚合操作等，資料節點對cpu，記憶體，io要求較高， 在優化的時候需要監控資料節點的狀態，當資源不夠的時候，需要在集群中添加新的節點

4.2.2 壓測資料

clickhouse資料服務：32C128G6節點2副本
應用服務器：4核8G2
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資料服務：32C128G6節點2副本
應用服務器：4核8G2
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 優化建議

1. 對ES協調節點進行擴容
2. bigdata應用執行緒池最大執行緒數調高至200
3. bigdata應用 dbcp執行緒池maxTotal設定成50
4. 讀取組態檔工具類增加記憶體快取

作者：潘雪艷

標籤：其他

上一篇：MongoDB，入門看這一篇足矣！

下一篇：openGauss內核分析：執行計劃生成