多租户低代码平台数据库选择问题

[Chad0000]

按我的理解低代码产生的数据应该使用 Json 保存，所以要么使用 NoSql 要么使用支持 Json 的数据库。目前考虑有：

MySql

主要是它比较成熟，尤其是国内云平台比如阿里玩儿得很遛了。性能也可以，每个租户使用一张表，还可以根据需要将大表及时抽出独立出来（可能没必要？），私有部署则每个表单使用一张表格，大幅提升性能。

MongoDB

天生文档型数据库，主要是我没怎么用过，怕吃不了兜着走。

PostgreSQL

据说对 Json 支持得很好，同上面一样我不熟悉。

多谢各位出谋划策，先交待一下个人背景。

我十多年前就开始设计SaaS了，搞了几个商用SaaS平台在不同领域，对多租户系统还是有理解和经验的。我设计的SaaS都是TenantId方案，即共享数据库然后用租户字段隔离。我没用Schema是因为这玩意儿比较复杂，不同数据库支持程度也不一样。

而对于低代码平台，带来的挑战是用户自己可以随意设计表单，一切是动态的。这就导致本来我们可以根据功能和需求建立不同的表，但低代码这边直接给你拉平，由二维变成一维，即所有数据均保存到一张通用表中。如果租户共用，那么这张表主要内容就在Json字段中。而这个表的数量级很快就会上去：因为它放了几乎所有数据。

目前我们选数据库选型的基本原则是，尽量使用熟悉的数据库，否则再考虑更适合的。我们对MySql很熟悉，于是有如下几个方案：

方案1. 共享数据库+共享表（Json存储）

这个方案基本不行，因为这个共享表保存所有数据，很快就会突破性能和物理限制。

方案2. 共享数据库+每个租户一个表（Json存储）

这个方案较方案1有所改进，租户之间隔离也较好些，但对于大租户因为数据多还是会有性能问题。

方案3. 独立数据库+每个表单一个表（Json存储）

这个方案好处是完全隔离租户，同时每个表单也能保证性能。而且Json动态存储字段相当灵活，不用改结构。弊端是系统升级需要逐个租户进行，而且遇到极个别数量大的表单性能还是会有问题，这主要是Json带来的。

方案4. 独立数据库+每个表单一个表（创建字段）

这个方案好处较方案3是每个表都能发挥其性能，字段也方便建立索引以优化性能甚至分表。而较方案3的弊端则是维护字段要谨慎，对于数据量大的表加字段会慢。

对于其他方案比如建一张大表（4000个字段）作为元数据，或者使用EAU模型对我们来说直接略掉了，目前我们在方案3和4之间在做权衡。

同时我也看到了这篇文章，希望对同样迷惑的V友们有所帮助。

我没攻击人也没违反什么就给我降权？要么删除此帖要么转水深火热。
/t/1072723

[lecher]

多租户就应该强隔离，每个租户一个 database ，让业务数据有明确的类型定义，有利于复用数据库的各种特性，租户之间的业务差异性也更容易划分清楚。

[XiLingHost]

用 json 的话肯定是 nosql 啊，建议 mongodb 或者 elasticsearch
它们很方便做分片和复制，横向扩容能力很强，而且全文搜索性能好

[Chad0000]

@lecher
我也考虑过这种方案，但总感觉代价太大，想想如果有上万个租户，不确认数据库连接是否能跨库，也可能会导致升级变得麻烦。好处是性能会好很多。

[Chad0000]

@XiLingHost
ES 不是 DB ，我最多拿它来做搜索。MongoDB 得一票。:-)

[westoy]

选你熟的

mongodb 的高性能+高可用是需要靠超大内存机 + replication 保障的, 当然 es 也差不多, 而且 mongodb 现在的协议好像你这个业务不是很友好啊......

[cpstar]

？？
低代码就得 JSON ？多租户就得 NOSQL ？这都是啥逻辑。。。Mysql 和 PostgreSQL 都是典型的关系型数据库，mongo 则是一个典型的 kv 数据库。这几个放一起比较又是个啥逻辑。。。

