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

[Chad0000]

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

MySql

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

MongoDB

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

PostgreSQL

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

[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
还在立项阶段，不是私人项目，是在跟投资人谈。希望有朝一日我能把产品链接放出来吧，嘿嘿。