如何去维护大量用户 ID？

[ke1e]

各位公司是如何维护大量用户 ID 的？

因为很多地方查表都会用到用户 id，所以将用户的 id 单独维护起来，如果遇到需要对所有用户进行操作的时候，只需去遍历维护的 id 列表，然后再去牵扯到的表去查询即可。

头说不考虑 redis，目前的方案是想去用文件存储，各位有啥好办法么？

只需要方便遍历和添加新用户 id， 假设有 4000w Id

[maemual]

“需要对所有用户进行操作”，这个需求不是很常见啊。

[wilsonwen]

为什么不考虑 redis

[idblife]

用户 id 作为主键或者唯一约束不就行了，才 4000 万怕啥

[NaVient]

对所有用户进行操作的信息应该尽量放在用户基础表里才对,而且 4000 万的数据量说实话如果不是性能到了极限瓶颈，不是特别需要刻意的重构吧，当然如果你能说服领导当我没说

[paradoxs]

不考虑 redis 的头, 留着过夜?

[tabris17]

4000 万又不多，自增有什么问题？

[plprapper]

没看懂这个“维护” 是啥意思

是要在内存里加载? 还是别的什么

[crysislinux]

比如群发通知？

[noNOno]

用户 ID 不用修改吧，只有插入和查询。可以加一些常用的条件字段到用户表，然后给上索引，更快的遍历想要的用户 ID

[noNOno]

头考虑下 hbase 不

[celavi]

我也觉得这个操作能不能具体化一点？

[misaka19000]

4000w 和大量还是有差距的

[robertgenius]

4000W 也太少了

[ke1e]

@noNOno 对，不需要修改，只有插入和查询，每次查询估计都是要全部查询的

[ke1e]

@crysislinux 嗯呐 有这个需求

[ke1e]

@plprapper 就是简单的迭代，添加。。不知如何快速的迭代

[ke1e]

@idblife 因为有可能牵扯到多个表的操作

[ke1e]

@NaVient 但是有些用户行为数据就没办法放在基础表里了

[ratazzi]

如果是连续递增的数字 id 用 bitarray ？

[ke1e]

@ratazzi 用的 mongo 所以是 objectId