3

到目前为止的故事：首先，我们得到了一个 Web 应用程序和一个数据库。然后产品所有者决定对第一个应用程序进行分拆（如果第一个应用程序是服装网站，那么第二个网站是专门用于婴儿服装的网站）。我们为第二个应用创建了第二个数据库。之后是第三、第四、第 n 个。我可以证明这个决定是正确的，因为数据库的信息没有相交。

现在：产品负责人决定制作一个超级应用程序，一个应用程序来统治它们。常见故事：用户对某些产品进行查询，结果必须包含来自不同数据库的聚合数据（但不是全部，k from n）。

问题：是否有一些共同的模式可以解决摆在我们面前的常见问题？

第一种方法：超级数据库（所有数据库数据，复制到一个巨大的数据库）

  • 优点：只需要一个查询；应用排序或其他过滤更容易
  • 缺点：我们将如何区分项目的原始数据库；可能是一些ID冲突；必须对信息进行耗时且危险的复制；不会向后兼容旧应用程序

第二种方法：相同的数据库（无更改）

  • 优点：应用程序将向后兼容；不会有危险的应对
  • 缺点：一个查询变成多个查询（更慢，更难聚合）
4

1 回答 1

2

将这一切都放在多个数据库中很好，因为 MongoDB（当然）没有 JOIN，这里没有真正的聚合问题威胁。我想如果 10gen 释放聚合函数等中的子选择功能以允许某种类型的伪连接，您将来可能会遇到问题。

如果您要执行多个输出到同一个集合的 MR，但 MR 现在可以输出到不同的 DB（现在已经可用了一段时间），那么这里的 MR 可能存在一个问题，所以这很好。

同样对于多个数据库（在 2.2 中），由于 2.2 中的锁定机制是数据库级别的，因此锁定将在您身边。

在我个人看来，考虑到复制和冲突 ID 的问题，我会坚持你所拥有的，只是制作一个抽象层，让它看起来像是来自一个数据库。

当然，如果您觉得将其存放在不同的数据库中是一个真正的逻辑问题，并且您很容易混淆数据，那么您可能别无选择。

于 2012-10-01T13:16:44.667 回答