天啦，从Mongo到ClickHouse我到底经历了什么？

Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475

前言：

在实现前端监控系统的最初，使用了 Mongo 作为日志数据存储库。文档型存储，在日志字段扩展和收缩上都能非常方便。天生的 JSON 格式和 NodeJs 配合也非常贴合。就这样度过了几个月的蜜月期。

而后有一天发现，表里的数据越来越大了（单表上亿），查询变慢了，特别是聚合查询。于是使用了各种优化手段：复合索引、时间条件约束、定期清理过老数据等等，但最终效果都不理想。

在事情的发展过程中也从同事口中了解到有一个叫 ClickHouse 的数据库，也许对目前的场景比较有帮助。于是，自己经历了：

• “Mongo是最棒的”
• “一定是我 Mongo 没用好，继续深入优化肯定能行”
• “我玩不动了，看看 ClickHouse 吧”
• “ClickHouse 真香”

的心路历程。到现在已经稳定使用 ClickHouse 许久之后，回顾历史，有了这篇文章。

Mongo的苦与乐：

在最开始使用 Mongo 时，觉得使用起来非常顺手。在使用过程中，也不断的进行过优化，下面大概说下几个核心设计点和遇到的问题。

• 分表

前端监控日志收集是按照应用和数据类型区分来建表的，这算作一定的优化和单元拆分，可以让数据不要全部集中在一起，也方便后期应用删除。在某些表数据量特别大的情况下，想要主从模式的单表按照时间分区，在mongo中，其实并不支持时间分区，只支持集群分片。也考虑过按照月份再分表，这样的结果大概就是 app1_202101、app1_202102 这样来分，但是这样分的结果就是查询会被时间范围限制，不能方便的查连续的跨月的数据，会影响到我们很多的应用场景。

• 索引

日志数据主要更偏向于按照时间来查询，于是使用时间作为单索引。而后为了优化多字段聚合查询，还使用了基于实际查询条件的复合索引，但实际效果并不理想，而且索引本身会占据存储空间。

• 限制查询条件

最初进入后台系统的时候，没有限制时间，所以默认会查询所有时间范围的数据，在表数据量非常大的时候，就会需要很长时间，于是对所有查询都做了默认的时间条件限制。但这种方式治标不治本，也不能完全满足某些场景下的查询需求。

• 数据清理

既然表的数据量大，造成了查询缓慢，那就删除半年前的数据，使表的数据量维持在半年内。这时可能需要一个定时任务来删除半年前的数据，但其实数据量大的表也只是监控的某几个前端应用，只对这几个表做删除就行了（其他的应用查询性能不慢的能保留尽量保留），这里需要额外的判断逻辑。

在删除数据的过程中发现，当一个表上亿以后，我删除1个月左右的数据（大概千万级），数据库CPU直接拉满了，执行时间会非常长，这个时候我们查询和插入都会被影响到，这里提一嘴我们使用的主从模式。没事，那就一天天的删除吧。清理了数据量大的表之后，又发现空间没有释放，Mongo 只有在删除集合时才会释放空间，只是移除数据，空间占用依然在，如果要释放空间，需要把数据库先停下来，但这样会影响正常使用（不停机直接释放空间也是有方案的，只是有一定的实现成本，大概流程是拷贝一个新表，再切换，最后再做一次数据同步）。如果某一段时间某表的日志量上升，这个表空间占用会被拉大。突然发现这个优化方案也是治标不治本，难受～

• explain查询分析

在优化的过程中，也使用了 Mongo 的分析语句，做查询分析，但是发现事实就是，这些查询语句没啥问题，它就这个速度。

小结

随着，慢查询的增多，项目本身也成为了一个风险项目。最初前端监控系统和其他业务系统共享使用的云库，由于前端监控在某段时期存在数据库慢查询的问题，而这个慢查询刚好也是分钟级别的定时任务。导致数据库产生了很多慢查询，CPU 消耗也一直维持在较高位置。前端监控本身也会保持一定的监控数据并发量在做存储。前端监控拖累了整个数据库，并且由于慢查询日志很多，导致其它业务在排查数据库慢日志的时候，很难找到他们自己的日志。后来，运维同事就给单独配置了一个独享数据库给前端监控，不是说同事给开小灶给福利，而是花点小钱，把我这颗毒瘤清理出去。

迁移前配置12核32g三节点（一主两从），迁移后为2核4g三节点。虽然配置变小了，但是前端监控独享