各位公司是如何维护大量用户 ID 的?
因为很多地方查表都会用到用户 id,所以将用户的 id 单独维护起来,如果遇到需要对所有用户进行操作的时候,只需去遍历维护的 id 列表,然后再去牵扯到的表去查询即可。
头说不考虑 redis,目前的方案是想去用文件存储,各位有啥好办法么?
只需要方便遍历和添加新用户 id, 假设有 4000w Id
各位公司是如何维护大量用户 ID 的?
因为很多地方查表都会用到用户 id,所以将用户的 id 单独维护起来,如果遇到需要对所有用户进行操作的时候,只需去遍历维护的 id 列表,然后再去牵扯到的表去查询即可。
头说不考虑 redis,目前的方案是想去用文件存储,各位有啥好办法么?
只需要方便遍历和添加新用户 id, 假设有 4000w Id
|
maemualAug 17, 2017
1
“需要对所有用户进行操作”,这个需求不是很常见啊。
|
|
wilsonwenAug 17, 2017
2
为什么不考虑 redis
|
|
idblifeAug 17, 2017
3
用户 id 作为主键或者唯一约束不就行了,才 4000 万怕啥
|
|
NaVientAug 17, 2017
4
对所有用户进行操作的信息应该尽量放在用户基础表里才对,而且 4000 万的数据量说实话如果不是性能到了极限瓶颈,不是特别需要刻意的重构吧,当然如果你能说服领导当我没说
|
|
paradoxsAug 17, 2017
5
不考虑 redis 的头, 留着过夜?
|
|
tabris17Aug 17, 2017
6
4000 万又不多,自增有什么问题?
|
|
plprapperAug 17, 2017
7
没看懂这个“维护” 是啥意思
是要在内存里加载? 还是别的什么 |
|
crysislinuxAug 17, 2017 via Android
8
比如群发通知?
|
|
noNOnoAug 17, 2017
9
用户 ID 不用修改吧,只有插入和查询。可以加一些常用的条件字段到用户表,然后给上索引,更快的遍历想要的用户 ID
|
|
noNOnoAug 17, 2017
10
头考虑下 hbase 不
|
|
celaviAug 17, 2017
11
我也觉得这个操作能不能具体化一点?
|
|
misaka19000Aug 17, 2017 via Android
12
4000w 和大量还是有差距的
|
|
15
@crysislinux 嗯呐 有这个需求
|
|
19
如果是连续递增的数字 id 用 bitarray ?
|
|
21
LDAP ?
|
|
iyangyuanAug 18, 2017 via iPhone
23
每个用户按 8 字节算,4000 万用户 300m 左右空间,放内存绰绰有余。
用文件存储绝逼是坏主意,除非你们操控 io 的能力超越数据库。 |
|
24
Roaringbitmap 这里的吧 也许是你想要的东西
|