MongoDB 是否不是解决这个多对多问题的错误工具？
我目前正在设计一个具有以下实体的商店系统：
- 帐户（数百万）、用户名、电子邮件、密码...
- 产品（数百万）、标题、描述、评级...
帐户可以获得产品的许可证（许多-对多）。我将有一个页面，其中显示给定帐户许可的所有产品。
当前概念：产品具有一系列许可帐户，因此我可以使用 find(licensed_accounts: ObjectId("4d731fe3cedc351fa7000002"))。
我期待着很多账户。对于流行产品，该数组可能包含数百万个 ObjectId (12byte * 1,000,000 = 12MB)。 100 万份文件就已经接近目前的 16MB 大小限制。
有更好的方法来处理这个问题吗？或者 MongoDB 是处理这么多关系的错误工具吗？
I'm currently designing a shop system with these entities:
- Account (Millions), username, email, password...
- Product (Millions), title, description, rating...
An account can acquire a license for a product (many-to-many). I will have a page where I display all the Products licensed by a given account.
Current concept: Product has an array of licensed Accounts, so that I can use find(licensed_accounts: ObjectId("4d731fe3cedc351fa7000002")).
I am expecting a lot of accounts. For popular products, that array might contain millions of ObjectIds (12byte * 1,000,000 = 12MB). One million will bring the document close to its current 16MB size-limit already.
Is there a better approach to handle this? Or is MongoDB the wrong tool for that many relations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
看这张幻灯片：http://www.10gen.com/presentation/mongosf2011/schemabasics。有一个多对多样本，有多个替代方案。
在您的情况下，您应该将产品 ID 存储在帐户文档中：
一种产品可以有很多帐户，但一个帐户只能有几个产品？不是吗？
要显示帐户的所有产品：
Look at this slide : http://www.10gen.com/presentation/mongosf2011/schemabasics. There is a many-many sample with several alternatives.
In your case, you should store your products IDs in the account document:
One product can have a lot of accounts, but one account should only have a few products? Isn't it?
To display all the products for an account:
“连接表”类型的概念怎么样？您拥有产品、帐户和许可证。许可证具有产品 ID 和帐户 ID。这样您就不必支付大量文档的费用，并且仍然可以完成您想要做的事情。
Mongo 与其他东西有权衡，其中之一是文档数据库中的多对多确实很糟糕（一对多的权衡几乎是免费的）如果这是出于报告目的，我会研究每晚（或每周）或其他）map-reduce 查询将数据转换为使您的工作（和 mongos）更轻松的东西。 MapReduce 非常灵活，您可以告诉它将结果作为集合保存，它在集群中也可以很好地扩展，但单节点性能方面它非常慢（这就是为什么我将其作为每晚的事情）
how about a "join table" type concept? You have Products, Accounts, and Licenses. A license has a product id and an account id. That way you wont pay the cost of massive documents, and can still accomplish what you are trying to do.
Mongo vs other stuff has tradeoffs, one of those things is that many to many really sucks in a document database (the tradeoff is one to many is pretty much free) If this is for reporting purposes, I would look into a nightly (or weekly or whatever) map-reduce query to get the data into something that makes your job (and mongos) easier. Map reduce is incredibly flexible, and you can tell it to persist the results as a collection, it also scales well in a cluster, but single node performance wise it is very slow (which is why I would do it as a nightly thing)
首先您应该阅读： 何时使用 MongoDB 或其他文档面向数据库系统？
MongoDB 和 nosql 的主要功能是 分片。在这种情况下，不清楚什么值最适合用作分片键。
无论如何，您可以使用 nosql 或关系数据库来解决这个问题。我认为使用联接可以很好地关联帐户和产品。所以我会使用 SQL，因为它会减少所需的查询数量。
一种根本上是 nosql 的方法是只拥有您需要的文档类型的一个集合。但是，如果您需要更新产品，则必须进行大量更改，这更多地证明这更多是一个关系问题。
First you should read: When to use MongoDB or other document oriented database systems?
A major power of MongoDB and nosql is the idea of sharding. In this case it is not clear what value(s) would be best to use as a shard key.
In any case, you could solve this problem with nosql, or with a relational database. I think that the use of a join works well to correlate accounts and products. So I would use SQL because it would reduce the number of queries required.
One approach that would be radically nosql would be to only have one collection of the document type that you need. However if you need to update a product you'd have to make a large number of changes, which is more evidence that this is more of a relational problem.