Clickhouse & Elasticsearch 选型对比

Clickhouse&Elasticsearch介绍

Clickhouse是俄罗斯搜索巨头Yandex开发的完全列式存储计算的分析型数据库。ClickHouse在这两年的OLAP领域中一直非常热门，国内互联网大厂都有大规模使用。Elasticsearch是一个近实时的分布式搜索分析引擎，它的底层存储完全构建在Lucene之上。简单来说是通过扩展Lucene的单机搜索能力，使其具有分布式的搜索和分析能力。
今天很多用户在实际的业务场景中，常常面对ClickHouse和Elasticsearch技术选型的难题。本文将通过功能对比和性能测试的手段对比两者的优劣之处并进行选型，同时会附上一份覆盖多场景的测试报作为参考。

Clickhouse vs Elasticsearch

类别		Elasticsearch	Clickhouse
导入方式	MQ导入	内置支持kafka, 插件插件plusar	内置支持 kafka， 插件支持plusar
	JDBC导入	内置支持	内置支持
	用户导入	Rest API	HTTP接口/JDBC
存储架构	数据分区	时间分区，字段分区	支持多个分区字段
	数据分桶	支持主键Hash分桶	支持分片
	多副本	支持多副本设置	支持副本表
	字段类型	结构化 半结构化（Array、Map）	结构化 半结构化（Array、Map）
	压缩	LZ4，Deflate	LZ4，ZSTD
	存储引擎	行/列/倒排索引	行存/稀疏索引
	存储压缩比	一般	高
计算能力	向量化计算	不支持	支持
	并发能力	< ~100	< ～100
	写入性能	3000/s	3.5w/s
	谓词下推	弱	一般
	JOIN	不支持	支持BroadCast Join 支持预hash的Colocate JOIN
	物化视图（预计算）	不支持	支持
	自定义函数	不支持	支持
	全文搜索	支持	不支持
扩展性	协议	JDBC/ODBC/RESTAPI协议	JDBC/ODBC/HTTP协议
	SQL协议	DSL为主，SQL兼容性差	兼容标准SQL协议
	动态列	支持	不支持
	存储分离	不支持	不支持
	数据备份	支持快照，定时备份	第三方工具开
	扩缩容	需要Reblance数据	需要Reblance数据

ClickHouse与ES的对比优缺点

优点：

• ClickHouse写入吞吐量大，单服务器日志写入量在50MB到200MB/s，每秒写入超过60w记录数，是ES的5倍以上。
   
• clickhouse的计算框架，支持向量化引擎，以及自低向上的极致算法层面优化，在OLAP场景下可以最大限度的压榨CPU IO等性能，对比ES存在明显优势。
   
• clickhouse支持雾化视图和语句算功能，对于固定的统计分析场景可以将耗时从十几秒下降到几十毫秒级别级别
   
• ClickHouse比ES服务器成本更低。一方面ClickHouse的数据压缩比比ES高（行列存储索引的存在），相同数据占用的磁盘空间只有ES的1/3~1/30，节省了磁盘空间的同时，也能有效的减少磁盘IO；另一方面ClickHouse比ES占用更少的内存，更高效的利用CPU资源。 
   

• 相比ES，ClickHouse稳定性更高，运维成本更低。ES中不同的Group负载不均衡，有的Group负载高，会导致写Rejected等问题，需要人工迁移索引；在ClickHouse中通过集群和Shard策略，采用轮询写的方法，可以让数据比较均衡的分布到所有节点。
   
• ES中一个大查询可能导致OOM的问题；ClickHouse通过预设的查询限制，会查询失败，不影响整体的稳定性。 

• ClickHouse采用SQL语法，比ES的DSL更加简单，新用户学习成本更低。

缺点：

• 由于是列式数据库，且只支持稀疏索引（bloom fliter），不具备倒排索引功能，无法像ES一样提供同样的全文检索能力。
• 无法动态添加字段，需要提前定义好表schema。