userid是什么意思啊,抖音userid是什么意思啊

一般面对几千万级的数据,刚开始可能都是把数据放在MySQL的一个单库单表里,但往往这么大量级的数据到后期,数据库查询速度就很慢,因为数据量级太大,导致表的索引很大,树的层级很高,进而导致搜索性能下降,而且能放内存缓存的数据页是比较少。

所以推荐MySQL单表数据量不超过1000w,最好是在500w内,若能控制在100万以内,那是 最佳选择,基本单表100万以内的数据,性能上不会有太大的问题,前提是,只要你建好索引就行,其实保证MySQL高性能通常没什么特别高深的技巧,就是控制数据量不要太大,另外就是保证你的查询用上了索引就行。

针对该问题,就能分库分表,可选择将该用户大表拆分为比如100张表,那么此时几千万 数据瞬间分散到100个表里去,类似

  • user_001
  • user_002
  • user_100

这样的100个表,每个表也就几十万数据而已。

其次,可将这100个表分散到多台数据库服务器上去,此时要分散到几台服务器呢?你要考虑两个点,一个是数据量有多少个GB/TB,一个是针对用户中心的并发压力有多高。

互联网公司对用户中心的压力不会高到离谱,因为一般不会有很多人同时注册/登录或同时修改自己的个人信息,所以并发不是大问题。

数据量层面,一般1亿行数据,大致在1~几GB之间的范围,和具体你一行数据有多少个字段也有关,所以说你几千万的用户数据,往多了说也就几个GB。这点数据量,对服务器存储空间没压力。

综上,此时你完全能给他分配两台数据库服务器,放两个库,然后100张表均匀分散在2台服务器。分的时候,注意指定一个字段来分,一般就指定userid, 根据用户id进行hash后,对表进行取模,路由到一个表里去,这就能让数据均匀分散。

至此搞定用户表的分库分表,只要给系统加上数据库中间件技术,设置好路由规则,即可轻松对2个分库上的100张表crud。平时针对某个用户增删改查,直接对他的userid进行hash,然后对表取模,做个路由,就知道到哪个表里去找这个用户的数据了。

但是这里可能会出现一些问题:用户在登录时,可能不是根据userid登录,而是根据username、手机号,此时你就没有userid了, 怎么知道去哪个表里找这个用户的数据判断是否能登录? 对此。常规方案是建立一个索引映射表,搞个表结构为 (username, userid)的索引映射 表,把username和userid一一映射, 然后针对username再做一次分库分表,把这个索引映射表可拆分为比如100个表分散在两台服务器。然后用户登录时,就能根据username先去索引映射表里查找对应userid,比如对username进行hash,然后取模路由到一个表里去,找到username对应的userid,接着根据userid进行hash再取模,路由到按照userid分库分表的一个表里,找到用户的完整数据。但这种方式会把一次查询转化为两个表的两次查询,先查索引映射表,再根据userid去查具体的数据,性能有损耗,不过有时为解决分库分表问题,也只能用这种方案。

另外就是若公司运营团队里,有用户管理模块,需要对公司的用户按照手机号、住址、年龄、性别、职业等各种条件搜索,这咋办?

没啥好办法,基本上就是要对你的用户数据表进行binlog监听,把你要搜索的所有字段同步到ES,建立好搜索的索引。然后你的运营系统就可以通过ES进行复杂的多条件搜索,ES是适合干这个事儿的,然后定位到一批userid,通过userid回到分库分表环境里去找出具体的用户数据,在页面上展示出来即可。

这就是一套比较常规和完整的分库分表的方案。

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 sumchina520@foxmail.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.gooyie.com/46879.html