mean - Mongodb能够支持复杂项目的数据库吗？

Question

本人最近做一个O2O平台项目（含管理、预约、支付、接入微信等），当初出于人员能力、成本等考虑，选择了标准的MEAN作为技术选型。做起来确实很快，但随着项目需求的迭代，我感觉该技术选型特别是mongodb存在非常多的局限，主要如下：
1、mongodb不支持join的操作，只能简单通过populate扩展，因此，但凡有跨表的查询、统计都非常麻烦；我们现在很多是通过数据的冗余来做的，就是干脆数据字段在几个集合里都存。
2、mongodb不支持事务，因此很多回滚的操作我们现在是在业务的同步框架里处理，代码显得非常冗余，且本质上仍然不是真正意义上的回滚；

我听说业内现在有越来越多的纯MEAN的大项目，我不知道大家是怎么解决上述问题的？还是说核心业务逻辑仍然用的是关系型数据库。

Answer 1

我的项目有些遇到过join的问题。我的解决办法就是存储对应的ObjectId们,通过mongodb的aggregation来达到join的目的。我是用了WiredTiger引擎,所以解决了在大量读写的时候锁死数据库的问题。还有在设计数据库上面尽量避免传统的sql设计思维跟开发逻辑。一个collection尽量对应一个事件。后来因为项目的扩大，我引入了worker的开发模式，将逻辑层的关系改成独立的线程的worker，目前来说应对大量无上线并发效果不错(类似于无上线人数抢红包的效果）。一点儿拙见仅供参考。

还有就是对已习惯sql开发模式的人mongodb的局限性会让人很不习惯。但是在大数据时代mongodb的优势是显而易见。目前来说我的项目基本结构是:
服务器： nginx+mongodb+php-fpm+ubuntu
主程序： MVC(php) // 值提供逻辑关系交换
辅程序： Workers // 多线程处理对应的逻辑关系做数据库互交

Answer 2

技术选型时没考虑到？没必要只用mongo，可以多库并存

Answer 3

各位，其实我的问题不在于Mongo有没有缺陷，或者该不该换。而是，在假设不切换数据库的情况下，有没有什么方案可以解决上述问题。我相信业内一定有其他人遇到并且解决了这些问题。

Answer 4

mongodb不适合这种项目，他适合查询类的，而且是简单的，关系强的项目还是用关系数据库