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

django+mariadb 多租户架构方案讨论

  •  
  •   leven87 · 108 天前 · 1838 次点击
    这是一个创建于 108 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司搭建云平台需要实现多租户。搜索互联网,主要两个方案。

    1. 租户 id 区分,所有租户共用一个数据库;
    2. 按租户分库,每个租户一个数据库。

    方案一最简单直接,缺点就是数据隔离性和安全性差一些,但中小应用还好。 方案二架构就会比较复杂,但是数据隔离性和安全性好。

    现在的问题是考虑方案二的话,如何将各租户的数据聚合,因为租户数据都是存在不同的库里面。管理员应该能看到并管理所有租户数据,如果实时从每个库查询效率太低,应该也不是通用做法吧(这方面经验少)。想到的一个架构是,采用阿里开源的实时同步工具 canal, 将每个租户的数据同步到一个全量数据库。管理员在全量数据库去查询数据。

    请教 V 友,多租户分库方案,数据如何聚合进行查询的问题,谢谢大家。

    27 条回复    2023-12-29 09:39:12 +08:00
    roundgis
        1
    roundgis  
       107 天前 via Android
    方案二定時做匯總就行了
    Masoud2023
        2
    Masoud2023  
       107 天前
    能不能把需求讲明白点,做什么业务的云平台实现什么功能实现多租户?
    mightybruce
        3
    mightybruce  
       107 天前
    你的问题其实 HTAP 类型的数据库就能满足, 不过你可能是用 mysql 吧, 你可以通过 mysql CDC 工具同步到 ES 来做分析或建立一些数仓来做分析。
    kuituosi
        4
    kuituosi  
       107 天前   ❤️ 1
    互联网模式选 1
    2b 模式且对应甲方比较少选 2
    812603834
        5
    812603834  
       107 天前
    客户已经有了吗?如果是研发新产品方案 2 太宏大了,可以折中一点,根据租户 id 分库分表,分几个库百来张表。用 es 做数据汇总查询处理,具体的操作直接操作数据库
    chenqh
        6
    chenqh  
       107 天前
    都用 django 了,确定是大项目吗?
    devliu1
        8
    devliu1  
       107 天前
    2 一点都不复杂,1 才复杂,业务层需要的改动太多。

    多租户你应该只要部分统计数据,离线计算就可以
    yy77
        9
    yy77  
       107 天前
    还是 2 比较好,1 的话一个 bug 或者运维失误那就很难搞定了。
    shyangs
        10
    shyangs  
       107 天前
    方案一,增加了維運搞出 P0 級事故的可能. 一個失誤影響所有租戶.
    shuimugan
        11
    shuimugan  
       107 天前
    方案一很勇哦,先想一想灰度方案怎么做,怎么样更新不会影响全租户,租户有没有数据库私有化的需求,有没有"坏租户"数据量过大拖垮整个数据库性能的风险
    DeWjjj
        12
    DeWjjj  
       107 天前
    这不是应该启动一个服务,定期把客户的分表全部映射到一个总表上给后台看么?
    leven87
        13
    leven87  
    OP
       107 天前
    @roundgis @DeWjjj 还是希望实时,管理员在租户数据库的写操作,希望能实时同步到全量数据库。
    leven87
        14
    leven87  
    OP
       107 天前
    @kuituosi 谢谢
    leven87
        15
    leven87  
    OP
       107 天前
    @812603834 老板就随口一说,数据库要不要分库。我们以前是做私有化部署,现在要弄到公网上,所以要做多租户。
    leven87
        16
    leven87  
    OP
       107 天前
    @chenqh 哈哈,技术栈就是 python.
    leven87
        17
    leven87  
    OP
       107 天前
    @shyangs
    @shuimugan
    暂时是小系统,没到那么复杂的架构。只是老板考虑以后升级成本
    sivacohan
        18
    sivacohan  
       107 天前   ❤️ 1
    方案二,每个用户一个 schema 。
    管理员具备查看多个 schema 的权限。

    主键 ID 不要用自增 ID ,可以用 snowflake 之类的分布式 ID 。这样多个 schema 相同表 union 的时候,不会出现主键冲突,排序和分页都冗余很多。

    并且,如果是 ToB 业务,不同租户之间可能表结构、逻辑结构都有所区别。遇到租户级的定制需求,方案一满足起来非常困难,做到最后会发现数据库已经弱化成了存储,“实时上”自己手动实现了一个数据库。
    roundgis
        19
    roundgis  
       107 天前 via Android   ❤️ 1
    @DeWjjj 量不大可以考慮用 signal 有寫入行為時觸發同步

    如果量很大就要考慮用 mq 了
    0703wzq
        20
    0703wzq  
       107 天前   ❤️ 1
    我这边也是做 saas ,采用的方案二,方案二的优点很明显,业务侧不需要管租户的问题,只需要实现它的业务,数据库的切换由底层去实现。在独立部署的时候也不会遇到什么问题只开通一个租户即可。如果使用方案一,后期租户数量多将会是个灾难,对于业务侧来说,每个数据考虑租户的问题有时候也是个头疼的事情。至于汇总数据的问题无非是多做一个定期同步到上一级汇总表。
    fengpan567
        21
    fengpan567  
       107 天前
    选方案 2
    leven87
        22
    leven87  
    OP
       107 天前
    @0703wzq 谢谢。 还有个问题,如果租户多了,数据库太多,会不会给服务器很大的压力。
    0703wzq
        23
    0703wzq  
       107 天前   ❤️ 1
    @leven87 #22 如果到那个程度的用户量,把数据库分开实例就可以了,如 A 、B 租户在数据库实例 1 ,C 、D 租户在 数据库实例 2 。 分库的方案在后期扩容上还是很灵活的。
    37Y37
        24
    37Y37  
       107 天前
    我们自动化系统,也是 python 写的,Django 基础框架,公司内部用,不同项目/部门实现多租户,用了方案一,封装了个框架做租户层的隔离,无论是插入还是读取,遵循框架就好,目前用起来还挺好的,同样同意楼上老哥的观点:
    互联网模式选 1
    2b 模式且对应甲方比较少选 2
    mightybruce
        25
    mightybruce  
       107 天前
    之前没看到是 mariadb, 那么就是分库的方案了,schema 拆分, 现在谈论任何优化都是过早的事情, 在你的用户量确定和增长量确定,然后服务器监控指标再说这些。
    另外数据库分库分表也是根据实际情况来的,也是多种方案,你现在想这个实在是太早, 分库分表带来的一堆问题你自己都不好解决的。
    架构演进可以如下
    scheme 分拆 到 分区表 主从优化 最后才是分库分表或分布式数据库。
    danhahaha
        26
    danhahaha  
       107 天前
    2 吧,等客户多了之后,保不准有的客户需要定制或搬迁,1 搞起来太麻烦了,2 随时可以分开
    leven87
        27
    leven87  
    OP
       107 天前
    @mightybruce 好的,我的想法也是先方案一,可以先做些准备,等有些规模后再迁移。领导需要一个评估。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2322 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 01:49 · PVG 09:49 · LAX 18:49 · JFK 21:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.