来自 mongoDB docs :
When would MySQL be a better fit?
A concrete example would be the booking engine behind a travel
reservation system, which also typically involves complex
transactions. While the core booking engine might run on MySQL, those
parts of the app that engage with users – serving up content,
integrating with social networks, managing sessions – would be better
placed in MongoDB
在这个(甚至一点点)具体示例中我不明白的两件事:
我的担忧不是理论上的，因为我们在我们的应用程序中同时使用 MYSQL 和 MongoDB，更好地理解上述内容确实有助于我们为 future 的功能设计我们的数据库模型。
MySQL 是 ACID 兼容的(假设您使用的是 INNODB 或类似的)，MogoDB 不是。在此处阅读有关原子性的 MongoDB 文档:
MongoDB Atomicity
想想去杂货店结账，POS 系统正在使用 MySQL。单笔交易中可能会发生哪些步骤？
- 扫描项目，检索价格
- 库存已更新，现有数量减 1
- 部门指标已更新(添加金额、数量、项目
类型等)
- 商品有特价吗？显示客户节省了多少钱
收据
- 客户使用了优惠券，确保我们通知供应商以便我们获得
报销
- 将收据总数发送给会计，更新月/年/周统计数据
现在是付款的时候了。糟糕!顾客把钱包落在家里，说他稍后会回来。我们已经对许多数据库表进行了所有这些更改，现在我们该怎么办？如果我们使用 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 是为流动的、动态的和(可能)有些未知的模式而构建的。它的速度部分取决于这样一个事实，即没有可能必须撤消的整体事务，部分取决于插入时没有不断验证的模式。
需要分析来 self 们 POS 系统的 100,000 个收据 JSON 文件？只需运行 mongoimport 并开始查询您想要的内容。
需要为少数库存项目添加一些特殊数据或将少数客户标记为“特殊处理”？ MongoDB 也适用于此。
需要导入和查询来自 20 个不同州的纳税申报单(想一想:不同的字段名称、不同的字段数量以及一些重叠)？毫无疑问，Mongo 在这里获胜。
任何具有几个已知的、具体的步骤的东西都必须工作，并且在适当的顺序中工作，然而(想想:ATM 机)，MySQL 更适合。