某年某月,我接到公司的任务,要搭建一个游戏平台系统,管理旗下所有游戏的玩家账户数据。起初拿到任务后,想了想。那么这个系统就是一个注册,一个登陆就ok了。
于是有了下面的数据库设计。
于是有了下面的数据库设计。
tbl_account. 表【主键ID,用户名,密码,注册时间,……】
业务逻辑开发完成,OK。内网测试没问题,业务流程正常,可以提供服务了。此时数据是A数量级条。
过了几天自己在该表插入B数量级条测试数据,发现查询速度(注册,登录),瞬间变慢了,好难过……
凭借多年的临床经验告诉我,应该进行分表了。
采用将用户名hash的方式,mod N之后把数据hash到N张表(tbl_account000,tbl_account001,tbl_account002,……)中,这时候单张表就会小很多了。
修改完毕,业务流程正常,服务正常。
过了几天自己用测试数据装入以上分好的表中,将数据量添加到C数量级。再次发现业务响应变慢了,十分难过……
这次数据量的大小快把数据库所在服务器硬盘撑满了,小伙伴怕不怕呢
如果外网运营真的满了,呵呵吧
好在我们有一颗不服输的心
大学时算法老师说的好,分而治之。
所以我们又有了新的解决办法。
将所有的业务数据拆分为M个库,同样采用hash用户名的方式,将用户数据hash到不同的库中(不同的库位于不同的服务器主机上),每个库中同样采用分表的处理办法。