共计 1894 个字符，预计需要花费 5 分钟才能阅读完成。
目前来说，网上有很多相干的材料证实 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 好太多。
