導(dǎo)航
????????在完成將公司日志數(shù)據(jù)從Elasticsearch(下稱ES)轉(zhuǎn)戰(zhàn)到Clickhouse后，個人認(rèn)為有必要將過程記錄分享。限于篇幅及便于分類組織，我會以一個系列文章的形式記錄：
- 01 《Elasticsearch vs Clickhouse》
- 02 《Clickhouse的基礎(chǔ)知識掃盲》
- 03 《?Clickhouse多分片多副本集群部署?》
- 04 《??Clickhouse表引擎選擇和表結(jié)構(gòu)設(shè)計?》
- 05 《?clickhouse高效數(shù)據(jù)處理工具vector?》
- 06 《?????????clickhouse的數(shù)據(jù)可視化工具clickvisual?》
- 07?《kibana自定義插件跳轉(zhuǎn)clickvisual》
- 08 《妙用clickvisual api實(shí)現(xiàn)用戶自動管理》（敬請期待）
一、常見的日志解決方案ELK
????????跟大部分企業(yè)一樣，在日志解決方案選型時，優(yōu)先選擇了業(yè)界成熟方案elk + kafka + beats；顧名思義，該方案是使用ES進(jìn)行數(shù)據(jù)存儲的。
二、現(xiàn)狀與挑戰(zhàn)
????????ES 是一種基于 Lucene 的分布式全文搜索引擎，我司用ES存儲日志，目前服務(wù)器規(guī)模 20+，總?cè)萘?TB SSD+15TB HDD，日均日志接入量大約 2TB；數(shù)據(jù)按日期生成ES索引，按照既定的索引生命周期策略(iLM)進(jìn)行冷熱數(shù)據(jù)存放。
隨著日志量的增加，ES集群的一些問題逐漸暴露：
- 資源成本問題：ES集群使用20+臺規(guī)格為16c32g的服務(wù)器，總?cè)萘?TB SSD+20TB HDD。作為一個非利潤部門的工具平臺，占用的資源過多；
- 數(shù)據(jù)安全問題：出于資源成本考慮，沒有開啟數(shù)據(jù)副本功能(一旦開啟，資源成本會成倍增加，且副本寫入不是異步的，會影響數(shù)據(jù)寫入速率)，如此一來，存在數(shù)據(jù)丟失風(fēng)險；
- 性能問題(查詢超時或慢)：因數(shù)據(jù)按日期生成ES索引且冷熱分離，當(dāng)用戶查詢冷數(shù)據(jù)或跨天查詢數(shù)據(jù)時，經(jīng)常會出現(xiàn)查詢超時；
- 性能問題(寫入延遲)：因數(shù)據(jù)進(jìn)行冷熱分離，每天需將數(shù)據(jù)從熱節(jié)點(diǎn)(SSD)遷移到冷節(jié)點(diǎn)(HDD)，遷移過程中會占用大量的資源(譬如帶寬、磁盤IO、ES隊(duì)列等)，期間會導(dǎo)致寫入延遲。
站在運(yùn)維人員的角度，資源成本和運(yùn)維成本的增加，無疑壓力是越來越大，亟需尋找優(yōu)化方案
三、為什么選擇Clickhouse
????????ClickHouse 是一款高性能列式分布式數(shù)據(jù)庫管理系統(tǒng)，我們對 ClickHouse 進(jìn)行了大量的資料搜集，發(fā)現(xiàn)有下列優(yōu)勢：
- ClickHouse 寫入吞吐量大
????????單服務(wù)器日志寫入量在 50MB 到 200MB/s，每秒寫入超過 60w 記錄數(shù)，是 ES 的 5 倍以上。在 ES 中比較常見的寫 Rejected 導(dǎo)致數(shù)據(jù)丟失、寫入延遲等問題，在 ClickHouse 中不容易發(fā)生。
- 查詢速度快
????????官方宣稱數(shù)據(jù)在 pagecache 中，單服務(wù)器查詢速率大約在 2-30GB/s；沒在 pagecache 的情況下，查詢速度取決于磁盤的讀取速率和數(shù)據(jù)的壓縮率。經(jīng)測試 ClickHouse 的查詢速度比 ES 快 5-30 倍以上。
- 查詢語法門檻低
????????ClickHouse的SQL語法與標(biāo)準(zhǔn)SQL語法基本相同，相對于ES的Lucene語法，學(xué)習(xí)門檻要更低，且在復(fù)雜的查詢條件下表現(xiàn)更好
- ClickHouse 比 ES 服務(wù)器成本更低
????????一方面 ClickHouse 的數(shù)據(jù)壓縮比比 ES 高，相同數(shù)據(jù)占用的磁盤空間只有 ES 的 1/3 到 1/30，節(jié)省了磁盤空間的同時，也能有效的減少磁盤 IO，這也是ClickHouse查詢效率更高的原因之一。
| Elasticsearch |
Clickhouse |
說明 |
|
| 版本 |
7.4.2 |
22.7.4 |
|
| 分布式支持 |
√ |
√ |
|
| 擴(kuò)展性 |
高 |
中 |
增加節(jié)點(diǎn)后ES會自動均衡數(shù)據(jù)，CK需手工均衡數(shù)據(jù) |
| 寫入速度 |
慢 |
快 |
|
| 數(shù)據(jù)壓縮率 |
低 |
高 |
|
| 精確匹配查詢 |
一般 |
快 |
|
| 模糊匹配查詢 |
快 |
一般 |
|
| 權(quán)限管理 |
支持 |
支持 |
|
| 查詢難度 |
高 |
低 |
CK支持通用SQL語法 |
| 可視化支持 |
高 |
低 |
|
| 維護(hù)難度 |
一般 |
一般 |
????????在了解Clickhouse的特點(diǎn)后，結(jié)合我司實(shí)際情況，決定使用Clickhouse代替ES存儲日志數(shù)據(jù)。期間以Clickhouse為存儲的新日志系統(tǒng)與ELK并行，數(shù)據(jù)同時寫入ES和Clickhouse；同時在kibana添加入口以查詢Clickhouse上的日志數(shù)據(jù)，以逐漸過渡到新日志系統(tǒng)。文章來源：http://www.zghlxwxcb.cn/news/detail-766933.html
下回預(yù)告
????????Clickhouse的基礎(chǔ)知識掃盲，歡迎關(guān)注后續(xù)更新的系列文章~文章來源地址http://www.zghlxwxcb.cn/news/detail-766933.html
到了這里，關(guān)于「從ES到CK 01」Elasticsearch vs Clickhouse的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
