Elasticsearch與Clickhouse資料存盤對比

1 背景

京喜達技術部在社區團購場景下采用JDQ+Flink+Elasticsearch架構來打造實時資料報表，隨著業務的發展Elasticsearch開始暴露出一些弊端，不適合大批量的資料查詢，高頻次分頁匯出導致宕機、存盤成本較高，

Elasticsearch的查詢陳述句維護成本較高、在聚合計算場景下出現資料不精確等問題，Clickhouse是列式資料庫，列式型資料庫天然適合OLAP場景，類似SQL語法降低開發和學習成本，采用快速壓縮演算法節省存盤成本，采用向量執行引擎技術大幅縮減計算耗時，所以做此對比，進行Elasticsearch切換至Clickhouse作業，

2 OLAP

OLAP意思是On-Line Analytical Processing 聯機分析處理，Clickhouse就是典型的OLAP聯機分析型資料庫管理系統(DBMS)，OLAP主要針對資料進行復雜分析匯總操作，比如我們業務系統每天都對當天所有運輸團單做匯總統計，計算出每個省區的妥投率，這個操作就屬于OLAP類資料處理，與OLAP類似的還有一個OLTP類資料處理，意思是On-Line Transaction Processing 聯機事務處理，在OLTP場景中用戶并發操作量會很大，要求系統實時進行資料操作的回應，需要支持事務，Mysql、Oracle、SQLServer等都是OLTP型資料庫，

2.1 OLTP場景的特征

• 寬表，即每個表包含著大量的列
• 對于讀取，從資料庫中提取相當多的行，但只提取列的一小部分，
• 查詢相對較少(通常每臺服務器每秒查詢數百次或更少)
• 查詢結果明顯小于源資料，換句話說，資料經過過濾或聚合，因此結果適合于單個服務器的RAM中
• 絕大多數是讀請求
• 資料以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新，
• 對于簡單查詢，允許延遲大約50毫秒
• 列中的資料相對較小：數字和短字串(例如，每個URL 60個位元組)
• 處理單個查詢時需要高吞吐量(每臺服務器每秒可達數十億行)
• 事務不是必須的
• 對資料一致性要求低

3 特性

3.1 Elasticsearch

• 搜索： 適用倒排索引，每個欄位都可被索引且可用于搜索，海量資料下近實時實作秒級的回應，基于Lucene的開源搜索引擎，為全文檢索、高亮、搜索推薦等提供了檢索能力，百度搜索、淘寶商品搜索、日志搜索等
• 資料分析： Elasticsearch提供了大量資料分析的API和豐富的聚合能力，支持在海量資料的基礎上進行資料分析處理，統計訂單量、爬蟲爬取不同電商的某個商品資料，通過Elasticsearch進行資料分析（各個平臺的歷史價格、購買力等等）

3.2 Clickhouse

• 列式存盤
• 壓縮演算法：采用lz4和zstd演算法資料壓縮，高壓縮比降低資料大小，降低磁盤IO，降低CPU使用率，
• 索引：按照主鍵對資料進行排序，clickhouse能在幾十毫秒內完成在大量資料對特定資料或范圍資料進行查找，
• 多核心并行處理：ClickHouse會使用服務器上一切可用的資源，來全力完成一次查詢，
• 支持SQL：一種基于SQL的宣告式查詢語言，在許多情況下與ANSI SQL標準相同，支持group by，order by，from, join，in以及非相關子查詢等，
• 向量引擎：為了高效的使用CPU，資料不僅僅按列存盤，同時還按向量(列的一部分)進行處理，這樣可以更加高效地使用CPU，
• 實時的資料更新：資料總是已增量的方式有序的存盤在MergeTree中，資料可以持續不斷高效的寫入到表中，不會進行任何加鎖等操作，寫入流量在50M-200M/s
• 適合在線查詢：回應速度快延遲極低
• 豐富的聚合計算函式

4 我們的業務場景

1. 大寬表，讀大量行少量列進行指標聚合計算查詢，結果集比較小，資料表都是通過Flink加工出來的寬表，列比較多，在對資料進行查詢或者分析時，經常選擇其中的少數幾列作為維度列、對其他少數幾列作為指標列，對全表或者一定范圍內的資料做聚合計算，這個程序會掃描大量的行資料，但是只用了少數幾列，
2. 大量的串列分頁查詢與匯出
3. Flink中資料大批量追加寫入，不做更新操作
4. 有時某個指標計算需要全表掃描做聚合計算
5. 很少進行全文搜索

結論：資料報表、資料分析場景是典型的OLAP場景，在業務場景上列式存盤資料庫Clickhouse比Elasticsearch更有優勢，Elasticsearch在全文搜索上更占優勢，但是我們這種全文搜索場景較少，

5 成本

