「从ES到CK 01」Elasticsearch vs Clickhouse

导航

        在完成将公司日志数据从Elasticsearch(下称ES)转战到Clickhouse后，个人认为有必要将过程记录分享。限于篇幅及便于分类组织，我会以一个系列文章的形式记录：

• 01 《Elasticsearch vs Clickhouse》
• 02 《Clickhouse的基础知识扫盲》
• 03 《​Clickhouse多分片多副本集群部署​》（敬请期待）
• 04 《​​Clickhouse表引擎选择和表结构设计​》（敬请期待）
• 05 《​高效数据处理工具vector​》（敬请期待）
• 06 《​​​​​​​​​clickhouse的数据可视化工具clickvisual​》（敬请期待）
• 07 《kibana自定义插件跳转clickvisual》（敬请期待）
• 08 《妙用clickvisual api实现用户自动管理》（敬请期待）

一、常见的日志解决方案ELK

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

二、现状与挑战

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

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

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

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

三、为什么选择Clickhouse

        ClickHouse 是一款高性能列式分布式数据库管理系统，我们对 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 服务器成本更低

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

        在了解Clickhouse的特点后，结合我司实际情况，决定使用Clickhouse代替ES存储日志数据。期间以Clickhouse为存储的新日志系统与ELK并行，数据同时写入ES和Clickhouse；同时在kibana添加入口以查询Clickhouse上的日志数据，以逐渐过渡到新日志系统。

下回预告

        Clickhouse的基础知识扫盲，欢迎关注后续更新的系列文章~