首页科学探索SaaS创业:这一篇文章让你搞懂SaaS产品的数据库架构设计!
46682

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

我要新鲜事2023-05-14 01:30:490

在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开源框架作者,著有《良质!》等电子书;退役士兵,华南师范大学软件工程专业,喜欢交流分享。

0000
评论列表
共(0)条