image.png
记录大小评估
假定按照unicode 编码，并且都是中文即1 char 占用 3字节
用户表 ：
8 + (64 + 128 + 32)*3 + 4 = 8 + 224 * 3 + 4 = 8 + 672 + 4 = 684 字节
好友表 ：
4+ 4 = 8 字节
离线消息：
8 + 8 + 4 + 4 + 256 * 3 + 4 = 24 + 768 + 4 = 796字节
表容量规格
- 100byte以下 单表5000W条
好友表 - 100byte以上单表1000w
用户表、离线消息表
容量评估
- 【用户表】:
假定是有10亿用户，那么
- 需要的表的数量就是10*10000w / 1000w = 100个表=取幂128个表
- 大小估计：用户表单条记录最大是684字节，因为有varchar字段，所以平均来说假定是没条有512byte(0.5k)，那么单表的大小大概是：0.5k * 1000w = 0.5k * 1000* 10000 = 0.5M * 1000* 10 =0.5G * 10 = 5G
100个表 ： 5G * 100 = 500G
因为我们是按照unicode 中文占用的字符数来计算的，所以，考虑到还有英文或者数字的情况，所占用的空间可能会减少一半，同事加上索引,数据空隙，预估其总大小在300-500G
根据服务器的配置情况，8台机器足够，4主4从。即4库，每库32表
2，4，8，16，32，64，128，
- 【关系表】
假定是有10亿用户，那么每个人如果有50个好友，那么就是500亿条记录
- 需要的表的数量就是10*10000w / 5000w = 20个表=取幂32个表
- 大小估计：用户表单条记录最大是8字节，每条有16byte，那么单表的大小大概是：16byte * 5000 * 10000 = 16byte * 1000 * 5 * 1000 * 10 = 16k * 5 * 1000 * 10 = 16M * 5 * 10 = 800M
20个表：0.8G * 20 = 16G
根据服务器的配置情况，附加到用户表的8台机器足够，4主4从，每个库8个表
- 【离线消息表】
假定是有1亿活跃用户，假定每天有1亿条离线消息存量，已读的离线消息会被迁移到其他的历时消息表，并从离线消息表中删除调。加上历时的存量，假定半年累计会导致有5亿条历时消息存量。
- 其大小大致是用户表的一半。即 150-250G，所需的总表数为64
根据服务器的配置情况，需要额外的的4台机器足够，2主2从，每个库32个表
查询维度
用户表
查询场景：
- 登录使用用户名
- 用户昵称似乎不常用呢
- 好友关系，通过用户ID关联的，所以查询好友列表会根据ID拉去好友清单
分片键设计：
ID为主，用户名为辅，考虑以ID为分片键，用户名作为基因位
写入时，基因法生成userid，关于xbit基因，因为要分128张表，故x可取7，即7bit基因；也可加上分4库，每个库32个表的逻辑，采用5bit基因；根据userid查询时可直接取模路由到对应的分库或分表。根据username查询时，先通过usernamecode生成函数生成username_code再对其取模路由到对应的分库或分表
关系表
查询场景：
最常见的使用方法就是我的好友有哪些
分偏键设计：
以uid1作为分片键，uid1的基因能满足128个表，自然能满足关系表的32个表
离线消息表
查询场景：
- 接受方要知道，都谁给我发了离线消息，根据接收方的Id拉取消息，
- 【可选，非必要】发送方要知晓，都发给了谁的离线消息，还未接受，根据发送方的Id拉取消息。
更新场景：
接收方看到消息后，需更新消息状态为已读，后续会删除此已读记录。此时是按照消息ID来检索
分片键设计：
-
更新消息场景：需通过消息ID检索数据，这就与接收方uid作为分片键检索冲突了；但消息以消息ID作为分片键才具有扩展性
-
拉取消息场景：以接收方uid作为分片键，uId和消息ID的映射表，记录数等同离线消息表,采用相同的分库分表也无妨，通过接收方uid在映射表检索到关联的消息Id，然后再查询离线消息表。映射表本没多大
uid1的基因能满足128个表，自然能满足离线消息表的64个表可采用映射表的做法 -
如果需满足发送方uid查询，也需要再增加映射表（发送方uID->消息ID的映射）
服务器数量
总计12台
用户表：300-500G ，128个表，占用8台服务器（4主4从），分4库每库32表
关系表：16G，32个表，复用用户表的8台服务器（4主4从），分4库没库8表
离线消息表：150-250G，64个表，占用4台服务器（2主2从），分2库，每库32表
离线消息表映射表：16G，16个表，复用离线消息表的服务器(2主2从），分2库每库8个表
网友评论