未分類
9 10 月 2020

关于 mysql 分表的方案设计，求助

关于 mysql 分表的方案设计，求助

資深大佬 : xmpx310 2

我们有一个活动发放奖品的记录表，业务逻辑是一场活动 activity_id 会给用户 user_id 发放奖品 reward_id,随着活动场次的增多，给用户的奖品发放记录已经达到了亿级别的数据，现在准备分表，要支持一个查询一个用户领取的所有奖品，和一场活动的所有发放奖品用户列表两种常用查询，请问如何分表？

感觉水平分表案 user_id hash,mod 和按 activity_id hash，mod 都不太好支持这种场景，请问 v 友有什么更好的方案吗？

别的数据库 es，mongodb 暂不考虑，可以支持这种场景的 mysql 中间件可以考虑，但我参考了 mycat，感觉不太可行

大佬有話說 (20)

  • 資深大佬 : lasuar

    partition

  • 主 資深大佬 : xmpx310

    @lasuar mysql 的分区表吗？

  • 資深大佬 : lasuar

    @xmpx310 对

  • 資深大佬 : wangritian

    冗余一下如何，用户和活动各自分表，一次领奖插 2 条记录

  • 資深大佬 : guoer

    activity_reward_idx_xxx
    user_reward_idx_xxx
    reward_xxx

    按三个维度分表。

  • 主 資深大佬 : xmpx310

    @guoer 意思是领一次奖插入 3 条记录吗

  • 主 資深大佬 : xmpx310

    @wangritian 考虑过，想看看有没有更优的方案

  • 資深大佬 : guoer

    @xmpx310 #6 是，用事务保证数据一致性

  • 資深大佬 : opengps

    优先看下表分区能否够用
    实在要水平分表，按照活动开始时间，分多个物理表

  • 資深大佬 : MarioLuo

    如题只能通过数据冗余，满足多个查询键的需求。建议按照上老哥说的按照时间纬度分表，或者不分表做个历史归档表，不过需要从业务上面做一定调整

  • 資深大佬 : hpeng

    这种不会变的数据做冷热分离，数据归档省事多了

  • 資深大佬 : xx6412223

    这种查询固定的只读数据，分表不是最好方案。即使不用其他数据库的话，考虑下将数据序列化后按查询做成单条数据

  • 資深大佬 : lihongming

    这场景用 nosql 真的挺合适，实在不想换数据库，也可以按 nosql 的方式来用 mysql 。

    首先根据活动分表，然后建立用户 ID 和发奖记录的索引表，就行了。索引表可以用 trigger 自动维护。

  • 資深大佬 : wakzz

    主这种场景，一般用异构索引或者用双数据源。
    我们公司的处理方案是后者，因为需要通过用户维度和活动维度两个维度查询，对于消费者来说必须实时查询，所以主数据源是用户 ID 来分表，然后通过同步工具或者直接双写将数据同步到另一个数据源，次数据源通过活动维度分表，因为活动维度分表是给商户分析用的，可以有延迟，甚至可以通过大数据批跑来实现。

  • 資深大佬 : user8341

    @wakzz 所以你的答案跟 4 是一个意思？

  • 資深大佬 : wakzz

    @user8341 四是我的方案的一个子集，不建议写两次，一般是主库通过同步工具同步到从库，然后主库和从库各自分库分表。
    实际上，主这种业务场景，活动纬度的查询一般是商户分析使用，是不需要实时的。完全可以主库按用户纬度分表，然后由大数据的同事一天一次或者一小时一次增量读 /监听队列之内的方案来提供分析数据

  • 資深大佬 : lihongming

    其实大家说的方案思路都差不多，都是按照用户和活动分别组织数据。

    但昨晚仔细想了一下，这些方案怕是有个共同的缺点——冷热分布太不均匀，有的表忙死，有的表闲死，可能仍会产生瓶颈。

    所以，最好还是按照哈希值随机分表，然后分别根据活动和用户建两个索引表，这样就比较均衡了。

  • 資深大佬 : yangzixue

    tidb

  • 資深大佬 : q474818917

    如果不想用异构数据源（ nosql ）之类的话，4 正解

  • 主 資深大佬 : xmpx310

    感谢大家，方案大概确定了，还是维护两个索引表，用事务保证数据的一致性，这个方案比较简单。用空间换时间