业务水平分表

业务水平分表

legegeCoder 72 2022-11-11

起因

之前一直着手于公司的中台项目,导致业务相关的经验有欠缺,最近半年终于接手了公司的业务。包括活动引擎,小红点等。 业务的数据落地不同于中台,中台业务数据量大,大多选择ES,ClickHouse,Hbase等,业务数据的落地目前大多都是MySql,基于MySql 单表 至多存2000w (mysql其实没有最大数量的限制,但是业务上其实一张表最好最多2000w, 同样数据会大于500w才考虑分表) 的数据,单表很难满足特性。

思路

所有的分表方案都要跟着需求走,分表的方案也是见仁见智,也都有对应会带来的问题。就拿活动来说:

如果按照活动id取模来分表,那么每个活动的数据都在一张表里,这样拉取活动的相关数据会很方便,随之带来的问题:

  1. 热点数据问题,某个活动过于火爆,可能会打爆数据库
  2. 用户参与记录查询问题散落在所有的分表中
  3. 最大数据量:n张分表 * 2000w 条数据

如果按照用户id取模分表,那么每个用户的活动记录都在一张表里,这样拉取用户的参与记录会很方便,根据用户拆分数据没有热点问题,问题:

  1. 活动相关的数据不好拉取,比如活动的参与人数等
  2. 最大数据量:n张分表 * 2000w 条数据

如果按照时间分表 table_2022_11 那么每个月的数据记录在一张表里,不用再担心数据量问题,表可以无限扩充,问题:

  1. 活动数据拉取涉及多张表
  2. 用户信息拉取涉及多张表

分析

上述的三种方案各有各的优点和缺点,所以得跟着需求来,假如我没有 用户参与记录查询的需求,那第一种可以满足,没有 拉取活动相关的数据 的需求 那第二种可以, 如果我的数据只是做个记录排查问题,那第三种最合适。 假如需求都有,那就要跟着出现场景,或者访问量来。活动引擎大多的场景都是查询用户有没有完成,所以第二种最合适,那要拉取活动的相关数据,完全可以通过离线数据T+1去跑,因为这个其实是产品运营所关心的。

结论

活动引擎,任务引擎相关的分表其实很简单。复杂的是订单相关,多维数据如 订单id, 购买者id, 店铺 id的分表选择。而这常常会用到基因法等,简单来说就是在你的订单 id中融入购买者id。这个等我有空了再写吧。。。


# 深入浅出mysql # 分表