设计数据库架构以支持MYSQL中的多租户

Question

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

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

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

我不希望有学生桌（学校X的学生，学校Y的学生，...）

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

Answer 1

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

  

以物理方式分离每个租户（学校）的数据，即   模式必须包含仅与特定租户相关的数据。

优点：

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

缺点：

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

  

按逻辑将每个租户（学校）的数据分开，即一个模式   包含所有租户的数据。

优点：

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

缺点：

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

这不是完整的列表。这些都是基于我在两种类型的设计上的经验。两种设计都是通用的，并根据用例由多个组织使用。