代码再低，也得看你要提供的业务是什么，什么样的数据模型，有了 datamodel 才来分析到底是 RDB 还是 K-V 。然后结合多租户的所谓相对隔离，是要设计更优良的 datamodel 。
这里边数据库选型是最最后的东西，怎么就混为一谈了呢？

[WispZhan]

PostgreSQL 适合多租户

[lmshl]

我开发了 5 年多多租户 SaaS 软件，目前线上有 3000+租户在运行。我的建议是：
数据库：PostgreSQL ，你可以用 pg 的 Schema 实现逻辑隔离，同时又可以兼顾所有数据库应有的 ACID 特性，它支持跨 Schema 事务与外键，因为他的多个 Schema 都在一个 Database 中。不建议 MySQL ，因为 MySQL 的 Schema 其实相当于 PG 的 Database ，缺少中间逻辑层。

PG 支持 JSONB 的同时还支持在 JSONB 上建索引

[Chad0000]

@westoy
那就是 MySql 啦，我现在初步定了 MySql+每个租户独立数据库的方案。

@cpstar
客户完全动态定义表单列表啥的，如果共用数据库那就得用 Json ，这样最简单直接，如果独立数据库，就可以不用 Json ，这样有啥问题么？而且因为是低代码，提供的业务也是动态的由客户建立起来的，即使独立数据库有些场景还是需要用 Json 存储的，具体产品可参照简道云。

[Chad0000]

@lmshl
因为低代码的场景太动态化了，再加上对 PostgreSql 不太熟悉，不确定它能不能基于 Schema 做备份和还原。目前方案是每个租户独立的 MySql 数据库，动态创建表格。这样也方便备份和独立部署。可能升级会麻烦些。

[jack778]

如果有一万个租户,想想下要维护多少张表,可怕哦,每次升级数据库你都要重复一万次操作,确定这样好吗? 万一 Schema 之间的表结构或者元数据不同步了,感觉很头痛.

[moen]

@Chad0000 pg_dump/pg_restore 可以指定 schema

PS：pg 存 json 用 jsonb ，不要用 json 类型

[forgottencoast]

如果新手刚起步，注意我说的是新手，不要搞复杂的方案，所有业务表加一个租户 Id 就行了。
等你租户多了，赚到钱了，有钱招人了，再来考虑其他方案。

[xuanbg]

既然是多租户，那么必然是 SaaS 应用喽，那么必然单租户数据量不会太大。有辣么大体量的用户会用 SaaS ？
每个租户一个 Schema 简直就是给自己增加运维成本。

所以，一般业务，多租户的正确打开方式就是用租户 ID 字段进行标记。

[lmshl]

@Chad0000 mysql 能做的，pg 只会比它做得更好，关键是当你涉及到跨租户事务的时候，会变得很容易处理。
比如跨租户共享 /编辑数据，转移积分等等

[lmshl]

以及资源计费，多租户间成员关系，一个用户可以加入多个租户等情况。
这些跨租户，租户管理的功能，比较安全的实现方式肯定是在同一个事务里解决，那 pg 是你的最佳选择，因为他支持跨 Schema 的事务和外键。

[documentzhangx66]

1.能选 Oracle 的，请无脑 Oracle 。

2.Mysql 能撑得住的，就不要用 MongoDB 。

3.Mysql 能满足需求的，请不要用 PostgreSQL 。这玩意看着美，实际上是个烂心大苹果。不然你想想，这玩意如果真的好，为啥知名度一直没 Mysql 高？

4.不要直接用数据库，多用中间层，多用 ORM 、中间件，比如 MyBatis 、FreeSQL 之类的。这样后期单数据库换集群数据库，或者 Mysql 换 Oracle ，能方便很多。

5.数据库用于生产之前，请做好 HA 、调试、瓶颈排查、备份、恢复等问题的预案与测试。

[Chad0000]

@jack778
Schema 可能还不如用多个数据库。我设计过的 SaaS 平台都是共用数据库和表，通过 TenantId 区分的，前提是这些客户功能和表结构差不多。但低代码完全不同，每家表结构都可能完全不一样。

@forgottencoast
嗯，我已经不是新手，我十年前就开始设计 SaaS 了。那些系统我也是用租户 Id 隔离的。

