MongoDB听起来像是解决您的问题的一个很好的应用程序，但是有很多理由不使用它。
MongoDB不太适合需要以下功能的应用程序：
1.多对象事务：MongoDB只支持单个文档的ACID事务。

1. SQL：SQL是众所周知的，很多人知道如何编写非常复杂的查询来做很多事情。这些知识可以在MongoDB的查询语言特定的很多实现中转移。
   1.强酸保证：MongoDB允许不一致的读取，这在一些应用程序中是好的，但不是在所有应用程序中。
   1.传统BI：存在许多非常强大的工具，它们允许OLAP和其他强大的BI应用程序以及针对传统SQL数据库运行的应用程序。

MongoDB是一个很棒的数据库，我很喜欢使用它。也就是说，如果你来自SQL世界，它会有一些小问题。
除了ACID和其他有据可查的东西（其他答案也是如此），以下这些东西让我们大吃一惊：

• MongoDB希望你有内存。大量的内存。如果你不能在内存中容纳你的工作集，你可以忘记它。这与大多数关系数据库不同，它们只使用内存作为缓存！**更具体地说：**MongoDB使用RAM作为主存储，并将不需要的部分“交换”到磁盘（Mongo将哪些部分被“交换”的决定权留给内核）。传统的RDBMS的工作方式正好相反-它们使用磁盘作为主存储，使用RAM作为缓存机制。因此，一般来说，MongoDB使用更多的RAM。这本身并不是一件坏事，但作为一个后果，“真实的的” RAM消耗很难预测，一旦工作集增长超过（难以预测）限制，这可能会导致严重和意想不到的性能下降。
• 删除记录时存储不会自动收缩。为每个集合分配的空间将保持已分配状态，直到您repair DB或删除该集合为止。并且它在DB级别上以大块的形式分配（* 数据文件 *），然后在需要时将其分配给集合（extents）。也就是说，在集合的分配空间内，被移除的文档确实会为同一集合中的其他文档释放空间。http://www.10gen.com/presentations/storage-engine-internals
• 与服务器端解析的SQL相反，在Mongo中，您将数据结构传递给查询和CRUD函数。结果是每个驱动程序提供不同的语法，这有点烦人。例如，PyMongo使用元组列表而不是字典（可能是因为Python中的dict不保留键的顺序）来指定find()将返回哪些字段：（公平地说，这可能是唯一明智的方法--但这是不使用基于字符串的语言（如SQL）的结果）
• MongoDB shell ：db.test.find({}, {a:1})
• 皮蒙戈：db.find({}, fields=[(a,1,)]

这不应该被看作是对MongoDB的批评--我喜欢使用它，它已经被证明是一个可靠和高性能的工具。但是要正确地使用它，你需要了解它的空间管理。

可能的缺点：
1.您在一个只使用SQL关系数据库的组织中工作。您尚未批准或支持使用NoSQL数据库。
1.您从未管理过MongoDB集群;就像所有的技术一样，都有一个学习曲线。
1.您的数据确实是相关的（例如，一个用户有许多问题;一个问题有许多答案），而您忽略了这种可能性。
MondoDB是一个很好的解决方案，对于那些它适用的情况是一个很好的替代方案。如果你能使用它，为什么不呢？

补充其他评论意见;选择数据存储区（SQL还是NoSQL）在很大程度上取决于您的复制要求。
MongoDB遵循MySQL风格的master-slave-slave-*（一个主机，多个从机）配置。你只能写主机。
在地理位置分散的系统中，这是不可接受的（您需要能够写入任何主服务器并协调服务器）。
在这种情况下，像Cassandra、Riak、CouchDB这样的服务器在这种情况下会更好。
话虽如此，如果MySQL非常适合您的应用程序，并且您希望使用NoSQL，Mongo是完美的解决方案。

@johndodo关于内存使用情况。他们在官方FAQ页面上说：
MongoDB是否需要大量RAM？
不一定。在一台只有少量空闲内存的机器上运行MongoDB当然是可能的。MongoDB会自动使用机器上所有的空闲内存作为它的缓存。系统资源监视器显示MongoDB使用了大量内存，但它的使用是动态的。如果另一个进程突然需要服务器一半的内存，MongoDB会把缓存内存让给另一个进程。
从技术上讲，操作系统的虚拟内存子系统管理MongoDB的内存。这意味着MongoDB将使用尽可能多的空闲内存，并根据需要交换到磁盘。如果部署中有足够的内存来容纳应用程序在RAM中的工作数据集，将获得最佳性能。
所以我认为，学习曲线就是答案。你对技术了解得越多-你的系统就会越好。

我找不到理由不把所有的数据，从用户信息到问答都放在MongoDB中，除了一个实际的原因：
在共享主机环境中，要找到一家提供MongoDB主机的服务提供商并不容易。与mySql不同，MongoDB已成为主机计划的标准。

我已经在几个基于SQL DB的系统上工作过，在使用mongodb（带有Rails mongoid驱动程序）3年多之后，我有三个主要原因。

• 我不需要连接表格，所以这样更快。大多数时候，一个文档包含了我需要的所有内容，如果没有，我会获取相关的文档-同样非常快。
• 我提取文档一次，然后Map数组/json来收集数据并进行操作。因此，我访问DB的次数更少，而且因为Map/收集发生在内存中，所以速度快得多。当我使用嵌入式文档时，这变得更加有效。
• 我可以让客户端轻松有效地定义他们自己的字段。对于SQL DB来说，这不值得尝试。

在为我的项目决定数据库时，我听说mongoDB是免费的，然后我想为什么不mongoDB呢？
嗯，为了更确定一点，我打电话给MongoDB客户支持团队。目前有三个不同版本的MongoDB。
1.社区服务器
1.专业人员
1.企业
实际上社区服务器是免费的和其他2个是付费软件。
我问过那个人-

• • 在哪里可以使用mongodb的社区服务器？**
• • 下面是我通过电子邮件收到的回复-**
• • Community Server的**建议用于开发环境。对于生产用途，需要企业产品。

请在使用该版本之前确认。
希望这对你有帮助：）

没有理由不使用MongoDB作为您的用例，我甚至会建议将您的用户信息存储在MongoDB中，使其成为一个无缝的体验。
关于问答集，我唯一要提的建议是：如果一个问题在理论上可以有无限数量的回答，那么将问题的所有答案嵌入在同一文档中（例如，在称为“答案”的数组中）可能导致称为无界数组的反模式，或者通常导致文档大小超过16 MB，这是MongoDB中对文档大小的限制，一般也不建议使用这么大的文档，因为这会导致性能下降。
我建议使用Subset Pattern或Extended Reference Pattern为问答集合建模。
使用Subset Pattern：在这种情况下，您可以将最近的答案、投票最多的答案或查询最常访问的答案保留在Q&A集合中，并将其余答案卸载到另一个名为“Answers”的集合中。在这种情况下，如果您希望检索与某个问题关联的所有答案，则必须使用$lookup运算符（相当于SQL中的左外连接），这将比检索主集合（即本例中的Q&A集合）中嵌入的文档性能差，但这里的想法是“Answers”集合很少或不太频繁地被访问。
如果您的用例相对较小，并且仅处于开发模式，我建议您在MongoDB Atlas上使用M0集群层，它是终身免费的，并且消除了部署和维护数据库集群的管理开销。（但是，M0层不适合用于生产，并且存在需要注意的limitations）