多个模式与巨大的表[关闭]

Question

考虑一个包含每个用户信息的移动设备管理器系统，例如存储他在手机上安装的应用程序的表、审核详细信息、通知信息等。为每个用户创建单独的架构是否明智？对应的表？对于单个用户来说，表的数量很大，每个用户大约有 30 个表。最好有一个单独的架构，将所有这些信息放入这些表中（进而创建巨大的表？）还是为每个用户都有一个架构？

提前致谢

Answer 1

我想看看哪种方法在数据库中查询效率更高。

在多租户数据库中，查询只是问题的一部分。问题的其他部分是成本、数据隔离和保护、维护和灾难恢复。这些很重要；您不能考虑仅多租户数据库中的查询效率。

多租户解决方案的范围从每个租户一个数据库（不共享任何内容）到每个租户一个行（共享所有内容）。

“不共享”、“独立数据库”或每个租户一个数据库

• 每个客户最昂贵。 （大量的客户端意味着大量的服务器。）
• 最高程度的数据隔离。
• 单个租户的灾难恢复简单明了。
• 维护理论上更难，因为需要在每个数据库中进行更改。但是您的 dbms 可能很容易支持在每个数据库中运行存储过程。 （例如，SQL Server 有一个未记录的系统存储过程 sp_msforeachdb。您可以自己编写。）
• “无共享”也是最容易定制的，但这也会引发更多维护问题。例如，每个租户可能有不同的使用模式，这表明每个租户可能需要一些其他租户不需要的索引。这与“不共享任何内容”无关紧要。 “共享所有内容”是不可能的（如下）。
• 每个表的行数最少。查询速度接近最佳。

“共享一切”或“共享架构”或“每个星球一个数据库”

• 每个租户最便宜。
• 最低程度的数据隔离。每个表都有一个列，用于标识行属于哪个租户。由于租户行在每个表中都混合在一起，因此意外暴露其他租户的数据相对容易。
• 单租户容灾相对复杂；您必须恢复许多表中的各个行。另一方面，单租户灾难相对不常见。大多数灾难可能会影响所有租户。
• 结构维护更简单，因为所有租户共享表。但是，它增加了通信负载，因为您必须与每个租户沟通和协调每次更改。它不容易定制。
• 每个表的最大行数。快速查询更难，但这取决于有多少租户和多少行。您可以轻松进入 VLDB 领域。

在“不共享任何内容”和“共享所有内容”之间是“共享架构”。

“共享架构”

• 租户共享一个数据库，但每个租户都有自己的命名架构。成本介于“不共享”和“共享一切”之间；大型系统通常比“不共享”需要更少的服务器，比“共享一切”需要更多的服务器。
• 比“共享一切”更好的隔离。不像“什么都不分享”那样孤立。 （您可以对架构授予和撤销权限。）
• 单个租户的灾难恢复需要还原多个架构之一。这要么相对容易，要么相当困难，具体取决于您的 dbms。
• 维护比“不共享”更容易；不像“共享一切”那么容易。编写将在数据库中的每个模式中执行的存储过程相对简单。在租户之间共享公用表比“不共享”更容易。
• 通常每台服务器的活动租户多于“不共享”，这意味着它们共享（降级）更多资源。但还没有“共享所有内容”那么糟糕。

Microsoft 在multi-tenant architecture 上有一篇很好的文章，其中包含更多详细信息。 （该链接仅指向多页文档的一页。Microsoft 已删除该页面；该链接现在指向 archive.org 中的副本。）