@xuanbg
嗯，我很同意你说的。其他系统我也是这么设计的，只是低代码太动态了，共享表显得没意义。

@lmshl
低代码的问题是所有数据都是动态的导致它几乎没共享可言，这是跟传统 SaaS 的最大区别。普通系统你还可以建立多张表来维护，到低代码直接一个通用表，二维都压成一维了，当然你硬创建一个 4000 字段的表做元数据也不是不可以，或者说使用 Json 更为简单，但又得考虑性能和稳定性，以及现有开发人员是否足够熟悉。在我看来用 Schema 可能还不如用多库，而外键因为我们选择不在数据库设置外键也没什么影响（这个话题可以展开之前也有人讨论过，我们不在 DB 设置是因为性能和易扩展比如分表分库，在我们这边对 DB 的定位就是只负责存储数据和索引，不要做过多校验和计算）。

@documentzhangx66
你说的很有道理，Oracle 买不起也没用过，在我们这边看来 MySql8 哪怕用 Json 存储都可以撑得住的。

[blackboom]

@documentzhangx66

> 1.能选 Oracle 的，请无脑 Oracle 。
为什么？


> 2.Mysql 能撑得住的，就不要用 MongoDB 。
嗯？


> 3.Mysql 能满足需求的，请不要用 PostgreSQL 。这玩意看着美，实际上是个烂心大苹果。不然你想想，这玩意如果真的好，为啥知名度一直没 Mysql 高？
PostgreSQL 知名度还不高吗？可以预见的是 PostgreSQL 未来占比会越来越高。


回复给 @Chad0000 显然在这三项中 MySQL 和 MongoDB 可能没有 PostgreSQL 更好。


为什么？

1. 排除 MongoDB 因为 @Chad0000 不熟悉。
2. MySQL JSON 支持没有 PostgreSQL 好。
3. 引用个案例 https://github.com/supabase/supabase PostgreSQL 多租户被 supabase 玩的很溜作为佐证。

[xzysaber]

@Chad0000 ES 属于 DB ，自身除了存储索引也会存储数据，并且也在 DBrank 中存在： https://db-engines.com/en/ranking 。

[C603H6r18Q1mSP9N]

赞同
方案 4. 独立数据库+每个表单一个表（创建字段）

方便后期分离和优化，比如 saas 中其中有个用户用户量非常大、并发非常高，需要独立部署和高配置，就很好解决；

Oracle 为什么强？
我记得 10 年前，线上业务 bug ，有死循环直接访问数据库，1 个小时访问了几亿次数据，Oracle 报警了，但对其他业务没有任何影响

[Chad0000]

@blackboom
多谢提供分析和建议。

我这边是最终都不一定会采用 Json 的方案，如果使用方案 4 即动态创建表和字段，则 Json 性能差一些也没什么影响了。MongoDB 一是不熟悉二是对 Sql 及统计的支持很有限，我们同时也在考虑允许客户二次开发，这种情况下使用常见的数据库更为重要，所以还是聚焦在关系型 DB 上比较好。

回到 PostgreSql 上，同样我们也是不熟悉，这就会带来额外的工作量以及不确定的风险，二是国内各云商对 MySql 支持得比较多也优化得比较多，我个人在阿里云买的 1C1G 的跑了 N 多系统有的数据量还很大它还是很强，而且有开箱即用的慢 Sql 和恢复到任意时间以及只读实例等功能。这样下来的结果就是除非 MySql 的 Json 比 PostgreSql 慢一个数量级我们才有可能考虑。何况要不要用 Json 我们还没最终拍板，很有可能只用它来保存表单配置以及涉及到工作流的部分。

[Chad0000]

@xzysaber
ES 我只会用它来做搜索哈，不会真正拿它当 DB 用。我在电商系统里用它来搜索商品，偶尔还遇到全部丢失无法查询需要全刷一遍的问题，这种如果发生在 DB 里是会挨揍的[doge]。

[jjx]

postgresql 很适合企业应用

复杂查询(自子查询,表链接)等场景, 性能表现远超 mysql, 当前有测试我们自身的业务表现

至于 mysql 的确当前选择的很多, 但看看他们的一些要求

* 不用外键
* 不用表链接 等等

