目前消息中心的量级还不是很大,大概每天200多W数据的样子,并发也就几十到两百,其实一两年内都不一定有并发的问题,按道理来说只要分表就可以了,但是凡是还是必须考虑长远点,目前还是需要考虑分一下库,那么分多少库呢? 设计可以动态扩容缩容的分库分表方案其实就是对我们服务的发展做一定的评估,根据吞吐量来计算要求的数据库梳理(比如一个数据库服务器2000并发,我们预计达到1W就设计5个库),根据数据量大小计算表数据(比如一个表我们最多放500W数据,预计5000W数据就放10个表)
如图,假设我们申请了4台数据库服务器,每台上面部署了8个数据库,每个数据库对于每张表分了32张表
倍数扩容
,4台数据库服务器,扩到8台数据库服务器,16台数据库服务器,原来的数据库服务器的数据库数量倍数递减(比如原来有4台服务器,每台服务器部署8个数据库,现在扩容一倍,有8台数据库服务器,那么每台数据库服务器就只用放原来的一半数据库,4个数据库即可)dba负责
将原先数据库服务器的库
整个迁移到新的数据库服务器上去(比如这里的db0~db3),,不需要进行数据迁移或者表迁移啥的,dba有很多工具,库迁移
,比较便捷
原先的路由规则变都不用变
,直接可以基于2倍的数据库服务器的资源,继续进行线上系统的提供服务如果我们想一开始设计成以后不需要改业务代码的表设计,那么我们需要对自己的数据量和吞吐量做一定的计算,然后对分的库数量和表数量做评估。
比如说假定一台数据库服务器可以承受2000写并发,一张表我们预计存500W数据,我们这个32个数据库,32张表,最多可以放32*500W约=40亿的数据,后面申请服务器资源的话也只是对并发数量进行扩容,而不是对表存储量扩容。