ClickHouse学习笔记一

clickhouse的进化之路

ClickHouse是由俄罗斯的Yandex公司研发的，这家公司的主要业务是搜索引擎，而他们的营收是非常依赖流量和在线广告业务的，所以针对网络流量的在线分析是十分必要，且因为数据量十分的庞大，也是经历了几次技术的更新才又了当前的Clickhouse。

MySQL分布式集群

早期的Yandex Metrica 在实现流量分析时，那个时候还是以固定的报表形式帮助用户进行分析，这在当下也还是许多的项目在使用的，像一般进入首页都会是一个数据统计的界面，但是这种形式下分析维度和场景是固定的，新的需求往往都是需要it人员进行程序的迭代和更新的。
那个时候还是关系型数据库主导的时期，所以他们选择了以MySQL集群的方案进行数据的存储和分析，也遇到了以下几个问题：

1. 磁盘碎片 在一个大型的分布式集群环境下，数据的写入是完全随机存储的，这样会导致产生大量的磁盘碎片，而普通的机械硬盘的读写性能是比较低的（也不可能都使用SSD），如果需要读取大量的行数进行聚会处理，响应的时间往往是不能接受的；
2. 数据的爆发式增长 随着时间的推移，互联网的高速发展，数据量也飞速积累，虽然Yandex做了很多的优化，将分析报告控制在26秒内返还，但这套方案显然已经有点力不从心了。

Metrages时期

由于MySQL的局限性，Yandex公司自己研发了一套新的系统并命名为Metrage,具体有以下2大不同的地方：

1. 它使用的是Key-Value键值对模型代替了关系型模型，在索引方面也使用LSM树代替了B+树，而数据的写入也是先将数据写入到内存中的一个小树中，然后到达某个阈值时再将小树刷到磁盘中生成一个小数据段，这样极大的提高了写入性能也保证了数据的局部有序性。
2. 通过预处理的方式将需要分析的数据预先聚合，针对需要分析的具体场景实施立方体建模，然后将所有的维度组合情况都预先计算处理存储好，这样在进行数据查询时，就可以针对预先统计好的数据进行快速查询

但是通过这种预先聚合的方式会带来另外一种新的问题：数据膨胀
因为需要先根据维度预先进行组合计算，那么当维度较多时，数据的组合方式是一种指数级的增长，有时可能会导致存储的数据比原始数据多少10～20倍。

OLAPServer时期

如果说Metrage是性能瓶颈的产物，那么OLAPServer就是产品升级倒逼的结果。
在产品的初期它仅支持固定的报表分析场景，但随着时间推移，客户更想要的是一种自定义分析报告的功能，这样可以根据自身的实际情况获取最想要的数据信息，但是Metrage因为需要预先处理，给每个客户去定制化预先处理显然也是不太现实的，这也会带来数据量的急剧膨胀，所以OLAPServer顺势而生。

1. 数据模型又换回关系型模型，而且使用了SQL作为查询语言，也让它的学习成本降低了很多。
2. 结合MyISAM和LSM树的优点，进一步优化了索引的性能
3. 采用列式存储，将索引文件和数据文件按列的粒度拆分

但是OLAPServer最初的定位只是和Metrage结合使用，所以它当前还不能算是一个数据库管理系统。

ClickHouse时代

因为OLAPServer在数据查询方面并不比Metrage差太多，而且在查询灵活性上更胜一筹，所以Yandex团队在OLAPServer基础上将其完善成一个数据库管理系统，于是ClickHouse诞生了，并在2016年进行了开源。

ClickHouse的使用

适用场景：它是一款高性能的OLAP数据库，在数据分析类的场景下我们都可以尝试使用它，且当前国内的阿里、腾讯、新浪、携程等都已经在使用；

不擅长：不支持事务、支持但不擅长根据主键按粒度查询、不擅长按行删除数据；但这些对于一个OLAP数据库来说并不能算作缺点。

参考《ClickHouse原理解析与实践应用》-朱凯、官方文档