目前来说，网上有很多相干的材料证实ClickHouse数据库查问响应速度比MySQL快上一百到几百倍。实际上，ClickHouse和MySQL具备不同的利用场景和局限性，最近在钻研这个ClickHouse打算利用于大量数据的表来做查问的时候，踩了些坑，于是在此做个总结，用于后续做数据存储以及解决的时候作为备忘，以及对想要用ClickHouse替换MySQL数据库某局部数据存储的时候做个参考。
采纳 VersionedCollapsingMergeTree 引擎来做会产生批改然而不常批改的数据
自身 ClickHouse 不适宜解决数据的频繁批改以及删除操作，对于删除和批改会耗费大量的性能，特地是频繁的单条数据批改。所以，通常咱们看到很多材料上说数据尽量批量写入，不论是以1000条，10000条还是多少条为一批，用以晋升ClickHouse的性能。
另外，自身ClickHouse的数据写入、批改、删除是异步的，对于操作写入、批改、删除后的数据须要做及时查问的，不适宜用ClickHouse来做存储，且ClickHouse不反对事务，所以ClickHouse不要用于数据一致性较高的场景。
在某些场景，可能数据通常来说是不须要批改的，然而某些场景须要批改一次或者几次，而后为了响应速度，心愿切换到ClickHouse来的话，能够采纳VersionedCollapsingMergeTree引擎来做数据存储，对于这个存储引擎，我这里能够简略介绍一下，具体的能够参考ClickHouse的具体文档。
这个存储引擎的大抵原理是，通过提供一个sign和一个version标记，sign存储的时候，值为1和-1，version存储数据的版本号，具体利用于以下两种场景的规定为：
- 须要删除的状况下，从新插入这一行的数据，
version放弃不变，sign设置为-1，那么数据表就会存在两条除了sign不一样的反复数据。而后ClickHouse会定期执行合并折叠，把这样两条数据统一，然而两条sign相加为0的数据删掉。这里就须要留神一点，是定时合并革除的，所以查问的时候须要用group by之后，再做having(sign)>0)来手动排除删除的数据。 - 批改的状况下，在做以上操作的同时，插入新数据，
sign标记为1，version在上一次的根底上减少1即可。当然查问的时候，也须要进行手动排除前一个版本的数据。
稠密索引不适宜用于准确查问
在说这个稠密索引不适宜做准确查问之前，先来说以下我说的这种准确查问的场景：
- 须要依据某个加了索引的条件，比方
id或者user_id来查问以后行的数据； - 须要依据某个加了索引的条件，如
id或者user_id来取数据列表做分页
ClickHouse 用的是稠密索引，和MySQL的B+树不一样。（对于稠密索引和B+树索引我这里不做介绍，这两个货色如果做介绍不是一时半会能解释分明，如果有人看到我这篇文章不理解的话，能够自行去先钻研一下。）,所以再做准确条件查问的时候，ClickHouse扫描数据量会很大，理论响应速度并不会达到现实的状态。
而对于ClickHouse采纳了稠密索引的状况，特地适宜用group by来做查问，通过几次group by 之后，就能排除大量的数据，所以通常状况下最适宜的场景就是用于解决统计查问，在这种状况下，大量数据状况下响应速度比MySQL快几十倍，几百倍就能提现进去了。
列式数据库不适宜一次性查问大量列
另外就是ClickHouse的列式数据库的个性，基于以上说的，须要准确查问的场景，一次性须要查问大量的字段状况下，响应速度也没有设想的现实。就算式减少了很多个group by条件，最初因为须要扫描的列很多，在MySQL正确加索引的状况下，ClickHouse响应速度通常没有MySQL快。
ClickHouse 查问成果比 MySQL 稳固
具体的测试我这里就不做多说，次要说一下场景。在两种数据表都正确做好索引的状况下，在做2亿数据列表查问的时候，MySQL在做分页数据查问的时候，开始的几页查问会显著比拟耗时，大略在500ms至800ms不等，然而后续的的分页查问基本上能达到50ms至80ms，这里应该是MySQL数据预热起了作用。然而ClickHouse基本上都是稳固在230ms至300ms。
总结
以目前的测试和察看来看，如果须要做统计查问，且数据不是频繁批改的状况下，采纳ClickHouse来存储和解决数据查问。如果须要频繁批改或是做大数据列表查问的场景，最好的计划还是用MySQL查问，并对数据进行分表处理，失去的数据响应性能会比ClickHouse好太多。