1.查詢性能：DorisDB vs ClickHouse vs Apache Doris
查詢性能對比測試使用SSB測試集，數(shù)據(jù)量最大的表lineorder約60億(scale 1000)。在ClickHouse最擅長的寬表模式下，分別在限制線程數(shù)不超過8，不限制線程數(shù)兩種情況下對比了DorisDB和Clickhouse的性能。
在DorisDB和ClickHouse單節(jié)點都使用不超過8個線程的情況下，13個查詢中有9個DorisDB的性能好于ClickHouse。
(寬表模式，設(shè)置ClickHouse max_threads=8）
不限制ClickHouse線程數(shù)情況下，13個查詢中有7個DorisDB性能好于ClickHouse。
(寬表模式，不限制max_threads）
在多表Join模式下，對比了DorisDB和Apache Doris的表現(xiàn)。整體上DorisDB比Apache Doris有5-10倍的性能優(yōu)勢。
沒有對Apache Doris的寬表性能進程測試，是由于在60億的數(shù)據(jù)量下，DorisDB可以直接使用insert into select語句將數(shù)據(jù)轉(zhuǎn)成寬表，Apache doris執(zhí)行相同語句會報oom。由此也可以看出DorisDB在內(nèi)存的管理和執(zhí)行效率上比Apache Doris要好不少。同時也了解到DorisDB后續(xù)也有開源的計劃，所以我們在應(yīng)用中都使用了DorisDB作為OLAP分析引擎。
2.高并發(fā)：DorisDB vs Druid
線上實際環(huán)境，以寬表模式對Druid和DorisDB進行了高并發(fā)的壓力測試。Druid集群的QPS可以達到600-700左右，平均響應(yīng)時間100ms左右，最大響應(yīng)時間300ms左右。相同規(guī)模的DorisDB集群，QPS可以達到1500-2000，平均響應(yīng)時間在50ms左右，最大響應(yīng)時間在100ms左右。
（壓力測試下Druid并發(fā)量）
（壓力測試下DorisDB并發(fā)量）
此外，我們額外對DorisDB的Join模式進行了高并發(fā)的壓力測試，QPS可以到200-300，平均響應(yīng)時間470ms?？梢钥闯黾词乖贘oin模式的復(fù)雜查詢場景下，DorisDB的并發(fā)性能還依舊維持在一個不錯的水準(zhǔn)。
3.其他指標(biāo)
如下表所示，我們也對其他方面的指標(biāo)進行了比較：
四、DorisDB在貝殼的應(yīng)用
目前貝殼的DorisDB集群使用35臺物理機（80core、192GB內(nèi)存、3TB SSD），部署了35 BE，3 FE。支持了如指標(biāo)平臺、可視化報表平臺、典型業(yè)務(wù)場景等多個應(yīng)用。
1.指標(biāo)平臺
1）高QPS指標(biāo)查詢
通過DorisDB強大的并發(fā)能力支撐以往Druid所不能滿足的高QPS場景。如房屋經(jīng)紀(jì)人業(yè)績考核時段，QPS會瞬間從幾十飆升到3000。以往使用Durid應(yīng)對這類瞬時高壓場景沒有很好的解決辦法，集群會不停告警乃至宕機。使用DorisDB支撐的指標(biāo)平臺就能很好的解決這個問題。
2）可自動更新的物化視圖
DorisDB有非常好的物化視圖能力。對慢查詢指標(biāo)通過rollup聚合，在查詢時可以自動命中物化視圖，自動路由，加速整個查詢。同時物化視圖支持自動更新，當(dāng)明細表發(fā)生變化時，物化視圖自動刷新聚合結(jié)果。
3）實時的大屏指標(biāo)
原有的實時指標(biāo)是通過ClickHouse來支持的，但是需要建大量的視圖。ClickHouse物化視圖不支持自動路由，在查詢時需要指定對應(yīng)的物化視圖表名字。而且ClickHouse對Update的支持也非常有限，查詢最新的記錄需要額外的函數(shù)支持，不符合標(biāo)準(zhǔn)的SQL語法?？傮w來說使用ClickHouse來計算實時指標(biāo)，實現(xiàn)過程非常復(fù)雜。通過DorisDB來支持實時指標(biāo)場景，能自動對指標(biāo)進行實時更新，只需要創(chuàng)建對應(yīng)的物化視圖即可，無需額外的任何操作就可以指標(biāo)的實時更新。
4）更靈活的數(shù)據(jù)模型
DorisDB同時也具備非常強的單表查詢能力和多表Join能力，可以支持寬表模式和多表Join模式。在應(yīng)對部分靈活指標(biāo)，如前文提到的經(jīng)紀(jì)人組織架構(gòu)變更場景，基于DorisDB就無需構(gòu)建寬表。使用在線Join的方式，當(dāng)維度發(fā)生變動的時候，更新維度表重新進行關(guān)聯(lián)查詢即可。
2.奧丁可視化平臺
此前我們基于MySQL做了大量的報表，如市場管理看板等。隨著數(shù)據(jù)量增大，數(shù)據(jù)量達到千萬級別MySQL已經(jīng)完全不能支撐。目前已將這些可視化系統(tǒng)報表全部遷移到DorisDB上。由于DorisDB對MySQL協(xié)議的支持，整個遷移的過過程比較平滑，只需要很少的工作量。
3.典型業(yè)務(wù)
原有的典型業(yè)務(wù)如A/B試驗平臺、交易平臺、風(fēng)控平臺、直播中臺等，之前是基于ClickHouse和Apache Doris構(gòu)建的?，F(xiàn)在我們已經(jīng)開始將這些業(yè)務(wù)應(yīng)用逐步遷移至DorisDB。此外，后續(xù)構(gòu)建的新應(yīng)用，如用戶行為分析等，我們也會基于DorisDB來進行構(gòu)建。
下圖是直播中臺從Apache Doris遷移到DorisDB后的查詢效率對比。可以看到查詢效率均有成倍的提升，在數(shù)據(jù)量大的情況下（全量表）性能提升尤為明細，性能提升均在7倍以上。
（直播平臺使用DorisDB后，所有查詢的延時都顯著降低）
寫在最后
在近半年的使用過程中，從整體來看DorisDB在穩(wěn)定性和查詢性能上要優(yōu)于Apache doris。寬表性能和ClickHouse不相上下，多表Join能力要勝于ClickHouse。DorisDB在保持甚至超過ClickHouse性能的同時，極大降低了我們的運維壓力，簡化了數(shù)據(jù)開發(fā)的鏈路。
DorisDB對hive外表的支持也給我們很大的想象空間，尤其是一些Ad hoc查詢場景?，F(xiàn)在我們的小查詢用Spark SQL，大的查詢用hive或者是presto。后續(xù)使用DorisDB來分擔(dān)一些熱查詢的流量，整體的查詢效率也可以得到進一步的提升。使用DorisDB查詢ElasticSearch外表也在我們下一步的規(guī)劃中。
后續(xù)我們會將DorisDB覆蓋到更多的業(yè)務(wù)場景，使用DorisDB逐步替代Druid、Clickhouse、Kylin等其他分析引擎，來構(gòu)建我們?nèi)珗鼍敖y(tǒng)一的極速OLAP分析平臺。
DorisDB團隊的同學(xué)支持也十分給力，在此表示感謝。
