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

Question

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

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

Answer 1

일부 프로젝트에 조인 문제가 발생했습니다. 내 솔루션은 해당 ObjectId를 저장하고 mongodb의 집계를 통해 조인 목적을 달성하는 것입니다. WiredTiger 엔진을 사용하여 많은 양의 읽기 및 쓰기 중에 데이터베이스가 잠기는 문제를 해결했습니다. 또한 데이터베이스를 디자인할 때 전통적인 SQL 디자인 사고와 개발 논리를 피하십시오. 컬렉션은 하나의 이벤트에 대응해야 합니다. 이후 프로젝트 확장으로 인해 작업자 개발 모델을 도입하고 논리 계층 간의 관계를 독립적인 스레드가 있는 작업자로 변경했으며 현재는 온라인 연결 없이 많은 수의 동시성을 처리하는 데 좋은 효과가 있습니다. 온라인에 있는 사람 없이 빨간 봉투를 잡는 효과와 유사합니다. 단지 참고용으로 조금 겸손한 의견입니다.

또한 mongodb의 한계는 SQL 개발 모델에 익숙한 사람들에게는 매우 불편할 것입니다. 하지만 빅데이터 시대에 mongodb의 장점은 분명합니다. 현재 내 프로젝트의 기본 구조는 다음과 같습니다.
서버: nginx+mongodb+php-fpm+ubuntu
주 프로그램: MVC(php) // 값은 논리적 관계 교환을 제공합니다
보조 프로그램: 작업자 // 데이터베이스 상호 작용을 위한 논리적 관계에 해당하는 멀티 스레드 처리

Answer 2

기술을 선택할 때 고려하지 않으셨나요? mongo만 사용할 필요가 없으며 여러 라이브러리가 공존할 수 있습니다

Answer 3

여러분 사실 제 질문은 몽고가 불량인지 교체해야 하는지가 아닙니다. 오히려 데이터베이스가 전환되지 않는다고 가정하면 위의 문제에 대한 해결책이 있을까요? 업계에는 이러한 문제를 직면하고 해결한 다른 사람들도 있을 것이라고 확신합니다.

Answer 4

Mongodb는 이런 유형의 프로젝트에는 적합하지 않으며, 관계가 강한 프로젝트의 경우 여전히 관계형 데이터베이스를 사용합니다.