这是一个创建于 396 天前的主题，其中的信息可能已经有所发展或是发生改变。
用于存储样本的特征，几千维的浮点数据和文本数据。仅按照 id 查询，修改很少。目前用 mysql 存储（ longblob ），由于近期有图的需求，需要在一个请求里一次性查几百个 id ，耗时在 1min 左右。
 |
1
adoal 2023-10-30 20:41:43 +08:00
有没有可能耗时不在查询，而在大字段内容的传输
|
 |
3
lovelylain 2023-10-30 21:04:47 +08:00 via Android
仅按照 id 查询，是主键或唯一索引 id 吗，是的话才查几百个，不至于会超过 1min 吧
|
 |
4
OysterQAQ OP @lovelylain 是主键 先通过 nebula 进行随机游走得到 id 大概需要 1.2s 之后就是通过 id 到 mysql 查询了，其实测试了我十个请求一起也是 1min 左右平均耗时，在想要不要试试做个从库或者是找个别的小心的 btree 数据库同步过去
|
 |
5
chendy 2023-10-30 21:54:24 +08:00
看描述有点离谱
看需求可能直接用文件更合适 |
|
6
OysterQAQ OP @chendy 说大不大 说小也不小 就是图片的 2000 维的 float 特征和一些小型文本特征，mysql 没有数组 只能用 longblob 存（主要这特征其实是三个部分组成，所以三个 longblob 字段） 也到不了文件那个级别
|
 |
7
spediacn 2023-10-30 22:14:17 +08:00 via iPhone
查库干嘛，按 id 前两位+id 存为文件是不是更合适，磁盘索引速度远大于数据库检索速度的。如果数据有冷热之分就上个高速缓存来做热数据检索即可
|
 |
9
XiLingHost 2023-10-30 22:34:36 +08:00
如果只查 id 不查别的字段，你这个比较适合用 mongo 或者 es 这种文档数据库
|
|
10
OysterQAQ OP @XiLingHost 我想找一个 btree 存储模型的轻量 kv 数据库，感觉更加合适
|
|
11
XiLingHost 2023-10-30 23:05:28 +08:00
@OysterQAQ 那其实这种需求自己实现一个存储服务也许性能会更好
|
 |
12
kuituosi 2023-10-30 23:16:23 +08:00
明显文件啊
|
 |
13
sujin190 2023-10-30 23:26:50 +08:00 via Android
可以把 id 存库，查询和管理迁移方便，数据确实还是存文件更好，想要速度多机并行化就是了，缓存也更容易做，还可以用 hbase 之类的分布式存储，oss 服务之类的，扩展能力安全性效率都更好
|
 |
14
GeekGao 2023-10-30 23:36:08 +08:00
尝试一下分表呢
|
 |
15
LUO12826 2023-10-30 23:45:27 +08:00
你想要的东西是不是叫“向量数据库”。可以搜一下，已经有一些产品了
|
 |
16
mysunshinedreams 2023-10-31 05:58:15 +08:00
ID->对象存储唯一标识，东西存对象存储上面
|
 |
18
lsk569937453 2023-10-31 09:06:20 +08:00
其实 16 楼已经给出答案了，就是 mysql 只存储标识，id+标识。一般不会把二进制数据存储在 mysql 中。
还有我怀疑你这个耗时 1min 钟，是传输的数量太大导致的，毕竟 mysql 也要把数据从磁盘读出来。 |
 |
19
Desdemor 2023-10-31 09:14:53 +08:00
clickhouse 贼快
|
 |
20
8355 2023-10-31 09:21:02 +08:00
如果可以格式化成 json 推荐 MongoDB
如果是大文本推荐对象存储 |
 |
21
815979670 2023-10-31 09:55:38 +08:00
@Desdemor ClickHouse 快 但应该不符合 op 的需求，ClickHouse 是做 OLAP 场景的 如果是条数多还行，但是单条的内容多 可能不是很合适
|
|
22
OysterQAQ OP |
 |
23
MidGap 2023-10-31 11:21:53 +08:00
想判断是否是字段太大，这个思路靠谱么？建一张一样的表，存小的数据同样的查询比较一下，感觉光“觉得”没法找到有效解决办法呢~
|
 |
24
flmn 2023-10-31 11:54:28 +08:00
这种场景，很明显是 HBase 最适合的。
但是 HBase 的开销不小。 我想问下，在一个请求里一次性查几百个 id ，是查所有维度，还是单个或者几个维度？ |
 |
25
thevita 2023-10-31 14:53:04 +08:00
数千个维度 大概 数 K-数十 k, 典型小对象，存取, 数百个 也就 几十 MB ，mysql 要一分钟, 应该就是 io 次数多一点.
用 object store 或者 kv ？ 好处在于有现成的云或分布式方案，对 ssd 优化也好，能承担更大量的并发读 再，看读上是否有写 固定模式，可以适当做一些读优化设计（毕竟说 读多写少） |
 |
26
charslee013 2023-10-31 16:56:27 +08:00
> 主要是反过来用向量查 id 的 #22
有个疑惑，为什么不在 Milvus 新增一个 ID 字段用来映射 mysql 数据库？ 在 milvus 进行向量查询之后根据返回的 ID 字段来反向查询 mysql 数据库 🤔 |
Select Language