数据库是用MongoDB好,还是用MySQL(PostgreSQL)好

写这篇文章的时候已经是2023年了，相信同样标题的文章和释疑已经很多了，但是最近项目中遇到了一些运维问题，因此选择将项目中的MongoDB数据库切换为其它数据库。

项目分为两个主要的子项目，以下分别介绍一下。

项目一，主要应用场景是OLAP，单个表（或者MongoDB中的Collection，以下均用表替代表述）最多大约6000万条数据，100个字段左右，字段均为基础类型，无JSON嵌套关系，每日清空表后集中4个小时写入（相信部分读者已经猜到用途了），写入的同时有并行读取分析需求，单个数据库大约4-6张同样的大规模数据表。

项目一最开始使用的是MongoDB，遇到了以下问题。问题（1），MongoDB需要的内存量，大概是同等量的CSV数据存储形态的10倍，也就是说，例如你有1GB CSV文件，大概需要10GB内存支持，由于这种情形，单机内存配置到了512GB，但仍然不能解决随着数据量增长查询效率急剧下降的问题，因超时导致查询失败的情形非常常见；问题（2），内存用尽后，产生了大量的硬盘交换，导致性能进一步下降且加速消耗硬盘寿命（HDD、SSD均有此问题）；问题（3），重启困难，如遇到硬件问题或其它情形重启服务器，MongoDB似乎不会主动加载数据到内存，直到有相关查询触发，导致初始访问十分困难，如果数据量较大，基本导致无法查询。

这些问题确实可能和使用不当有关，但是由于运维人力有限，且一个萝卜多个坑，没有专家支持，没有集群，因此最终使用列式数据库ClickHouse替换，同样的非专家运维情形下，ClickHouse基本无需配置，内存占用量降低70%（CPU需求并未下降），硬盘所需存储数据量下降为同等量的CSV数据存储形态的1/8倍，也就是说，例如你有1GB CSV文件，大约被压缩为128MB。总投入成本直线下降。

需要补充的是，虽然都是OLAP场景，但很多人的需求是对不可靠数据的收集和清洗，相信这一点还是MongoDB更胜一筹。

项目二，小型管理系统，业务场景较为简单，偏重于OLTP，部分数据列存在关联关系，但不需要十分严谨的事务操作，譬如，产品一张表，用户一张表，用户需要和产品建立权限管理关系，但是删除产品并不一定要求从用户中删除此关联关系。最初没有使用MySQL而是使用MongoDB，就是希望利用MongoDB的文档特性，字段中可以存入JSON Array，不需要建立过多的中间关联表。

然而，项目二数据量不大同样遇到了一些运维问题。问题（1），缺乏便捷的数据库管理工具，这个问题直接导致许多临时修改无法快速操作，无论是开发环境还是测试环境，又不能像SQL一样在直观的在Console进行事务操作；问题（2），与SpringBootJPA一类的框架配合使用已经足够成熟，但是细节不足，例如，联合唯一Key的自动建立，数据列的自动拓展，其中，特别是数据列自动拓展这一条，原本是MongoDB文档数据库的特点，但是当与JPA配合之后，如果代码中更新了对象字段，就会导致数据与代码字段不匹配，异常频发，手动更新每行数据的字段，缺乏便捷的数据库客户端，又十分困难；问题（3），这个问题可能会有争议，但我确实遇到了，也是驱动我彻底放弃MongoDB的主要原因，在某次通过第三方数据库客户端维护数据时，发出了删除部分行的命令，确定是删除了部分行，因为鼠标选中行后操作，然而开始执行后MongoDB死机，Collection无法访问，无奈重启，重启后，丢失了这个Collection的很多数据列，是的，不是行丢了，是一些列不见了，未能查明原因。

由于MySQL已经支持JSON字段，JPA也能支持，因此项目二最终切换回了MySQL。

声明，本文中的内容主要为个人使用经验和部分狭隘应用场景下的描述，且更多是偏项目使用运维中的问题，如果有足够资金和人力支持，应有更好的解决方案，因此仅供参考。