如果使用 mongo db 时没有嵌入文档，那么使用 mongodb 相对于 mysql 有什么优势吗？
我正在使用带有 mongodb 适配器的 php 框架，该适配器当前不将嵌入文档理解为模型/关联关系。在阅读了几天有关 mongodb 的内容后，您似乎应该对最常一起显示的对象使用嵌入文档。这对我来说很有意义。在一次 mongo 模式演讲中据说，许多小文档的集合可能会抵消 mongo 相对于 RDBMS 的一些优势。
在搜索 stackoverflow 及其他内容时，我似乎看不到将 mongodb 部署到使用合理规范化模式（就像在传统 RDBMS 中找到的那样）实现的环境时存在哪些优势（如果有的话）。
这样使用MongoDB还有优势吗？缩放？性能？
I'm using a php framework with a mongodb adapter that doesn't currently comprehend embedded documents as a Model/association relationship. After reading about mongodb for a few days it seems that you should use embedded documents for objects that are most often displayed together. This makes a lot of sense to me. It was said during one mongo schema talk that a collection of many small documents can negate some of the advantages of mongo over an RDBMS.
In searching stackoverflow and beyond, I can't seem to see what advantages exist, if any, when deploying mongodb into an environment where it is implemented with a reasonably normalized schema like you'd find in a traditional RDBMS.
Are there still advantages to using MongoDB when used in this way? Scaling? Performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果“合理规范化”意味着您需要一个表中的信息来过滤另一个表中的信息（即联接），那么 mongo 就会对您不利。在 SQL 数据库中，您可以通过单个查询轻松地从多个表中获取信息。在 mongo 中，您需要多个查询才能从多个集合中获取数据。 mongo 为您提供的从单个集合中提取数据的任何速度优势都将通过多次往返数据库而很快被抵消。
If by "reasonably normalized" you mean that you need information from one table to filter the information from another table (i.e. a join), then mongo is going to work against you. In a SQL database you can easily get the info from multiple tables with a single query. In mongo you'll need multiple queries to get data from multiple collections. Any speed advantage mongo gives you in pulling from a single collection will quickly be negated by making multiple round trips to the database.
以下是 MongoDb 可能为您提供的一些优势（取决于您的用例）：
MongoDB 网站有一个很好的 生产部署案例研究列表。
Here are some advantages that MongoDb might give you (depending on your usecase):
MongoDB website has a good list of casestudies of production deployments.
MongoDB 内置了复制和分片功能。
这些都是 MySQL 可以完成的事情。
缺点是学习曲线较高并且缺乏了解它的程序员。
如果它只适合你，那么作为一个学习项目会很有趣。
如果这是一个较大的项目，您需要权衡 MongoDB 程序员的缺乏和学习曲线与 MySQL 的受欢迎程度。
MongoDB has replication and sharding built in.
These are things that can be done with MySQL.
The downside is the learning curve and lack of programmers that know it.
If it's just for you, it would be fun as a learning project.
If this is for a larger project, you'll need to weigh the lack of MongoDB programmers and learning curve against popularity of MySQL.
我首先使用 MySQL 开发我的大学论文项目，然后考虑尝试使用 MongoDB 来提高性能。使用 Jongo 重写代码非常简单明了。制作过程非常顺利。
不幸的是表现很糟糕。我对 MongoDB 查询不是特别熟练，但我相信我做了相当多的研究：我使用过 Map Reduce，我使用过聚合框架，$limit 和所有这些东西......当在同一阶段我收到消息时：“请求堆使用超过物理RAM的10%”我真的放弃了，交付了MySQL版本。
对我来说，这确实是一种耻辱，因为我非常努力地工作，以使其能够以最好的方式与 MongoDB 一起工作（作为一个大学项目，如果你做一些不同的事情，就会脱颖而出）。不过我想我将来会继续研究 MongoDB，但目前我坚持性能（或者我能做到的更好的性能）。
我希望我的评论不会冒犯 MongoDB 粉丝，但这是我的经验。
I have been developing my University dissertation project with MySQL first then thought to give a shot to MongoDB to improve performance. Rewriting code was really easy and straightforward with Jongo. Production has been really smooth.
Unfortunately performance were terrible. I am not particularly skilled with MongoDB queries, but I believe I did quite a lot of research: I have used map reduce, I have used the aggregation framework, $limit and all that stuff... when at same stage I got the message: "request heap use exceeded 10% of physical RAM" I really gave up and delivered the MySQL version.
For me it's really a shame because I was working so hard to make it work the best way possible with MongoDB (as a University project stands out if you do something different). However I think I will continue study MongoDB in future, but for the moment I stick to performance (or better what I can make perform).
I hope my comment will not offend MongoDB fans, but this is my experience.