MongoDB结构：单个集合vs多个较小的集合

Question

我有一个通用数据库结构问题。在我的场景中，我碰巧使用了mongodb。

我创建了一个应用程序，用户可以上传歌曲列表（标题，艺术家等），但不知道是否应该为所有用户提供一个songList集合，或者单独的songList.user＃collection每个用户。用户只能查询与其相关的歌曲，因此用户A将永远不会知道用户B的歌曲。

代码示例：每用户

db.songList.userA.find() 
{"title": "Some song of user A", "artist": "Some artist of user A"} 

db.songList.userB.find() 
{"title": "Some song of user B", "artist": "Some artist of user B"} 

• 优点
  • 小集合的大小

    多个集合查询

• 缺点
  • 可维护性
    • 1000个用户装置1000点的集合

VS与所属单个集合 '用户' 字段

db.songList.find({"user":"A"}) 
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"} 

• 优点
  • 灵活地在用户查询，如果需要不断arised
• 缺点
  • 性能

我试图建立一个亲/ con list，但仍然在围栏上。鉴于每个用户的歌曲将彼此隔离，哪种方法更好？我主要关心的是维护和查询性能。

在此先感谢。

Answer 1

MongoDB是在水平扩展很大。它可以在动态集群中对集合进行分片，以生成一个快速，可排队的数据集合。

所以拥有一个较小的集合大小并不是真正的专业人士，我不确定这个理论到了哪里，它不在SQL中，它不在MongoDB中。分片的性能如果做得好，应该与查询单个小数据集合的性能有关（开销很小）。如果它不是，那么你已经设置你的分片错误。

MongoDB在垂直伸缩方面并不是很好，正如@Sushant引用的那样，MongoDB的ns大小在这里将是一个严重的限制。引用没有提及的一点是，索引大小和计数也影响ns大小，因此它描述的原因如下：

因此，如果每个集合都有一个索引，我们可以创建多达12,000个集合。 --nssize参数允许你增加这个限制（见下文）。

Answer 2

我会推荐NOT为每个用户分别收集。

阅读documentation

默认情况下，MongoDB的具有每 数据库约24,000命名空间的限制。每个命名空间为628字节，默认情况下，.ns文件为16MB，默认为 。

与每个索引一样，每个集合都计为一个名称空间。因此，如果每个集合有一个索引，我们可以创建多达12,000个 集合。 --nssize参数允许你增加这个限制 （见下文）。

请注意，每个集合有一定的最小开销 - 一个 几KB。此外，任何索引都需要至少8KB的数据空间，因为 的b-tree页面大小为8KB。如果 是很多集合并且元数据被分页，则某些操作可能会变慢。

因此，如果您的用户超出命名空间限制，您将无法优雅地处理它。随着用户群的增长，它的性能也不会很高。

UPDATE

由于@Henry刘在评论中提到。对于使用WiredTiger存储引擎的Mongodb 3.0或更高版本，它将不再是限制。

docs.mongodb.org/manual/reference/limits/#namespaces