将数据建模为单个集合或单独的集合是否更好？

Question

作为一个例子，想象一下一个简单的“帮助台”类型的应用程序，其中有支持票据，该应用程序支持多个公司登录和管理他们的票证。

鉴于公司不会互相互动“门票”....

拥有一个“门票”和查询的集合是否更好？或者是否更好地为每个公司创建门票集合？

Answer 1

这里有几点需要考虑。

首先是预先分配空间。您会在mongodb-user组中找到几个线程，因此当他们的数据占用的空间非常小时，OP会对数据库为什么占用这么多空间感到困惑。这是因为当您在集合中达到预分配的某个点时，默认情况下将创建大小为2GB的文件，即使您只使用100meg的空间。

现在想象一下1000家公司的预分配模式;这很快就会造成磁盘空间的低效使用，并且在大多数线程中会出现性能和成本问题。

这里要考虑的第二件事是nssize，最大为2GB。这可能看起来很疯狂，但如果你的成员超过300万（假设公司是“注册用户”）怎么办？您将很快用完MongoDB可以提供的最大命名空间文件大小。

此外，您不会从锁定（在数据库级别）获益，也不会将它们拆分为单独的数据库，这当然会在维护每个公司的数据库连接时产生操作开销。

MongoDB通常设计用于扩展群集而不是垂直扩展，垂直扩展通常被认为是大型网站的坏主意。

Answer 2

我没有太多时间使用mongodb，但我会给出一些论据，以便我们讨论它。我认为您应该只创建一个Tickets集合，原因如下：

• 为每家公司创建一个集合似乎是冗余。
• 每次向系统添加新公司以创建票证时，您都必须创建和配置集合，而另一方面，您只需要创建公司。
• 我不知道您计划在哪里创建公司文档与相应的故障单集合之间的链接，但我认为使用公司文档的ID以及故障单中的idcompany属性创建链接更为直接集合。

我认为可能会让您考虑为每家公司创建故障单集合的原因之一是，由于大量数据可能会降低查询速度（所有公司都会插入相同的故障单集合）。但是你可以解决这个问题的方法是创建一个分片集群，使用带有idcompany的复合分片键和Tickets文档中的一些有用属性，这种方式很可能是给定公司的所有文档都保留在同一个分片中，所以常见查询的执行速度相对较快。

Answer 3

我的0.02美元：

通过将每个公司分成他们自己的集合或更好的数据库......它使得客户迁移和个性化备份，恢复，导入和导出变得更加容易，代价是使代码变得更加糟糕。

隔离客户数据可能会降低您的数据存储要求，因为您不需要将客户ID嵌入到每个文档中。当然，对于单独的数据库，大多数驱动程序会将其视为单独的网络连接。

与所有事情一样，存在权衡。