ClickHouse与ES的优劣对比

优点：

1. ClickHouse写入吞吐量大，单服务器日志写入量在50MB到200MB/s，每秒写入超过60w记录数，是ES的5倍以上。
2. 查询速度快，官方宣称数据在pagecache中，单服务器查询速率大约在2-30GB/s；没在pagecache的情况下，查询速度取决于磁盘的读取速率和数据的压缩率。。
3. ClickHouse比ES服务器成本更低。一方面ClickHouse的数据压缩比比ES高，相同数据占用的磁盘空间只有ES的1/3到1/30，节省了磁盘空间的同时，也能有效的减少磁盘IO；另一方面ClickHouse比ES占用更少的内存，消耗更少的CPU资源。。
4. 相比ES，ClickHouse稳定性更高，运维成本更低。ES中不同的Group负载不均衡，有的Group负载高，会导致写Rejected等问题，需要人工迁移索引；在ClickHouse中通过集群和Shard策略，采用轮询写的方法，可以让数据比较均衡的分布到所有节点。ES中一个大查询可能导致OOM的问题；ClickHouse通过预设的查询限制，会查询失败，不影响整体的稳定性。ES需要进行冷热数据分离，ClickHouse按天分partition，一般不需要考虑冷热分离，特殊场景用户确实需要冷热分离的，数据量也会小很多，ClickHouse自带的冷热分离机制就可以很好的解决。
5. ClickHouse采用SQL语法，比ES的DSL更加简单，学习成本更低。

缺点：

1. 由于是列式数据库，无法像ES一样提供全文检索功能。
2. 无法动态添加字段，需要提前定义好表schema。
3. 日志无法长期保存，历史数据需定期清理下线，如果有保存历史数据需求，需要通过迁移数据，采用ClickHouse_copier或者复制数据的方式实现。
4. ClickHouse查询速度快，能充分利用集群资源，但是无法支持高并发查询，默认配置qps为100。
5. Clickhouse并不适合许多小数据高频插入，批量写入日志会有一定延迟。

携程相同类型日志在ES和ClickHouse占用磁盘空间

携程相同类型日志在ES和ClickHouse查询时间

ClickHouse替换ES的可行性方案

1. 容灾部署与集群规划

采用多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