是 MongoDB + Socket.io 比 MySQL 更好 + Socket.io 是一个实时应用程序吗？
我正在构建一个实时应用程序和我想知道我是否应该从 MySQL 迁移到 MongoDB。我的应用程序发生了大量写入，但读取情况仍然更高。我目前在客户端-服务器端使用 XHR，但也快要迁移到 Socket.io 了。
我的研究确实让我想转向 MongoDB + Socket.io，但想从社区获得一些想法。
更新我目前正在通过更快的应用来定义“更好”，如果这有意义的话。我“认为”没有sql我也能生活。目前使用 0 JOIN 等。但我想看看是否有人有从 MySQL 迁移到 MongoDB 以获得“通用”实时应用程序的经验。
谢谢。
I am building a real-time app & am wondering if I should bother moving from MySQL to MongoDB. My app has a ton of writes happening, though the read cases are higher still. Am currently using XHR on the client-server side but am almost done moving to Socket.io too.
My research does make me want to move to MongoDB + Socket.io, but wanted to get some thoughts from the community.
update I am currently defining 'better' by a faster app, if that makes any sense. I am sort of able to live without sql, I 'think'. Currently using 0 JOINs etc. But I was trying to see if anybody out there had any experience moving from MySQL to MongoDB for a 'generic' real-time app.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于你如何定义“更好”。
如果关系模型和集合对您来说更重要，那么 MySQL 比 MongoDB “更好”。
如果您可以放弃 ACID，并且您的数据更多地基于文档，那么 MongoDB 比MySQL。
无论如何，这都很难回答，尤其是在不了解更多有关您的用例的情况下。
It depends on how you define "better".
If the relational model and sets are more important to you, MySQL is "better" than MongoDB.
If you can give up ACID, and your data is more document based, MongoDB is "better" than MySQL.
It's difficult to answer in any case, but especially so without knowing more about your use cases.
也许添加这个有点晚了，但我在实时分析应用程序从 mySQL 迁移到 mongodb 方面有一些经验。根据我的经验，mySQL 速度更快且响应更快，因为我的应用程序写入量很大。通过使用 innodb，我能够获得行级锁，而当我使用 mongodb 时，我必须处理全局锁。不确定他们是否已经解决了“全局”锁定问题。
我的最终解决方案是使用 innodb 和 Percona 版本的 mySQL。
Maybe late to add this, but I've had some experience with a real time analytics application moving from mySQL to mongodb. In my experience mySQL was much faster and responsive because my app was so WRITE HEAVY. By using innodb I was able to get row level locks, whereas when I was using mongodb I had to deal with a global lock. Not sure if they've since resolved the "global" lock thing.
My final solution was to use innodb and the Percona release of mySQL.
MongoDB 不是关系数据库管理系统。在没有先指定数据的情况下就说 MongoDB 比任何 RDBMS 都好，这表明确实缺乏知识。
MongoDB 中不存在键约束。没有引用完整性检查。我们使用 MongoDB 进行 blob 存储，并将 MongoDB 键存储在 SQL Server 中。这很好，但我永远不会用 MongoDB 彻底替换规范化的 SQL Server 或 MySQL RDBMS 实例。
也许很多人认为 MongoDB 更好，因为他们不想担心优化索引和执行计划……但这是以数据完整性为代价的。这是一种无模式结构，这意味着不存在一致性。它会吃你喂它的任何东西，这可能是危险的。
考虑一下当您从 JSON 添加/删除属性或根据不断变化的业务规则添加/删除参考数据时，随着时间的推移会发生什么。想一想与 RDBMS 实例相比，MongoDB 中的转换会是什么样子。
我知道我听起来对 MongoDB 很挑剔，但我不是故意的。我们使用它并且它可以很好地满足我们的需求，但它并不能替代 RDBMS。更多的是一种补充。
MongoDB isn't a relational database management system. Saying MongoDB is better than any RDBMS without first specifying the data shows a real lack of knowledge.
Key constraints don't exists in MongoDB. There are no referential integrity checks. We use MongoDB for blob storage and store the MongoDB keys in SQL Server. It's great for that but I would never outright replace a normalized SQL Server or a MySQL RDBMS instance with MongoDB.
Maybe a lot of people see MongoDB as being better because they don't want to worry about optimizing indexes and execution plans...but that comes at a cost of data integrity. It's a schemaless structure which means consistency doesn't exist. It will eat anything you feed it which can be dangerous.
Think about what happens over time as you add/remove properties from your JSON or add/remove reference data based on changing business rules. Think about what that conversion would look like in MongoDB compared to a RDBMS instance.
I know I sound pretty critical of MongoDB but I don't mean to. We use it and it works well for our needs but it's not a replacement for RDBMS. More of a supplement.