用于多用户应用程序的 mongodb 数据库架构

Question

问题:一个应用程序中有数以万计的用户(但少于 50 万)。

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

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

感谢您的回答。

Answer 1

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

优势

就像你提到的，索引更新时间会更短，因为它们只有一部分用户。

由于元素数量较少，对非索引字段(如果有)的查询会更快。

全局写锁不会发挥太大作用，因为您只锁定每个应用程序。

缺点

由于索引是由集合限定的，因此您将有 (# of Applications) 倍的索引保留在内存中(如果您将它们分页，则索引没有用处)。

因为索引和集合占用自己的命名空间，每个命名空间占用大约628个字节，所以你需要担心默认的16MB namespace limit .这将限制您可以拥有的应用程序数量。例如使用 2 个索引，您被限制为大约 8,000 个集合。

最后，由于您的用户将位于不同的集合中，您将无法跨应用程序进行查询。这可以被 MapReduce 颠覆，但会增加更多的复杂性。

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