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

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

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

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

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

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

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

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

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

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

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

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

明显文件啊

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

尝试一下分表呢

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

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

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

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

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

clickhouse 贼快

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

@Desdemor ClickHouse 快 但应该不符合 op 的需求，ClickHouse 是做 OLAP 场景的 如果是条数多还行，但是单条的内容多 可能不是很合适

@8355 我不知道算不算大文本 三个 longblob 字段分别是 1024 维的 float 数组 512 维 float 数组 256 维 flost 数组

@Desdemor olap 适合数据聚合分析而不是单条查询吧

想判断是否是字段太大，这个思路靠谱么？建一张一样的表，存小的数据同样的查询比较一下，感觉光“觉得”没法找到有效解决办法呢~

这种场景，很明显是 HBase 最适合的。

但是 HBase 的开销不小。

我想问下，在一个请求里一次性查几百个 id ，是查所有维度，还是单个或者几个维度？

数千个维度 大概 数 K-数十 k, 典型小对象，存取, 数百个 也就 几十 MB ，mysql 要一分钟, 应该就是 io 次数多一点.
用 object store 或者 kv ？

好处在于有现成的云或分布式方案，对 ssd 优化也好，能承担更大量的并发读

再，看读上是否有写 固定模式，可以适当做一些读优化设计（毕竟说 读多写少）

> 主要是反过来用向量查 id 的 #22

有个疑惑，为什么不在 Milvus 新增一个 ID 字段用来映射 mysql 数据库？

在 milvus 进行向量查询之后根据返回的 ID 字段来反向查询 mysql 数据库