就知道对于企业应用软件场景根本就不适合

简单的如进销存 erp 软件,每报表必须有合计和小计, 查询条件多且多遍, 直接把一些互联网应用投机取巧的优化给打回去

不得不老老实实的依赖数据库本身的表现

[joesonw]

低代码的 json 需要检索吗？不然不就是 string 吗？

[Chad0000]

@jjx
目前很多低代码平台还在用 MongoDB 呢，关联查询更是要命更别说报表了。

目前来说都是关系型数据库，真遇到问题或瓶颈，迁移起来也容易些。像报表这种，前期直接查，再慢就提前准备数据，再不行就把数据同步到 BI 平台，让专业的人去做专业的事情可能更好。

另外求助，有哪里可以看到详细地对比么，尤其是实测？我查了一些不是很全，我自己的体验是电商数据库从 Sql Server 切换到 MySql ，性能也没有明显变化。

[Chad0000]

@joesonw 不止检索还有可能要分析统计。

[joesonw]

复杂的 json 检索还是放 MongoDB 好一点。统计分析这些不想用 MongoDB ，可以 ETL 倒入到适合分析的数据库嘛，没必要强行放一块。

[yinshen]

@cpstar manggo 不是单纯的 kv

[lmshl]

@Chad0000
关于 pg 的跨租户外键和事务，我的态度是：“我可以不用，你不能没有”
确实你“物料库”里的数据是无需事务与外键的，但你的物料创建关系，以及用户，资产还是免不了需要事务机制。
我司从去年也在把现在的 SaaS 多租户平台往低代码上升级，实际上我们做的事是很高度相似的，元数据管理，用户自定义动态字段，规则引擎等等

[adoal]

很难理解为什么同一个人会针对同一个场景既提倡 Oracle 又以提倡 MySQL 为保底反对 PostgreSQL…论起能力来 O 和 P 的相似性很高，M 几乎都不是一个物种。

[dbpe]

@adoal 可能因为 pg 是新鲜事物吧。。。

[murmur]

低代码 mongo 你是坑死个人，现在的低代码都有自动建模功能

[victorc]

肯定要用 mysql

1.是大家都熟悉，技术门槛低
2.不要选文档数据库，传统数据库有 scheme 约束，对代码质量，可维护性都是一个保障


这事不好解决，没有完美方法，我做的 saas ，最开始也是用一个租户字段进行区分，行级别隔离，后面市场规模扩大，有些大客户要求独占，又开始来拆分，几乎要全部重构


但是一开始就搞一个租户一个 db ，也是很难决策的，因为成本很高，没有人能保证项目一定能成功

[siaronwang]

postgresql + schema 隔离 +1

[documentzhangx66]

@blackboom

1.因为 Oracle 是地球上最强的数据库，而且还不止数据库。


2.你可能不了解 MongoDB 的黑历史，建议去了解一下。比如丢数据的黑历史。


3.建议先去了解一下这两款数据库的历史，关键字：Release history 。你在这方面有知识盲区。


4.MySQL 和 MongoDB 可能没有 PostgreSQL 好？？？？

虽然在我眼里，Mysql 、MongoDB 、PostgreSQL 都是垃圾，但这 3 个垃圾相互比较：

Mysql 在被收购前后，都很努力。至少没有出现过，像 PostgreSQL 作者那样耍无知，觉得内存表完全不需要，由 OS 去管理就好的傻子言论。还记得比尔盖茨曾经说，多少 KB 的内存就能满足人类使用嘛？

MongoDB ，你去翻它的黑历史，以奸商的出发点去做数据库，能做的好？只是那阵子被大佬扒光了，近几年稍微收敛了一点。但从商业模式来看，后面肯定还会作妖。ps.这结论不是我看出来的，是某商业大佬带团做背调后发现的。

PostgreSQL ，我根本不想评价。前几天有个 .Net 团队大佬，打算从 Mysql 换 PostgreSQL ，对它做可行性分析。我一开始就告诉他，别浪费时间，他不信。调研了一周后，他也郁闷了，而且某些关系型数据库的核心功能，居然至今还是缺失。


