大家看一下，这种 key-value 结构的数据用什么来存储

資深大佬 : shitoushaonian 3

大家勿喷啊，纯粹的技术交流，这个东西是遗留下来的，任务交到我头上了。

数据没有更新操作

key-value 查找。

key 的话：我们存储了用户的 id：长度在 40-60 左右 value 的话，我们存储了用户的其他信息的缩略信息，长度在 300 左右

数据量在百亿级别。

检索要求快快快，但是写入基本上是一次性数据，读远远大于写。

大家有没有好的思路啊。

单机，内存不大，redis，LevelDB，RocksDB，那个比较合适啊。或者还有其他的，都可以说啊。

纯技术探讨，勿喷勿喷

大佬有話說 (5)

資深大佬 : dethan

es 啊快速检索

資深大佬 : swulling

只能选 rocksdb 了

資深大佬 : raaaaaar

不太清楚，说说我的思考吧。

首先看到 key value，第一反应肯定是 map，O(1) 最快了，但是你这个数据量太大了，肯定需要持久化吧，那么这里可以借鉴两个思路，一是把那些查找频率高的加载到 map 里做缓存，二是找原理是 hash 的数据库。

然后首先直接排除关系型数据库，看看 NOSQL，但是你又说内存小，这就很不行了吧，要速度肯定要利用内存的随机存取特性，如果是存在磁盘中的数据查找也太慢了，但是 redis 这种都是放在内存里的，百亿要占多少内存啊。

又没有写操作，说明也不用持久化吧，那就只好用空间换时间了，先把数据加载到内存中，然后再查。内存又小，那就只能加缓存了。

資深大佬 : XiaoxiaoPu

读远大于写就用 lmdb 吧，B+树。LevelDB 、RocksDB 是 LSM，更偏向优化写入的。
当然，最好还是做个性能测试都对比一下。

資深大佬 : XiaoxiaoPu

另外一点，既然数据写入量很少，那么可以提前按 key 的分布情况做均匀分片，分到多个底层存储单元里（分多层也行），类似桶排序的思想。