一個比 ClickHouse 還快的開源數據庫

開源分析數據庫 ClickHouse 以快著稱，真的如此嗎？我們通過對比測試來驗證一下。

ClickHouse vs Oracle

先用 ClickHouse（簡稱 CH）、Oracle 數據庫（簡稱 ORA）一起在相同的軟硬件環境下做對比測試。測試基準使用國際廣泛認可的 TPC-H，針對 8 張表，完成 22 條 SQL 語句定義的計算需求（Q1 到 Q22）。測試採用單機 12 線程，數據總規模 100G。TPC-H 對應的 SQL 都比較長，這裏就不詳細列出了。

Q1 是簡單的單表遍歷計算分組彙總，對比測試結果如下：

CH 計算 Q1 的表現要好於 ORA，說明 CH 的列式存儲做得不錯，單表遍歷速度很快。而 ORA 主要喫虧在使用了行式存儲，明顯要慢得多了。

但是，如果我們加大計算複雜度，CH 的表現怎麼樣呢？繼續看 TPC-H 的 Q2、Q3、Q7，測試結果如下：

計算變得複雜之後，CH 性能出現了明顯的下降。Q2 涉及數據量較少，列存作用不大，CH 性能和 ORA 幾乎一樣。Q3 數據量較大，CH 佔了列存的便宜後超過了 ORA。Q7 數據也較大，但是計算複雜，CH 性能還不如 ORA。

做複雜計算快不快，主要看性能優化引擎做的好不好。CH 的列存佔據了巨大的存儲優勢，但竟然被 ORA 用行式存儲趕上，這說明 CH 的算法優化能力遠不如 ORA。

TPC-H 的 Q8 是更復雜一些的計算，子查詢中有多表連接，CH 跑了 2000 多秒還沒有出結果，應該是卡死了，ORA 跑了 192 秒。Q9 在 Q8 的子查詢中增加了 like，CH 直接報內存不足的錯誤了，ORA 跑了 234 秒。其它還有些複雜運算是 CH 跑不出來的，就沒法做個總體比較了。

CH 和 ORA 都基於 SQL 語言，但是 ORA 能優化出來的語句，CH 卻跑不出來，更證明 CH 的優化引擎能力比較差。

坊間傳說，CH 只擅長做單表遍歷運算，有關聯運算時甚至跑不過 MySQL，看來並非虛妄胡說。想用 CH 的同學要掂量一下了，這種場景到底能有多大的適應面？

esProc SPL 登場

開源 esProc SPL 也是以高性能作爲宣傳點，那麼我們再來比較一下。

仍然是跑 TPC-H 來看 ：

Q2、Q3、Q7 這些較複雜的運算，SPL 比 CH 和 ORA 跑的都快。CH 跑不出結果的 Q8、Q9，SPL 分別跑了 37 秒和 68 秒，也比 ORA 快。原因在於 SPL 可以採用更優的算法，其計算複雜度低於被 ORA 優化過的 SQL，更遠低於 CH 執行的 SQL，再加上列存，最終是用 Java 開發的 SPL 跑贏了 C++ 實現的 CH 和 ORA。

大概可以得到結論，esProc SPL 無論做簡單計算，還是複雜計算性能都非常好。

不過，Q1 這種簡單運算，CH 比 SPL 還是略勝了一籌。似乎可以進一步證明前面的結論，即 CH 特別擅長簡單遍歷運算。

且慢，SPL 還有祕密武器。

SPL 的企業版中提供了列式遊標機制，我們再來對比測試一下：在 8 億條數據量下，做最簡單的分組彙總計算，對比 SPL（使用列式遊標）和 CH 的性能。（採用的機器配置比前面做 TPC-H 測試時略低，因此測出的結果不同，不過這裏主要看相對值。）

簡單分組彙總對應 CH 的 SQL 語句是：

SQL1：

SELECT mod(id, 100) AS Aid, max(amount) AS Amax
FROM test.t
GROUP BY mod(id, 100)

這個測試的結果是下圖這樣：

SPL 使用列式遊標機制之後，簡單遍歷分組計算的性能也和 CH 一樣了。如果在 TPC-H 的 Q1 測試中也使用列式遊標，SPL 也會達到和 CH 同樣的性能。

測試過程中發現，8 億條數據存成文本格式佔用磁盤 15G，在 CH 中佔用 5.4G，SPL 佔用 8G。說明 CH 和 SPL 都採用了壓縮存儲，CH 的壓縮比更高些，也進一步證明 CH 的存儲引擎做得確實不錯。不過，SPL 也可以達到和 CH 同樣的性能，這說明 SPL 存儲引擎和算法優化做得都比較好，高性能計算能力更加均衡。

當前版本的 SPL 是用 Java 寫的，Java 讀數後生成用於計算的對象的速度很慢，而用 C++ 開發的 CH 則沒有這個問題。對於複雜的運算，讀數時間佔比不高，Java 生成對象慢造成的拖累還不明顯；而對於簡單的遍歷運算，讀數時間佔比很高，所以前面測試中 SPL 就會比 CH 更慢。列式遊標優化了讀數方案，不再生成一個個小對象，使對象生成次數大幅降低，這時候就能把差距拉回來了。單純從存儲本身看，SPL 和 CH 相比並沒有明顯的優劣之分。

接下來再看常規 TopN 的對比測試，CH 的 SQL 是：

SQL2：

SELECT * FROM test.t ORDER BY amount DESC LIMIT 100

對比測試結果是這樣的：

