来自mongoDB docs：
MySQL什么时候更适合？
一个具体的例子是旅行背后的预订引擎 预订系统，通常也涉及复杂 交易。虽然核心预订引擎可能在MySQL上运行，但那些 与用户互动的应用程序部分 - 提供内容， 与社交网络整合，管理会话 - 会更好 放在MongoDB中
我不明白这个（甚至不是一点点）具体例子中的两件事：
哪种查询足够复杂，更适合MYSQL （这种查询的具体例子有很大的帮助）？
从哪个行分隔“核心预订引擎” “与用户互动的应用的部分”？
我的关注不是理论上的，因为我们在我们的应用程序中同时使用MYSQL和MongoDB，更好地理解上述内容将真正帮助我们设计用于未来功能的数据库模型。
答案 0 :(得分：9)
MySQL符合ACID（假设您正在使用INNODB或类似产品），MogoDB不是。在这里阅读有关原子性的MongoDB文档：
考虑去杂货店结账，POS系统正在使用MySQL。单个交易可能会采取哪些步骤？
现在是付款的时候了。 OOPS！顾客把钱包留在家里，并说他会晚点回来。我们已经对许多数据库表进行了所有这些更改，现在我们该怎么办？如果我们使用MySQL并在单个事务中拥有所有这些更新，我们可以回滚一个事务并且不会造成任何损害。所有更改都将以正确的顺序自动恢复。
在非事务性数据库中执行此操作意味着编写代码以按正确的顺序回溯所有这些更改。
MongoDB适用于文档存储和检索。这不是我一次创建一小块文档的首选，您希望在单独的地方存储一些信息。
我们如何在杂货店示例中使用MongoDB？我们可以将它用作库存系统的一部分。
我们的MySQL库存可能有我们绝对必须拥有的模式 - SKU，价格，部门。但是，我们不一定要通过添加诸如'Easter_2016_Promotion'之类的列来混淆我们通常不需要知道的事情。在MongoDB中，由于我们没有一个一成不变的架构，这不是问题。
像
这样的东西db.inventory.update(
{ _id: 1 },
{ $set: { "Easter_2016": "y" } }
)
可以将“Easter_2016”字段添加到单个广告资源项目中，而不会影响其他任何广告资源。在MySQL中，通过添加单个列来影响表中的每一行 - 在MongoDB中不是这样。此外，在查询Mongo时，您可以在所有记录（文档）中搜索可能或可能不存在的字段。在MySQL中，字段存在或不存在。
MongoDB是针对流畅，动态且（可能）有些未知的模式而构建的。它的速度部分依赖于这样一个事实，即它可能不必撤消整体事务，并且部分地说在插入时没有一个模式可以不断地进行验证。
需要从我们的POS系统分析100,000个收据JSON文件吗？只需运行mongoimport并开始查询您想要的内容。
需要为少数库存商品添加一些特殊数据，还是将少数客户标记为“特殊处理”？ MongoDB也是如此。
需要从20个不同的州导入和查询纳税申报表（想想：不同的字段名称，不同的字段数，有几个重叠）？ Mongo在这里赢得胜利。
任何有一些已知的，具体步骤必须工作的东西，并且在适当的情况下工作（然而（想想：ATM机））和MySQL是更合适的。
答案 1 :(得分：1)
具有多个联接的查询将是一个很好的示例。这一点背后的主要思想是关系DB m:n关系是对称的，而在面向文档的DB中，它们不是。从v3.2开始，MongDB有$lookup在某种程度上解决了这个问题。
核心预订引擎和表示引擎之间的行由CAP theorem绘制。核心部分必须是一致的，而面向客户的部分可以实现最终的一致性。 MongoDB中的recommended workaround for lack of atomic transactions应该为这个陈述提供一些启示。或者，您的核心预订部分可以使用event sourcing来保持状态一致而无需交易。