实现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 |
