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

[Chad0000]

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

MySql

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

MongoDB

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

PostgreSQL

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

[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 。