ClickHouse與esProc SPL性能對比
開源分析數(shù)據(jù)庫 ClickHouse 以快著稱，真的如此嗎？我們通過對比測試來驗證一下。
CH 計算 Q1 的表現(xiàn)要好于 ORA，說明 CH 的列式存儲做得不錯，單表遍歷速度很快。而 ORA 主要吃虧在使用了行式存儲，明顯要慢得多了。但是，如果我們加大計算復(fù)雜度，CH 的表現(xiàn)怎么樣呢？繼續(xù)看 TPC-H 的 Q2、Q3、Q7，測試結(jié)果如下：
計算變得復(fù)雜之后，CH 性能出現(xiàn)了明顯的下降。Q2 涉及數(shù)據(jù)量較少，列存作用不大，CH 性能和 ORA 幾乎一樣。Q3 數(shù)據(jù)量較大，CH 占了列存的便宜后超過了 ORA。Q7 數(shù)據(jù)也較大，但是計算復(fù)雜，CH 性能還不如 ORA。做復(fù)雜計算快不快，主要看性能優(yōu)化引擎做的好不好。CH 的列存占據(jù)了巨大的存儲優(yōu)勢，但竟然被 ORA 用行式存儲趕上，這說明 CH 的算法優(yōu)化能力遠不如 ORA。TPC-H 的 Q8 是更復(fù)雜一些的計算，子查詢中有多表連接，CH 跑了 2000 多秒還沒有出結(jié)果，應(yīng)該是卡死了，ORA 跑了 192 秒。Q9 在 Q8 的子查詢中增加了 like，CH 直接報內(nèi)存不足的錯誤了，ORA 跑了 234 秒。其它還有些復(fù)雜運算是 CH 跑不出來的，就沒法做個總體比較了。CH 和 ORA 都基于 SQL 語言，但是 ORA 能優(yōu)化出來的語句，CH 卻跑不出來，更證明 CH 的優(yōu)化引擎能力比較差。坊間傳說，CH 只擅長做單表遍歷運算，有關(guān)聯(lián)運算時甚至跑不過 MySQL，看來并非虛妄胡說。想用 CH 的同學(xué)要掂量一下了，這種場景到底能有多大的適應(yīng)面？
Q2、Q3、Q7 這些較復(fù)雜的運算，SPL 比 CH 和 ORA 跑的都快。CH 跑不出結(jié)果的 Q8、Q9，SPL 分別跑了 37 秒和 68 秒，也比 ORA 快。原因在于 SPL 可以采用更優(yōu)的算法，其計算復(fù)雜度低于被 ORA 優(yōu)化過的 SQL，更遠低于 CH 執(zhí)行的 SQL，再加上列存，最終是用 Java 開發(fā)的 SPL 跑贏了 C++ 實現(xiàn)的 CH 和 ORA。大概可以得到結(jié)論，esProc SPL 無論做簡單計算，還是復(fù)雜計算性能都非常好。不過，Q1 這種簡單運算，CH 比 SPL 還是略勝了一籌。似乎可以進一步證明前面的結(jié)論，即 CH 特別擅長簡單遍歷運算。且慢，SPL 還有秘密武器。SPL 的企業(yè)版中提供了列式游標機制，我們再來對比測試一下：在 8 億條數(shù)據(jù)量下，做最簡單的分組匯總計算，對比 SPL（使用列式游標）和 CH 的性能。（采用的機器配置比前面做 TPC-H 測試時略低，因此測出的結(jié)果不同，不過這里主要看相對值。）簡單分組匯總對應(yīng) CH 的 SQL 語句是：SQL1：
SPL 使用列式游標機制之后，簡單遍歷分組計算的性能也和 CH 一樣了。如果在 TPC-H 的 Q1 測試中也使用列式游標，SPL 也會達到和 CH 同樣的性能。測試過程中發(fā)現(xiàn)，8 億條數(shù)據(jù)存成文本格式占用磁盤 15G，在 CH 中占用 5.4G，SPL 占用 8G。說明 CH 和 SPL 都采用了壓縮存儲，CH 的壓縮比更高些，也進一步證明 CH 的存儲引擎做得確實不錯。不過，SPL 也可以達到和 CH 同樣的性能，這說明 SPL 存儲引擎和算法優(yōu)化做得都比較好，高性能計算能力更加均衡。當前版本的 SPL 是用 Java 寫的，Java 讀數(shù)后生成用于計算的對象的速度很慢，而用 C++ 開發(fā)的 CH 則沒有這個問題。對于復(fù)雜的運算，讀數(shù)時間占比不高，Java 生成對象慢造成的拖累還不明顯；而對于簡單的遍歷運算，讀數(shù)時間占比很高，所以前面測試中 SPL 就會比 CH 更慢。列式游標優(yōu)化了讀數(shù)方案，不再生成一個個小對象，使對象生成次數(shù)大幅降低，這時候就能把差距拉回來了。單純從存儲本身看，SPL 和 CH 相比并沒有明顯的優(yōu)劣之分。接下來再看常規(guī) TopN 的對比測試，CH 的 SQL 是：SQL2：
單看 CH 的 SQL2，常規(guī) TopN 的計算方法是全排序后取出前 N 條數(shù)據(jù)。數(shù)據(jù)量很大時，如果真地做全排序，性能會非常差。SQL2 的測試結(jié)果說明，CH 應(yīng)該和 SPL 一樣做了優(yōu)化，沒有全排序，所以兩者性能都很快，SPL 稍快一些。也就是說，無論簡單運算還是復(fù)雜運算，esProc SPL 都能更勝一籌。
這是因為 SPL 不僅使用了列式游標，還使用了遍歷復(fù)用機制，能在一次遍歷過程中計算出多種分組結(jié)果，可以減少很多硬盤訪問量。CH 使用的 SQL 無法寫出這樣的運算，只能靠 CH 自身的優(yōu)化能力了。而 CH 算法優(yōu)化能力又很差，其優(yōu)化引擎在這個測試中沒有起作用，只能遍歷兩次，所以性能下降了一倍。SPL 實現(xiàn)遍歷復(fù)用的代碼很簡單，大致是這樣：
CH 做分組 TopN 計算比常規(guī) TopN 慢了 42 倍，說明 CH 在這種情況下很可能做了排序動作。也就是說，情況復(fù)雜化之后，CH 的優(yōu)化引擎又不起作用了。與 SQL 不同，SPL 把 TopN 看成是一種聚合運算，和 sum、count 這類運算的計算邏輯是一樣的，都只需要對原數(shù)據(jù)遍歷一次。這樣，分組求組內(nèi) TopN 就和分組求和、計數(shù)一樣了，可以避免排序計算。因此，SPL 計算分組 TopN 比 CH 快了 22 倍。而且，SPL 計算分組 TopN 的代碼也不復(fù)雜：
審核編輯：湯梓紅 ClickHouse vs Oracle
先用 ClickHouse（簡稱 CH）、Oracle 數(shù)據(jù)庫（簡稱 ORA）一起在相同的軟硬件環(huán)境下做對比測試。測試基準使用國際廣泛認可的 TPC-H，針對 8 張表，完成 22 條 SQL 語句定義的計算需求（Q1 到 Q22）。測試采用單機 12 線程，數(shù)據(jù)總規(guī)模 100G。TPC-H 對應(yīng)的 SQL 都比較長，這里就不詳細列出了。Q1 是簡單的單表遍歷計算分組匯總，對比測試結(jié)果如下：CH 計算 Q1 的表現(xiàn)要好于 ORA，說明 CH 的列式存儲做得不錯，單表遍歷速度很快。而 ORA 主要吃虧在使用了行式存儲，明顯要慢得多了。但是，如果我們加大計算復(fù)雜度，CH 的表現(xiàn)怎么樣呢？繼續(xù)看 TPC-H 的 Q2、Q3、Q7，測試結(jié)果如下：計算變得復(fù)雜之后，CH 性能出現(xiàn)了明顯的下降。Q2 涉及數(shù)據(jù)量較少，列存作用不大，CH 性能和 ORA 幾乎一樣。Q3 數(shù)據(jù)量較大，CH 占了列存的便宜后超過了 ORA。Q7 數(shù)據(jù)也較大，但是計算復(fù)雜，CH 性能還不如 ORA。做復(fù)雜計算快不快，主要看性能優(yōu)化引擎做的好不好。CH 的列存占據(jù)了巨大的存儲優(yōu)勢，但竟然被 ORA 用行式存儲趕上，這說明 CH 的算法優(yōu)化能力遠不如 ORA。TPC-H 的 Q8 是更復(fù)雜一些的計算，子查詢中有多表連接，CH 跑了 2000 多秒還沒有出結(jié)果，應(yīng)該是卡死了，ORA 跑了 192 秒。Q9 在 Q8 的子查詢中增加了 like，CH 直接報內(nèi)存不足的錯誤了，ORA 跑了 234 秒。其它還有些復(fù)雜運算是 CH 跑不出來的，就沒法做個總體比較了。CH 和 ORA 都基于 SQL 語言，但是 ORA 能優(yōu)化出來的語句，CH 卻跑不出來，更證明 CH 的優(yōu)化引擎能力比較差。坊間傳說，CH 只擅長做單表遍歷運算，有關(guān)聯(lián)運算時甚至跑不過 MySQL，看來并非虛妄胡說。想用 CH 的同學(xué)要掂量一下了，這種場景到底能有多大的適應(yīng)面？esProc SPL 登場
開源 esProc SPL 也是以高性能作為宣傳點，那么我們再來比較一下。仍然是跑 TPC-H 來看 ：Q2、Q3、Q7 這些較復(fù)雜的運算，SPL 比 CH 和 ORA 跑的都快。CH 跑不出結(jié)果的 Q8、Q9，SPL 分別跑了 37 秒和 68 秒，也比 ORA 快。原因在于 SPL 可以采用更優(yōu)的算法，其計算復(fù)雜度低于被 ORA 優(yōu)化過的 SQL，更遠低于 CH 執(zhí)行的 SQL，再加上列存，最終是用 Java 開發(fā)的 SPL 跑贏了 C++ 實現(xiàn)的 CH 和 ORA。大概可以得到結(jié)論，esProc SPL 無論做簡單計算，還是復(fù)雜計算性能都非常好。不過，Q1 這種簡單運算，CH 比 SPL 還是略勝了一籌。似乎可以進一步證明前面的結(jié)論，即 CH 特別擅長簡單遍歷運算。且慢，SPL 還有秘密武器。SPL 的企業(yè)版中提供了列式游標機制，我們再來對比測試一下：在 8 億條數(shù)據(jù)量下，做最簡單的分組匯總計算，對比 SPL（使用列式游標）和 CH 的性能。（采用的機器配置比前面做 TPC-H 測試時略低，因此測出的結(jié)果不同，不過這里主要看相對值。）簡單分組匯總對應(yīng) CH 的 SQL 語句是：SQL1：
這個測試的結(jié)果是下圖這樣：SELECT mod(id, 100) AS Aid, max(amount) AS AmaxFROM test.tGROUP BY mod(id, 100)
SPL 使用列式游標機制之后，簡單遍歷分組計算的性能也和 CH 一樣了。如果在 TPC-H 的 Q1 測試中也使用列式游標，SPL 也會達到和 CH 同樣的性能。測試過程中發(fā)現(xiàn)，8 億條數(shù)據(jù)存成文本格式占用磁盤 15G，在 CH 中占用 5.4G，SPL 占用 8G。說明 CH 和 SPL 都采用了壓縮存儲，CH 的壓縮比更高些，也進一步證明 CH 的存儲引擎做得確實不錯。不過，SPL 也可以達到和 CH 同樣的性能，這說明 SPL 存儲引擎和算法優(yōu)化做得都比較好，高性能計算能力更加均衡。當前版本的 SPL 是用 Java 寫的，Java 讀數(shù)后生成用于計算的對象的速度很慢，而用 C++ 開發(fā)的 CH 則沒有這個問題。對于復(fù)雜的運算，讀數(shù)時間占比不高，Java 生成對象慢造成的拖累還不明顯；而對于簡單的遍歷運算，讀數(shù)時間占比很高，所以前面測試中 SPL 就會比 CH 更慢。列式游標優(yōu)化了讀數(shù)方案，不再生成一個個小對象，使對象生成次數(shù)大幅降低，這時候就能把差距拉回來了。單純從存儲本身看，SPL 和 CH 相比并沒有明顯的優(yōu)劣之分。接下來再看常規(guī) TopN 的對比測試，CH 的 SQL 是：SQL2：
SELECT * FROM test.t ORDER BY amount DESC LIMIT 100
對比測試結(jié)果是這樣的：單看 CH 的 SQL2，常規(guī) TopN 的計算方法是全排序后取出前 N 條數(shù)據(jù)。數(shù)據(jù)量很大時，如果真地做全排序，性能會非常差。SQL2 的測試結(jié)果說明，CH 應(yīng)該和 SPL 一樣做了優(yōu)化，沒有全排序，所以兩者性能都很快，SPL 稍快一些。也就是說，無論簡單運算還是復(fù)雜運算，esProc SPL 都能更勝一籌。進一步的差距
差距還不止于此。正如前面所說，CH 和 ORA 使用 SQL 語言，都是基于關(guān)系模型的，所以都面臨 SQL 優(yōu)化的問題。TPC-H 測試證明，ORA 能優(yōu)化的一些場景 CH 卻優(yōu)化不了，甚至跑不出結(jié)果。那么，如果面對一些 ORA 也不會優(yōu)化的計算，CH 就更不會優(yōu)化了。比如說我們將 SQL1 的簡單分組匯總，改為兩種分組匯總結(jié)果再連接，CH 的 SQL 寫出來大致是這樣：SQL3：SELECT *FROM (SELECT mod(id, 100) AS Aid, max(amount) AS AmaxFROM test.tGROUP BY mod(id, 100)) AJOIN(SELECTfloor(id/200000)ASBid,min(amount)ASBminFROMtest.tGROUPBYfloor(id/200000))BONA.Aid=B.Bid
這種情況下，對比測試的結(jié)果是 CH 的計算時間翻倍，SPL 則不變：
這是因為 SPL 不僅使用了列式游標，還使用了遍歷復(fù)用機制，能在一次遍歷過程中計算出多種分組結(jié)果，可以減少很多硬盤訪問量。CH 使用的 SQL 無法寫出這樣的運算，只能靠 CH 自身的優(yōu)化能力了。而 CH 算法優(yōu)化能力又很差，其優(yōu)化引擎在這個測試中沒有起作用，只能遍歷兩次，所以性能下降了一倍。SPL 實現(xiàn)遍歷復(fù)用的代碼很簡單，大致是這樣：| 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(id200000:Bid;min(amount):Bmin) |
| 4 | =A2.join@i(Aid,A3:Bid,Bid,Bmin) | |
再將 SQL2 常規(guī) TopN 計算，調(diào)整為分組后求組內(nèi) TopN。對應(yīng) SQL 是：
SQL4：SELECTgid,groupArray(100)(amount)ASamountFROM(SELECTmod(id, 10) AS gid,amountFROMtest.topnORDERBYgid ASC,amount DESC)ASaGROUPBYgid
這個分組 TopN 測試的對比結(jié)果是下面這樣的：
CH 做分組 TopN 計算比常規(guī) TopN 慢了 42 倍，說明 CH 在這種情況下很可能做了排序動作。也就是說，情況復(fù)雜化之后，CH 的優(yōu)化引擎又不起作用了。與 SQL 不同，SPL 把 TopN 看成是一種聚合運算，和 sum、count 這類運算的計算邏輯是一樣的，都只需要對原數(shù)據(jù)遍歷一次。這樣，分組求組內(nèi) TopN 就和分組求和、計數(shù)一樣了，可以避免排序計算。因此，SPL 計算分組 TopN 比 CH 快了 22 倍。而且，SPL 計算分組 TopN 的代碼也不復(fù)雜：| A | |
| 1 | =file("topn.ctx").open().cursor@mv(id,amount) |
| 2 | =A1.groups(id%10:gid;top(10;-amount)).news(#2;gid,~.amount) |
不只是跑得快
再來看看電商系統(tǒng)中常見的漏斗運算。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 無法實現(xiàn)這樣的計算，我們以 ORA 為例看看三步漏斗的 SQL 寫法：
ORA 的 SQL 寫出來要三十多行，理解起來有相當?shù)碾y度。而且這段代碼和漏斗的步驟數(shù)量相關(guān)，每增加一步數(shù)就要再增加一段子查詢。相比之下，SPL 就簡單得多，處理任意步驟數(shù)都是這段代碼。這種復(fù)雜的 SQL，寫出來都很費勁，性能優(yōu)化更無從談起。而 CH 的 SQL 還遠不如 ORA，基本上寫不出這么復(fù)雜的邏輯，只能在外部寫 C++ 代碼實現(xiàn)。也就是說，這種情況下只能利用 CH 的存儲引擎。雖然用 C++ 在外部計算有可能獲得很好的性能，但開發(fā)成本非常高。類似的例子還有很多，CH 都無法直接實現(xiàn)。with e1 as (select gid,1 as step1,min(etime) as t1from Twhere 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 t2from T as e2inner join e1 on e2.gid = e1.gidwhere e2.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e2.etime<to_date('2021-01-25', 'yyyy-MM-dd')and e2.etime > t1and e2.etime < t1 + 7and eventtype='eventtype2' and …group 1),with e3 as (select gid,1 as step3,min(e2.t1) as t1,min(e3.etime) as t3from T as e3inner join e2 on e3.gid = e2.gidwhere e3.etime>= to_date('2021-01-10', 'yyyy-MM-dd') and e3.etime<to_date('2021-01-25', 'yyyy-MM-dd')and e3.etime > t2and e3.etime < t1 + 7and eventtype='eventtype3' and …group by 1)selectsum(step1) as step1,sum(step2) as step2,sum(step3) as step3frome1left join e2 on e1.gid = e2.gidleft join e3 on e2.gid = e3.gid
總結(jié)一下：CH 計算某些簡單場景（比如單表遍歷）確實很快，和 SPL 的性能差不多。但是，高性能計算不能只看簡單情況快不快，還要權(quán)衡各種場景。對于復(fù)雜運算而言，SPL 不僅性能遠超 CH，代碼編寫也簡單很多。SPL 能覆蓋高性能數(shù)據(jù)計算的全場景，可以說是完勝 CH。
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
SQL
+關(guān)注
關(guān)注
1文章
783瀏覽量
45145 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3926瀏覽量
66218 -
開源
+關(guān)注
關(guān)注
3文章
3688瀏覽量
43829
原文標題：ClickHouse 挺快，esProc SPL 更快
文章出處：【微信號：芋道源碼，微信公眾號：芋道源碼】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
熱點推薦
Linux下AWTK與Qt的性能對比
為了比較直觀的看到AWTK的基本性能，我們對產(chǎn)品開發(fā)者比較關(guān)心GUI的一些參數(shù)做了測試，如界面刷新幀數(shù)、啟動時間等。讓我們從參數(shù)上直觀了解Linux下AWTK與Qt的性能對比。
發(fā)表于 10-29 08:26
談?wù)凷T的單片機分類及性能對比
,轉(zhuǎn)載請注明.文章目錄前言一、ST的單片機分類二、ST性能對比總結(jié)前言最近，由于新項目即將開始，我在選型的時候，突然想到早些年的一個面試。當時面試的時候，我說了兩個項目。兩個用到了不同的MCU
發(fā)表于 12-09 06:10
arduino和stm32性能對比究竟誰更厲害？
一些DIY和各種小項目？arduino和stm32性能對比究竟誰更厲害呢？我們一起來討論一下。比較兩者之前首先我們來了解下arduino和stm32的特點：Arduino:Arduino UNO-DFRobot商城1. Arduino更傾向于創(chuàng)意，它弱化了具體的硬件的操作，它的函數(shù)...
發(fā)表于 01-24 07:14
高頻型直流充電機性能對比檢驗試驗總結(jié)報告
高頻型直流充電機性能對比檢驗試驗總結(jié)報告(開關(guān)電源技術(shù)課程設(shè)計)-高頻型直流充電機性能對比檢驗試驗總結(jié)報告? ? ? ? ? ?
發(fā)表于 08-31 19:55
?19次下載
ClickHouse和Elasticsearch壓測對比
ClickHouse 是一個真正的列式數(shù)據(jù)庫管理系統(tǒng)（MS）。在 ClickHouse 中，數(shù)據(jù)始終是列存儲的，包括向量（對或列塊）的執(zhí)行過程。只要有可能，操作都是基于向量進行分派的，而不是實現(xiàn)的價值，這被稱為?它有查詢實際的數(shù)據(jù)處理?。
工商網(wǎng)監(jiān)
評論