ClickHouse vs Oracle
開源分析資料庫ClickHouse以快著稱，真的如此嗎？我們通過對比測試來驗證一下。
先用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<date("2021-01-25") && A1.contain(etype) && …) | |
| 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(etypeA1.~ && etime>t && etime<t1+7).etime, null)))) | |
| 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-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就簡單得多，處理任意步驟數都是這段代碼。
SPL資料
- SPL下載下傳
- SPL源代碼