需求說明

    針對clickhouse作為生產環境的底層資料儲存，為了能保證生產環境服務穩定可用，做如下效能測試：

（1）chproxy + clickhouse 能否實現叢集高可用

（2）clickhouse 寫效能

（3）clickhouse查詢效能

（4）clickhouse開啟欄位分割槽能否提高查詢效能

（5）chproxy開啟快取對效能影響

    本文件將針對上述方案做驗證以及測試輸出結果。

邏輯架構圖

ch5、ch6等機器構成一個clickhouse叢集，使用者讀寫請求直接作用在chproxy，chproxy提供透明的控制訪問配置以及讀寫指標的監控，可實現使用者無感知的故障訪問切換。對於讀服務，chproxy利用distrubute分散式表優秀的sql解析功能實現資料的查詢服務；對於寫請求，儘量降低寫帶來的叢集IO負載，chproxy穿透distrubute表直接作用在具體表節點上，減少叢集表節點資料轉發帶來的IO。若後期業務的擴充套件需求，可直接橫向擴充套件機器節點即可。

物體架構圖

測試效能

測試指標說明：

本次分別在寫執行緒5/10/20/40/80 每秒寫場景下，模擬不同併發讀效能，其中讀壓力測試以10s內，啟用500/1000/1500個查詢，測試併發場景在不同級別下表sql的效能，用於生產環境clickhouse機器部署參考，測試效能如下所示,在查詢過程中將主要捕獲如下指標:

  (1)  throughput:用來衡量吞吐量的指標，通常由TPS和QPS來表示

（2）插入的rows/s：反映叢集的寫入效能

（3）插入的bytes/s：反映叢集的寫入效能

sql語句準備

  綜合上述的情況準備瞭如下sql：

  Q1: select * from db.table where tenant_id = ${tenant_id} and project_id =${project_id}  limit 20; //該語句組合了“不使用聚合”+“多條件查詢”，查詢複雜性最小，基本只存在叢集頻寬瓶頸

  Q2:select count(*) from db.table where  tenant_id = ${tenant_id} and project_id =${project_id}  //該語句組合了“使用聚合”+“多條件查詢”，查詢複雜性一般

  Q3:select tenant_id,count(*) as c,max(project_id) as m,count(distinct(project_id)) from db.table where  tenant_id = ${tenant_id} group by tenant_id //該語句組合了“多聚合”+“條件查詢” ，查詢複雜性較難

  Q4:select count(*) from db.table where  tenant_id =${tenant_id} and tenant_id in (select distinct(tenant_id) from db.table2) group by project_id //該語句組合了“聚合”+“過濾”+“跨表join”，查詢複雜性最難

環境準備

本次使用3臺測試環境物體機16core，64 GIB，該機器上同時搭載有kudu叢集，hdfs叢集，yarn等服務，當在生產環境部署時，效能會比本次測試優越。在上述的兩臺機器上按上述物體架構部署3個節點，其中：

192.168.104.93 clickhouse節點，用於接收資料寫入及查詢

192.168.104.94 clickhouse節點，用於接收資料寫入及查詢

192.168.104.95 chproxy節點,用於查詢服務代理轉發

其中192.168.104.93與192.168.104.94互為副本。

測試結論報告

（1） HA測試，停止某臺服務，對外服務是否正常訪問

如左圖所示，啟動500個執行緒執行100秒，在100秒過程中，手動kill 192.168.104.94節點上clickhouse服務，在查詢結果樹種，由於節點下線，該時刻的查詢失敗，但服務依舊正常執行sql，因此HA驗證結果成功。

（2）spark 以(5/10/20/40)個併發模擬寫資料時，讀效能(讀50/100/150併發）測試

2.1 寫併發測試

     在測試環境中啟動4個併發，寫batch為10W時，clickhouse表現效能如下，其中資料寫入峰值為80W/s，180MiB/s，平均寫入效能為40W/s,90M/s

 啟動8個併發， 寫batch為20W時，clickhouse表現效能表現不穩定，峰值寫入103W/s,230M/s，偶爾存在超時失敗情況。

 啟動20個併發，寫batch為20W時，clickhouse表現效能表現寫入一段時間後超時失敗。

啟動40個併發，寫batch為20W時，clickhouse表現效能表現寫入一段時間後超時失敗。

在大批量寫入情況下，持續寫入併發為2~6,單臺機器1~3左右最穩定，寫入效能最高（But if you follow the recommendations to insert data in batches of no more than one INSERT per second, it does not create any problems）測試符合預期。同時從圖中可以發現數據寫入對cpu效能影響很小。

2.2 qps併發效能測試

    在上述4個併發，20W/s寫入條件下，對不同量級別的表做併發測試，其中分別在500/1000/1500執行緒（大於1500情形目前不考慮）在10s內完成向chproxy傳送請求不開啟快取的情況下，獲取QPS效能結果如下：

Python PHP JAVA Centos

考慮上述的sql查詢都在租戶下查詢實現的，因此單位租戶下資料量的多少在一定程度上影響了clickhouse 查詢，如20000W表，租戶為1278時，進過租戶條件過濾後數量量很小，基本沒效能影響。儘管在複雜sql查詢下存在資料量大的表可能存在查詢問題，但這類sql查詢不到0.1%的場景，且不存在連續查詢情況，因此在真實生產環境下存在併發效能問題的可能性很小.

（3）租戶劃分使用場景

                                   不劃分租戶                       VS           劃分租戶

     如上圖所示，不同量級的表在劃分租戶與否的情況下QPS效能幾乎一致，分割槽並不能加速查詢，常用於表分割槽drop等操作使用（partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc）

Linux Nginx C# C++ Mysql

（4）快取

    如上圖sql分析所示，在真實生產環境中80%的sql查詢都查詢了重複的sql，重複的資料，如下圖在15000併發查詢在100內開啟快取時，Q3在（12000W條，2100M，45個租戶）分割槽表上的QPS與不開啟快取Q3在（12000W條，2100M，45個租戶）分割槽表表現對比：

儘管測試sql包含了大量重複的sql查詢，可能無法cover生產環境，但快取的使用攔截了大量查詢請求，提高了查詢效能。

結論

本測試報告結合真實生產環境中sql的型別、大小表使用頻率、sql重複查詢使用情況做了分析，並以此模擬真實生產環境，圍繞clickhouse效能在3臺測試環境下展開，並給出瞭如下效能報告總結：

（1）寫併發測試：在持續大批量寫入時，單臺機器併發建議在1~3左右最穩定，資料寫入峰值為80W/s，180MiB/s，平均寫入效能為40W/s,90M/s

（2） 在複雜sql查詢下存在資料量大的表可能存在查詢問題，但正如上述sql分析的那樣，這類sql查詢不到1%的場景，且不存在連續高併發查詢情況，因此在真實生產環境下存在效能問題的可能性為0.

（3）分割槽並不能加速查詢，不需要為特定欄位分割槽

（4）開啟快取

轉自：https://www.dianjilingqu.com/