既然跨数据库查询在一个集群中可用，我正在尝试了解是否/何时值得创建单独的数据库。在大多数情况下，似乎将所有内容都放在一个数据库中是最好的解决方案。
我还没有找到有关跨数据库查询的详细信息，但我认为性能会比在一个数据库上运行时慢。
我的问题是，我什么时候应该设置多个数据库，而不是将所有内容都放在一个数据库中。
我们有 4 个不同的“产品”或电子商务网站。相关但不同。我们曾考虑将它们放在同一集群内的不同数据库中，但我们发现这种方法有太多缺点。
答案 0 :(得分：2)
如果您有单独的项目/模块，每个项目/模块都有自己的数据，那么为它们创建单独的数据库是有意义的。示例：
假设你有
每个平均有 1 000 000 个用户，但它们之间的关系并不密切。实际上，在这种情况下，如果将数据分离到单独的数据库中，对性能会更好，这样每当用户登录项目时，都会从 1 000 000 条可能的记录中搜索用户，而不是从 1 000 x 1 000 000 条可能的记录中搜索。您需要问自己的主要问题是：“我的数据集是否密切相关”？如果是这样，您可能会使用单个数据库。如果没有，那么将它们分成不同的数据库实际上在理论上会提高性能而不是造成损坏。永远不要优化不慢的东西。
答案 1 :(得分：2)
跨数据库查询的工作原理是制作远程数据库中表的每会话副本（在查询发布数据库中）。
因此，无论是在磁盘方面还是在第一个查询的性能方面都有很大的开销，因为我认为它会将表从 S3 中删除，并且必须在每个会话中重复这项工作每张桌子都被这样访问。 （S3 的下架是为什么只有 RA3 节点提供跨数据库。）
请注意，当您对原始表进行修改时，不会将作为修改的一部分传播到副本；相反，只有在发生修改后第一次查询远程表时，才会将更改复制到远程表。
我自己看不到使用多个数据库的任何理由，也看不到此功能存在的意义。
您在权限/安全性方面没有得到任何好处（组和用户与数据库分开），但您确实得到了上述性能和磁盘成本。
我还怀疑使用它的人是在完全不知情的情况下使用它；文档中没有关于成本的内容。不过，这是 Redshift 普遍存在的严重问题。在这种情况下，这不是一次性的特殊问题。
答案 2 :(得分：2)
与其他人一样，我只看到非常有限的情况，其中 Redshift 集群中的多个数据库具有优势。硬件在这些数据库之间共享，因此对一个数据库的性能要求会影响其他数据库。这些可能表现为 CPU 影响、磁盘 IO 影响、网络影响、内存影响、领导节点订阅过多或临时空间影响。一次为单个数据库管理 Redshift 已经足够具有挑战性了，为什么要把事情复杂化。
如果数据基本上是独立的，那为什么不设置多个集群呢？共享有限的数据可以通过其他方式处理。这会增加您可以应用的马力并提供更好的硬件隔离。
如果存在高级别的数据共享，那么“数据库”只会在单个数据库中有效地提供更高级别的数据组织。不是坏事，但不是真正的多数据库使用模型。只有 2 层“模式”。
有一些额外的数据保护/隔离/访问控制，在某些用例中可能是驱动程序。
有些可能有许多小型数据库，它们的工作负载很轻，因此将它们组合到一个集群中可以节省成本。不需要很大的马力，因此在许多数据库用例中共享它。
我可以看到在某些情况下，多数据库 Redshift 可能是一个优势，但我看不到大多数当前 Redshift 客户迁移到此模型的驱动力。