• 學習成本：Clickhouse是SQL語法比Elasticsearch的DSL更簡單，幾乎所有后端研發都有Mysql開發經驗，比較相通學習成本更低，
• 開發、測驗、維護成本：Clickhouse是SQL語法，與Mysql開發模式相似，更好寫單元測驗，Elasticsearch是使用Java API拼接查詢陳述句，復雜度較高，不易讀不易維護，
• 運維成本：未知，互聯網上在日志場景下Clickhouse比Elasticsearch成本更低，
• 服務器成本：
• Clickhouse的資料壓縮比要高于Elasticsearch，相同業務資料占用的磁盤空間ES占用磁盤空間是Clickhouse的3-10倍，平均在6倍， 見圖1
• Clickhouse比ES占用更少的CPU和記憶體

結論：同等資料量情況下，Elasticsearch使用的存盤空間是Clickhouse的3-10倍，平均在6倍，綜合學習、開發、測驗、維護方面，Clickhouse比Elasticsearch更友好

6 測驗

6.1服務器配置

以下均基于下圖配置進行測驗

6.2 寫入壓測

以下基于wms_order_sku表，通過Flink在業務平穩情況下雙寫Elasticsearch和Clickhouse1000W+資料進行測驗得到的結果

• 占用CPU情況：Elasticsearch CPU一直占用很高，Clickhouse占用很少CPU，見 圖2

• 占用記憶體情況：Elasticsearch 記憶體升高頻繁GC，Clickhouse占用記憶體較低，比較平穩，見 圖3

• 寫入吞吐量：CH單機寫入速度大約為50~200MB/s，如果寫入的資料每行為1kb，寫入速度為5-20W/s，圖 4(寫入吞吐量)為互聯網上Elasticsearch與Clickhouse寫入資料的對比圖，同等資料樣本的情況下CH寫入性能是Elasticsearch的5倍，由于我們目前Flink任務為雙寫，考慮到會互相影響，后續補充壓測結果，

結論：批量寫入資料時Elasticsearch比Clickhouse更吃記憶體和CPU，Elasticsearch消耗的記憶體是Clickhouse的5.3倍，消耗的CPU是Clickhouse的27.5倍，吞吐量是Elasticsearch的5倍

6.3 查詢性能(單并發測驗)

以下場景是我們資料報表以及資料分析中出現的高頻場景，所以基于此進行查詢性能測驗

資料對比情況

• Clickhouse自身在集群配置差一倍的情況下查詢性能差異不是很大，CH2(48C 182GB)比CH1(80C 320GB)平均慢14%，見圖 5

• Elasticsearch在集群配置差一倍的情況下查詢性能受影響較大，ES2(46C 320GB)比ES1(78C 576GB)平均慢40%，見圖 6

• ES2(46C 320GB)與CH2(48C 182GB)相比，ES2與CH2 CPU核數相近，ES2記憶體是CH2 1.75倍的情況下，CH2的回應速度是ES2的回應速度的的12.7倍，見圖 7

結論：查詢資料時Elasticsearch比Clickhouse慢，在配置相近的情況下Clickhouse的回應速度是Elasticsearch的12.7倍，特別是基于時間的多欄位進行聚合查詢是Clickhouse比Elasticsearch快32倍，Clickhouse的查詢回應素速度受集群配置大小的影響較小，

6.4 查詢壓測(高并發測驗，資料來源于互聯網)

由于準備高并發測驗比較復雜耗時多，后續會基于我們的業務資料以及業務場景進行查詢壓力測驗，以下資料來源于互聯網在用戶畫像場景（資料量262933269）下進行的測驗，與我們的場景非常類似，

結論：Clickhouse對于高并發支持的不夠，官方建議最大QPS為100，高并發情況下吞吐量不如Elasticsearch更友好

7 總結

Clickhouse與Elasticsearch對比Clickhouse的優缺點，

優點:

• 硬體資源成本更低，同等場景下，Clickhouse占用的資源更小，
• 人力成本更低，新人學習、開發單測以及測驗方面都更加友好，更容易介入，
• OLAP場景下Clickhouse比Elasticsearch更適合，聚合計算比Elasticsearch更精缺、更快，更節省服務器計算資源，
• 寫入性能更高，同等情況下是Elasticsearch的5倍，寫入時消耗的服務器資源更小，
• Elasticsearch在大量匯出情況下頻繁GC，嚴重可能導致宕機，不如Clickhouse穩定，
• 查詢性能平均是Elasticsearch的12.7倍，Clickhouse的查詢性能受服務器配置影響較小
• 月服務器消費相同情況Clickhouse能夠得到更好的性能，

缺點：

• 在全文搜索上不如Elasticsearch支持的更好，在高并發查詢上支持的不如Elasticsearch支持的更好

作者：京東物流 馬紅巖

內容來源：京東云開發者社區

標籤：其他

上一篇：【資料庫】時區及JDBC的時區設定

下一篇：返回列表