从业务数据库到元数据,SaaS 架构设计经验全总结

未来社会模型中 SaaS 的位置与分量上图是一个从连接这个透视角度抽象出来的社会模型，其中的家庭、人、组织、物都是相互连接的，它也是一个从软件架构抽象出来的社会模型。

SaaS 是对软件的获得和使用方式的革命，早在 2004 年就已有端倪（当时称为 ASP，Application Service Provider）。

笔者认为，可以将 SaaS 放在社会运行机制、发展趋势这样的大格局中定位其社会作用。

SaaS 企业也需要这样的格局与信念，虽然在中国还没有出现非常成功的 SaaS 企业，但终究会出现的，信任、习惯、规范、与能力都需要进化，需要时间。

在没有电之前，人们就有传递信息的需求，这也是为什么微信能够存在的本质根由。

同理，各种组织都离不开软件，而且软件的渗透越来越广泛与深入，因为整个世界的数字化是不可阻挡的趋势。

而 SaaS 在大部分情况下是必选之路，会越来越成为标配，除非特殊原因，或者不在乎成本、或者已经拥有某种等效的软件、或者其他原因。

只要这种本质性的需求存在着，社会的发展终究会以越来越先进的方式来满足它。

这里分享一个关于云的小故事，笔者曾经算过一笔账，如果在云上订购托管机房中约 500 台机器的同等算力，每年需要支出 5000 万，相当有悖于流行认知，其实对于稍微有些规模的 IT 资源诉求，云相对是更加昂贵的，但来的快、方便，两方面都是事实。

这里只想传递一个观点，长远来看，SaaS 有它存在与发展的必然性。

结构上讲，它是社会运行机制中不可或缺的一部分。

同样或者类似的软件，显然没有必要每个人、每个组织都各买一套或各自开发一套，这是社会资源的极大浪费，有悖于社会发展的基本规律——既然是必需的，必然选择物美价廉。

而且组织支出比个人支出更理性、更注重实用价值，有利可图的需求终究会达到稳态的、某种主流服务的满足。

从架构角度看 SaaS 面临的挑战如果说 SaaS 在大部分情况下将会成为必选之路，那么它面临的最大挑战又是什么呢？概括来讲，SaaS 面临的最大挑战是满足客户的个性化需求。

从架构角度看，它体现在如下图所示的几个方面：其中最有挑战性的又要属多变的后台逻辑与数据模型。

对于 SaaS 供应商而言，这种需求显然不能通过项目的方式来定制满足，而只有通过提供灵活的自服务平台才能满足，这种灵活性就需要用 PaaS 来生产客户想要的软件。

这一点笔者在2013 年做一个 SaaS 项目的架构工作时就深有体会：一开始的目标也是做 SaaS，但是后来还是走上了 PaaS 的道路，不过是专为生产 SaaS 而自用的 PaaS，而不是定位于 PaaS 供应商。

如果一个 SaaS 企业从一开始就只是聚焦某个业务，而没有着手 PaaS 的建设，那说明它在满足个性化需求的道路上一定是在某个局部、某个层面解决问题，而不是系统、全面、可复用地解决问题。

同时，从中国 SaaS 市场现状来看，它的成长比较慢，环境的综合成熟度还不够高，聚焦单一业务成长的加速度不够，因此企业后续很可能会从最开始聚焦的核心业务向外扩展，到时候又要面临种种个性化需求问题。

因此，一个成功的 SaaS 企业必然要去寻求 PaaS 的支撑。

从这两个意义上讲，PaaS 可能也是 SaaS 企业提高生产力的必经方向。

据有关数据表明，在企业弃用 SaaS 的原因中，无法满足个性化需求占了 23%，可见 PaaS 的支撑多么重要。

如何做好 SaaS 架构？1 业务数据库SaaS，特别是 To B 的时候，业务数据库必然是存储的核心，这里笔者针对业务数据库总结了一些架构层面的建议。

建议一：对于任何 mission critical 的场景都要使用 RDBMS企业应用与 To C 的使用场景有一个明显的区别是，绝大部分情况下，它对正确性、准确性的要求更高，而且 SaaS 提供方需要对此承担相应的责任。

因此，支撑一线黄金业务流程的数据库目前来看还是得使用关系型数据库。

目前来看有两个开源可选项，分别是 MySQL 和 PostgreSQL。

建议二：分库支持多租户可以有多种方式，这里所说的分库并不是指每个租户一个独立的库（当然产品销售时可以作为套餐的一个选项），而是指多个数据库实例，每个实例包含多个租户的完整数据。

说到多租户，需要提个醒，通常大家都会想当然地认为租户之间是隔离的，但是事情都有另一面，对于大集团客户，在某些业务上，它的分公司、子集团之间可能还是有连接的。

另外，人员组织机构建模上，也要考虑一个人任职多个子集团或公司的可能。

建议三：Partitioning即使是一个数据库实例，也可以再继续分区，MySQL 和 PostgreSQL（至少版本 11 以上）都支持在一个实例内部分区。

对租户进行 Partitioning 可以在一定程度上提高性能，因为把一个查询限制在更小的数据范围内进行，而非全量数据空间，效率自然会更高。

建议四：元数据驱动，Salesforce 不是标杆一个民族、一个国家如果没有非权威精神，是不会有根本性创新的。

动则大厂是如何做的，好像大厂总是做的最好的，那是不行的，盲目崇拜只能是 follower，不可能是 creator，当然也不能盲目忽视，最要紧的是把业务架构搞清楚、明确定义到底要什么。

