SaaS 数据库架构选择

发布日期:2020年06月16日本文同步发表于公众号:

Cover

多租户数据库架构

多租户(Multi Tenancy/Tenant)是一种软件架构,其定义是:

在一台服务器上运行单个应用实例,它为多个租户提供服务。

Cover

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

常见的多租户数据隔离方案有以下三种:

  1. 数据库级:每个租户独享一个数据库实例,它提供了最强的隔离度,租户的数据彼此物理不可见,备份、恢复都很灵活,系统升级复杂;

Cover

  1. Schema 级:将每个租户关联到同一个数据库的不同 Schema,租户间数据彼此逻辑不可见,上层应用程序的实现和独立数据库一样简单,但备份、恢复、系统升级稍显复杂;

Cover

  1. 行级:租户数据在数据表级别实现共享,它提供了最低的成本,但引入了额外的编程复杂性(程序的数据访问需要用 tenant_id 来区分不同租户),备份、恢复也更复杂,但是系统升级简单些。

Cover

如何选择

借用 这里 总结的。

场景 建议
大量的租户 考虑行级
大量低价值租户(废弃账号或者免费试用) 考虑行级
少量的高价值租户 schema 级更可行
对数据隔离高要求(保证租户间数据不泄露) 考虑 schema 级
因为合规的原因,客户要求更多的数据隔离? 考虑 schema 级甚至数据库级
使用托管的云数据库 如果想使用 schema 级,确认云平台支持
将已有的单用户系统升级到多租户系统 schema 级更容易快速实现
全新项目 行级更可行
租户间有大量共享数据 schema 级可以,但是行级是更安全的赌注

我的项目及选择

研究 SaaS 数据库架构的原因是,我想将一个开发到一半的单用户系统 SaaS 化。前一段刚把数据库从 MySQL 迁移到了 PostgreSQL,选择 schema 级应该是最简单的。

但是我最终选择了行级。因为我的系统面向小 B,其实是有更多的跨租户数据共享需求的。

一些新的 SaaS 软件,比如钉钉和石墨,他们的设计逻辑是先后个人后有企业,个人天然是跨企业的,所以,数据是围绕个人来组织而不是企业。我觉得这是未来的趋势,尤其是面向小 B 的系统。

所以,如果你在开发面向小 B 的系统,我建议你把人单拿出来考虑,而不是像原来的系统那样,先有企业,然后企业下面有用户。一个人如果属于多个企业的话,有多个账号。

如果是转化一个已经开发完成的系统,我会选择 schema 级吧。

参考资料