mysql - 设计数据库架构以支持 MYSQL 中的 Multi-Tenancy

Question

我正在使用 ASP 开发一个连接到 MYSQL 数据库的学校管理软件。当我将软件部署在每个用户(学校)的本地计算机中时，该软件运行良好，但我想将软件迁移到 AZURE 云。用户将拥有一个帐户来连接到同一应用程序，但数据不得与其他学校的数据混合。我的问题是找到部署和管理数据库的最佳方法。

1. 我必须为每所学校部署 1 个数据库
2. 所有学校数据都位于同一数据库中。

我不确定我的解决方案是最好的方法。

我不想要前学生表(内容为 X 学校的学生，Y 学校的学生，...)

请帮助找到最佳解决方案。

Answer 1

有多种可能的方法来设计架构以支持 Multi-Tenancy 。设计的简单性取决于用例。

Separate the data of every tenant (school) physically, i.e., one schema must contain data related to only a specific tenant.

优点:

1. 易于 A/B 测试。您可以向某些租户发布需要更改数据库的更新，并随着时间的推移将其提供给其他租户。
2. 轻松将数据库从一个数据中心移动到另一个数据中心。支持针对不同客户的不同SLA进行备份。
3. 每个租户数据库级别的自定义非常简单。为客户添加新表或修改/添加字段变得很容易。
4. 第三方集成相对容易，例如将您的数据与 Google Data Studio 连接。
5. 扩展相对容易。
6. 从一个租户检索数据非常简单，无需担心外键值混淆。

缺点:

1. 当您必须修改任何字段/表时，您的应用程序代码需要处理某些数据库中未完成更改的情况。
2. 跨客户检索分析变得很困难。设计用于使用情况分析的查询变得更加困难。
3. 与其他数据库系统集成时，尤其是NoSQL，您将需要更多资源。例如，在 Elasticsearch 中为每个租户建立索引数据将需要每个租户的索引，如果有数千个客户，则将导致创建数千个分片。
4. 需要将跨租户的通用数据复制到每个数据库中

Separate data for every tenant (school) logically, i.e., one schema contains data for all the tenants.

优点:

1. 软件发布很简单。
2. 轻松查询多个租户的使用情况分析。

缺点:

1. 扩展相对棘手。可能需要数据库分片。
2. 维护所有表中每个租户的数据的逻辑隔离需要更多的关注，如果不在应用程序级别仔细处理，可能会导致数据损坏。
3. 为支持多个区域的应用程序设计数据库系统非常复杂。
4. 从单个租户检索数据很困难。 (请记住:所有记录都将使用外键与其他一些记录相关联。)

这不是一个完整的列表。这些都是基于我从事这两种设计类型的经验。这两种设计都很常见，并且被多个组织根据用例使用。