原以为基于SaaS架构的数据库数据隔离的设计,无外乎就是3种设计模式: (1)独立数据库 (2)Share数据库,独立Schema (3)Share数据库.Share Schema,每个表均加以个 tenentid(租户ID),这3种模式的优缺点大家都提了很多了,SaaS架构设计的前辈/我/阿里软件
原以为基于SaaS架构的数据库数据隔离的设计,无外乎就是3种设计模式:
(1)独立数据库
(2)Share数据库,独立Schema
(3)Share数据库.Share Schema,每个表均加以个 tenentid(租户ID),这3种模式的优缺点大家都提了很多了,SaaS架构设计的前辈/我/阿里软件最新出的那本书,也都是这么讲的,包括2年前微软推出的SaaS架构设计指南,也都是这么说的。最近一直在思索这个问题,难道真的就没别的出路了?
这3种模式中,第一种做SaaS架构的,相信都不会采纳了,但是第2种与第3种设计的架构之争,常常是谁也说服不了谁。这两种架构,各有优缺点,而且都还很鲜明。
第2种架构设计,Share数据库,独立Schema,比较适用于复杂MIS的应用,数据库关联比较多;而第3种架构设计,适合简单的网站应用,比如网上书店,Performance显然第3种架构比较好,但是数据隔离权限太复杂,对程序员要求比较高,第2种由于Performance问题比较大,对软件系统架构师要求很高。而且第2种,在对B2B网站和供应链/进销存系统整合的应用中,如果综合查询所有租户(供应商/客户)的统计数据,则几乎是不可能的,每个租户之间的数据很难综合共享,每个之间都是数据孤岛。
难道真的就没有更好的设计了吗?后来,在每天不断的苦苦求索当中,终于看到了一缕曙光,利用数据库的特性,也许可以把第2类和第3类设计的优点整合起来,就可以解决这个难题了,只是牺牲了跨数据库的优点,但是对应用程序架构的设计,改动是不大的,而且综合了设计2和设计3的优点,个人认为,这种牺牲,在具体应用中,还是值得的。
本文原创发布php中文网,转载请注明出处,感谢您的尊重!