首页 > 数据库 > MySQL

ClickHouse 与 MySQL 数据库适用场景对比总结

来源：SegmentFault

时间：2023-02-24 12:26:46 152浏览收藏

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《ClickHouse 与 MySQL 数据库适用场景对比总结》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

目前来说，网上有很多相关的资料证明

ClickHouse

数据库查询响应速度比

MySQL

快上一百到几百倍。实际上，

ClickHouse

和

MySQL

具有不同的应用场景和局限性，最近在研究这个

ClickHouse

打算应用于大量数据的表来做查询的时候，踩了些坑，于是在此做个总结，用于后续做数据存储以及处理的时候作为备忘，以及对想要用

ClickHouse

替换

MySQL

数据库某部分数据存储的时候做个参考。

采用

VersionedCollapsingMergeTree

引擎来做会产生修改但是不常修改的数据

本身

ClickHouse

不适合处理数据的频繁修改以及删除操作，对于删除和修改会消耗大量的性能，特别是频繁的单条数据修改。所以，通常我们看到很多资料上说数据尽量批量写入，不管是以1000条，10000条还是多少条为一批，用以提升

ClickHouse

的性能。

另外，本身

ClickHouse

的数据写入、修改、删除是异步的，对于操作写入、修改、删除后的数据需要做及时查询的，不适合用

ClickHouse

来做存储，且

ClickHouse

不支持事务，所以

ClickHouse

不要用于数据一致性较高的场景。

在某些场景，可能数据通常来说是不需要修改的，但是某些场景需要修改一次或者几次，然后为了响应速度，希望切换到

ClickHouse

来的话，可以采用

VersionedCollapsingMergeTree

引擎来做数据存储，关于这个存储引擎，我这里可以简单介绍一下，具体的可以参考

ClickHouse

的详细文档。

这个存储引擎的大致原理是，通过提供一个

sign

和一个

version

标记，

sign

存储的时候，值为

和

-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

好太多。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。

mysql MySQL 数据库后端大数据处理 clickhouse

声明：本文转载于：SegmentFault 如有侵犯，请联系study_golang@163.com删除

ClickHouse 与 MySQL 数据库适用场景对比总结

采用
VersionedCollapsingMergeTree
引擎来做会产生修改但是不常修改的数据

稀疏索引不适合用于精确查询

列式数据库不适合一次性查询大量列

ClickHouse
查询效果比
MySQL
稳定

总结