SaaS 行业垂直数据库需求 5 点思考:成本、计费、库表量、多云、低代码
撰文|宇婷
宇婷收到某大厂的读者来信,是关于 SaaS 行业垂直数据库的思考。这里为你转述。
传统的 Oracle、阿里云、SQLServer 或者 AWS 数据库是面对软件而设计。但是 SaaS 创业公司对数据库使用,有自己的诉求。
Htap 数据库是一个通用场景,几乎可以覆盖所有行业所有场景,类似 OceanBase;但也有一些场景是 saas 特有的,比如
1,saas 比 software 的获客成本更低,客单价更低,因此用不起太昂贵的数据库,需要低于 10 元/月/租户的起步价
2,也正是因为 saas 的客单价低,租户变多,导致数据库的库表数量非常多(百万级),传统的数据库很少有超过 1 万张表
3,随着时间的积累,数据越来越多,一个租户的应用最早可能用单体的数据库就够了,现在需要升级到分布式数据库,甚至要用 HTAP 数据库,在这个升级的过程中,能不能做到完全自动,不需要租户停机维护,不需要 saas 厂商做数据库迁移,而是由云数据库根据数据规模、负载高低自动完成升级,按实际的资源消耗进行计费,整个过程对业务无感
4,saas 需要能够在任何一朵云上部署,不被云 lock-in,因此需要数据库也能够(开源的通用的数据库在各个云上都有,但满足上述条件又能在各个云上部署的数据库,有点难)
5,还有一个新方向,是低代码系统,aPaaS,比较典型的场景是:频繁的 DDL,希望秒级完成且不影响业务。(现在的数据库都支持的并不好)
传统的数据库表结构是由软件的开发者来定义,因此如果软件不更新,表结构是不会变的。但低代码系统里面,软件的设计、表结构的设计都是由终端用户来维护,可能随时修改,并且改了之后希望立马生效,这个操作对应数据库里面的 DDL,现在频率加大了,还希望可以立即生效,不影响业务,对数据库挑战非常大。
有些 aPaaS 系统为了规避 DDL,就在数据库之上做了一套自己的逻辑,但会增加系统的复杂度(比如 Salesforce 用 Oracle 的时候存的是一张大宽表),并且我认为不是一个特别好的做法。现在随着提供 saas/低代码服务的公司越来越多,相应需求也可能产生。
版权声明: 本文为 InfoQ 作者【B Impact】的原创文章。
原文链接:【http://xie.infoq.cn/article/a90a08d79cf90c9b175a240c0】。文章转载请联系作者。
评论