多租户saas 架构_SaaS 数据库架构选择

多租户数据库架构

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

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

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

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

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

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

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

如何选择

借用

https://blog.arkency.com/comparison-of-approaches-to-multitenancy-in-rails-apps

总结的。

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

我的项目及选择

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

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

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

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

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

参考资料

• 数据层的多租户浅谈 (https://www.ibm.com/developerworks/cn/java/j-lo-dataMultitenant/index.html)

• Comparison of approaches to multitenancy in Rails apps    (https://blog.arkency.com/comparison-of-approaches-to-multitenancy-in-rails-apps/)

• Three Database Architectures for a Multi-Tenant Rails-Based SaaS App     (https://rubygarage.org/blog/three-database-architectures-for-a-multi-tenant-rails-based-saas-app)

-------------- END --------------

        

请关注公众号或加个人微信号

不定时获取关于科技新知的文章

请放心，不会推送垃圾信息