传统RDBMS架构师的MongoDB思维破局与落地实践

最近公司在搞新项目，其中一个架构师对他的系统设计中，是否使用大量的MongoDB存在一些困惑，作为单位的数据库架构，也作为把MongoDB在单位大面积铺开的beginner，则无旁待的解决架构师的困惑。

这个架构师资历还是蛮深的，技术交流中，是做过大的项目的，而且还是中东的一些海外的大项目。但没有聊太深，有机会继续和他聊项目中的一些问题。

从项目启动到现在差不多有4个月的时间，他大概找我聊MongoDB 有7-8次，我发现几个问题

1 软件开发人员，尤其是没有用过 mongodb的人真是不少，而且不少都是经过大项目的架构师都没有用过mongodb

2 他们对MongoDB的一开始就陷入网络铺天盖地的概念混乱，尤其是集群，这个概念。在他们的脑子里集群就和PG ORACLE SQL SERVER MYSQL的集群概念一样，就是一个数据库的Failover 的必备选项。我们需要给他们解释很多情况我们不要用 MONGODB 的集群，而是应该用复制集这个产品来作为主要的使用MongoDB的对象。

3 他们对MongoDB的数据稳定性存在疑虑，比如他们对于MongoDB为什么100毫秒写日志，但是可以依然保证数据在系统DOWN机不丢失的问题，特别的感兴趣，我也和他解释了分布式存储系统的数据库产品和单机的数据库产品的不一样，他们要完成数据在系统崩溃的数据不丢是实际用的分布式协议，保证多点可写入的方式，而不会是会传统数据的日志方式COMMIT 的方式。

4 他们对于MongoDB数据存储的中的意义没有特别的明确，比如我解释快速开发系统，并且系统前期设计变化较大，或者你的业务要求724小时在变更schema的情况下不会有锁表的情况，以及对DDL 特别敏感的业务系统，尤其宽表，大表，复杂JOIN设计的系统，可以考虑使用MongoDB来解决你的问题。基本用上了都没有说不好的，尤其在我们这样对DDL 严格审核的单位，每次DDL都是一次磨难，折磨的开发直接骂娘的企业，MongoDB就好像给开发开了一个后门，绝对不会痛苦。

变更表的KEY VALUE 是非常的方便，根本没有上线这么一说，上不上线程序上线了，数据架构就联动的着变化了。

这是非常吸引他们的一个点。

5 同时目前经济情况不好，希望对硬件使用更省，或者说，可以承载更多的数据，使用更少的CPU 内存的相对于RDBMS的情况，MONGODB在不进行聚合操作的场景下是完胜 一众数据库什么ORACLE ,PG ,MYSQL ,SQL SERVER来了都是白给。他们的劣势，就是MONGODB 的强势，这也是喊了那么多年的 这个能替代MOGNODB 那个能替代MONGODB 最终都是 纸上谈兵的结果，大数据量，高并发，查询方式复杂的情况下，目前没有可以替代的产品出现。

但是在介绍和沟通中我们也强调了几点

1 我们不希望在金融类数据存储中使用 MOGNODB ，这点我们非常的明确，不可以

2 对有强聚合需求的业务，不可以用MongoDB

3 业务波峰波谷特别明显的，我们不建议使用MongoDB

除此以外，针对数据库中时间的部分我们也明确了希望使用ISODate 而不是string类型的意义和需求说明，其中最主要的是如果有多个时区的业务存在一个collection 的情况下，通过string类型来存储时间是一个非常糟糕的设计。

最后还是架构师会总结，他觉得，在移动应用端，如高频的数据插入，数据查询，注册信息，操作系统日志，前段应用可快速扩展的应用，缓存类（REDIS 存储太贵）需要考虑成本的下的折中环境，都应该使用MongoDB。

其实我也在想，随着公司大量应用AI ，对长期记忆的向量语义检索中，可以使用尤其上下文特别大的情况下，可以单行存储更大的用户信息，避免传统数据的低效的存储和提取的问题。所以我也评估了后续我们在MongoDB上加大投入的性价比，目前看还是比较大的。