5.另外你提 json ，我是建议楼主，先试试中间件。其他主流 ORM 如果楼主不会用，我建议他试试 FreeSQL 也行。FreeSQL 的作者，无论技术实力，还是对大家提问的热情度，让我觉得 FreeSQL 能够高质量地稳定发展下去。


6.多租户，只是一种业务模式，与用什么数据库有啥关系。这问题好比是：是否只有 Java 才有 OO ，汇编与 C 就没 OO ？

[documentzhangx66]

@Chad0000

买不起没关系，白嫖就完事了。让 Oracle 在纯内网环境下跑，不让它访问外网。

想要稳一点，找个第三方 Oracle 运维公司，花点小钱，让他们帮你们做做架构，买个自动化运维脚本，再送你们最新补丁。

[lecher]

@Chad0000
跨库的业务操作应该显式写集成业务，这种集成业务是隐藏不掉的，应该让这类的业务归纳入版本管理中，至于跨租户的数据集成问题，可以考虑引入其它 OLTP 数据库来支持集成。

升级的问题同理，变更是很难通过自适应的业务流程计算出 diff 并升级的，应该让开发讲升级 /降级的变更写成迁移脚本，归纳入版本管理中随代码迭代。
升级无法进行版本管理并自动化，会让新业务的上线变得更加困难，需要支持按租户区分功能开关的形式，业务代码可以随时灰度上线。隔离好变更的影响范围。

[3dwelcome]

投 mysql 一票，没别的原因，就是国内用的人最多最火。

如果是我写低代码平台，应该会用 leveldb 之类的 kv 数据库，但是不推荐大家用。一是查询需要全部自己建索引额外处理，二是 nosql 也是需要实际经验的，没经验还不如用 mysql 实在。

[Chad0000]

@documentzhangx66 #37
Oracle 同样我们也不熟悉哈，像这种新产品如果熟悉的 DB 能搞定性能没太大影响的话，肯定是先用熟悉的来，所以是 MySql 了。FreeSql 我会去看看，之前就 Star 他们了。

@lecher #38
你的思路是对的，而且之前我们的 SaaS 平台是先更新表（没有 Not Null 约束），再更新系统。而你的按租户设定开关，则会让升级变得更平滑，更适合这种无法短时完成升级的平台。而且私有化部署的升级也需要我们准备这些。

[Chad0000]

@3dwelcome
我之前搞新系统为了高性能直接上 NoSql ，步子迈太大结果差点蹦了，现在对于新项目，没有足够的理由我也是不太想换数据库。

[lecher]

https://www.v2ex.com/t/850237#r_11620231
https://www.v2ex.com/t/850237#r_11622092

纵上，如果不考虑历史包袱，我认为多租户系统需要考虑这几个问题。
1. 商户之间的资源可以隔离
2. 部署版本的影响范围可控，可自动化
3. 能复用上基本的数据库特性，如索引
4. 最好支持私有化部署
5. 跨租户的业务集成方案

所以数据库层面：
按租户分 database
一个租户的数据，尽可能落在一个 database 中，而不是随着不同的微服务分散在不同服务的 database 上。

服务部署
按版本部署，力求业务代码仅提供计算能力，一个租户可以自由地在兼容的两个版本中来回切换

请求路由
按租户的 tenantId 区分，力求能够根据每一个 tenantId 提供一个路由表声明，实现不同 tenantId 转发到不同的基础设施上。如 tenantId.mysql.local.svc 指向不同的 mysql 实例

开发约定上
按分布式系统来考虑实现方案，如 id 不能用自增，而是生成线性有序的唯一 id ，业务不能假定都能在一个事务中提交，而是可以分阶段，支持幂等等
禁止破坏性的变更，至少应该让两个版本之间可平滑过渡，为对应的功能增加合适的开关，这个开关也属于租户的业务数据，落到租户的 database 中。

至此 CI/CD 才能实现随时上线，按需开启。

[Chad0000]

@lecher #42
感谢，你上面给的方案已经很详细了。

其中根据 TenantId 做路由我倒是有想，但把 MySql 实例也用类似方式表达有点担心连接资源是不是会占用太多？我想的是加在数据库实例名称中，比如 ABC_TenantId 这样，一般租户共用数据库连接资源，特殊租户有独立的数据库实例，在同样是在应用入口做转发。

