toc
多租户数据库架构
多租户（Multi Tenancy/Tenant）是一种软件架构，其定义是：
在一台服务器上运行单个应用实例，它为多个租户提供服务。
在 SaaS 实施过程中，有一个显著的考量点，就是如何对应用数据进行设计，以支持多租户，而这种设计的思路，是要在数据的共享、安全隔离和性能间取得平衡。
常见的多租户数据隔离方案有以下三种：
- 数据库级：每个租户独享一个数据库实例，它提供了最强的隔离度，租户的数据彼此物理不可见，备份、恢复都很灵活，系统升级复杂；
- Schema 级：将每个租户关联到同一个数据库的不同 Schema，租户间数据彼此逻辑不可见，上层应用程序的实现和独立数据库一样简单，但备份、恢复、系统升级稍显复杂；
- 行级：租户数据在数据表级别实现共享，它提供了最低的成本，但引入了额外的编程复杂性（程序的数据访问需要用 tenant_id 来区分不同租户），备份、恢复也更复杂，但是系统升级简单些。
如何选择
借用 这里 总结的。
| 场景 | 建议 |
|---|---|
| 大量的租户 | 考虑行级 |
| 大量低价值租户（废弃账号或者免费试用） | 考虑行级 |
| 少量的高价值租户 | schema 级更可行 |
| 对数据隔离高要求（保证租户间数据不泄露） | 考虑 schema 级 |
| 因为合规的原因，客户要求更多的数据隔离? | 考虑 schema 级甚至数据库级 |
| 使用托管的云数据库 | 如果想使用 schema 级，确认云平台支持 |
| 将已有的单用户系统升级到多租户系统 | schema 级更容易快速实现 |
| 全新项目 | 行级更可行 |
| 租户间有大量共享数据 | schema 级可以，但是行级是更安全的赌注 |
我的项目及选择
研究 SaaS 数据库架构的原因是，我想将一个开发到一半的单用户系统 SaaS 化。前一段刚把数据库从 MySQL 迁移到了 PostgreSQL，选择 schema 级应该是最简单的。
但是我最终选择了行级。因为我的系统面向小 B，其实是有更多的跨租户数据共享需求的。
一些新的 SaaS 软件，比如钉钉和石墨，他们的设计逻辑是先后个人后有企业，个人天然是跨企业的，所以，数据是围绕个人来组织而不是企业。我觉得这是未来的趋势，尤其是面向小 B 的系统。
所以，如果你在开发面向小 B 的系统，我建议你把人单拿出来考虑，而不是像原来的系统那样，先有企业，然后企业下面有用户。一个人如果属于多个企业的话，有多个账号。
如果是转化一个已经开发完成的系统，我会选择 schema 级吧。