單看 CH 的 SQL2，常規 TopN 的計算方法是全排序後取出前 N 條數據。數據量很大時，如果真地做全排序，性能會非常差。SQL2 的測試結果說明，CH 應該和 SPL 一樣做了優化，沒有全排序，所以兩者性能都很快，SPL 稍快一些。

也就是說，無論簡單運算還是複雜運算，esProc SPL 都能更勝一籌。

進一步的差距

差距還不止於此。

正如前面所說，CH 和 ORA 使用 SQL 語言，都是基於關係模型的，所以都面臨 SQL 優化的問題。TPC-H 測試證明，ORA 能優化的一些場景 CH 卻優化不了，甚至跑不出結果。那麼，如果面對一些 ORA 也不會優化的計算，CH 就更不會優化了。比如說我們將 SQL1 的簡單分組彙總，改爲兩種分組彙總結果再連接，CH 的 SQL 寫出來大致是這樣：

SQL3：

SELECT *
FROM ( 
  SELECT mod(id, 100) AS Aid, max(amount) AS Amax 
  FROM test.t 
  GROUP BY mod(id, 100)
  ) A 
  JOIN ( 
  SELECT floor(id / 200000) AS Bid, min(amount) AS Bmin 
  FROM test.t 
  GROUP BY floor(id / 200000)
  ) B 
  ON A.Aid = B.Bid

這種情況下，對比測試的結果是 CH 的計算時間翻倍，SPL 則不變：

這是因爲 SPL 不僅使用了列式遊標，還使用了遍歷複用機制，能在一次遍歷過程中計算出多種分組結果，可以減少很多硬盤訪問量。CH 使用的 SQL 無法寫出這樣的運算，只能靠 CH 自身的優化能力了。而 CH 算法優化能力又很差，其優化引擎在這個測試中沒有起作用，只能遍歷兩次，所以性能下降了一倍。

SPL 實現遍歷複用的代碼很簡單，大致是這樣：

MqAYLt

再將 SQL2 常規 TopN 計算，調整爲分組後求組內 TopN。對應 SQL 是：

SQL4：

SELECT
  gid,
  groupArray(100)(amount) AS amount
FROM
(    
  SELECT
    mod(id, 10) AS gid,
    amount    
  FROM test.topn    
  ORDER BY
    gid ASC,
    amount DESC
) AS a
GROUP BY gid

這個分組 TopN 測試的對比結果是下面這樣的：

CH 做分組 TopN 計算比常規 TopN 慢了 42 倍，說明 CH 在這種情況下很可能做了排序動作。也就是說，情況複雜化之後，CH 的優化引擎又不起作用了。與 SQL 不同，SPL 把 TopN 看成是一種聚合運算，和 sum、count 這類運算的計算邏輯是一樣的，都只需要對原數據遍歷一次。這樣，分組求組內 TopN 就和分組求和、計數一樣了，可以避免排序計算。因此，SPL 計算分組 TopN 比 CH 快了 22 倍。

而且，SPL 計算分組 TopN 的代碼也不復雜：

TQiKSV

不只是跑得快

再來看看電商系統中常見的漏斗運算。SPL 的代碼依然很簡潔：

ZBnFJX

CH 的 SQL 無法實現這樣的計算，我們以 ORA 爲例看看三步漏斗的 SQL 寫法：

with e1 as (  
  select gid,1 as step1,min(etime) as t1  
  from T  
  where etime>= to_date('2021-01-10', 'yyyy-MM-dd') and etime<to_date('2021-01-25', 'yyyy-MM-dd')    
    and eventtype='eventtype1' and …  
  group by 1
),
with e2 as (  
  select gid,1 as step2,min(e1.t1) as t1,min(e2.etime) as t2  
  from T as e2  
  inner join e1 on e2.gid = e1.gid  
  where e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd') 
    and e2.etime > t1    
    and e2.etime < t1 + 7
    and eventtype='eventtype2' and …  
  group by 1
),
with e3 as (  
  select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3  
  from T as e3  
  inner join e2 on e3.gid = e2.gid  
  where e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd') 
    and e3.etime > t2    
    and e3.etime < t1 + 7
    and eventtype='eventtype3' and …  
  group by 1
)
select
  sum(step1) as step1,  
  sum(step2) as step2,  
  sum(step3) as step3
from
  e1  
  left join e2 on e1.gid = e2.gid  
  left join e3 on e2.gid = e3.gid

ORA 的 SQL 寫出來要三十多行，理解起來有相當的難度。而且這段代碼和漏斗的步驟數量相關，每增加一步數就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數都是這段代碼。

這種複雜的 SQL，寫出來都很費勁，性能優化更無從談起。

而 CH 的 SQL 還遠不如 ORA，基本上寫不出這麼複雜的邏輯，只能在外部寫 C++ 代碼實現。也就是說，這種情況下只能利用 CH 的存儲引擎。雖然用 C++ 在外部計算有可能獲得很好的性能，但開發成本非常高。類似的例子還有很多，CH 都無法直接實現。

總結一下：CH 計算某些簡單場景（比如單表遍歷）確實很快，和 SPL 的性能差不多。但是，高性能計算不能只看簡單情況快不快，還要權衡各種場景。對於複雜運算而言，SPL 不僅性能遠超 CH，代碼編寫也簡單很多。SPL 能覆蓋高性能數據計算的全場景，可以說是完勝 CH。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/J484o6LFsen70hMD9LZ9-A

猜你喜歡