求助大表优化方案

搞两份，一份按用户分，一份按标签分。或者看下你业务按哪个查比较多，就怎么分

@nine99 主要是存在一个数据量不均衡的问题，有的标签用户很多，有的标签又没啥用户，所以还是只能按用户分，随着数据量的增长，可能还是会存在单表过大的问题。
按用户分的话，分表的张数如何考虑，而且也确实有通过标签查用户的需求，虽然场景不多，这个查询怎么做好。
或者说有没有比现有一个用户一个标签一条数据这样的数据存储方式更优化的数据结构？

按用户分 mysql。

然后数据打到 ES/Mongo 中做旁路。

@owenliang 能详细说一下吗，还有就是性能上 ES/mongo 能否满足？因为涉及这张表的接口访问量都非常大

@alamaya 性能问题优先 redis 缓存热点，其次考虑 mysql 分表内走索引或者 mongodb 走索引，es 不适合那么高性能。

mysql 吗？表分区做了吗

@owenliang 那针对少量的通过标签查用户的场景，怎么处理好？

@alamaya 不是 mongo 旁路了吗，是个分布式存储

@unforgiven 尽量不要做表分区，mysql 的表分区一直不太稳定，业界反应 bug 挺多的

@nine99 的路子是最直接有效的，定好再次分表的规则，能够做到一直水平分下去，再做上 redis 主动缓存，2 亿数据可以快到不可想象
@owenliang mongo 的性能就是 shit，过千万记录之后，加索引都救不了

全部改用 redis, 结束。

@sunsh2017 按照 lz 的叙述，感觉数据量会一直增长，成本会不会太高啊？

有没有什么没那么复杂的方案哦

你先搜索一下，这个问题在 V 站讨论不下十几次了

hbase 有点大炮打蚊子：数据存两套
一套 userId + tag 当 rowkey，专门给用户查询 tag 用
一套 tag + userId 当 rowkey， 给 tag 查用户用
数据就是增长到 200 亿都是亚秒级查询

高性能 mysql 上面有一整章说这件事情怎么办,你可以看看,我记得知乎以前也有说过,主要是垂直拆分和水平拆分两种

@ebingtel 不高 用 redis 是最好的方案 用 set 即可 用户数不过百万 标签也不过百万 其实很省的 嫌费内存 你用 ssdb 好了