clickhouse的进化之路
ClickHouse是由俄罗斯的Yandex公司研发的,这家公司的主要业务是搜索引擎,而他们的营收是非常依赖流量和在线广告业务的,所以针对网络流量的在线分析是十分必要,且因为数据量十分的庞大,也是经历了几次技术的更新才又了当前的Clickhouse。
MySQL分布式集群
早期的Yandex Metrica 在实现流量分析时,那个时候还是以固定的报表形式帮助用户进行分析,这在当下也还是许多的项目在使用的,像一般进入首页都会是一个数据统计的界面,但是这种形式下分析维度和场景是固定的,新的需求往往都是需要it人员进行程序的迭代和更新的。
那个时候还是关系型数据库主导的时期,所以他们选择了以MySQL集群的方案进行数据的存储和分析,也遇到了以下几个问题:
- 磁盘碎片 在一个大型的分布式集群环境下,数据的写入是完全随机存储的,这样会导致产生大量的磁盘碎片,而普通的机械硬盘的读写性能是比较低的(也不可能都使用SSD),如果需要读取大量的行数进行聚会处理,响应的时间往往是不能接受的;
- 数据的爆发式增长 随着时间的推移,互联网的高速发展,数据量也飞速积累,虽然Yandex做了很多的优化,将分析报告控制在26秒内返还,但这套方案显然已经有点力不从心了。
Metrages时期
由于MySQL的局限性,Yandex公司自己研发了一套新的系统并命名为Metrage,具体有以下2大不同的地方:
- 它使用的是Key-Value键值对模型代替了关系型模型,在索引方面也使用LSM树代替了B+树,而数据的写入也是先将数据写入到内存中的一个小树中,然后到达某个阈值时再将小树刷到磁盘中生成一个小数据段,这样极大的提高了写入性能也保证了数据的局部有序性。
- 通过预处理的方式将需要分析的数据预先聚合,针对需要分析的具体场景实施立方体建模,然后将所有的维度组合情况都预先计算处理存储好,这样在进行数据查询时,就可以针对预先统计好的数据进行快速查询
但是通过这种预先聚合的方式会带来另外一种新的问题:数据膨胀
因为需要先根据维度预先进行组合计算,那么当维度较多时,数据的组合方式是一种指数级的增长,有时可能会导致存储的数据比原始数据多少10~20倍。
OLAPServer时期
如果说Metrage是性能瓶颈的产物,那么OLAPServer就是产品升级倒逼的结果。
在产品的初期它仅支持固定的报表分析场景,但随着时间推移,客户更想要的是一种自定义分析报告的功能,这样可以根据自身的实际情况获取最想要的数据信息,但是Metrage因为需要预先处理,给每个客户去定制化预先处理显然也是不太现实的,这也会带来数据量的急剧膨胀,所以OLAPServer顺势而生。
- 数据模型又换回关系型模型,而且使用了SQL作为查询语言,也让它的学习成本降低了很多。
- 结合MyISAM和LSM树的优点,进一步优化了索引的性能
- 采用列式存储,将索引文件和数据文件按列的粒度拆分
但是OLAPServer最初的定位只是和Metrage结合使用,所以它当前还不能算是一个数据库管理系统。
ClickHouse时代
因为OLAPServer在数据查询方面并不比Metrage差太多,而且在查询灵活性上更胜一筹,所以Yandex团队在OLAPServer基础上将其完善成一个数据库管理系统,于是ClickHouse诞生了,并在2016年进行了开源。
ClickHouse的使用
适用场景:它是一款高性能的OLAP数据库,在数据分析类的场景下我们都可以尝试使用它,且当前国内的阿里、腾讯、新浪、携程等都已经在使用;
不擅长:不支持事务、支持但不擅长根据主键按粒度查询、不擅长按行删除数据;但这些对于一个OLAP数据库来说并不能算作缺点。
参考《ClickHouse原理解析与实践应用》-朱凯、官方文档