V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Chad0000
V2EX  ›  数据库

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

  •  
  •   Chad0000 · 2022-04-30 18:33:39 +08:00 · 4756 次点击
    这是一个创建于 698 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    MySql

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

    MongoDB

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

    PostgreSQL

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

    第 1 条附言  ·  2022-05-01 07:04:57 +08:00

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

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

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

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

    方案1. 共享数据库+共享表(Json存储)

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

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

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

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

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

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

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

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

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

    70 条回复    2022-05-04 11:24:44 +08:00
    lecher
        1
    lecher  
       2022-04-30 18:46:42 +08:00
    多租户就应该强隔离,每个租户一个 database ,让业务数据有明确的类型定义,有利于复用数据库的各种特性,租户之间的业务差异性也更容易划分清楚。
    XiLingHost
        2
    XiLingHost  
       2022-04-30 18:54:26 +08:00
    用 json 的话肯定是 nosql 啊,建议 mongodb 或者 elasticsearch
    它们很方便做分片和复制,横向扩容能力很强,而且全文搜索性能好
    Chad0000
        3
    Chad0000  
    OP
       2022-04-30 19:01:13 +08:00
    @lecher
    我也考虑过这种方案,但总感觉代价太大,想想如果有上万个租户,不确认数据库连接是否能跨库,也可能会导致升级变得麻烦。好处是性能会好很多。
    Chad0000
        4
    Chad0000  
    OP
       2022-04-30 19:02:18 +08:00
    @XiLingHost
    ES 不是 DB ,我最多拿它来做搜索。MongoDB 得一票。:-)
    westoy
        5
    westoy  
       2022-04-30 19:20:23 +08:00
    选你熟的

    mongodb 的高性能+高可用是需要靠超大内存机 + replication 保障的, 当然 es 也差不多, 而且 mongodb 现在的协议好像你这个业务不是很友好啊......
    cpstar
        6
    cpstar  
       2022-04-30 19:23:14 +08:00   ❤️ 1
    ??
    低代码就得 JSON ?多租户就得 NOSQL ?这都是啥逻辑。。。Mysql 和 PostgreSQL 都是典型的关系型数据库,mongo 则是一个典型的 kv 数据库。这几个放一起比较又是个啥逻辑。。。

    代码再低,也得看你要提供的业务是什么,什么样的数据模型,有了 datamodel 才来分析到底是 RDB 还是 K-V 。然后结合多租户的所谓相对隔离,是要设计更优良的 datamodel 。
    这里边数据库选型是最最后的东西,怎么就混为一谈了呢?
    WispZhan
        7
    WispZhan  
       2022-04-30 19:43:02 +08:00 via Android
    PostgreSQL 适合多租户
    lmshl
        8
    lmshl  
       2022-04-30 19:57:16 +08:00   ❤️ 4
    我开发了 5 年多多租户 SaaS 软件,目前线上有 3000+租户在运行。我的建议是:
    数据库:PostgreSQL ,你可以用 pg 的 Schema 实现逻辑隔离,同时又可以兼顾所有数据库应有的 ACID 特性,它支持跨 Schema 事务与外键,因为他的多个 Schema 都在一个 Database 中。不建议 MySQL ,因为 MySQL 的 Schema 其实相当于 PG 的 Database ,缺少中间逻辑层。

    PG 支持 JSONB 的同时还支持在 JSONB 上建索引
    Chad0000
        9
    Chad0000  
    OP
       2022-04-30 20:02:31 +08:00
    @westoy
    那就是 MySql 啦,我现在初步定了 MySql+每个租户独立数据库的方案。

    @cpstar
    客户完全动态定义表单列表啥的,如果共用数据库那就得用 Json ,这样最简单直接,如果独立数据库,就可以不用 Json ,这样有啥问题么?而且因为是低代码,提供的业务也是动态的由客户建立起来的,即使独立数据库有些场景还是需要用 Json 存储的,具体产品可参照简道云。
    Chad0000
        10
    Chad0000  
    OP
       2022-04-30 20:13:00 +08:00
    @lmshl
    因为低代码的场景太动态化了,再加上对 PostgreSql 不太熟悉,不确定它能不能基于 Schema 做备份和还原。目前方案是每个租户独立的 MySql 数据库,动态创建表格。这样也方便备份和独立部署。可能升级会麻烦些。
    jack778
        11
    jack778  
       2022-04-30 20:56:06 +08:00
    如果有一万个租户,想想下要维护多少张表,可怕哦,每次升级数据库你都要重复一万次操作,确定这样好吗? 万一 Schema 之间的表结构或者元数据不同步了,感觉很头痛.
    moen
        12
    moen  
       2022-04-30 21:28:58 +08:00   ❤️ 1
    @Chad0000 pg_dump/pg_restore 可以指定 schema

    PS:pg 存 json 用 jsonb ,不要用 json 类型
    forgottencoast
        13
    forgottencoast  
       2022-04-30 21:45:32 +08:00   ❤️ 2
    如果新手刚起步,注意我说的是新手,不要搞复杂的方案,所有业务表加一个租户 Id 就行了。
    等你租户多了,赚到钱了,有钱招人了,再来考虑其他方案。
    xuanbg
        14
    xuanbg  
       2022-04-30 22:08:58 +08:00
    既然是多租户,那么必然是 SaaS 应用喽,那么必然单租户数据量不会太大。有辣么大体量的用户会用 SaaS ?
    每个租户一个 Schema 简直就是给自己增加运维成本。

    所以,一般业务,多租户的正确打开方式就是用租户 ID 字段进行标记。
    lmshl
        15
    lmshl  
       2022-04-30 22:14:20 +08:00   ❤️ 1
    @Chad0000 mysql 能做的,pg 只会比它做得更好,关键是当你涉及到跨租户事务的时候,会变得很容易处理。
    比如跨租户共享 /编辑数据,转移积分等等
    lmshl
        16
    lmshl  
       2022-04-30 22:37:48 +08:00
    以及资源计费,多租户间成员关系,一个用户可以加入多个租户等情况。
    这些跨租户,租户管理的功能,比较安全的实现方式肯定是在同一个事务里解决,那 pg 是你的最佳选择,因为他支持跨 Schema 的事务和外键。
    documentzhangx66
        17
    documentzhangx66  
       2022-04-30 23:00:48 +08:00   ❤️ 1
    1.能选 Oracle 的,请无脑 Oracle 。

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

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

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

    5.数据库用于生产之前,请做好 HA 、调试、瓶颈排查、备份、恢复等问题的预案与测试。
    Chad0000
        18
    Chad0000  
    OP
       2022-05-01 06:24:03 +08:00
    @jack778
    Schema 可能还不如用多个数据库。我设计过的 SaaS 平台都是共用数据库和表,通过 TenantId 区分的,前提是这些客户功能和表结构差不多。但低代码完全不同,每家表结构都可能完全不一样。

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

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

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

    @documentzhangx66
    你说的很有道理,Oracle 买不起也没用过,在我们这边看来 MySql8 哪怕用 Json 存储都可以撑得住的。
    blackboom
        19
    blackboom  
       2022-05-01 07:30:57 +08:00   ❤️ 1
    @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
        20
    xzysaber  
       2022-05-01 09:12:12 +08:00
    @Chad0000 ES 属于 DB ,自身除了存储索引也会存储数据,并且也在 DBrank 中存在: https://db-engines.com/en/ranking
    shanghai1998
        21
    shanghai1998  
       2022-05-01 09:16:28 +08:00
    赞同
    方案 4. 独立数据库+每个表单一个表(创建字段)

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

    Oracle 为什么强?
    我记得 10 年前,线上业务 bug ,有死循环直接访问数据库,1 个小时访问了几亿次数据,Oracle 报警了,但对其他业务没有任何影响
    Chad0000
        22
    Chad0000  
    OP
       2022-05-01 09:24:36 +08:00
    @blackboom
    多谢提供分析和建议。

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

    回到 PostgreSql 上,同样我们也是不熟悉,这就会带来额外的工作量以及不确定的风险,二是国内各云商对 MySql 支持得比较多也优化得比较多,我个人在阿里云买的 1C1G 的跑了 N 多系统有的数据量还很大它还是很强,而且有开箱即用的慢 Sql 和恢复到任意时间以及只读实例等功能。这样下来的结果就是除非 MySql 的 Json 比 PostgreSql 慢一个数量级我们才有可能考虑。何况要不要用 Json 我们还没最终拍板,很有可能只用它来保存表单配置以及涉及到工作流的部分。
    Chad0000
        23
    Chad0000  
    OP
       2022-05-01 09:27:35 +08:00
    @xzysaber
    ES 我只会用它来做搜索哈,不会真正拿它当 DB 用。我在电商系统里用它来搜索商品,偶尔还遇到全部丢失无法查询需要全刷一遍的问题,这种如果发生在 DB 里是会挨揍的[doge]。
    jjx
        24
    jjx  
       2022-05-01 09:31:00 +08:00
    postgresql 很适合企业应用

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

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

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

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

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

    不得不老老实实的依赖数据库本身的表现
    joesonw
        25
    joesonw  
       2022-05-01 09:49:28 +08:00 via iPhone
    低代码的 json 需要检索吗?不然不就是 string 吗?
    Chad0000
        26
    Chad0000  
    OP
       2022-05-01 09:57:30 +08:00
    @jjx
    目前很多低代码平台还在用 MongoDB 呢,关联查询更是要命更别说报表了。

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

    另外求助,有哪里可以看到详细地对比么,尤其是实测?我查了一些不是很全,我自己的体验是电商数据库从 Sql Server 切换到 MySql ,性能也没有明显变化。
    Chad0000
        27
    Chad0000  
    OP
       2022-05-01 09:59:26 +08:00
    @joesonw 不止检索还有可能要分析统计。
    joesonw
        28
    joesonw  
       2022-05-01 10:33:17 +08:00 via iPhone
    复杂的 json 检索还是放 MongoDB 好一点。统计分析这些不想用 MongoDB ,可以 ETL 倒入到适合分析的数据库嘛,没必要强行放一块。
    yinshen
        29
    yinshen  
       2022-05-01 10:42:29 +08:00
    @cpstar manggo 不是单纯的 kv
    lmshl
        30
    lmshl  
       2022-05-01 12:10:48 +08:00
    @Chad0000
    关于 pg 的跨租户外键和事务,我的态度是:“我可以不用,你不能没有”
    确实你“物料库”里的数据是无需事务与外键的,但你的物料创建关系,以及用户,资产还是免不了需要事务机制。
    我司从去年也在把现在的 SaaS 多租户平台往低代码上升级,实际上我们做的事是很高度相似的,元数据管理,用户自定义动态字段,规则引擎等等
    adoal
        31
    adoal  
       2022-05-01 13:14:42 +08:00 via iPhone
    很难理解为什么同一个人会针对同一个场景既提倡 Oracle 又以提倡 MySQL 为保底反对 PostgreSQL…论起能力来 O 和 P 的相似性很高,M 几乎都不是一个物种。
    dbpe
        32
    dbpe  
       2022-05-01 13:22:05 +08:00
    @adoal 可能因为 pg 是新鲜事物吧。。。
    murmur
        33
    murmur  
       2022-05-01 14:23:23 +08:00
    低代码 mongo 你是坑死个人,现在的低代码都有自动建模功能
    victorc
        34
    victorc  
       2022-05-01 15:37:53 +08:00
    肯定要用 mysql

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


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


    但是一开始就搞一个租户一个 db ,也是很难决策的,因为成本很高,没有人能保证项目一定能成功
    siaronwang
        35
    siaronwang  
       2022-05-01 16:01:49 +08:00 via iPhone
    postgresql + schema 隔离 +1
    documentzhangx66
        36
    documentzhangx66  
       2022-05-01 18:03:38 +08:00
    @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
        37
    documentzhangx66  
       2022-05-01 18:07:10 +08:00
    @Chad0000

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

    想要稳一点,找个第三方 Oracle 运维公司,花点小钱,让他们帮你们做做架构,买个自动化运维脚本,再送你们最新补丁。
    lecher
        38
    lecher  
       2022-05-01 18:50:54 +08:00
    @Chad0000
    跨库的业务操作应该显式写集成业务,这种集成业务是隐藏不掉的,应该让这类的业务归纳入版本管理中,至于跨租户的数据集成问题,可以考虑引入其它 OLTP 数据库来支持集成。

    升级的问题同理,变更是很难通过自适应的业务流程计算出 diff 并升级的,应该让开发讲升级 /降级的变更写成迁移脚本,归纳入版本管理中随代码迭代。
    升级无法进行版本管理并自动化,会让新业务的上线变得更加困难,需要支持按租户区分功能开关的形式,业务代码可以随时灰度上线。隔离好变更的影响范围。
    3dwelcome
        39
    3dwelcome  
       2022-05-01 19:09:53 +08:00
    投 mysql 一票,没别的原因,就是国内用的人最多最火。

    如果是我写低代码平台,应该会用 leveldb 之类的 kv 数据库,但是不推荐大家用。一是查询需要全部自己建索引额外处理,二是 nosql 也是需要实际经验的,没经验还不如用 mysql 实在。
    Chad0000
        40
    Chad0000  
    OP
       2022-05-01 19:13:13 +08:00
    @documentzhangx66 #37
    Oracle 同样我们也不熟悉哈,像这种新产品如果熟悉的 DB 能搞定性能没太大影响的话,肯定是先用熟悉的来,所以是 MySql 了。FreeSql 我会去看看,之前就 Star 他们了。

    @lecher #38
    你的思路是对的,而且之前我们的 SaaS 平台是先更新表(没有 Not Null 约束),再更新系统。而你的按租户设定开关,则会让升级变得更平滑,更适合这种无法短时完成升级的平台。而且私有化部署的升级也需要我们准备这些。
    Chad0000
        41
    Chad0000  
    OP
       2022-05-01 19:15:53 +08:00
    @3dwelcome
    我之前搞新系统为了高性能直接上 NoSql ,步子迈太大结果差点蹦了,现在对于新项目,没有足够的理由我也是不太想换数据库。
    lecher
        42
    lecher  
       2022-05-01 19:56:58 +08:00   ❤️ 2
    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
        43
    Chad0000  
    OP
       2022-05-01 20:10:35 +08:00
    @lecher #42
    感谢,你上面给的方案已经很详细了。

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

    同时部署两个版本也是我没设想的,我设想的是升级的时候两套逻辑同时支持,然后在下个版本中移除。
    lecher
        44
    lecher  
       2022-05-01 21:51:15 +08:00
    @Chad0000

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

    多版本主要是为了平滑升级吧,因为多租户的迁移本身是一个较长周期的过程,最好是能按租户升级。
    hyacinthus
        45
    hyacinthus  
       2022-05-01 22:49:28 +08:00
    @lecher 按 database 分租户,这样横向扩展估计会碰到问题,租户数几万这种估计撑不住
    AyaseEri
        46
    AyaseEri  
       2022-05-01 23:35:36 +08:00
    我司几个低代码平台用的都是 MongoDB 。Salesforce 好像是自研 ORM + Oracle 。
    lecher
        47
    lecher  
       2022-05-02 00:40:07 +08:00
    @hyacinthus

    这是资源划分的问题,分租户天然就应该可以支持分布式部署才对,无论按 database 、table 、field 做为多租户的标识,都应该要支持在入口分流到不同的实例上,按租户将负载平摊到不同的物理资源上。
    实现上,只要保证一个事务的修改,能够在一个集群内执行完即可,至于不同租户是否要在一个实例内,按需拆分。
    Chad0000
        48
    Chad0000  
    OP
       2022-05-02 05:30:23 +08:00
    @hyacinthus #45
    其实也看场景,对于企业级应用,如果有几万正式租户可能就发财了。

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

    @lecher #47
    让租户回归到自己的数据库是核心,这种模式的产品很多,比如 ES 官方的服务就是这么干的,Snowflake 也是。
    sdrzlyz
        49
    sdrzlyz  
       2022-05-02 07:30:45 +08:00 via iPhone
    @documentzhangx66 PG 还不如 MySQL ?还真是张嘴就来
    tomjames
        50
    tomjames  
       2022-05-02 08:43:33 +08:00 via iPhone
    看了评论,建议可以问简道云,明道云这类公司的研发相关的人员,了解下他们的瓶劲和困惑
    documentzhangx66
        51
    documentzhangx66  
       2022-05-02 08:45:11 +08:00
    @sdrzlyz

    如果你的语文不好,建议你,把我写的那一段话,大声朗读 100 次并背诵,来加深理解。然后再去想想,是不是张嘴就来。
    Chad0000
        52
    Chad0000  
    OP
       2022-05-02 08:48:59 +08:00
    @sdrzlyz #49
    如果你能就你的观点展开讨论那就有说服力了,最好是有对比数据甚至实际案例。

    @tomjames #50
    直接问他们就像:Hi ,竞争对手,我想问问你们怎么设计的以及有哪些困难,最好顺便说下 RoadMap ,我们好参考一下。[doge]
    bthulu
        53
    bthulu  
       2022-05-02 11:14:09 +08:00
    @documentzhangx66 能详细的讲一讲 PostgreSQL 缺少哪些核心功能吗?
    knives
        54
    knives  
       2022-05-02 12:06:30 +08:00
    个人在用 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
        55
    Huelse  
       2022-05-02 12:20:44 +08:00
    @sdrzlyz #48 之前在推特上看到一个甲骨文 mysql 的维护者说 mysql 的部分代码就像一坨屎,不如 PostgreSQL
    Huelse
        56
    Huelse  
       2022-05-02 12:28:15 +08:00
    zlo309618100
        57
    zlo309618100  
       2022-05-02 12:55:51 +08:00
    其实核心是需要支持租户自定义字段+自定义的业务实体
    所以从隔离层次上来说,可以设计为实体,字段两个维度
    然后落地到存储维度,其实要解决的是查询+数据存取两个问题
    查询可以用 es,存储可以选择可扩展的列数据库.
    方便,大家可以交流一下想法.
    Chad0000
        58
    Chad0000  
    OP
       2022-05-02 13:09:37 +08:00
    @knives #54
    嗯,Json 操作方面 MySql 确实逊一些。方案 4 已经排除掉 Json 了,尽量使用数据库本身的特性,所以影响就小了。PG 长度没限制确实是个优势,但用户少也是劣势。目前项目在考虑要支持二次开发,这时别说 MySql 了,可能常见的 Oracle 和 SqlServer 都得支持。如果是这样那么就尽量少用数据库特有的,尽量使用都支持的特性。

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

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

    对列数据库熟悉的 V 友可以展开讨论,如果很适合这种场景,重点考虑它也无妨。
    zlo309618100
        59
    zlo309618100  
       2022-05-02 14:35:42 +08:00
    @Chad0000 如果是 saas 产品的话,业务上还是要关注用户的续约.
    如果不搞融资,上市,其实专注于小而美的独立领域,能够让自己活的滋润.
    个人感觉其实单体+mysql 也能玩的转.最多抽离出来 1 套单独的元数据库,然后根据租户来分表.
    在分库和分表的设计上耦合设计一定做好就 OK 了.
    产品的链接可以放出来观摩一下么.
    Chad0000
        60
    Chad0000  
    OP
       2022-05-02 14:40:07 +08:00
    @zlo309618100 #59
    还在立项阶段,不是私人项目,是在跟投资人谈。希望有朝一日我能把产品链接放出来吧,嘿嘿。
    twing37
        61
    twing37  
       2022-05-02 14:43:36 +08:00
    https://www.infoq.cn/article/rwstpgujoxxuw9tlm88t 元数据驱动下的多租户架构 saleforce.

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

    1.没有内存表。

    2.大写是个坑。

    3.易用性不如 MYSQL 。

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

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

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

    7.事务遇到客户端冲突时会有丢数据的 Bug 。
    debuggerx
        64
    debuggerx  
       2022-05-02 23:47:45 +08:00
    《 SaaS 行业需要什么样的数据库-阿里云数据库专家德哥》:
    https://www.bilibili.com/video/BV1zv41157vd
    从 15 分钟开始看完就差不多了。
    MoYi123
        65
    MoYi123  
       2022-05-03 10:57:39 +08:00
    @debuggerx 没看视频, 但我猜德哥肯定狂吹 pg
    PopRain
        66
    PopRain  
       2022-05-03 11:34:43 +08:00
    @documentzhangx66 postgresql 是小写吧,oracle 、firebird 等大部分才是大写
    Chad0000
        67
    Chad0000  
    OP
       2022-05-03 12:11:47 +08:00
    @MoYi123 #65
    我看了那个,他的场景是固定行业 SaaS ,不是低代码 SaaS ,只是有一定参考价值

    @debuggerx #64
    感谢分享,如果是纯低代码或无代码 SaaS 就更好了。
    documentzhangx66
        68
    documentzhangx66  
       2022-05-03 15:37:19 +08:00
    @PopRain

    意思是 PostgreSQL 的大写有坑。百度:PostgreSQL 大写
    ychost
        69
    ychost  
       2022-05-04 00:06:18 +08:00
    MySQL + 一票,能不用 MongoDB 就不用(坑一抹多,用来存用户评论 /日志等不重要的数据比较合适)核心数据还是建议用关系型数据库,当然如果有条件优先考虑 Oracle/SQL Server
    PopRain
        70
    PopRain  
       2022-05-04 11:24:44 +08:00
    @documentzhangx66 据我所知只有 SQL Server ,My Sql 才可以表、字段命名用大小写(驼峰命名)且大小写不敏感,其它数据库要么自动转为大写(SQL 标准,oracle)要么自动转为小写(postgresql) ,如果要保留大小写则用引号引起来,这样后果就是大小写敏感了,拼写必须写对。(所以这些数据库一般用蛇形命名)
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1066 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 18:57 · PVG 02:57 · LAX 11:57 · JFK 14:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.