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

【问题标题】：mongodb database schema for many-users-application多用户应用程序的 mongodb 数据库模式
【发布时间】：2011-12-26 08:18:49
【问题描述】：

问题：一个应用程序中有数万用户（但少于 50 万）。

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

这样好吗？或者我应该使用一个带有命名空间的通用集合？

感谢您的回答。

【问题讨论】：

所以你想知道你的

标签： mongodb collections namespaces schema

【解决方案1】：

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

优势

正如您所提到的，索引将花费更少的时间来更新，因为它们只有一部分用户。
由于元素数量较少，对非索引字段（如果有）的查询会更快。
全局写入锁不会发挥太大作用，因为您只锁定每个应用程序。

缺点

由于索引的范围是按集合划分的，因此您将拥有 (# of Applications) 倍的索引来保存在内存中（如果您将它们分页，索引几乎没有用处）。
由于索引和集合占用自己的命名空间，每个命名空间大约占用628字节，所以需要担心默认的16MB namespace limit。这将限制您可以拥有的应用程序数量。例如使用 2 个索引，您可以收集大约 8,000 个集合。
最后，由于您的用户将位于不同的集合中，您将无法跨应用程序进行查询。这可以被 MapReduce 颠覆，但增加了更多的复杂性。

归根结底，您可以通过简单地对某些应用程序密钥进行分片来获得这些好处，同时规避缺点。多集合场景很诱人，但我认为最终不是 mongo 的优化对象。

【讨论】：

是的，你没看错。那么，你怎么看。 mongo 针对什么进行了优化？这种情况我该怎么办？
如果您有能力设置几个分片（一个分片通常是由三台或更多机器组成的副本集），您应该按照我在最后一段中指出的那样做，而不是每个应用程序都有一个集合。对应用程序密钥进行分片将是理想的。如果您确信您可以仅使用一个副本集将所有用户和索引保留在内存中，并且不担心命名空间限制，那么我建议您按照问题中所述进行操作并将应用程序拆分为收藏。