这是一个创建于 1435 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家勿喷啊，纯粹的技术交流，这个东西是遗留下来的，任务交到我头上了。
数据没有更新操作
key-value 查找。
key 的话：我们存储了用户的 id：长度在 40-60 左右 value 的话，我们存储了用户的其他信息的缩略信息，长度在 300 左右
数据量在百亿级别。
检索要求快快快，但是写入基本上是一次性数据，读远远大于写。
大家有没有好的思路啊。
单机，内存不大，redis，LevelDB，RocksDB，那个比较合适啊。或者还有其他的，都可以说啊。
纯技术探讨，勿喷勿喷
 |
1
dethan 2021-01-07 11:31:05 +08:00 via Android
es 啊 快速检索
|
 |
2
swulling 2021-01-07 11:32:08 +08:00 via iPhone
只能选 rocksdb 了
|
 |
3
raaaaaar 2021-01-07 11:39:32 +08:00 via Android
不太清楚，说说我的思考吧。
首先看到 key value，第一反应肯定是 map，O(1) 最快了，但是你这个数据量太大了，肯定需要持久化吧，那么这里可以借鉴两个思路，一是把那些查找频率高的加载到 map 里做缓存，二是找原理是 hash 的数据库。 然后首先直接排除关系型数据库，看看 NOSQL，但是你又说内存小，这就很不行了吧，要速度肯定要利用内存的随机存取特性，如果是存在磁盘中的数据查找也太慢了，但是 redis 这种都是放在内存里的，百亿要占多少内存啊。 又没有写操作，说明也不用持久化吧，那就只好用空间换时间了，先把数据加载到内存中，然后再查。内存又小，那就只能加缓存了。 |
 |
4
XiaoxiaoPu 2021-01-07 11:43:08 +08:00
读远大于写就用 lmdb 吧，B+树。LevelDB 、RocksDB 是 LSM，更偏向优化写入的。
当然，最好还是做个性能测试都对比一下。 |
|
5
XiaoxiaoPu 2021-01-07 11:52:54 +08:00
另外一点，既然数据写入量很少，那么可以提前按 key 的分布情况做均匀分片，分到多个底层存储单元里（分多层也行），类似桶排序的思想。
|
Select Language