ClickHouse 数据库 优缺点

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。由号称“俄罗斯 Google”的Yandex开发而来，在2016年开源，在计算引擎里算是一个后起之秀，在内存数据库领域号称是最快的。由于它有几倍于GreenPlum等引擎的性能优势，所以不少人都选择将其安装云服务器中使用。

ClickHouse是一个列导向数据库，是原生的向量化执行引擎。它在大数据领域没有走Hadoop生态，而是采用Local attached storage作为存储，这样整个IO可能就没有Hadoop那一套的局限。它的系统在生产环境中可以应用到比较大的规模，因为它的线性扩展能力和可靠性保障能够原生支持shard+replication这种解决方案。它还提供了一些SQL直接接口，有比较丰富的原生client。

1.优点
数据按列存储，非常适合聚合计算。
为了高效的使用CPU，数据不只仅按列存储，同时还按向量进行处理；
数据压缩空间大，减少IO传输，但数据的解压缩需要消耗CPU,处理查询高吞吐量，每台服务器秒级数十亿行。
索引是类似跳表结构，并不是mysql的B树结构，不需要满足最左原则。
写入速度非常快，50-200 M/S ,建议写本地表而不是all表,对于大量的数据更新非常实用。
查询快，比Vertica快5倍以上，比GP快10倍以上，比HIVE快200倍以上，比MYSQL快800倍以上。
高效实用CPU,并行处理单个查询，充分利用多核，在多个服务器山分布式处理。
开源的列存储，支持线性扩展，简单方便，高可用容错。

2.缺点
不支持事务，所以不存在隔离级别，所以定位是分析性数据库。
不支持高并发，官方建议QPS为100，可以通过修改config.xml的max_concurrent_queries配置。
采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以不能支持高并发场景，默认单查询也会使用CPU核数为服务器核数的一半。
建议1000条以上批量的写入，不建议单条记录修改和删除。
尽可能作1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操做，由于ClickHouse底层会不断的作异步的数据合并，会影响查询性能，这个在作实时数据写入的时候要尽可能避开
SQL满足平常使用80%以上的语法，join写法比较特殊；最新版已支持相似SQL的join，但性能很差；
不支持BIOB DOCUMENT 类型数据，聚合结果必须小于一台机器的内存大小。

相关优化：

1，关闭虚拟内存，物理内存和虚拟内存的数据交换，会致使查询变慢。

2，为每个帐户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值。

3，JOIN操做时必定要把数据量小的表放在右边，ClickHouse中不管是Left Join 、Right Join仍是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，因此右表必须是小表。

4，批量写入数据时，必须控制每一个批次的数据中涉及到的分区的数量，在写入以前最好对须要导入的数据进行排序。无序的数据或者涉及的分区太多，会致使ClickHouse没法及时对新导入的数据进行合并，从而影响查询性能。

5，尽可能减小JOIN时的左右表的数据量，必要时能够提早对某张表进行聚合操做，减小数据条数。有些时候，先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短。

6，ClickHouse的分布式表性能性价比不如物理表高，建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满。

7，CPU通常在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要很是关注。

性能状况：

1,单个查询吞吐量：若是数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约可以以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度能够达到30GB／s）。若是数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，若是一个磁盘容许以400MB／s的速度读取数据，而且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，若是你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的状况下。

2，处理短查询的延时时间：数据被page cache缓存的状况下，它的延迟应该小于50毫秒(最佳状况下应该小于10毫秒)。 不然，延迟取决于数据的查找次数。延迟能够经过如下公式计算得知： 查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

3，处理大量短查询：ClickHouse能够在单个服务器上每秒处理数百个查询（在最佳的状况下最多能够处理数千个）。可是因为这不适用于分析型场景。建议每秒最多查询100次。

4，数据写入性能：建议每次写入很多于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。若是您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。若是您的行更小，那么写入速度将更高。为了提升写入性能，您可使用多个INSERT进行并行写入，这将带来线性的性能提高。

count: 千万级别，500毫秒，1亿 800毫秒  2亿 900毫秒 3亿 1.1秒
group: 百万级别 200毫米，千万 1秒，1亿 10秒，2亿 20秒，3亿 30秒
join：千万-10万 600 毫秒， 千万 -百万：10秒，千万-千万 150秒

ClickHouse并不是无所不能，查询语句须要不断的调优，可能与查询条件有关，不一样的查询条件表是左join仍是右join也是颇有讲究的。

其余补充：

1，MySQL单条SQL是单线程的，只能跑满一个core，ClickHouse相反，有多少CPU，吃多少资源，因此飞快；

2，ClickHouse不支持事务，不存在隔离级别。ClickHouse的定位是分析性数据库，而不是严格的关系型数据库。

3，IO方面，MySQL是行存储，ClickHouse是列存储，后者在count()这类操做自然有优点，同时，在IO方面，MySQL须要大量随机IO，ClickHouse基本是顺序IO。

4，有人可能以为上面的数据导入的时候，数据确定缓存在内存里了，这个的确，可是ClickHouse基本上是顺序IO。对IO基本没有过高要求，固然，磁盘越快，上层处理越快，可是99%的状况是，CPU先跑满了（数据库里太少见了，大多数都是IO不够用）。