如何创建具有共享表结构的多租户数据库？

我们的软件当前在MySQL上运行。所有租户的数据都存储在同一架构中。由于我们使用的是Ruby on Rails，因此我们可以轻松确定哪些数据属于哪个租户。但是，当然有些公司担心其数据可能会遭到破坏，因此我们正在评估其他解决方案。

到目前为止，我已经看到了三种选择：

• 多数据库（每个租户都有自己的-每个客户几乎与1台服务器相同）
• 多模式（在MySQL中不可用，每个租户都在共享数据库中获得自己的模式）
• 共享模式（我们当前的方法，可能在每列上都有其他标识记录）

我最喜欢Multi-Schema（考虑到成本）。但是，创建一个新帐户并进行迁移似乎很痛苦，因为我将不得不遍历所有模式并更改其表/列/定义。

问： Multi-Schema似乎被设计为每个租户都有略微不同的表-我不想要这个。是否有任何RDBMS允许我使用多模式多租户解决方案，其中所有租户之间共享表结构？

PS多重代表我的意思是超级多重（10.000+个租户）。

但是，当然有些公司担心其数据可能会遭到破坏，因此我们正在评估其他解决方案。

这是不幸的，因为客户有时会误以为只有物理隔离才能提供足够的安全性。

有一篇有趣的MSDN文章，标题为Multi-Tenant Data Architecture，您可能需要检查一下。这就是作者如何解决对共享方法的误解：

一个普遍的误解认为，只有物理隔离才能提供适当级别的安全性。实际上，使用共享方法存储的数据也可以提供强大的数据安全性，但是需要使用更复杂的设计模式。

至于技术和业务方面的考虑，本文简要分析了某种方法可能比另一种方法更合适的地方：

您期望服务的租户的数量，性质和需求都以不同的方式影响您的数据体系结构决策。以下某些问题可能会使您偏向于一种更孤立的方法，而另一些问题可能使您偏向于一种更加共享的方法。

• 您预计要定位多少个潜在租户？您可能无法凭一己之力来估计预期的用途，但要考虑数量级：您是否正在为数百个租户构建应用程序？几千？成千上万？更多？您期望租户基数越大，您就越有可能考虑采用更共享的方法。

• 您希望普通租户的数据占用多少存储空间？如果您期望某些或所有租户存储大量数据，则使用单独数据库方法可能是最好的。（实际上，数据存储要求可能仍然迫使您采用单独的数据库模型。如果是这样，那么从一开始就以这种方式设计应用程序比以后再采用单独的数据库方法要容易得多。）

• 您希望普通租户支持多少个并发最终用户？数量越大，越能满足最终用户需求的方法越合适，越孤立。

• 您是否希望提供任何按租户的增值服务，例如按租户的备份和还原功能？通过更隔离的方法更容易提供此类服务。

更新：进一步更新预期的租户数量。

对于大多数（如果不是全部）场景，预期的租户数量（10k）应该排除多数据库方法。我认为您不会喜欢维护10,000个数据库实例，每天都必须创建数百个新实例的想法。

仅从该参数来看，似乎最适合共享数据库单模式方法。每个租户将仅存储大约50Mb的事实，并且没有每个租户的附加组件，这一事实使这种方法更加合适。

上面引用的MSDN文章提到了三种安全模式，这些模式解决了共享数据库方法的安全注意事项：

• 可信数据库连接
• 租户视图过滤器
• 租户数据加密

如果您对应用程序的数据安全措施充满信心，则可以为客户提供服务级别协议，以提供强有力的数据安全保证。在SLA中，除了保证之外，您还可以描述将要采取的确保数据不被破坏的措施。

更新2：显然，Microsoft伙计们移动/撰写了有关此主题的新文章，原始链接不见了，这是新链接：多租户SaaS数据库租用模式（对Shai Kerer表示感谢）

我的经验（尽管有SQL Server）是，多数据库是必经之路，每个客户端都有自己的数据库。因此，尽管我没有mySQL或Ruby On Rails的经验，但我希望我的输入可能会增加一些价值。

原因包括：

1. 数据安全/灾难恢复。每个公司的数据都与其他公司完全分开存储，从而降低了数据被泄露的风险（例如，如果您引入了代码错误，则意味着某些情况下如果不该错误地查看其他客户数据，就可以避免此类损失）特定的数据库被破坏等。给客户带来的安全利益更大（增加了额外的副作用！）
2. 可扩展性。本质上，您将对数据进行分区以实现更大的可伸缩性-例如，数据库可以放在不同的磁盘上，您可以使多个数据库服务器联机并使数据库移动更容易分散负载。
3. 性能调优。假设您有一个很大的客户，一个很小的客户。使用模式，数据量等可以有很大的不同。您可以根据需要为每个客户端更轻松地进行调整/优化。

我希望这能提供一些有用的输入！还有更多原因，但是我的想法变得一片空白。如果它恢复正常，我将更新:)

编辑：
自从我发布了这个答案以来，现在很明显，我们正在与10,000多个租户交谈。我的经验是在数百个大型数据库中-我认为对于您的方案而言，10,000个单独的数据库不会太容易管理，因此我现在不赞成在您的方案中使用多数据库方法。尤其是现在很明显，您正在为每个租户谈论小数据量！

无论如何都要保持我的答案，因为它可能对类似船只（租户较少）中的其他人有所帮助

以下是Salesforce.com上白皮书如何实现多租户的链接：

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

它们有1个巨大的表，带有500个字符串列（Value0，Value1 ... ... Value500）。日期和数字以格式存储为字符串，以便可以在数据库级别将其转换为其本机类型。有元数据表定义了数据模型的形状，每个租户可以是唯一的。还有用于索引，关系，唯一值等的其他表。

为什么要麻烦？

每个租户都可以在运行时自定义自己的数据模式，而不必在数据库级别（更改表等）进行更改。这绝对是执行此类操作的困难方法，但非常灵活。

正如您提到的，每个租户一个数据库是一个选项，并且确实有一些较大的折衷。它可以在较小的规模上很好地工作，例如个位数或十位以下的租户，但除此之外，它变得更难管理。不仅是迁移，而且还只是保持数据库的正常运行。

每个模式模型不仅对于每个模式都有用，尽管仍然难以在所有租户之间进行迁移，而且在1000个模式下，Postgres可能会遇到麻烦。

更具可扩展性的方法是绝对让租户随机分布，存储在同一数据库中，但跨不同的逻辑分片（或表）。根据您的语言，有许多库可以帮助您解决此问题。如果您使用的是Rails，则可以使用一个库来保存租期acts_as_tenant，这有助于确保租户查询仅拉回该数据。还有一个瑰宝apartment-尽管它使用模式模型，但确实有助于跨所有模式的迁移。如果您使用的是Django，那么会有很多数字，但是最受欢迎的数字之一似乎是跨模式的。所有这些都在应用程序级别提供了更多帮助。如果您正在直接在数据库级别上寻找更多东西，Citus致力于为您提供这种类型的分片与Postgres一起进行多租户工作更加容易。