本人最近做一个O2O平台项目（含管理、预约、支付、接入微信等），当初出于人员能力、成本等考虑，选择了标准的MEAN作为技术选型。做起来确实很快，但随着项目需求的迭代，我感觉该技术选型特别是mongodb存在非常多的局限，主要如下：
1、mongodb不支持join的操作，只能简单通过populate扩展，因此，但凡有跨表的查询、统计都非常麻烦；我们现在很多是通过数据的冗余来做的，就是干脆数据字段在几个集合里都存。
2、mongodb不支持事务，因此很多回滚的操作我们现在是在业务的同步框架里处理，代码显得非常冗余，且本质上仍然不是真正意义上的回滚；
我听说业内现在有越来越多的纯MEAN的大项目，我不知道大家是怎么解决上述问题的？还是说核心业务逻辑仍然用的是关系型数据库。
我想大声告诉你2017-05-02 09:19:43
私のプロジェクトの一部で結合の問題が発生しました。私の解決策は、対応する ObjectId を保存し、mongodb の集計を使用して結合の目的を達成することです。 WiredTiger エンジンを使用したため、大量の読み取りと書き込み中にデータベースがロックされる問題を解決しました。また、データベースを設計するときは、従来の SQL 設計思考と開発ロジックを避けるようにしてください。コレクションは 1 つのイベントに対応するように努める必要があります。その後、プロジェクトの拡張に伴い、ワーカー開発モデルを導入し、論理層間の関係を独立したスレッドを持つワーカーに変更しました。現在、オンライン接続なしで大量の同時実行に対処するのに効果があります。オンラインに誰もいない状態で赤い封筒を掴んだ場合の効果に似ています)。あくまで参考程度に、ちょっとした個人的な意見です。
また、SQL 開発モデルに慣れている人にとって、mongodb の制限は非常に不快なものとなるでしょう。しかし、ビッグデータの時代では、mongodb の利点は明らかです。現在、私のプロジェクトの基本構造は次のとおりです:
サーバー: nginx+mongodb+php-fpm+ubuntu
メインプログラム: MVC(php) // 値は論理関係の交換を提供します
補助プログラム: Workers // 対応するロジックマルチスレッド処理へのリレーショナルデータベースインタラクション
漂亮男人2017-05-02 09:19:43
皆さん、実際に私の質問は、Mongo に欠陥があるかどうか、または交換する必要があるかどうかではありません。むしろ、データベースが切り替わらないと仮定して、上記の問題を解決する方法はありますか?業界には、これらの問題に遭遇して解決した人が他にもいると思います。
仅有的幸福2017-05-02 09:19:43
mongodb はこの種のプロジェクトには適していません。クエリ タイプに適していますが、強い関係を持つプロジェクトの場合は、リレーショナル データベースを使用することをお勧めします
