“ClickHouse works 100-1000x faster than traditional approaches”，这是官方网站首页的一句话，clickhouse比传统方式快100到1000倍，本次分享会围绕一个快字，了解clickhouse究竟有多快以及它是怎么做到这么快的。
Apache Doris前身是百度Palo，是百度开发的面向在线报表和分析的数据仓库系统，在百度内部一些数据分析的场景有着广泛的应用，自2017年在GitHub上开源以来（比ClickHouse晚了1年），先后被国内十多家互联网公司使用，不过既生瑜何生亮，对于这两个高性能的OLAP分析引擎选型，可以结合自己公司的一些场景或者是技术栈，比如公司内部是高并发的场景，则可以考虑下Doris，毕竟目前来看高并发是Clickhouse的短板，希望Clickhouse未来能解决，其他方面这里不展开对比，网上有人做了比较全面的对比。
从上图来看，Clickhouse在最近几年提交的代码数越来越多，基本上现在每个月保持一个版本的发布，主要原因是了解或者使用Clickhouse的用户越来越多，ClickHouse社区越来越活跃，社区的活跃反过来助力推动Clickhouse的向前发展
Mysql基于行存储的结构，这样存储的好处是比如你要查询账号是3645这个人的信息，你只需要一次磁盘的查找，找到3645然后再顺序读取到Luce，21就可以了；不过加入你要查询所有用户的年龄的话，你需要走全表扫描，遍历很多不必要的数据。而列存储有什么好处呢？其实分析场景中，我们一般会读大量的行而取少量的列，在列式存储结构下，我们只需要取对应的列数据就可以，不参与计算的列完全不会被扫描到，这会极大的降低磁盘IO的消耗。
集成引擎补充一点：Mysql数据库引擎，例如允许将远程的MySQL服务器中的表映射到ClickHouse中，并允许对表进行INSERT和SELECT查询，MySQL数据库引擎会将对其的查询转换为MySQL语法并发送到MySQL服务器中，让你可以执行诸如SHOW TABLES或SHOW CREATE TABLE之类的操作
上图中的LSM-Trss并不是真实的mergetree的结构，只能说mergetee借鉴了LSM-tree的思想，在《Clickhouse原理解析与应用实践》一书中给出了详细的图例，远远比LSM-tree复杂很多。LSM-tree来源于谷歌大名鼎鼎的“三驾马车”的论文-- “BigTable”论文中的文件组织方式，全名名字叫 Log Structured-Merge Tree，它是一种分层，有序，面向磁盘的数据结构，其核心思想是充分了利用了磁盘批量的顺序写要远比随机写性能高出很多，这里面最典型的例子就属于Kakfa了，把磁盘顺序写发挥到了极致，故而在大数据领域成为了互联网公司标配
这里是一张公司内部大数据的架构图，因为比较敏感，所以这里就不放出来了，用文字表达一下：在原本的大数据计算和存储引擎加了ClickHouse，作为对外的数据共享或者是数据服务。
878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
