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_dockwms.wms_ob_assign_orderwms.wms_picking_task.wms.wms_check_task_detailwms.wms_order_sku

3）查詢的資料量，如下：

select   (ifnull(sum(m.shouldBeCrossedDockQty),   0) -        ifnull(sum(m.satisfiedCrossedDockQty),   0)) as preCrossStockSkuQty,   count(m.docId) as preCrossStockTaskQtyfrom   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 preAssignedOrderQtyfrom 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 prePickingTaskQtyfrom 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 prePickingTaskQtyfrom wms.wms_picking_task m finalprewhere        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 unTrackQtyfrom 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. 讀取配置檔案工具類增加記憶體快取

作者：潘雪豔