「从ES到CK 01」Elasticsearch vs Clickhouse-Toy模板网

这篇具有很好参考价值的文章主要介绍了「从ES到CK 01」Elasticsearch vs Clickhouse。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

跟大部分企业一样，在日志解决方案选型时，优先选择了业界成熟方案elk + kafka + beats；顾名思义，该方案是使用ES进行数据存储的。

ES 是一种基于 Lucene 的分布式全文搜索引擎，我司用ES存储日志，目前服务器规模 20+，总容量6TB SSD+15TB HDD，日均日志接入量大约 2TB；数据按日期生成ES索引，按照既定的索引生命周期策略(iLM)进行冷热数据存放。

「从ES到CK 01」Elasticsearch vs Clickhouse,日志解决方案,elasticsearch,clickhouse

随着日志量的增加，ES集群的一些问题逐渐暴露：

资源成本问题：ES集群使用20+台规格为16c32g的服务器，总容量6TB SSD+20TB HDD。作为一个非利润部门的工具平台，占用的资源过多；
数据安全问题：出于资源成本考虑，没有开启数据副本功能(一旦开启，资源成本会成倍增加，且副本写入不是异步的，会影响数据写入速率)，如此一来，存在数据丢失风险；
性能问题(查询超时或慢)：因数据按日期生成ES索引且冷热分离，当用户查询冷数据或跨天查询数据时，经常会出现查询超时；
性能问题(写入延迟)：因数据进行冷热分离，每天需将数据从热节点(SSD)迁移到冷节点(HDD)，迁移过程中会占用大量的资源(譬如带宽、磁盘IO、ES队列等)，期间会导致写入延迟。

站在运维人员的角度，资源成本和运维成本的增加，无疑压力是越来越大，亟需寻找优化方案

ClickHouse 是一款高性能列式分布式数据库管理系统，我们对 ClickHouse 进行了大量的资料搜集，发现有下列优势：

单服务器日志写入量在 50MB 到 200MB/s，每秒写入超过 60w 记录数，是 ES 的 5 倍以上。在 ES 中比较常见的写 Rejected 导致数据丢失、写入延迟等问题，在 ClickHouse 中不容易发生。

官方宣称数据在 pagecache 中，单服务器查询速率大约在 2-30GB/s；没在 pagecache 的情况下，查询速度取决于磁盘的读取速率和数据的压缩率。经测试 ClickHouse 的查询速度比 ES 快 5-30 倍以上。

ClickHouse的SQL语法与标准SQL语法基本相同，相对于ES的Lucene语法，学习门槛要更低，且在复杂的查询条件下表现更好

一方面 ClickHouse 的数据压缩比比 ES 高，相同数据占用的磁盘空间只有 ES 的 1/3 到 1/30，节省了磁盘空间的同时，也能有效的减少磁盘 IO，这也是ClickHouse查询效率更高的原因之一。