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支持的更好

作者：京東物流 馬紅岩

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