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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 389 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

MySQL

longblob

浮点

存储

26 条回复 • 2023-10-31 16:56:27 +08:00

adoal

2023-10-30 20:41:43 +08:00

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

OysterQAQ

2023-10-30 20:43:31 +08:00

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

lovelylain

2023-10-30 21:04:47 +08:00 via Android

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

OysterQAQ

2023-10-30 21:15:15 +08:00

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

chendy

2023-10-30 21:54:24 +08:00

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

OysterQAQ

2023-10-30 22:14:10 +08:00

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

spediacn

2023-10-30 22:14:17 +08:00 via iPhone

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

OysterQAQ

2023-10-30 22:16:28 +08:00

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

XiLingHost

2023-10-30 22:34:36 +08:00

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

OysterQAQ

2023-10-30 22:54:47 +08:00 via iPad

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

XiLingHost

2023-10-30 23:05:28 +08:00

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

kuituosi

2023-10-30 23:16:23 +08:00

明显文件啊

sujin190

2023-10-30 23:26:50 +08:00 via Android

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

GeekGao

2023-10-30 23:36:08 +08:00

尝试一下分表呢

LUO12826

2023-10-30 23:45:27 +08:00

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

mysunshinedreams

2023-10-31 05:58:15 +08:00

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

OysterQAQ

2023-10-31 08:15:53 +08:00 via iPhone

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

lsk569937453

2023-10-31 09:06:20 +08:00

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

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

Desdemor

2023-10-31 09:14:53 +08:00

clickhouse 贼快

8355

2023-10-31 09:21:02 +08:00

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

815979670

2023-10-31 09:55:38 +08:00

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

OysterQAQ

2023-10-31 10:05:04 +08:00

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

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

MidGap

2023-10-31 11:21:53 +08:00

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

flmn

2023-10-31 11:54:28 +08:00

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

但是 HBase 的开销不小。

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

thevita

2023-10-31 14:53:04 +08:00

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

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

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

charslee013

2023-10-31 16:56:27 +08:00

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

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

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