SaaS创业：这一篇文章让你搞懂SaaS产品的数据库架构设计！

在SaaS产品平台，本质上是多租户订阅使用的服务模式，因此在技术架构实现层面，需要对不同租户的数据库存储（甚至包括文件存放）进行隔离和划分。那具体怎么设计，既能满足前期快速MVP版本迭代，又能符合未来更多客户、更多海量数据增长而不是系统崩溃卡顿呢？

从2017年研发果创云PaaS低代码接口开发平台开始，在对不同开发者、不同应用、不同服务客户的数据，我们已经有一套很完善的数据存储、数据库变更、数据迁移、数据清理和释放体系。所以，在经历从几个开发者用户到几万个开发者用户，从一开始几十张表到现在十几万张表和几十万个表字段，乃至从最初几百条数据到现在已经在过亿条数据存储，我们PaaS平台都做到了很低的维护、很高效的交付速度和极高的API响应速度（平均在100ms以内）。

当然，SaaS产品和PaaS平台，又有些区别。SaaS产品更多是面向直接的使用用户、不懂技术的用户、直接开通账号，然后按订阅的方式就可以使用产品功能，解决他们在特定业务场景的软件需求，例如：招聘、项目管理、ERP、客户管理、营销推广等。

下面，结合过往我们在PaaS平台以及目前正在设计的YesDev SaaS研发协同工具产品，一起来给技术负责人、老板介绍一下，怎么设计SaaS数据库才不会掉坑。

简单来说，SaaS数据库设计是由技术人员实现的具体存储方案。

但如果作为老板或者技术负责人，没有规范好和提前了解清楚技术实现的思路和方案，到后期发现有不合理再去调整就会成本非常大。

对于SaaS数据库的设计，核心就是要区分好每个租户、每个团队、每个用户的数据。在数据库技术层面的体现就是在数据库、数据库表、数据库表字体上的设计和实现。

站在SaaS平台的角度去俯视，就是要把每个租户的数据清晰划分出来，做到“高内聚、低耦合”。每个租户的数据，要高内聚，放在一起；另一方面，平台又要能容易看到汇总后的各个维度的全部租户数据。

SaaS数据库隔离有三种，从粗到细，分别是：

1、【粗】物理存储隔离方式：按整个数据库进行隔离2、【中】技术存储隔离方式：通过表前缀区分隔离3、【细】业务存储隔离方式：通过表字段划分租户数据4、【混合】混合的隔离方式

下面分别介绍，再来对比，看哪种方式更合适。

1、【粗】物理存储隔离方式：按整个数据库进行隔离

简单、粗暴、直接的方式，就是给每个开通的租户都分别创建一个数据库，单独隔离。

好处是：对于技术实现相对简单，只要在用户访问时，进行数据库的绑定和切换就可以了。数据迁移、导入导出方便。

不足是：需要给每个新租户动态创建一个数据库，并且后续随着产品版本迭代要变更追加新的数据库表很复杂、很麻烦。

2、【中】技术存储隔离方式：通过表前缀区分隔离

第2种折中的方式是，按年份月份或服务的区域进行数据库划分，然后再针对每个不同的租户通过表前缀的方式进行划分。

好处是：有同一个数据库中，可以集中进行管理和维护。

不足是：针对每个新开通的租户，依然要动态创建一系列的系统基础数据库表；后续有数据库变更，也要批量进行变更和调整。

3、【细】业务存储隔离方式：通过表字段划分租户数据

第3种就是在业务层面，通过表字段来进行区分。例如有一个app_key表示不同的企业、不同的团队、不同的客户。

好处是：数据库表结构可以只维护一份。

不足是：数据量大时会容易产生慢查询，后续客户需要迁移到私服环境，数据拆分和清理需要更多的处理工作。

4、【混合】混合的隔离方式

第4种混合模式，适用于区分存储平台数据和客户数据。尤其是当你的SaaS产品允许用户动态自定义字段时，就更加需要采用混合的隔离方式。一方面，把平台的系统表、基础表、全局数据、平台自主的数据，进行集中管理。另一方面，针对用户自定义添加的字段，进行单独隔离存储。

如前面有介绍，SaaS产品的升级迭代和服务是一个动态的过程，所以在最初构建数据库存储方案时，就要结合现有的客户以及未来的服务模式进行设计。不然，一旦成形，再来调整，就不是三天两头的事，而是伤筋动骨的大重构了。

