目录
1.ClickHouse 概述
2.Clickhouse 特点
2.1 列式存储
2.2 DBMS的功能
2.3 多样化引擎
2.4 高吞吐写入能力
2.5 数据分区与线程级并行
2.6 性能对比
3.Clickhouse 应用场景
4.ClickHouse 不完美之处
1.ClickHouse 概述
- ClickHouse 是俄罗斯的Yandex(欧洲最大的互联网公司之一)于2016年开源的列式存储数据库(DBMS)，使用C++语言编写，主要用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。
- 为什么叫ClickHouse：Click Stram+Data WareHouse
2.Clickhouse 特点
2.1 列式存储
- 对于列的聚合，计数，求和等统计操作原因优于行式存储。
- 由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重。
- 由于数据压缩比更好，一方面节省了磁盘空间，另一方面对于cache也有了更大的发挥空间。
2.2 DBMS的功能
- 几乎覆盖了标准SQL的大部分语法，包括 DDL和 DML ,以及配套的各种函数。
- 用户管理及权限管理
- 数据的备份与恢复
2.3 多样化引擎
- clickhouse和mysql类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类20多种引擎。
2.4 高吞吐写入能力
- ClickHouse采用类LSM Tree的结构，数据写入后定期在后台Compaction。通过类LSM tree的结构，ClickHouse在数据导入时全部是顺序append写，写入后数据段不可更改，在后台compaction时也是多个段merge sort后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力，即便在HDD上也有着优异的写入性能。
- 官方公开benchmark测试显示能够达到50MB-200MB/s的写入吞吐能力，按照每行100Byte估算，大约相当于50W-200W条/s的写入速度。
2.5 数据分区与线程级并行
- ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。
- 在这种设计下，单条Query就能利用整机所有CPU。极致的并行处理能力，极大的降低了查询延时。
- 所以，clickhouse即使对于大量数据的查询也能够化整为零平行处理。但是有一个弊端就是对于单条查询使用多cpu，就不利于同时并发多条查询。所以对于高qps的查询业务，clickhouse并不是强项。
2.6 性能对比
- 单表查询：
- 关联查询：
- 结论: clickhouse像很多OLAP数据库一样，单表查询速度由于关联查询，而且clickhouse的两者差距更为明显。
3.Clickhouse 应用场景
- 绝大多数请求都是用于读访问的。
- 数据需要以大批次（大于1000行）更新或者根本没有更新操作。
- 读取数据时，会从数据库中提取出大量的行，但只用到一小部分列。
- 表很“宽”，即表中包含大量的列。
- 查询频率相对较低（通常每台服务器每秒查询数百次）。
- 对于简单查询，允许大约50毫秒的延迟。
- 列的值是比较小的数值和短字符串（例如，每个URL只有60个字节）。
- 在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）。
- 数据一致性要求较低。
- 每次查询中只会查询一个大表。除了一个大表，其余都是小表。
- 查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小。
4.ClickHouse 不完美之处
- 不支持事物。
- 不支持真正的Update/Delete操作。
- 不支持二级索引。
- 不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下。
- SQL满足日常使用80%以上的语法，join写法比较特殊，最新版已支持类似SQL的join，但性能不好。
- 不支持窗口功能。
- 元数据管理需要人工干预维护。
- 不使用与OLTP场景、key Value 数据库。
- 支持有限操作系统。现在支持ubuntu、centos 需要自己编译，对于Windows 不支持。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
