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

求教个 Mysql 数据库分库分表的问题

  •  
  •   Laysan · 2023-08-22 14:28:06 +08:00 · 2475 次点击
    这是一个创建于 438 天前的主题,其中的信息可能已经有所发展或是发生改变。

    有个表 biz_order 是单表的,目前已经 600W+数据,每日还在 30w 增长量

    考虑把 biz_order 表分库分表,分成 10 库 100 表,根据 order_id hash 计算分表位

    现在的问题是创建好表了,旧数据如何快速迁移到新的分表里面

    用存储过程能快速迁移么?还是要写代码慢慢查询再插入?

    26 条回复    2023-08-23 19:13:34 +08:00
    plutome
        1
    plutome  
       2023-08-22 14:32:16 +08:00   ❤️ 1
    600W 而已。insert into select xxxxx 也花不了多久。
    qizheng22
        2
    qizheng22  
       2023-08-22 14:33:30 +08:00
    shardingjdbc 分库分表,不是有个 sharding-ui 和 sharding-proxy 。
    shardingproxy 相当一个中单件,用 mysql 客户端连接,再导入。
    仅用 order_id 的 hash 分表,以后表不够,再扩展就麻烦了
    dusu
        3
    dusu  
       2023-08-22 14:43:31 +08:00 via iPhone   ❤️ 1
    按 1kw 分一次表 上线后等 id 满了切就行
    不用考虑这次迁移 一个表不差几百 w
    与其考虑迁移 不如多考虑分表后的数据聚合问题吧
    yungeo
        4
    yungeo  
       2023-08-22 14:47:41 +08:00
    不考虑使用 datax 吗?
    declandragon
        5
    declandragon  
       2023-08-22 15:07:43 +08:00
    写个小脚本,多线程分段处理数据很快的,我也是 3 楼的想法,聚合怎么办
    T0m008
        6
    T0m008  
       2023-08-22 15:10:20 +08:00
    订单表难道不是把旧日期的分出去吗,过时的订单能有多少流量?
    wqhui
        7
    wqhui  
       2023-08-22 15:16:51 +08:00
    不理解怎么会想要分 100 个表存储,有没想过如果查询条件里面没有带上分表键需要所有表扫一次,应该是把冷数据归档掉,分表只存热数据。除非规定每个查询一定要带分表键,或者把这些数据同步到别的组件比如 es 上
    Granado
        8
    Granado  
       2023-08-22 15:25:55 +08:00
    说下我的想法吧:
    如果是有明显时间冷热的数据,建议的做法是定期归档然后,删除历史数据,查历史数据的时候就查归档。当然这么做也需要有一定的基建后比较轻松。

    如果采用分表,以后非分表维度的查询(例如你文中提到的 order_id 分表,查询的时候需要查用户的订单,查询维度是 user_id )就会比较麻烦,要构建单独的查询索引(例如前面提到的 user_id ---> order_ids 的映射),这时候又会有额外的维护(索引维护,数据一致性问题,延迟问题)。

    这时候我建议还是直接上 tidb 这种天然支持分表的,维护成本低很多,相对来说迁移也比较好迁移,前期数据量低可以停机迁移,数据量大先双写单读,再单写单读就好。
    me1onsoda
        9
    me1onsoda  
       2023-08-22 15:46:04 +08:00
    2023 年还有人分库分表吗?这方案还是建立在以前 hhd 低速存储的前提下,以后 ssd 都比 hhd 便宜,速度再提升,要进历史的垃圾桶吧?
    james2013
        10
    james2013  
       2023-08-22 15:50:47 +08:00
    我觉得分库没有必要,直接在 1 个库里分 100 张表,使用和维护比较方便
    存放分表数据采用代码提供的唯一的 id,然后使用代码分批插入,比如每次 3000 条
    kanepan19
        11
    kanepan19  
       2023-08-22 15:55:13 +08:00
    那个是怎么说来着, 分表分库是解决插入问题的。
    kanepan19
        12
    kanepan19  
       2023-08-22 15:56:55 +08:00
    接上面,分表分库是解决 插入性能不足问题的。
    查询性能不行,加读库 或 olap
    lsk569937453
        13
    lsk569937453  
       2023-08-22 15:58:54 +08:00
    自己写程序迁移,有唯一 id 的好迁移。
    dw2693734d
        14
    dw2693734d  
       2023-08-22 16:31:28 +08:00
    @me1onsoda 2023 年了,还有人不知道 shard 是很多公司(包括谷歌, 微软)在数据库管理中常用的技术吗?通过将数据分割成较小的部分,可以提高数据库的性能和可扩展性。
    dw2693734d
        15
    dw2693734d  
       2023-08-22 16:33:07 +08:00
    说到分库分表 shard ,就不得不提一下 postgres 了,使用 citus 插件,一键分表,自动计算 hash

    me1onsoda
        16
    me1onsoda  
       2023-08-22 16:59:48 +08:00
    @dw2693734d 你别光说好处,代价呢?
    dw2693734d
        17
    dw2693734d  
       2023-08-22 17:09:18 +08:00
    @me1onsoda 用空间换时间,本来就是互联网公司常用的技术。缓存不也是一样的道理。
    dailiha01sy
        18
    dailiha01sy  
       2023-08-22 17:50:03 +08:00
    一年也才一个亿 分啥
    gam2046
        19
    gam2046  
       2023-08-22 18:36:38 +08:00
    @dw2693734d #14 大佬,现在我正好遇到一个问题,现在有一个 postgres 表,存在一个 timestamp 类型的字段,而这个字段又是索引字段,很多地方需要通过这个来作为查询条件。同时这个字段更新又非常频繁,导致索引也需要频繁更新,进而导致 IO 性能低下。

    针对这种场景,有什么优化建议嘛,目前索引类型是 btree
    poembre
        20
    poembre  
       2023-08-22 19:57:00 +08:00
    我有个单表表 目前 7 亿+ 数据量, 一周差不多 2-3KW 写入量。
    lovelylain
        21
    lovelylain  
       2023-08-22 20:29:52 +08:00 via Android
    按 uid hash 分库分表,将这个 hash 值塞到 order_id 里,这样既能通过 uid 从一个表找到用户的所有订单,又能通过 order_id 找到对应的表。至于已经存在的历史 order ,因为改 order_id 使其符合新规则可能有隐患,建议不迁移,这样一个用户最多查一次新表一次旧表就能找出所有订单,旧表没有新记录写入也不用担心性能下降,而且订单是有时效的,过段时间还能直接干掉旧表。
    dw2693734d
        22
    dw2693734d  
       2023-08-22 22:39:04 +08:00 via iPhone
    @gam2046 用 brin 索引试试呢
    phx13ye
        23
    phx13ye  
       2023-08-22 23:04:32 +08:00
    新数据双写,历史数据迁移或归档
    mmdsun
        24
    mmdsun  
       2023-08-22 23:50:23 +08:00
    没多少数据直接 sql 插入。还是需要不停机维护?

    分表分库注定要被淘汰,建议选择云数据库、分布式数据库。
    kanepan19
        25
    kanepan19  
       2023-08-23 14:07:44 +08:00
    @phx13ye
    不停机归档,有没有方案?
    phx13ye
        26
    phx13ye  
       2023-08-23 19:13:34 +08:00
    @kanepan19 没做过太高大上的,
    1select 源库数据,插入归档库,两边校验,delete 源数据库历史数据, 对源表做一下 alter table tb_123 engine=innodb ,释放空间

    最后两步可选
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1232 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 18:17 · PVG 02:17 · LAX 11:17 · JFK 14:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.