怎么处理上亿级别的用户列表数据?

我们假设一般项目的用户有哪些基础应用功能呢?一般至少应该有“注册/登录” 和 “填写/修改用户资料”两个基本基本功能是吧?那么我们就根据这两个基本的功能来设计表,如果有其他扩展功能,可以增加其他扩展表方式,本章不讨论其他扩展表的设计。

针对注册/登录功能,我们采用hash散列设计 user_register 表,表只有三列,分别为user_id,user_name,password,把user_name做为hask_key进行hash散列,方式:把user_name进行md5加密变成16进制的数字,然后转化成10进制数字,采用hash散列算法,就可以判断是存储到哪个库的哪个表。可以设计10个库,每个库100个表,表里面的user_name存储的是原始的user_name值,hash散列算法只是实现判断具体存储在哪个库的哪个表而已,这样用户在注册或者登录时,就可以引导用户连接到具体的分表去操作。

针对“填写/修改用户资料”,我们根据 user_id 进行hash散列,因为user_id本身已经是数字,所以直接计算就可以了,比较简单。
————————————————
版权声明:本文为CSDN博主「xpb1980」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/xpb1980/article/details/31032369

 

疑问:1.哈希算法能一次就确定A用户名的所在库+所在表吗?还是要多次哈希

2.看起来,哈希方法只是处理了把用户名改成了数字,然后匹配一下而已。为什么不直接使用用户id这个唯一标记直接查找?01001xxxxxx就代表01库001表某某某,不是更方便吗。

3.使用哈希方法的话,如果用户后面发生了修改用户名的操作,是不是要进行数据迁移?

4.10个库每个库100张表,一共1000张表。以mysql为例,每张表平均需要存10w条。加上哈希可能不均匀,峰值可能突破20w条,会不会突破单张表的存储上限?

 

怎么处理上亿级别的用户列表数据?

上一篇:注释以及格式化输出(%s以及format运用)


下一篇:pwsh7 tab键下拉菜单智能提示