clickhouse 的前世今生(2)

作者: ZYvette | 来源:发表于2021-05-08 16:51 被阅读0次

ClickHouse的发展历程

A. 顺理成章的MySQL时期

早期需求:

固定报表的形式帮助用户进行分析,例如分析访问者使用的设备、访问者来源的分布之类。

技术方案:

Mysql作为它的数据存储和分析引擎的解决方案。
表引擎只用的MyISAM(不支持事务)

顺序读写性能更高

  1. 读取顺序文件会用更少的磁盘寻道和旋转延迟时间(这里主要指机械磁盘)
  2. 操作系统可以预读取

MyISAM表引擎使用B+树结构存储索引,而数据则使用另外单独的存储文件(InnoDB表引擎使用B+树同时存储索引和数据,数据直接挂载在叶子节点中)。

缺点:实际只有单线程写入,且没有删除修改,才会顺序读写。
随着数据量大,性能明显下降。

B. 另辟蹊径的Metrage时期

Metrage在设计上与MySQL完全不同。

  • 首先,在数据模型层面,它使用Key-Value模型(键值对)代替了关系模型;
  • 其次,在索引层面,它使用LSM树代替了B+树;
  • 最后,在数据处理层面,由实时查询的方式改为了预处理的方式。

设计一:LSM 树

基于原理:磁盘或内存的连续读写性能远高于随机读写性能

LSM 介绍:https://hzhu212.github.io/posts/2d7c5edb/
原理: 新来的数据,存入mem的树中,达到一定程度,合并disk中。局部segment有序,整体无序。读取采用稀疏索引找到对应segment。

优化:磁盘顺序读取、预读缓存、稀疏索引等

设计二:数据预处理

通过预处理的方式,将需要分析的数据预先聚合

缺陷:采用MOLAP,维度组合的爆炸会直接导致数据膨胀。

C.自我突破的OLAPServer时期

背景:初期只支持固定分析报告,不支持自定义分析报告。

设计

  • 在数据模型方面,它又换回了关系模型,因为相比Key-Value模型,关系模型拥有更好的描述能力

  • 在存储结构和索引方面,它结合了MyISAM和LSM树最精华的部分
    存储结构:它与MyISAM表引擎类似,分为了索引文件和数据文件两个部分
    索引方面:使用了LSM树所使用到的稀疏索引
    数据文件:沿用了LSM树中数据段的思想,即数据段内数据有序,借助稀疏索引定位数据段

  • 列式存储的思想,将索引文件和数据文件按照列字段的粒度进行了拆分,每个列字段各自独立存储,以此进一步减少数据读取的范围。

缺陷:从功能的完备性角度来看,OLAPServer可称之为数据库,不能成为数据库管理系统,没有DBMS应有的基本管理功能(DDL查询等)。

D.水到渠成的ClickHouse时代

难点:

(1)由于预先聚合只能支持固定的分析场景,所以它无法满足自定义分析的需求。
(2)维度组合爆炸会导致数据膨胀,这样会造成不必要的计算和存储开销。因为用户并不一定会用到所有维度的组合,那些没有被用到的组合将会成为浪费的开销。
(3)流量数据是在线实时接收的,所以预聚合还需要考虑如何及时更新数据。

设计

  • 预聚合方案改为实时聚合
  • 查询方面,实现完备的数据库管理系统(DBMS)
image.png

1.8 ClickHouse适用的场景

ClickHouse做到了90%的查询都能够在1秒内返回的惊人之举

1.9 ClickHouse不适用的场景

❑ 不支持事务。
❑ 不擅长根据主键按行粒度进行查询(虽然支持),故不应该把ClickHouse当作Key-Value数据库使用。
❑ 不擅长按行删除数据(虽然支持)。

对于一款OLAP数据库而言,上述这些能力并不是重点,只能说这是为了极致查询性能所做的权衡。

优点:

  • 为了高效的使用CPU,数据不仅仅按列存储,同时还按向量进行处理;
  • 数据压缩空间大,减少IO;处理单查询高吞吐量每台服务器每秒最多数十亿行;
  • 索引非B树结构,不需要满足最左原则;只要过滤条件在索引列中包含即可;即使在使用的数据不在索引中,由于各种并行处理机制ClickHouse全表扫描的速度也很快;
  • 写入速度非常快,50-200M/s,按照每行100Byte估算,大约相当于50W-200W条/s的写入速度。对于大量的数据更新非常适用。

缺点:

  • 不支持事务;
  • 不支持高并发,官方建议qps为100,可以通过修改配置文件增加连接数,但是在服务器足够好的情况下;
  • SQL满足日常使用80%以上的语法,join写法比较特殊;最新版已支持类似SQL的join,但性能不好;
  • 尽量做1000条以上批量的写入,避免逐行insert或小批量的insert,update,delete操作,因为ClickHouse底层会不断的做异步的数据合并,会影响查询性能,这个在做实时数据写入的时候要尽量避开;
  • Clickhouse快是因为采用了并行处理机制,即使一个查询,也会用服务器一半的CPU去执行,所以ClickHouse不能支持高并发的使用场景,默认单查询使用CPU核数为服务器核数的一半,安装时会自动识别服务器核数,可以通过配置文件修改该参数。

相关文章

  • clickhouse 的前世今生(2)

    ClickHouse的发展历程 A. 顺理成章的MySQL时期 早期需求: 固定报表的形式帮助用户进行分析,例如分...

  • clickhouse 的前世今生

    背景 Google于2003~2006年相继发表了三篇论文“Google File System”“Google ...

  • ClickHouse原理解析与应用实践

    第1章 ClickHouse的前世今生 在大量数据分析场景的解决方案中,传统关系型数据库很快就被Hadoop生态所...

  • 前世今生2

    1. 2010年的电影《剑雨》,里面的一个前缘故事我记忆尤深,每每想起,依旧会觉得很感动。 为了争抢一具传闻能生死...

  • 前世今生(2)

    在前世,芳草围成的小溪从山涧而来,从门前流过,像一条银链,三三两两的小鱼游弋在鹅软石铺就的小溪里。阳光洒进小溪,水...

  • 将军在上之男昭女惜重生三世千年孽缘

    前世!今生!来世再续! 前世欠谁!今生还!来世再续前缘! 前世因!今生续!来世果!

  • 人死,并非如灯灭……

    “今生,是前世的“来生”,是来生的“前世”。在今生中,我们能见到自己的前世与来生。回溯前世,是为了改善今生;回到今...

  • 前世今生来世缘

    谈何前世情 今生还 今生情 来世还 前世孽债 前世还 未了 今生还 今生欠 今生还 谈何来世还 来世欠 来世还 能...

  • iOS Device ID 的前世今生

    iOS Device ID 的前世今生 iOS Device ID 的前世今生

  • EOS的前世今生(2)

    1、EOS是什么? 官方的解释是企业级商用的操作系统,或者说区块链世界底层的商用操作系统。而从白皮书以及EOS团队...

网友评论

    本文标题:clickhouse 的前世今生(2)

    本文链接:https://www.haomeiwen.com/subject/ilpudltx.html