優點：
- 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