sql - 如何创建具有共享表结构的 Multi-Tenancy 数据库？

Question

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

到目前为止，我已经看到了三个选项:

• 多数据库(每个租户都有自己的 - 几乎与每个客户 1 台服务器相同)
• 多架构(在 MySQL 中不可用，每个租户在共享数据库中都有自己的架构)
• 共享架构(我们目前的方法，可能在每列上添加额外的标识记录)

多模式是我最喜欢的(考虑成本)。然而，创建一个新帐户并进行迁移似乎很痛苦，因为我必须遍历所有模式并更改它们的表/列/定义。

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

附:我所说的多是指超多(10.000 多个租户)。

Answer 1

However there are some companies of course who fear that their data might be compromised, so we are evaluating other solutions.

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

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

A common misconception holds that only physical isolation can provide an appropriate level of security. In fact, data stored using a shared approach can also provide strong data safety, but requires the use of more sophisticated design patterns.

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

The number, nature, and needs of the tenants you expect to serve all affect your data architecture decision in different ways. Some of the following questions may bias you toward a more isolated approach, while others may bias you toward a more shared approach.

• How many prospective tenants do you expect to target? You may be nowhere near being able to estimate prospective use with authority, but think in terms of orders of magnitude: are you building an application for hundreds of tenants? Thousands? Tens of thousands? More? The larger you expect your tenant base to be, the more likely you will want to consider a more shared approach.

• How much storage space do you expect the average tenant's data to occupy? If you expect some or all tenants to store very large amounts of data, the separate-database approach is probably best. (Indeed, data storage requirements may force you to adopt a separate-database model anyway. If so, it will be much easier to design the application that way from the beginning than to move to a separate-database approach later on.)

• How many concurrent end users do you expect the average tenant to support? The larger the number, the more appropriate a more isolated approach will be to meet end-user requirements.

• Do you expect to offer any per-tenant value-added services, such as per-tenant backup and restore capability? Such services are easier to offer through a more isolated approach.

---

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

对于大多数情况(如果不是所有情况)，预期的租户数量(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 致敬)