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

Question

我们的软件目前在MySQL上运行。所有租户的数据都存储在相同的模式中。因为我们使用的是Ruby on Rails，所以我们可以很容易地确定哪些数据属于哪个租户。然而，当然也有一些公司担心他们的数据可能会被泄露，所以我们正在评估其他解决方案。

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

• Multi-Database (每个租户都有自己的模式-几乎等同于每个customer)
• Multi-Schema有一个服务器(在MySQL中不可用，每个租户在一个共享的database)
• Shared模式中都有自己的模式)

多模式是我的最爱(考虑到成本)。然而，创建一个新帐户和执行迁移似乎是相当痛苦的，因为我必须迭代所有模式并更改它们的表/列/定义。

Q:多模式似乎被设计为为每个租户提供略有不同的表-我不希望这样。是否有RDBMS允许我使用多模式多租户解决方案，其中表结构在所有租户之间共享？

附注:我所说的多租户指的是超多租户(10.000+租户)之类的东西。

Answer 1

然而，当然也有一些公司担心他们的数据可能会被泄露，所以我们正在评估其他解决方案。

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

MSDN上有一篇有趣的文章，标题是Multi-Tenant Data Architecture，你可能想去看看。这就是作者如何解决对共享方法的误解：

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

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

您期望服务的租户的数量、性质和需求都会以不同的方式影响您的数据架构决策。下面的一些问题可能会让你倾向于更孤立的方法，而其他问题可能会让你倾向于更共享的方法。

• 您预计会瞄准多少潜在租户？您可能根本无法估计权威的预期用途，但请从数量级来考虑:您是否正在为数百个租户构建应用程序？几千人？数以万计？更多?你希望你的租户基数越大，你就越有可能考虑更多的共享方法。
• 你预计平均每个租户的数据会占用多少存储空间？如果您希望部分或所有租户存储大量数据，那么单独的数据库方法可能是最好的。(实际上，数据存储需求可能会迫使您采用单独的数据库模型。如果是这样的话，从一开始就以这种方式设计应用程序要比以后转移到单独的数据库方法容易得多。)
• 您希望平均每个租户支持多少并发最终用户？数字越大，越适合采用更孤立的方法来满足您期望提供的任何按租户增值服务的最终用户requirements.
• Do，例如按租户备份和恢复功能？这样的服务更容易通过一种更孤立的方法提供。

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

预期的租户数量(10k)应该排除多数据库方法，即使不是所有情况，也是大多数情况。我认为您不会喜欢维护10,000个数据库实例并每天创建数百个新实例的想法。

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

上面引用的MSDN文章提到了三种安全模式，它们解决了共享数据库方法的安全问题：

• Trusted Database Connections
• Tenant View Filter
• Tenant Data Encryption

当您对应用程序的数据安全措施很有信心时，您将能够为您的客户提供一个提供强大数据安全保证的Service Level Agrement。在您的SLA中，除了保证之外，您还可以描述您将采取的措施，以确保数据不会泄露。

更新2:显然微软的家伙们移动/制作了一篇关于这个主题的新文章，原来的链接不见了，这是一个新的链接：Multi-tenant SaaS database tenancy patterns (感谢Shai Kerer)

Answer 2

以下是Salesforce.com上有关他们如何实施多租户的白皮书的链接：

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

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

为什么这么麻烦？

每个租户都可以在运行时自定义自己的数据模式，而不必在数据库级别进行更改(alter table等)。这绝对是一种很难做到的方式，但是非常灵活。

Answer 3

我的经验(尽管是SQL Server)是多数据库的发展方向，每个客户端都有自己的数据库。因此，尽管我没有mySQL或Ruby On Rails的经验，但我希望我的输入可以增加一些价值。

原因包括：

1. 数据安全性/灾难恢复。每家公司的数据与其他公司的数据完全分开存储，从而降低了数据被泄露的风险(如果您引入了代码错误，这意味着某些东西错误地查看了其他客户端数据，而它不应该这样做)，如果一个特定的数据库被破坏，则最大限度地减少一个客户端的潜在损失，等等。给客户端带来的安全好处甚至更大(增加了额外的effect!)
2. scalability.从本质上讲，您可以将数据分区以实现更大的可扩展性-例如，数据库可以放在不同的磁盘上，您可以使多个数据库服务器联机并更容易地移动数据库，从而更容易地进行load.
3. performance调优。假设您有一个非常大的客户端和一个非常小的客户端。使用模式、数据量等会有很大的不同。如果需要，您可以更轻松地调整/优化每个客户端。

我希望这确实提供了一些有用的输入！还有更多的原因，但我的大脑一片空白。如果它回来了，我会更新:)

编辑：

自从我发布了这个答案，现在很明显，我们谈论的是10,000+租户。我的经验是在数百个大型数据库中-我不认为10,000个独立的数据库对于你的场景来说太容易管理了，所以我现在不赞成在你的场景中使用多数据库方法。尤其是现在很明显，您谈论的是每个租户的小数据量！

将我的答案保留在这里，因为它可能对类似船上的其他人有一些用处(租户较少)