你要考虑到SaaS客户会转移迁移到私有部署环境的数据迁移问题；你要做好底层的数据库表设计，不然技术后面就整天和你说“以前这样的数据库设计根本就不合理，现在想要扩展添加新功能，根本做不了，除非重构！”。

还要结合到具体开发的编程语言和后端技术栈，要能很好满足API接口开发、功能开发、管理后台报表查询汇总统计、定时任务、脚本工具等的配套落地开发。

原则1：尽早使用配置文件来显式维护租户的数据库存储策略

例如PHP开发语言的PhalApi开源接口框架，就可以直接通过数据库路由配置表，实现分库分表的配置。

return array(

'tables' => array(

'demo' => array(

// 表名，不带表前缀，不带分表后缀

'prefix' => '',

// 当前的表名前缀

'key' => 'id',

// 当前的表主键名

'map' => array(

// 当前的分表存储路由配置

array('db' => 'db_master'),

// 单表配置：array('db' => 服务器标记)

array('start' => 0, 'end' => 2, 'db' => 'db_master'),

// 三张分表的配置：array('start' => 开始下标, 'end' => 结束下标, 'db' => 服务器标记)

),

),

),

);

可以灵活配置数据库路由，支持分库分表，也可以支持表前缀的配置，当然也是可以支持整个数据库的切换。

数据库分库分表策略 - PhalApi 2.x 开源接口框架 开发文档

http://docs.phalapi.net/#/v2.0/database-multi

原则2：尽早封装统一的领域数据基类

每次只处理一个租户的数据，并且通过全局唯一的标识来区分不同的租户。在代码实现和UML建模时，尽量抽取和通用业务相关的字段和数据库表基类，支持租户身份的灵活切换。

尤其是在ERP、CRM、项目管理这类的系统管理工具中，尽量封装好数据库基类，减少代码的开发量和善用代码自动生成技术，可以极大提升系统的优雅性和强大性。

参考PhalApi框架推出的DataModel是比NotORMModel更新推出的数据基类，比NotORMModel功能更强大，并且开发使用更友好。

原则3：支持租户身份的灵活切换

不同的租户是有不同的数据存储位置，那么平台方在处理不同租户数据时，就要能快速进行切换。包括：代码层面的切换和鉴权、API接口和页面访问的横向鉴权、计划任务和MQ和异步通知的区分、脚本命令工具的手动指定等。

可以参考领域驱动设计的模型，从外到内，都要始终能区分租户的数据。

原则4：尽早统一维护SaaS系统的数据库完整变更记录

SaaS平台，难免会同时存在多个不同的环境，除了自己使用的开发环境、测试环境、正式环境；站在商用系统的交付维度，也会有多态环境，譬如：演示环境、正式SaaS环境、不同客户的私有部署环境、定制开发的环境、渠道版。

既然有那么多不同的环境，又有多种不同的数据存储策略，那么两者一结合，那就是乘数倍级的复杂度！

曾经就有位SaaS老板和我们说，“哎！现在很痛苦！明明昨天在开发环境还是好好的，今天在正式环境给客户一演示汇报就打不开了！！”。

后来一问，发现既没有预发布环境，又没有完整的数据库变更记录。很多时候代码发布到正式环境了，要么就是表字段忘加了，要么就是表忘建了。

多么初级和错误啊！

原则5：尽早统一业务数据语义

不同的业务字段，不同的值，在行业有不同的称呼，在不同的客户内部也有不同的理解。需要尽量针对SaaS场景服务的行业和目标客户对象，明确好每个业务字段的数据语义。

在内部、在研发团队、在外部宣传和客户沟通过程中，统一通用语言。

经验总结，就是：设计简单、调整很难。

在前期设计良好很简单，但如果一开始设计混乱，到SaaS产品发展中后期再来调整，就会成本很高、难度很大、而且很多技术人员都不喜欢维护这些烂摊子。客户也不会给内部的数据迁移、系统重构来埋单。最后痛苦的就是做SaaS产品的创业者老板。

专栏作者

黄禅宗 dogstar，果创科技创始人，YesApi果创云亿级流量PaaS平台创始人、YesDev研发协同SaaS创始人； 前唯品会高级开发工程师，千万级架构经验； 前MobVista高级工程师、前租租车技术经理； 10年以上互联网经验，对软件领域有独特见解；PhalApi开源框架作者，著有《良质!》等电子书；退役士兵，华南师范大学软件工程专业，喜欢交流分享。