实现saas多租户方案比较
看到一篇比较多租户数据隔离方案的文章，总结挺不错。其实大部分内容在我前几年写的文章都有。
文章翻译自：
https://blog.arkency.com/comparison-of-approaches-to-multitenancy-in-rails-apps/
多租户意味着同一个应用上有不用的用户隔离。这是非常典型的saas模型。你可以用不同的隔离级别来实现多租户。
1. 行级别： 在每个数据库表里添加tenat_id字段，然后在每个查询语句也添加相应的tenant_id
2. schema 级别： 每个租户有在同一个数据库内自己独立命名空间。 可以容易使用 PostgreSQL schemas 来实现. 后续会介绍使用Mysql如何实现。
3. 数据库级别：每个租户创建独立的数据库。 非常少用到。
下面是比较这几种实现方式的优缺点：
| 行级别 | schema级别 | db级别 | |
|---|---|---|---|
| 租户创建时间 | ?? 新增一条记录 | ?? 慢 (需要创建schema和表 ) | ?? 非常慢 + 可能需要运维支持 |
租户间泄漏数据风险 | ?? 忘记添加 WHERE | ? 比较安全 | ? 非常安全 |
| 侵入性 | ?? 所有代码需要添加tenant_id 列条件 | ?? 一般 | ?? 非常少 |
Need shared tables or merging data across tenants 不同租户间共享和合并数据 | ? 没任何问题 | ??sql可以跨数据查询 | ?? sql无法实现，只能应用代码实现 |
Running DB migrations 数据库迁移 | ?? O(1) | ?? O(n) | ?? O(n) |
| Conventionality | ?? Standard Rails | ?? Occasionally at odds with Rails assumptions | ?? |
Additional costs 其它成本 | ?? 无 | ?? 无 | ? 创建大量数据成本 |
Operational overhead 额外运维成本 | ? 无 | ??有可能，需要维护大量表 | ?? 需要维护大量数据库 |
Complexity 复杂度 | ?? 到处添加tenant_id | ?? 利用PG特性 search_path | ?? |
Where possible 可行性 | ?? 非常容易实现 | ?? 确认是否是托管数据库。是否有权限 | ?? 是否能按需创建数据库 |
Cost of switching 切换租户成本 | ?? 设置变量。tenant_id =? | ?? 需要设置search_path | ?? 需要创建独立数据库连接 |
Extract a single tenant’s data 抽取独立租户数据 | ?? 有点麻烦 | ?? 容易 | ?? 非常容易 |
MySQL vs PostgreSQL schemas
Mysql没有类似PostgreSQL schemas功能，但Mysql数据库可以实现类似方式使用。切换数据库时候不需要创建独立数据库连接，在Mysql可是通过use 语句来选择数据库。类型在 PG数据库使用search_path功能。类似方案，可以在表名前在租户数据库前缀。
Mysql缺点：是你需要保证数据库间没有名字冲突。创建租户时候，需要有创建数据库的权限。如果你没有需要。而PG只需要在当前数据库创建schemas的权限，并且不用关系名字冲突。即使在托管的数据库服务，也能很方便实现。
快速方案选择：
| 条件 | 推荐 |
|---|---|
| A lot of tenants? | consider row-level |
| A lot of low-value tenants? (like abandoned accounts or free tiers) | consider row-level |
| Less tenants and they’re high-value? | schema-level more viable |
| Anxious about data isolation? (ensuring no data leaks between tenants) | consider schema-level |
| Customers might require more data isolation for legal reasons? | consider schema-level or even db-level |
| On a managed or cloud hosted database? | if you wanna go for schema-level make sure it all works for you |
| Multitenantizing an existing single-tenant code base? | schema-level might be easier to introduce |
| Greenfield project? | row-level more viable |
| Need to combine a lot of data across tenants | schema-level possible, but row-level is a safer bet |