心里要有谱，但是技术本身绝对不是谱，而仅仅是可选的手段。

以下是根据 Salesforce官网资料整理的的核心数据模型：其业务数据表本身是没有物理索引的，真正的索引主要在MT_Indexes 中，但是这有点让人困惑，为什么不在MT_Data 上直接建立物理索引呢？难道列和索引太多了会影响性能？而反范式地单独以列的方式、按数据类型建立很少的索引就好？为此，笔者动手做了验证。

1）实验条件为了聚焦在问题本身，图 3 中只采用了绿色的两张表，而省略了红色的字段，本实验所使用的字段名和图 3 不一样，但是思路是一样的。

OS，Windows 10；DB，MySQL 5.7；两张业务表，有物理索引的 =bizdata，没有物理索引的 =bizdata2，结构如下：bizdata 和 bizdata2 都灌入了 10 万条数据，字符型长度为 4，它的值基于给定的一个长度为 10 的字符串随机生成，数值型的则为 100 以内的随机数；索引表为 pivot_index，其中 rowid 的值等于业务表中 id 的值，col 是列名，它们可能的值是 c1­c5、n1­n5，string_value 和 int_value 分别容纳的是字符型和数值型的业务数据值，总的数据行数是 100 万行。

2）实验结果以下比较，除了 SQL 形态上不一样，从语义上讲，条件与期望的结果都是完全一样的。

汇总如下：#方式结果（秒）5.391MT_Data（自身无物理索引） +MT_Indexes，Salesforce 方式2MT_Data（自身有物理索引）0.053MT_Data（自身无物理索引）0.130.164MT_Data（自身无物理索引），且字符字段都采用条件 like ‘%xxxx%’使用 Salesforce 索引表（相当于业务数据表 MT_Data 上没有物理索引，红框部分为行变列的 pivot 逻辑，其实红框外的条件在都是 or 的情况下是可以省略的，否则不可以，这里仅仅为了体现逻辑完整结构，Salesforce 后台用的是 Oracle，也许性能比 MySQL 好不少，也许 Oracle 有 pivot 的核武器，不过从逻辑上讲，就算给 Oracle 更大的想象空间，行数倍增也是不争的事实）的结果：直接使用物理索引（相当于业务数据表 MT_Data 上有物理索引）的结果：直接使用没有物理索引的业务数据表（相当于不考虑 MT_Indexes）的结果：在没有使用物理索引的 bizdata 上用’%xxx%’，看情况如何：3）实验结论结论是不要采用 Salesforce 的元数据使用方式，因为其行列转换的性能损失相当大。

此例相当于把数据行数放大了 10 倍，显然在业务数据表上直接建索引更可取。

当然，Salesforce 的情况可能有其历史原因，或者它有某种未知的核武器。

本文建议采用如下模型：其实，Salesforce 对于查询是有限制的，如果它消耗的资源太大，会直接抛异常。

很可能它是依据提取数据的行数的阈值或者时间（governor limits，资源裁判的角色）来限制的，因此它的性能还是有一定的局限性。

官网对此表述为：“被优化器认为资源开销过大的个别查询会抛出异常给调用方，尽管这听起来有点严格，但为了保护数据库系统总体的可伸缩性和性能，这是必要的。

”建议五：索引所有字段Salesforce 的做法是让租户自己决定一个字段是否要索引，但笔者认为在硬件越来越廉价的今天，如果要在用户体验与成本之间平衡，用户体验更可取。

不过 Salesforce 也会自动为特定字段建索引，参见这里。

其实软件这东西，从用户接受层面上讲，在根植于中国文化的市场上是有点障碍的。

例如：字段field，这个词对于中国大部分普通人来说是很陌生的，但是对于以英语为母语的市场而言，说“请把这个表格填一下”，然后说“包括每一个field”，则是一件很普通的事情。

当我们交付一个产品的时候，需要站在用户的角度去体验、思考、感受，而不能假设所有人都有和软件开发人员一样的认知背景。

建议六：PostgreSQL 优于MySQL这里不是要对二者做详尽的比较，而是瞄准一个核心点，元数据驱动的定制能力。

由于MySQL 的row size 是有限制的，65535 字节，而PostgreSQL 的限制则为1GB，显然后者有更广阔的空间，这也是推荐图 10 业务数据模型的原因之一。

建议七：深挖数据库本身的优化空间对于PostgreSQL，相信还有很多潜力可以挖掘，笔者暂未对其做过深入研究，这里只给出一个方向。

例如：它支持sub­partition，假设在用OrgID 分区的前提下，再进一步用年来分区，对于有些数据的性能可能会更进一步提升，不过无法保证这个可行，凡有得必有失。

再比如，在MySQL 中，通常可能认为插入一条数据没啥可优化的，就是通常见到的那种写法，但是，insert into table_1 set a=a1,b=b2 这样的写法据说是最高效的。

诸如此类，结合多租户、元数据驱动的特点，可能还有很多值得挖掘的地方，最可靠的方法是完整研读官网、对多种值得关注的选项动手试一试。

2 搜索搜索是 SaaS 必须具备的一种能力，例如：输入关键词，希望系统能找出附件中出现这些关键词的合同，不管附件的格式如何。

搜索和通常 RDBMS 的全文检索是完全不同的，尽管在某些技术思路上是一样的，但具体实现的能力差别很大。