同时部署两个版本也是我没设想的，我设想的是升级的时候两套逻辑同时支持，然后在下个版本中移除。

[lecher]

@Chad0000

如果没有多实例的需求，比如不同租户的资源需求不一样，一个连接，通过 database name 区分，复用底层数据库的连接是比较理想的。

多版本主要是为了平滑升级吧，因为多租户的迁移本身是一个较长周期的过程，最好是能按租户升级。

[hyacinthus]

@lecher 按 database 分租户，这样横向扩展估计会碰到问题，租户数几万这种估计撑不住

[AyaseEri]

我司几个低代码平台用的都是 MongoDB 。Salesforce 好像是自研 ORM + Oracle 。

[lecher]

@hyacinthus

这是资源划分的问题，分租户天然就应该可以支持分布式部署才对，无论按 database 、table 、field 做为多租户的标识，都应该要支持在入口分流到不同的实例上，按租户将负载平摊到不同的物理资源上。
实现上，只要保证一个事务的修改，能够在一个集群内执行完即可，至于不同租户是否要在一个实例内，按需拆分。

[Chad0000]

@hyacinthus #45
其实也看场景，对于企业级应用，如果有几万正式租户可能就发财了。

@AyaseEri #46
嗯，MongoDB 是低代码平台主流 DB 。我们目前的定位还是想做企业级包括可能允许深度二次开发，需要传统的关系型数据库而且后期需要支持常见关系型数据库。总不能强迫客户使用 MySql 吧，让客户在企业经营环境使用 MongoDB 也不太妥。

@lecher #47
让租户回归到自己的数据库是核心，这种模式的产品很多，比如 ES 官方的服务就是这么干的，Snowflake 也是。

[sdrzlyz]

@documentzhangx66 PG 还不如 MySQL ？还真是张嘴就来

[tomjames]

看了评论，建议可以问简道云，明道云这类公司的研发相关的人员，了解下他们的瓶劲和困惑

[documentzhangx66]

@sdrzlyz

如果你的语文不好，建议你，把我写的那一段话，大声朗读 100 次并背诵，来加深理解。然后再去想想，是不是张嘴就来。

[Chad0000]

@sdrzlyz #49
如果你能就你的观点展开讨论那就有说服力了，最好是有对比数据甚至实际案例。

@tomjames #50
直接问他们就像：Hi ，竞争对手，我想问问你们怎么设计的以及有哪些困难，最好顺便说下 RoadMap ，我们好参考一下。[doge]

[bthulu]

@documentzhangx66 能详细的讲一讲 PostgreSQL 缺少哪些核心功能吗?

[knives]

个人在用 MySQL8 和 PG 上存 JSON 有小规模生产实践，和 SAAS 这类场景相比算是玩具水平吧。就个人实践来说，存 JSON 字段这种用法还是在 PG 上稍微舒服一些。

主要在 PG 对数据字段长度的限制很宽松，可以直接在各种大长度字段建立索引，没做多少参数调整跑起来也没遇到什么问题。相对的 MySQL 在 JSON 字段上建立索引需要先建立虚拟列，还存在索引长度限制；最近生产环境还出现了 sort_buffer_size 不足的问题（临时增大了配置解决，疑似 MySQL 的 BUG ，https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html ）。

[Huelse]

@sdrzlyz #48 之前在推特上看到一个甲骨文 mysql 的维护者说 mysql 的部分代码就像一坨屎，不如 PostgreSQL

[Huelse]

具体可以看这篇文章

https://www.theregister.com/2021/12/06/mysql_a_pretty_poor_database/

[zlo309618100]

其实核心是需要支持租户自定义字段+自定义的业务实体
所以从隔离层次上来说,可以设计为实体,字段两个维度
然后落地到存储维度,其实要解决的是查询+数据存取两个问题
查询可以用 es,存储可以选择可扩展的列数据库.
方便,大家可以交流一下想法.

[Chad0000]

@knives #54
嗯，Json 操作方面 MySql 确实逊一些。方案 4 已经排除掉 Json 了，尽量使用数据库本身的特性，所以影响就小了。PG 长度没限制确实是个优势，但用户少也是劣势。目前项目在考虑要支持二次开发，这时别说 MySql 了，可能常见的 Oracle 和 SqlServer 都得支持。如果是这样那么就尽量少用数据库特有的，尽量使用都支持的特性。

