3

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

每个博主都有一个数据库更好吗？鉴于他们的博客和评论完全独立于其他博主。或者只是把所有东西放在一起？还是没有太大区别？

我想象所有博主都使用同一个网络应用程序（不是每个博主的独立网站/网址）。因此，当有人登录/访问博客时，代码会找到正确的数据库来使用并从中提取数据。

这有什么缺点吗？处理这些事情是正常的吗？

4

3 回答 3

4

我对你的需求做了很多假设。但是，一般来说，MongoDB 中的多租户应用程序有 3 条路径：

每位客户一次收集；永远，永远这样做。

每个客户单个数据库。好的。如果您的产品采用免费增值模式，您将权衡可用空间。无论哪种方式，您都希望使用“smallfiles”选项运行。如前所述，您将为您的环境构建路由系统。因此，您需要为正确的客户连接到正确的数据库。

每个文档的 customer_id 键 + 路径 slug。好的。这里的权衡是恢复可用空间。传统上，MongoDB 不会恢复已删除文档使用的空间。因此，创建和删除博客文章的客户将创建未使用的空间。通过使用“usePowerOf2Sizes”集合，您将恢复已删除文档的磁盘空间。但是，'usePowerOf2Sizes' 会创建臃肿的填充空间。

要克服磁盘空间填充，请查看此处使用的压缩：http: //blog.appsignal.com/blog/2013/07/30/taming-mongodb-disk-usage.html

回顾一下，我建议使用 customer_id 加上压缩。它为您提供两全其美的体验。

于 2013-08-14T04:31:56.817 回答
4

正如原始问题下的评论中所述，由于拥有每个数据库和最小存储的开销，将 MongoDB 存储拆分为每个博主的单独数据库确实没有性能优势。

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

说了这么多：您仍然可能有一些理由跨数据库拆分数据。也许您出于法律原因必须分离数据，或者确保客户的敏感数据不会与其他公司的数据混合。也许您的客户需要对其数据库的完全读/写访问权限，因此您使用每个数据库的配置作为安全边界。我敢肯定还有其他原因...

于 2013-08-14T04:32:05.477 回答
2

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

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

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

但是，您必须考虑管理与每个数据库的连接的应用程序中存在问题的方面。这将是一项超负荷工作，您将需要比被认为是标准的编码复杂得多。

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

因此，如果您的方案使其成为问题，那么空间问题实际上只是一个问题。

处理这些事情是正常的吗？

对于一个普通的博客网站，不，我对你的场景的复杂性了解得不够多，不能说有什么不同。正常操作是将所有内容集中在一起，因为您可以看到 1,000 或 1,000,000 个用户的区域，并且数据库分离不会很好地扩展。

于 2013-08-14T07:24:14.803 回答