【ClickHouse】深入浅出系列之初识ClickHouse

ClickHouse是什么？

先看官方怎么说：

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

用通俗易懂的中文（人话）解释下：

• 联机分析（OLAP）：在线分析查询，可以理解成平时在MySQL上执行SQL查询数据。
• 列式储存：咱们平时用的MySQL、PgSQL等每行进行存储，而ClickHouse是按照列进行存储，优点是压缩率高、节省服务器资源、查询效率高。
• 数据库管理系统：这个大家都不陌生，类似于MySQL、SQLSever等。
• 业界有些人会简称ClickHouse为CH或CK，我们后面的文章默认以CK代替ClickHouse

ClickHouse的优势

完备的DBMS功能

• DDL（数据定义语言）：可通过ddl快速操作ck，如增、删、改、查库表，动态修改冷热存储策略，无需重启服务。
• DML（数据操作语言）：即常见的SQL语句，如Insert、Update、Select、Delete、Drop等。
• 分布式管理：自身提供了丰富的System表，可查询集群、磁盘存储情况、操作日志等。
• 数据备份和恢复功能：可通过CVS等文件快速进行文件的导入导出。

写入性能

由于ck内部采用稀疏索引和列式存储，以及ck内部的优化，以至于写入数据非常快。如果再加上程序本身的优化（自定义规则写入本地表，不写入分布式表）会使得ck写入性能非常客观，根据多个技术博客（文末会挂载相关链接）的对写入性能的测试单节点单表可达到50W/S以上。

根据ck使用经验，以下做法会对ck的写入性能有极大的提升：

• 利用ck自身提供的冷热存储方案实现冷热分离，即热数据使用SSD磁盘存储，冷数据使用SATA磁盘存储（对于日志场景来说热数据一般存储7天，冷数据一般存储180天）
• 大批量的数据写入，如每批次10000-20000条数据写入更佳
• 编写程序时采用轮训写入ck集群节点的方式写入本地表，避免写入分布式表（会导致ck压力增加很多，如CPU使用率100%等问题）
• 磁盘IO尽可能高，尽量保持在30M/S以上，磁盘IO测试命令：

dd if=/dev/zero of=/data/text.txt bs=10k count=10000 oflag=direct

查询性能：

对于单表的查询非常快，基本都是毫秒级响应，特别适合数据分析。查询速率es性能的5倍以上。

一些优化查询性能的方法：

• 尽可能的避免join查询，对于ck而言更期望的是建立大宽表查询，而非多张表的关联查询。
• 可建立物化视图，会大大减少扫描磁盘的时间，从而提高查询效率。

节省成本：

相比ES而言，在日志场景下能节省很多成本。

• 采用列式存储，压缩比很高，基本在35%以上。
• 磁盘空间占用少，不需要像es一样建立倒排索引和正排索引之类的。
• 节省维护成本，单节点宕机时不影响其他集群节点，且数据恢复快。

使用场景

• 大数据量的日志场景
• 金融行业的交易分析场景
• 大屏的实时分析场景

目前在用的一些大厂：滴滴，京东，携程，微信，阿里云等

京东OLAP亿级查询高可用实践

ClickHouse在阿里云实时广告圈人业务最佳实践

滴滴基于 Clickhouse 构建新一代日志存储系统

从携程性能测试case中重新认识clickhouse - 简书

ClickHouse物化视图在微信的实战经验