许多用户应用程序的mongodb数据库模式

Question

问题：应用程序中有成千上万的用户（但少于500K）。

解决方案：将每个用户的集合（10-20）存储在一个单独的用户名称空间中（每个客户端只有一个），以便通过从每个用户的id“列”转义来节省磁盘空间;加快命名空间小索引的查询时间;降低锁定率（https://jira.mongodb.org/browse/SERVER-1240）;简化分片（https://jira.mongodb.org/browse/SERVER-939）。

这可以吗？或者也许我应该使用一个带名称空间的通用集合？

感谢您的回答。

Answer 1

我想我理解你的问题，但如果我错了，请纠正我。您似乎希望将每个应用程序的用户存储在他们自己的集合中。这有几个优点和缺点，你必须根据复杂的DBA决定，如R / W比率，负载等来加权。

<强>优点

• 与您提到的一样，索引更新时间更短，因为它们只有一部分用户。
• 由于元素数量较少，对非索引字段（如果有）的查询会更快。
• 由于您只是锁定每个应用程序，因此全局写锁定不会发挥作用。

<强>缺点

• 由于索引是按集合作为范围的，因此您将拥有（应用程序数量）次数以保留在内存中的索引（如果您将其分页，则索引效果不佳）。
• 由于索引和集合占用了自己的名称空间，并且每个名称空间占用大约628个字节，因此您需要担心默认的16MB namespace limit。这将限制您可以拥有的应用程序数量。例如有2个索引，你只能限制在8,000个收藏中。
• 最后，由于您的用户将在不同的馆藏中，因此您无法跨应用程序进行查询。这可以被MapReduce破坏，但会增加更多的复杂性。

在一天结束时，您可以实现大部分这些好处，同时通过简单地对某些应用程序密钥进行分片来避免这些缺点。许多收集场景很诱人，但我认为最终不是针对mongo进行优化的。