優點：
- ClickHouse寫入吞吐量大，單伺服器日誌寫入量在50MB到200MB/s，每秒寫入超過60w記錄數，是ES的5倍以上。
- 查詢速度快，官方宣稱資料在pagecache中，單伺服器查詢速率大約在2-30GB/s；沒在pagecache的情況下，查詢速度取決於磁碟的讀取速率和資料的壓縮率。。
- ClickHouse比ES伺服器成本更低。一方面ClickHouse的資料壓縮比比ES高，相同資料佔用的磁碟空間只有ES的1/3到1/30，節省了磁碟空間的同時，也能有效的減少磁碟IO；另一方面ClickHouse比ES佔用更少的記憶體，消耗更少的CPU資源。。
- 相比ES，ClickHouse穩定性更高，運維成本更低。ES中不同的Group負載不均衡，有的Group負載高，會導致寫Rejected等問題，需要人工遷移索引；在ClickHouse中通過叢集和Shard策略，採用輪詢寫的方法，可以讓資料比較均衡的分佈到所有節點。ES中一個大查詢可能導致OOM的問題；ClickHouse通過預設的查詢限制，會查詢失敗，不影響整體的穩定性。ES需要進行冷熱資料分離，ClickHouse按天分partition，一般不需要考慮冷熱分離，特殊場景使用者確實需要冷熱分離的，資料量也會小很多，ClickHouse自帶的冷熱分離機制就可以很好的解決。
- ClickHouse採用SQL語法，比ES的DSL更加簡單，學習成本更低。
缺點：
- 由於是列式資料庫，無法像ES一樣提供全文檢索功能。
- 無法動態新增欄位，需要提前定義好表schema。
- 日誌無法長期儲存，歷史資料需定期清理下線，如果有儲存歷史資料需求，需要通過遷移資料，採用ClickHouse_copier或者複製資料的方式實現。
- ClickHouse查詢速度快，能充分利用叢集資源，但是無法支援高併發查詢，預設配置qps為100。
- Clickhouse並不適合許多小資料高頻插入，批量寫入日誌會有一定延遲。
攜程相同型別日誌在ES和ClickHouse佔用磁碟空間
攜程相同型別日誌在ES和ClickHouse查詢時間
ClickHouse替換ES的可行性方案
- 容災部署與叢集規劃
採用多Shards、2 Replicas的方式，通過Zookeeper進行伺服器間互相備份，允許一個shard一臺伺服器down機資料不丟失。為了接入不同規模的日誌，可以按日誌型別及日誌量建立多個叢集。
2.消費資料到ClickHouse採用gohangout工具
a）採用輪詢的方式寫ClickHouse叢集的所有伺服器，保證資料基本均勻分佈。
b）大批次低頻率的寫入，減少parts數量，減少伺服器merge，避免Too many parts異常。通過兩個閾值控制資料的寫入量和頻次，超過10w記錄寫一次或者30s寫一次。
3. 表結構的設計
按日誌型別建立不同的本地表，非標欄位可以設定為map型別，有值的用值填充，沒有值就直接用 N 填充。
建表時考慮partition的設定，按天分partition。
4. 資料展示
Clickhouse自帶的web接面Tabix.
第三方視覺化介面可以接入Grafana，kibana