ClickHouse 挺快，esProc SPL 更快

開源分析數據庫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實現遍歷複用的代碼很簡單，大致是這樣：

	A	B
1	=file("topn.ctx").open().cursor@mv(id,amount)
2	cursor A1	=A2.groups(id%100:Aid;max(amount):Amax)
3	cursor	=A3.groups(id\200000:Bid;min(amount):Bmin)
4	=A2.join@i(Aid,A3:Bid,Bid,Bmin)

再將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的代碼也不復雜：

	A
1	=file("topn.ctx").open().cursor@mv(id,amount)
2	=A1.groups(id%10:gid;top(10;-amount)).news(#2;gid,~.amount)

不只是跑得快

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

	A	B
1	=["etype1","etype2","etype3"]	=file("event.ctx").open()
2	=B1.cursor(id,etime,etype;etime>=date("2021-01-10") && etime
3	=A2.group(id).(~.sort(etime))	=A3.new(~.select@1(etype==A1(1)):first,~:all).select(first)
4	=B3.(A1.(t=if(#==1,t1=first.etime,if(t,all.select@1(etype==A1.~ && etime>t && etime
5	=A4.groups(;count(~(1)):STEP1,count(~(2)):STEP2,count(~(3)):STEP3)

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-10', '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 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。

SPL資料

• SPL下載
• SPL源代碼