背景

其實(shí)早在去年我們就已經(jīng)開始接觸并研究clickhouse了，因?yàn)楫?dāng)時(shí)進(jìn)行多表關(guān)聯(lián)測試性能并不是特別優(yōu)秀，所以并沒有在線上大范圍使用，當(dāng)時(shí)研究的是分布式部署 （感覺分布式會(huì)比單機(jī)好一些）最后發(fā)現(xiàn)性能并不怎么樣 而且分布式的sql也有很多限制，不支持單條刪除和更新操作、不支持in和join（當(dāng)時(shí)的版本，18.12.14之前），直到前幾天看了攜程一篇關(guān)于clickhouse的文章，將clickhouse的性能描述的神乎其神，再次勾起了我研究的欲望，附攜程公眾號(hào)文章 每天十億級(jí)數(shù)據(jù)更新，秒出查詢結(jié)果，ClickHouse在攜程酒店的應(yīng)用

測試

開始之前我們先看結(jié)果：

• 攜程的case：

clickhouse 版本：18.12.13
服務(wù)器配置：

數(shù)據(jù)：

測試場景：

根據(jù)攜程給的一份查詢統(tǒng)計(jì)數(shù)據(jù)來看他們基于clickhouse的分析需求90%在500ms內(nèi)：

查詢分析

• 易企秀測試case：

clickhouse 版本：18.12.13
服務(wù)器配置：

數(shù)據(jù)：

測試場景：

單表聚合

多表關(guān)聯(lián)聚合

通過對比測試，在配置相當(dāng)?shù)那闆r下測試結(jié)果差距還是很大的，那么究竟是什么原因造成的呢？該如何進(jìn)行優(yōu)化...

過程再現(xiàn)

• 調(diào)參：
  網(wǎng)上有人說通過調(diào)大 max_memory_usage 與 max_bytes_before_external_group_by 的值可改善查詢性能（主要是處理并發(fā)query或單次查詢內(nèi)存約束的）

SET max_memory_usage = 128000000000; #128G，
SET max_memory_usage = 60000000000; #60G，

實(shí)際測試這種操作，性能并沒有任何影響，但在16C 、68G、普通硬盤環(huán)境下的clickhouse調(diào)大這兩個(gè)參數(shù)的值性能會(huì)有一倍提升。

• 優(yōu)化建表語句

  
  
  建表語句

通過縮小分區(qū)數(shù)量性能略有提升，但不明顯

• 優(yōu)化SQL
  JOIN操作時(shí)一定要把數(shù)據(jù)量小的表放在右邊，ClickHouse中無論是Left Join 、Right Join還是Inner Join永遠(yuǎn)都是拿著右表中的每一條記錄到左表中查找該記錄是否存在，所以右表必須是小表。

• 優(yōu)化engine
  將普通的mergetree engin 改為特殊的memory engine，性能無任何變化。

• io 排查
  通過測試過程中對硬盤io的監(jiān)控?cái)?shù)據(jù)看，clickhouse在計(jì)算的過程中基本沒有什么io操作，只是在最后一個(gè)階段有1-2s的寫io操作，這也側(cè)面印證mergetree的強(qiáng)大。

  
  
  memory engine

那么問題來了 ，這些都沒有明顯改善，那攜程的case是怎么快起來的呢？

初步懷疑攜程case中的操作并沒有使用到全表數(shù)據(jù)，應(yīng)該在聚合前加了很多篩選條件，帶著疑問郵件了上文的作者，結(jié)論如下：

郵件

攜程多表關(guān)聯(lián)聚合的真實(shí)case

• 我們調(diào)整后的case：

  
  
  秒查

結(jié)論

1、使用SSD盤比普通盤性能會(huì)提升1倍
2、億級(jí)別單表聚合排序最慢2s出結(jié)果，普通盤需4秒
3、多表關(guān)聯(lián)需增加過濾條件，將聚合結(jié)果控制在千萬級(jí)別內(nèi)可秒出
4、join時(shí)大表在左小表在右
5、如果不想加where條件，那么可以提前構(gòu)建大寬表或者預(yù)計(jì)算
6、按照我們業(yè)務(wù)量級(jí)上面服務(wù)器配置減半并不影響性能

其實(shí)clickhouse并不需要做什么優(yōu)化，100個(gè)并發(fā)內(nèi)單表分析可隨意操作，體驗(yàn)極佳；多表分析需根據(jù)實(shí)際使用場景針對性優(yōu)化

普通盤

認(rèn)為是對的 堅(jiān)持下去 就是對的，認(rèn)為是對的 不去堅(jiān)持 最后可能就是錯(cuò)的

目前我們實(shí)時(shí)數(shù)倉除了使用clickhouse 外 還在使用另外一個(gè)秒查引擎，億級(jí)規(guī)模場景下分析 這個(gè)engine是真的秒查哦 SnappyData

SnappyData