Clickhouse一览：我奶一口，未来几年ClickHouse必起飞

前言

我记得在我面试的时候，我的面试官（也是我后来的老大）钱总问我：“你们这个查询系统，在面对大数据量的时候，除了mysql数据库，还有什么别的选择吗？”我当时回答，“MongoDB。”
现在进了公司，发现这个问题的正解是——Clickhouse。

ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用：

• 今日头条 内部用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。
• 腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。
• 携程内部从18年7月份开始接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。
  快手内部也在使用ClickHouse，存储总量大约10PB， 每天新增200TB， 90%查询小于3S。

引用自https://zhuanlan.zhihu.com/p/98135840

ClickHouse是一个：来自俄罗斯的、性能彪悍的、面向大数据分析、列式存储的的开源型数据库。

来自俄罗斯

ClickHouse是Yandex在2016年6月15日开源的一个专门面向数据分析的数据库。Yandex大家肯定没有听过，这个公司是在俄罗斯做搜索引擎的，市场覆盖率达到了俄罗斯全境68%（不过我寻思俄罗斯本来也没多少人）。但是俗话说的好，酒香不怕巷子深，东西好不怕没人用。这款数据库可以说是针对市场痛点设计的。用户基数大了之后，每天信息的流水动辄超多xxTB。这些数据有一个特征：

• 它不怎么需要改动（实际上流水信息不应该进行改动）；
• 读多于写——数据写进去就写进去了，后续主要是对他们进行分析。

针对这些数据，如果以传统的方式进行分析，那是比较头痛的。但是现在有ClickHouse；直接存到ClickHouse里面，后续直接基于ClickHouse进行分析。

性能彪悍

更让人惊讶的是，这个列式存储数据库的跑分要超过很多流行的商业MPP数据库软件，例如Vertica。如果你没有听过Vertica，那你一定听过 Michael Stonebraker，2014年图灵奖的获得者，PostgreSQL和Ingres发明者（Sybase和SQL Server都是继承 Ingres而来的）, Paradigm4和SciDB的创办者。Michael Stonebraker于2005年创办Vertica公司，后来该公司被HP收购，HP Vertica成为MPP列式存储商业数据库的高性能代表，Facebook就购买了Vertica数据用于用户行为分析。
作者：liuzx32
链接：https://www.jianshu.com/p/350b59e8ea68
来源：简书

在NJU期间选修了一门叫大数据分析的课，课上主要介绍的技术基于Hapoop和spark进行数据分析。这一套技术栈我当时用的时候就不太喜欢——搭建起来是真非常非常麻烦。现在有了ClickHouse，方便快捷，谁还特么用Hive。
同样是商业数据库软件，ClickHouse的跑分结果竟然是“友商”Vertica的5倍，也就是说ClickHouse的处理速度要比Vertica快5倍。在面对100Million数据量级的时候，ClickHouse要比Hive快279倍，比Mysql快801倍；在面对1Billion数据集的时候，Hive和Mysql已经无法完成任务了，ClickHouse还能高效完成。

面向大数据分析

其实从这样一款数据库的起源角度来看，大概能猜出来它主要是做什么的——分析各种各样的大批量日志数据。

• 非常契合电商大数据分析的场景。
• IOT时代来临，产生大量边缘端的数据，ClickHouse大有用武之地。
• 用户行为分析等各类日志分析。

列式存储

传统数据库（在学校里学的几乎所有数据库，比如Mysql、Oracle等）都是基于行进行存储的。
在基于行式存储的数据库（关系型数据库）中：

1. 数据时按行存储的
2. 没有索引的查询将会使用大量的IO操作，而建立索引又会消耗大量的空间
3. 大规模的查询性能不尽如人意

而在列式数据库之中：

1. 数据是按照列存储每一列单独进行存储
2. 数据即使索引
3. 只访问查询涉及的列——这将会大量降低系统的IO操作量
4. 对大规模的查询非常友好，但是对Update、Delete的支持较差。

列式数据库在分析需求（获取特点——每次查询几个维度，通常是）时候，不仅搜索时间效率占优势，其空间效率也是很明显的。特别是针对动辄按T计算的数据量来说，在分布式环境中能进行压缩处理能节省宝贵的内部带宽，从而提高整个计算任务性能。

综合来看，数据库的主要四个操作可以分为两类：

• 读操作
• 写操作（增、删、改）

基本上读操作和写操作是平衡的；如果你需要极致的读操作性能，那么你的写操作必然会比较拉跨。相反如果你需要读操作和写操作性能都过得去，那么它们两者中的任何一个都不可能会有极致的性能。又到了不得不面临TradeOff的时候。列式存储数据库就是这样一种完全面向读操作，然后写操作非常拉跨的极端“偏科”的设计，但是这类设计就是专门为了大规模读、大规模分析而设计的。

总结

其实拆开来讲，这四个部分的每一个部分都能够写很多东西；这个博客权当一个科普。我奶一口，将来5年ClickHouse必起飞。