SAAS系统中多租户数据库设计方案探讨

多租户（Multi Tenancy/Tenant）是一种软件架构，其定义是：在一台服务器上运行单个应用实例，它为多个租户提供服务，也就是我们日常所说的SAAS系统。

在SaaS实施过程中，有一个显著的考量点，就是如何对应用数据进行设计，以支持多租户，而这种设计的思路，是要在数据的共享、安全隔离和性能间取得平衡。

多租户也有了三种比较常用的设计：

1、独立数据库
2、共享数据库、独立Schema
3、共享数据库、共享Schema、共享数据表

• 独立数据库：是一个租户独享一个数据库实例，即一个租户一个数据库实例。它提供了最强的分离度，租户的数据彼此物理不可见，备份与恢复都很灵活；

• 共享数据库、独立Schema 将每个租户关联到同一个数据库的不同Schema，即一个租户一个schema，但都共享同一个数据库实例。租户间数据彼此逻辑不可见，上层应用程序的实现和独立数据库一样简单，但备份恢复稍显复杂；

• 共享数据库、共享Schema、共享数据表：该模式则是租户数据在数据表级别实现共享，即所有租户都使用一个表，然后通过在所有表中增加一个字段（通常就是租户id）来区分不同租户。但引入了额外的编程复杂性（程序的数据访问需要用 tenantId 来区分不同租户），备份与恢复也更复杂。

审视一下三种设计方案，从1到3隔离程度越来越低，共享程度越来越高。我们从以下一些维度对比一下它们各自的优劣：

• 可扩展性：隔离度越高，扩展性越差。数据库实例在数据库中是一个比较重的资源，虽然RDBMS中一般没有对database的个数做限制，但一个数据库服务器上面创建成千上万个数据库实例的场景应该是很少见的吧。所以从1到3，扩展性依次变差。

• 隔离性：主要是数据的隔离、负载的隔离。这个很明显，隔离性1最好，3最差，2适中。

• 成本/资源利用率：这里的成本主要指数据库的成本，或者说硬件的资源利用率。隔离程度越高，利用率越差。比如很多业务其实都有业务高峰和低峰，如果能把高峰不在同一时间段的业务部署在一起，自然是能够提升资源的利用率。

• 开发复杂度：主要体现在查询、过滤、database/schema/table切换等。1和2适中，3难度高一些。

• 运维复杂度：性能监控、管理；database/schema/table的管理；租户数据恢复；容灾等。扩展其实也算运维的一部分，第一个已经讨论过了，这里就不包含扩展了。从监控、管理、租户数据恢复、容灾等考虑，隔离度越高，越简单。

• 可定制性：根据不同租户的需求进行定制的难度，这个自然也是隔离度越高，定制化越好做。

那么实际开发中我们如何选择呢？这个要根据实际业务场景和各个方案的优劣进行选择了，没有完美方案，只有更适合你的方案。而且比如你选择了MySQL，那方案2就不存在了，因为MySQL中没有区分Database和Schema。还有这里只是比较学术的划分了一下设计方案，实际中一些大型SaaS会实现更复杂、灵活的多租户数据库方案，以平衡各个方案的优劣。