求[读多写少、大字段]数据库技术推荐

[OysterQAQ]

用于存储样本的特征，几千维的浮点数据和文本数据。仅按照 id 查询，修改很少。目前用 mysql 存储（ longblob ），由于近期有图的需求，需要在一个请求里一次性查几百个 id ，耗时在 1min 左右。

[adoal]

有没有可能耗时不在查询，而在大字段内容的传输

[OysterQAQ]

@adoal 我觉得可能是 longblob 的页读取吧，传输这个都在 local 上，应该不是问题

[lovelylain]

仅按照 id 查询，是主键或唯一索引 id 吗，是的话才查几百个，不至于会超过 1min 吧

[OysterQAQ]

@lovelylain 是主键 先通过 nebula 进行随机游走得到 id 大概需要 1.2s 之后就是通过 id 到 mysql 查询了，其实测试了我十个请求一起也是 1min 左右平均耗时，在想要不要试试做个从库或者是找个别的小心的 btree 数据库同步过去

[chendy]

看描述有点离谱
看需求可能直接用文件更合适

[OysterQAQ]

@chendy 说大不大 说小也不小 就是图片的 2000 维的 float 特征和一些小型文本特征，mysql 没有数组 只能用 longblob 存（主要这特征其实是三个部分组成，所以三个 longblob 字段） 也到不了文件那个级别

[spediacn]

查库干嘛，按 id 前两位+id 存为文件是不是更合适，磁盘索引速度远大于数据库检索速度的。如果数据有冷热之分就上个高速缓存来做热数据检索即可

[OysterQAQ]

@spediacn 在数据库里统一一些，千万条数据放文件也太怪了，而且没有到文件的体积

[XiLingHost]

如果只查 id 不查别的字段，你这个比较适合用 mongo 或者 es 这种文档数据库

[OysterQAQ]

@XiLingHost 我想找一个 btree 存储模型的轻量 kv 数据库，感觉更加合适

[XiLingHost]

@OysterQAQ 那其实这种需求自己实现一个存储服务也许性能会更好

[kuituosi]

明显文件啊

[sujin190]

可以把 id 存库，查询和管理迁移方便，数据确实还是存文件更好，想要速度多机并行化就是了，缓存也更容易做，还可以用 hbase 之类的分布式存储，oss 服务之类的，扩展能力安全性效率都更好

[GeekGao]

尝试一下分表呢

[LUO12826]

你想要的东西是不是叫“向量数据库”。可以搜一下，已经有一些产品了

[mysunshinedreams]

ID->对象存储唯一标识，东西存对象存储上面

[OysterQAQ]

@LUO12826 不是这个，这个我在用 milvus ，主要是反过来用向量查 id 的

[lsk569937453]

其实 16 楼已经给出答案了，就是 mysql 只存储标识，id+标识。一般不会把二进制数据存储在 mysql 中。

还有我怀疑你这个耗时 1min 钟，是传输的数量太大导致的，毕竟 mysql 也要把数据从磁盘读出来。

[Desdemor]

clickhouse 贼快

[8355]

如果可以格式化成 json 推荐 MongoDB
如果是大文本推荐对象存储