在MongoDB中管理独立的事物集时，使用多个数据库是否更好？

例如，如果您有一个博客网站使用MongoDB来存储数据

每个博客都有一个数据库更好吗？考虑到他们的博客和评论完全独立于其他博客。还是把所有的东西都放在一起？还是没什么区别

我想象着所有博客都使用同一个web应用程序（不是每个博客独立的web/URL）。因此，当有人登录/访问博客时，代码会找到合适的数据库来使用并将数据拖出

---

这有什么坏处吗？处理这类事情是正常的吗

我对你的需求做了很多假设。但是，在MongoDB中，通常有3条通向多租户应用程序的路径：

每个客户一次收集；永远不要这样做

每个客户有一个数据库。好。如果您的产品采用freemium型号，您将牺牲可用空间。无论哪种方式，您都希望使用“smallfiles”选项运行。如上所述，您将为您的环境构建路由系统。因此，您需要连接到适当客户的适当数据库

每个文档的客户id密钥+路径slug。好。这里的权衡是恢复自由空间。传统上，MongoDB不会恢复已删除文档所使用的空间。因此，创建和删除博客帖子的客户将创建未使用的空间。通过使用“UsePowerO2Sizes”集合，可以恢复已删除文档的磁盘空间。但是，“UsePowerO2Sizes”会造成填充空间过大

要克服磁盘空间填充，请查看此处使用的压缩：

---

总而言之，我建议使用customer_id加上压缩。它让您两全其美。

如原始问题下的评论所述，将MongoDB存储拆分为每个blogger的单独数据库实际上没有任何性能优势，因为每个数据库和最小存储都会带来开销

另一方面：你将使一些跨用户分析变得更加困难。作为一个非常简单的例子，基于您的博客示例：假设您希望查看每个用户的平均帖子数量。如果您的用户（和帖子）在同一个数据库中（通常在同一个集合中），那么这非常简单，并且您可以使用聚合框架来完成此任务。对于数量无限的数据库来说，这项任务将不是那么简单，您需要首先枚举所有数据库，然后对每个数据库执行一次聚合/平均。与单个数据库体系结构相比，这最终可能是一个较慢的操作

---

话虽如此，您仍然有理由在数据库之间分割数据。可能由于法律原因，您必须分离数据，或者确保客户的敏感数据不会与其他公司的数据混合。可能您的客户需要对其数据库进行完全读/写访问，因此您使用每个数据库配置作为安全边界。我相信还有其他原因…

如果您只看到100个数据库，那么分配100个数据库是完全正常的

数据库分离有很多好处。它们可以独立地分片，因为分片发生在数据库级别。数据库还有一个好处，即它是其中数据的完全隔离实例（包括锁）（很好的例子：空间分配发生在数据库级别）

这意味着，随着用户数据访问量的增加，它们可以在网络中移动，而且由于单个用户的数据可能没有那么大，因此比将所有用户数据移动到功能更强大的节点更容易

但是，在管理连接到每个数据库的应用程序时，必须考虑有问题的方面。这将是一个非常复杂的问题，你需要比标准的编码复杂得多的编码

考虑到空间，你不会看到空间的大量使用。使用单独数据库最有问题的部分是日志分配。当然，在单独的数据库中使用的每个集合也会预分配自身，但这实际上被认为是使用数据库分离（节点之间的数据库移动、隔离）的好处之一

因此，空间问题实际上只是一个问题，如果你的场景使它成为一个问题

处理这类事情是正常的吗

---

对于一个普通的博客网站来说，不，我也不知道你的场景有多复杂，所以不能说有什么不同。正常的操作是将所有数据集中在一起，因为您可以看到1000个或1000000个用户，数据库分离无法很好地扩展到这一范围。

我认为如果生成多个数据库（数百个？），您会遇到空间问题。这是因为MongoDB分配的内存是分块完成的（最初最小为64MB）。而且，我看不出这有任何可能的好处——它不增加功能，不增加速度，不占用更少的空间……它对一些查询没有帮助吗？我不确定我是否选择了最好的示例，但如果您需要查询与某个blogger相关的所有项目的集合，在单个db场景中，您只需获取所有项目？在这种情况下，每个blogger拥有集合。如果你在博客名上有索引，即使将所有内容存储在一个集合中，速度也几乎与单独的集合或数据库一样快。啊，很好的一点。没有每个博客名都有一个集合，你会后悔的。+1，就像cust_id+path slug方法一样，考虑到不会有太多的删除。不管怎样，都会发生IUSK重用，出现碎片的原因是，您的文档不适合其以前的空间，因此只能在高写场景中使用POWERLO2SIZES分配，因为在任何其他场景中，它实际上会创建数据库的未执行操作。一个好的模式就是一切