感觉pg就行了

【 在 chemphy123 的大作中提到: 】
: 多谢，纯粹科研用的，就我自己一个人用，一天只请求一百次左右。
--
FROM 119.139.198.*

value进行压缩，全load到内存里面，用hashmap查试试，可能一个hashmap不够，量大就慢，那就分片，多线程查
【 在 chemphy123 的大作中提到: 】
: 我有10亿个字符串，每个大概100个字符。
: 这些数据存磁盘上，gzip压缩后大概有18G。
: 需求是，一次按id号从中取20000个字符串出来。
: ...................
--
FROM 218.30.113.*

另外，数据使用也分情况
如果你的另一个数据集，规模在万级别，需要关联检索这个10亿级别的数据，然后进行其他计算。这种情况可以先把这个万级别的数据，用一晚上的时间，用最笨的办法先完成万级别的数据检索（把你关心的数据都合并到这个万级别的数据里面），然后就可以不用管那个十亿级别的数据了

【 在 chemphy123 的大作中提到: 】
: 多谢，纯粹科研用的，就我自己一个人用，一天只请求一百次左右。
:
--
FROM 219.142.238.*

自己写个小程序很容易，他有128G内存，字符串压缩一下大概60%的效率，加上key的占用，总共7,8十G的空间就够了。你说的这个也行，在内存不够用的时候用文件存储也完全没问题。现在磁盘也挺快的，还有一些针对磁盘加速的开发包。

【 在 chunhui 的大作中提到: 】
: 如果不用现成的kv数据库自己弄，其实不用把字符串加载到内存，只把key加载到内存即可。key指向数据文件的便宜位置。
: 这样内存不需要很多，查找速度飞快，找到key之后根据偏移位置再读字符串。
--
FROM 218.30.113.*

这个问题瓶颈不在查key，而在于读value

20000个随机读，缓存不够落在磁盘上的话，HDD的响应太慢

【 在 chunhui 的大作中提到: 】
: 如果不用现成的kv数据库自己弄，其实不用把字符串加载到内存，只把key加载到内存即可。key指向数据文件的便宜位置。
: 这样内存不需要很多，查找速度飞快，找到key之后根据偏移位置再读字符串。
--
FROM 115.171.245.*