导读： 7 月 13 日，CloudQuery（下文简称 CQ） 2.2.0 版本正式发布，在看到官方文档对新版本的介绍后，马上进行安装测试。本文主要为大家介绍从 CQ 1.4.2 升级到 2.2 的考量因素、测试情况，分享一些实践经验，给大家提供一些参考。

业务背景及 V 1.4.2 的使用感受

我司主要运营的业务为一款即时通信软件，最主要使用的数据库就是 MongoDB。MongoDB 数据库主要负责存储用户间聊天内容的数据，并且存在单个库中存在上千个集合的情况，开发人员如果直连数据库进行查询或修改，会导致执行命令后期不可查，所以在云端内网环境部署了 CloudQuery，用来针对 MongoDB 数据库进行审计。

虽然 CloudQuery 社区版 V 1.4.2 在数据操作上已经足够满足我们当前的需求，也具备完善的用户授权和审计功能，但在使用过程中仍有一些问题会比较困扰我们，比如：

• 无法通过审计界面查看用户对 MongoDB 数据库执行过的语句；
• 资源使用率较高，导致经常提示内存利用率报警；
• MongoDB 相关查询时间较⻓(已知原因为部分库内集合过多) ；
• 用户权限不足时，不能通过 CloudQuery 进行申请权限，只能通过联系管理员进行增加；

在得知 V2.2.0 新增支持 MongoDB，且资源配置降为 CPU：4-core；内存：16G；硬盘：100G 后，果断升级！

升级 V2.2.0 后体验

整体感受安装更加方便了，只需直接执行 shell 脚本后即可进行安装，无需再通过 web 界面进行安装配置，相较于旧版本安装速度也有较大提升，新版本解决了旧版本中出现的部分问题，但仍然存在一些已有问题。

测试场景

本次升级测试的场景为：通过本地部署 CloudQuery 后，添加 MongoDB 和 MySQL 两种数据库连接，分别测试授权用户不同权限情况下，对指定数据库进行操作后的审计结果，以及查询速度的检验。

解决的痛点

1、可实现对用户操作 MongoDB 数据库后，执行语句内容的记录。


2. 性能优化较好，未再出现多次查询后内存利用率报警的情况。

3、用户可直观查看针对数据库所拥有的权限，没有进行授权的权限可以直接发起申请。

未能解决的问题

如果数据库内集合较多，查询语句依然执行时间较⻓。

除了我们最关注的对 MongoDB 的审计问题，对比原来 1.4.2 版本，新版本不论是在功能上还是稳定性上确实都有非常大的提升：

• V 1.4.2 在我看来是面向小团队的操作管控平台，对比新版本，虽然在管控能力上可以满足小团队的需求，但整体来说更偏向是一个操作平台。而新版本从功能上来看就是「正经」面向企业的产品，管控功能完善太多了。
• 新增了提权功能、数据变更、动态脱敏、数据传输……这些还只是安装完之后光在页面上看到的，很多我都还没研究过哈哈
• 审计功能对比老版本也完善很多，原来只有审计概览和两张明细表，新版本又增加了对象审计和用户审计

总结及建议

在过去的使用体验中，CQ 已经展现出了其高效、易用、强大的特性，让数据库管理变得更为简单快捷。作为一款集成了多种数据库管理工具的平台，它的出现无疑给我们的工作带来了极大的便利。

然而，技术的发展永无止境。我们对 CQ 的期待，不仅仅停留在现有的功能和性能，更期待它能够持续创新，引领数据库管理工具的发展方向。我们希望 CQ 能够更深入地了解用户需求，持续优化用户体验，推出更多创新的功能和服务。

总体来着本次审计的体验还是比较好的，能够看到CQ一直在优化社区用户的使用体验，也有在关注和倾听社区用户的心声，并解决社区用户使用中遇到的问题。

最后对于 CQ 后续的版本，还有一些建议：

• 兼容 Docker Compose 2.0 及以上版本，安装过程中提示未安装 Dokcer Compose，原因为 Dokcer Compose 2. 0以后不再使用 docker-compose 命令，必须修改 docker-compose 位置，建议更新 shell脚本中的判断。
• 提供可直接下载压缩链接，当前阶段必须通过网盘下载后，再传输至服务器中进行安装，较为繁琐，虽然提供了多个网盘的下载地址，但是不能通过服务器直接下载，下载速度方面我使用的天翼云盘可以实现满速下载。
• 优化通过 CloudQuery 查询 MongoDB 数据库内集合较多情况下的速度。
• 官方文档中重要操作建议加粗显示，容易忽略部分内容导致后续无法操作，容易忽略部分内容导致后续无法操作。