MongoDB 对于社交网站（用 Ruby on Rails 开发）来说是一个好主意吗？
我的项目（在 Ruby on Rails 3 中）是开发一个“社交网络”站点，具有以下功能：
- 用户可以成为朋友。这是相互的友谊；不像 Twitter 那样不对称。
- 用户可以发布链接来共享它们。用户的好友可以看到该用户分享的内容。
- 朋友可以对这些共享链接发表评论。
所以基本上我们有用户、链接和评论，以及所有相关的东西。社交网络中一个有趣的事情是用户表与其自身具有多对多的关系。
我认为我可以使用 SQL 和 RoR 处理这种级别的复杂性。
我的问题是：对于这样的网站使用 MongoDB（或 CouchDB）是个好主意吗？
老实说，我认为答案是否定的。 MongoDB 似乎不太适合多对多关系。我想不出一个好的 MongoDB 方法来实现友谊关系。我读到 Diaspora 最初使用 MongoDB，但后来又转回经典 SQL。
但网络上的一些文章为社交网络捍卫 MongoDB，最重要的是，我想做出明智的决定，并且不要错过 MongoDB 的一个非常酷的方面，它将改变我的生活。
另外，我听说过图数据库，它可能很棒，但它们对我来说确实太年轻了，而且我不知道它们如何与 RoR 相适应（更不用说 Heroku 了）。
那么，我错过了什么吗？
My project (in Ruby on Rails 3) is to develop a "social network" site with the following features:
- Users can be friends. It's mutual friendships; not asymetric like Twitter.
- Users can publish links, to share them. Friends of a user can see what this user has shared.
- Friends can comment on those shared links.
So basically we have Users, Links, and Comments, and all that is connected. An interesting thing in social networks is that the User table has kind of a many-to-many relation with itself.
I think I can handle that level of complexity with SQL and RoR.
My question is: would it be a good idea to use MongoDB (or CouchDB) for such a site?
To be honest, I think the answer is no. MongoDB doesn't seem to fit really well with many-to-many relationships. I can't think of a good MongoDB way to implement the friendship relationships. And I've read that Diaspora started with MongoDB but then switched back to classic SQL.
But some articles on the web defend MongoDB for social networks, and above all I want to make a well-informed decision, and not miss a really cool aspect of MongoDB that would change my life.
Also, I've heard about graph DB, which are probably great, but they really seem too young to me, and I don't know how they'd fit with RoR (and not mentioning heroku).
So, am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我的建议是使用您最熟悉的任何工具，以便您可以快速启动并运行。从你的问题来看，这听起来像是 SQL 而不是 MongoDB。
My advice would be to use whatever you're most familiar with so that you can get up and running quickly. From your question it sounds like that would be SQL rather than MongoDB.
我喜欢 MongoDB 并且经常使用它，但我认为如果你正在处理关系数据，你应该使用正确的工具。我们为此拥有关系数据库。 Mongo 和 Couch 是文档存储。
如果您要维护大量文档间链接，Mongo 就有一个严重的缺点。仅保证一个文档的写入是原子的。因此，如果您不小心处理架构，关系的更新可能会不一致。
MongoDB 的好处在于它非常擅长扩展。您可以分片并创建副本集。 Foursquare 目前使用 MongoDB，并且它对他们来说运行得很好。 MongoDB 还可以进行映射缩减，并且具有良好的地理空间集成。开发 MongoDB 的团队非常优秀，我住在他们所在的纽约并且见过他们。尽管我认为一开始你可能不会遇到扩展问题。
至于散居国外的人切换......我不想跟随他们正在做的任何事情:)
不过你对图数据库的评论很有趣。我可能也不会使用图形数据库作为我的主数据库，但是在处理关系时，您可以用它们做一些令人惊奇的事情。事实上，图数据库公司的人员通常会给您提供的演示是从社交网络中提取关系知识。但是，没有什么可以阻止您将来使用这些进行网络分析。
总之，当您刚开始时，您还没有遇到大规模的问题，并且时间和金钱可能有限。请记住，即使 Facebook 也不只使用一种技术，他们基本上已经扩展到 NoSQL 来实现某些功能（例如 Facebook 消息传递）。未来没有什么可以阻止您使用 Mongo 和 gridFS 来处理图像上传或地理位置等。随着您的需求变化而成长是件好事。我认为您认为这里有一个 SQL 应用程序的直觉是正确的，并且使用 MongoDB 获得的好处暂时不会实现。
I like MongoDB and use it a lot, but I am of the opinion that if you are dealing with relational data, you should use the right tool for it. We have relational databases for that. Mongo and Couch are document stores.
Mongo has a serious disadvantage if you are going to be maintaining a lot of inter-document links. Writes are only guaranteed to be atomic for one document. So you could have inconsistent updates for relations if you are not careful with your schema.
The good thing about MongoDB is that it is very good at scaling. You can shard and create replica sets. Foursquare currently uses MongoDB and it has been working pretty well for them. MongoDB also does map-reduce and has decent geospatial integration. The team that develops MongoDB is excellent, and I live in NY where they are based and have met them. You probably are not going to have scaling issues though I would think starting out.
As far as Diaspora switching... I would not want to follow anything they are doing :)
Your comment about graph dbs is interesting though. I would probably not use a graph DB as my primary DB either, but when dealing with relationships, you can do amazing things with them. In fact usually the demo the guys from graph DB companies will give you is extracting relationship knowledge from a social network. However, there is nothing preventing you from playing with these in the future for network analysis.
In conclusion, when you are starting out here, you are not running into the problems of massive scale yet, and are probably limited on time and money. Keep in mind that even Facebook does not use just one technology, they have basically expanded to NoSQL for certain functionality (like Facebook messaging). There is nothing stopping you in the future from using say Mongo and gridFS for handling image uploads or geo-location etc. It is good to grow as your needs change. I think your gut feeling that you have an SQL app here is right, and the benefits gained with MongoDB would not be realized for a while.
一个有趣的可能性是 Riak。它是键值存储和图形数据库之间的交叉。用户 ID 可以是您的密钥，评论和链接可以存储在您的值中。但 Riak 还具有键对键链接。这可用于将您的用户连接为朋友。链接是不对称的，因此您需要在两个方向上处理添加和删除，但这应该不会太难。
但请注意，Riak 不是文档数据存储，这意味着它与值无关，这意味着它不会帮助您提取值的内部部分，这意味着如果您想提取注释，您需要首先检索用户存储的每条评论和链接。
您可能还想查看其他图形数据库。社交图是图数据库的典型用例。
An interesting possibility for this is Riak. It is a cross between a key-value store and a graph database. The userID could be your key and comments and links could be stored in your value. But Riak also has key-to-key linking. This could be used for connecting up your users as friends. The linking is asymmetric so you would need to deal with adding and deleting in both directions, but that shouldn't be too hard.
But note that Riak is not a document datastore, which means it is value-agnostic, which means it won't help you extract internal parts of your value, which means if you want to pull a comment out you'll need to first retrieve every comment and link that's stored with the user.
You may also want to check out other graph databases. Social graphs are the prototypical use-case for a graph database.
抱歉，但你必须开始学习图表。使用以 JSON 格式输出数据的图形数据库将其写入您的 Mongodb 数据库。您正在处理一个网络，这意味着必须有某种类型的图，它允许您创建一个自我（例如用户）或焦点或逻辑中心，它连接到其他它周围的节点。节点可以是特定用户的属性，例如姓名、喜欢、朋友、图片等。如果要绘制自我图，它会类似于中心和辐条。
如需进一步阅读，您可以参考 Facebook 如何实现其 Graph API - https://developers .facebook.com/docs/graph-api/overview/
这是连接 Mongodb 和 Neo4j 图形数据库的尝试 - https://neo4j.com/developer/mongodb/
Sorry, but you got to start learning about graphs. Use graph databases that spits out data in JSON format & write it to your Mongodb database.You are dealing with a network , which means there must be a graph of some sort that will allow you to create an ego(user, for example) or focal point or logical center, which is connected to other nodes around it.Nodes could be properties of a particular user such as name, likes,friends, pictures etc. An ego graph would resemble a hub and spokes if you were to draw it.
For further reading, you can refer to how Facebook implemented it's Graph API - https://developers.facebook.com/docs/graph-api/overview/
Here is an attempt to connect Mongodb and Neo4j graph database - https://neo4j.com/developer/mongodb/