例如,想象一个简单的“帮助台”类型的应用程序,其中有支持工单,该应用程序支持多个公司登录并管理他们的工单。
鉴于公司不会相互交互“门票”....
拥有一组“Tickets”并进行查询更好,还是为每个公司创建 Tickets 集合更好?
例如,想象一个简单的“帮助台”类型的应用程序,其中有支持工单,该应用程序支持多个公司登录并管理他们的工单。
鉴于公司不会相互交互“门票”....
拥有一组“Tickets”并进行查询更好,还是为每个公司创建 Tickets 集合更好?
这里有几件事需要考虑。
首先是预先分配空间。您会在 mongodb-user 组中找到几个线程,因此 OP 对为什么他们的数据库占用如此多的空间而他们的数据占用如此少的空间感到困惑。这是因为当你到达集合中的某个预分配点时,它会默认创建 2GB 大小的文件,即使你只使用 100meg 的空间。
现在想象一下这种针对 1000 家公司的预分配模式;这很快就会造成磁盘空间的低效使用,并且在大多数线程中,还会造成性能和成本问题。
这里要考虑的第二件事是 nssize,最大为 2GB。这可能看起来很疯狂,但是如果您确实拥有超过 300 万会员(假设一家公司是“注册用户”)怎么办?您将很快用完 MongoDB 可以提供的最大命名空间文件大小。
此外,如果不将它们拆分到单独的数据库中,您将不会从锁定(在数据库级别)中获得任何好处,这当然会在维护每个公司的数据库连接时产生操作开销。
MongoDB 通常被设计为通过集群扩展而不是垂直扩展,垂直扩展通常被认为对于大型网站来说是个坏主意。
我没有太多时间使用 mongodb,但我会给出一些论据,以便我们讨论它。我认为您应该只创建一个门票集合,原因如下:
我认为可能让您考虑为每个公司创建票证集合的原因之一是,由于大量数据可能会降低您的查询速度(所有公司都插入同一个票证集合)。但是你可以解决这个问题的方法是创建一个分片集群,使用带有 idcompany 的复合分片键和门票文档中的一些有用属性,这种方式很可能给定公司的所有文档都保留在同一个分片中,所以常见查询将执行相对较快。
我的 0.02 美元:
通过将每家公司分成他们自己的集合,或者更好的数据库……它使客户迁移和个性化备份、恢复、导入和导出变得更加容易,但代价是让你的代码变得更糟糕。
隔离客户数据可能会降低您的数据存储要求,因为您不需要将客户 ID 嵌入到每个文档中。当然,对于单独的数据库,大多数驱动程序会将其视为单独的网络连接。
与所有事情一样,都有权衡。