@Huelse #56
那个 MySql 代码垃圾的说法我也看到过，怎么说呢，JS 也垃圾，也不能阻止它很热能写出有用的东西出来。只要用的人多，研究的人多，就不缺方案。

@zlo309618100 #57
考虑过查询用 ES ，但一来它有时差，二来企业内部数据又不是量特别大非得用 ES ，强上可能得不偿失。目前的想法是用 ES 在全库搜索上，这样可以快速检索客户要的数据而不是去一个个页面里找。

对列数据库熟悉的 V 友可以展开讨论，如果很适合这种场景，重点考虑它也无妨。

[zlo309618100]

@Chad0000 如果是 saas 产品的话,业务上还是要关注用户的续约.
如果不搞融资,上市,其实专注于小而美的独立领域,能够让自己活的滋润.
个人感觉其实单体+mysql 也能玩的转.最多抽离出来 1 套单独的元数据库,然后根据租户来分表.
在分库和分表的设计上耦合设计一定做好就 OK 了.
产品的链接可以放出来观摩一下么.

[Chad0000]

@zlo309618100 #59
还在立项阶段，不是私人项目，是在跟投资人谈。希望有朝一日我能把产品链接放出来吧，嘿嘿。

[twing37]

https://www.infoq.cn/article/rwstpgujoxxuw9tlm88t 元数据驱动下的多租户架构 saleforce.

rds

[Chad0000]

@twing37 #61
之前也有说过元数据，这个是讲得比较多的。简单讲就是在数据库上实现了一个数据库，在现在可能更适合使用 Json 这么搞。整 1000 个表每个表存 Json ，然后根据用户对表单的定义将 Json 放入不同的表。数据库也能做到只更新 Json 某个字段。但这么整心智比较累，做这么多也只是做了一个数据库的功能还不一定比现有数据库好用。至于直接使用数据库，也是可以做到运行两个版本，新版上线逐个升级租户，不允许直接删除字段即可。也不会有太大篓子。

[documentzhangx66]

@bthulu

1.没有内存表。

2.大写是个坑。

3.易用性不如 MYSQL 。

4.没有 SHOW CREATE TABLE / SHOW TABLES / SHOW DATABASE / SHOW VARIABLES 等方法，对开发、运维与 DBA 很不友好。

5.PG 没有真正的 聚集索引 / 聚束索引 / CLUSTERED INDEX 。

6.资源少，解决方案少，连监控方案都很费劲。

7.事务遇到客户端冲突时会有丢数据的 Bug 。

[debuggerx]

《 SaaS 行业需要什么样的数据库-阿里云数据库专家德哥》：
https://www.bilibili.com/video/BV1zv41157vd
从 15 分钟开始看完就差不多了。

[MoYi123]

@debuggerx 没看视频, 但我猜德哥肯定狂吹 pg

[PopRain]

@documentzhangx66 postgresql 是小写吧，oracle 、firebird 等大部分才是大写

[Chad0000]

@MoYi123 #65
我看了那个，他的场景是固定行业 SaaS ，不是低代码 SaaS ，只是有一定参考价值

@debuggerx #64
感谢分享，如果是纯低代码或无代码 SaaS 就更好了。

[documentzhangx66]

@PopRain

意思是 PostgreSQL 的大写有坑。百度：PostgreSQL 大写

[ychost]

MySQL + 一票，能不用 MongoDB 就不用（坑一抹多，用来存用户评论 /日志等不重要的数据比较合适）核心数据还是建议用关系型数据库，当然如果有条件优先考虑 Oracle/SQL Server

[PopRain]

@documentzhangx66 据我所知只有 SQL Server ,My Sql 才可以表、字段命名用大小写（驼峰命名）且大小写不敏感，其它数据库要么自动转为大写(SQL 标准，oracle)要么自动转为小写(postgresql) ，如果要保留大小写则用引号引起来，这样后果就是大小写敏感了，拼写必须写对。（所以这些数据库一般用蛇形命名）