V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
OysterQAQ
V2EX  ›  数据库

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

  •  1
     
  •   OysterQAQ · 180 天前 · 1462 次点击
    这是一个创建于 180 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    26 条回复    2023-10-31 16:56:27 +08:00
    adoal
        1
    adoal  
       180 天前
    有没有可能耗时不在查询,而在大字段内容的传输
    OysterQAQ
        2
    OysterQAQ  
    OP
       180 天前
    @adoal 我觉得可能是 longblob 的页读取吧,传输这个都在 local 上,应该不是问题
    lovelylain
        3
    lovelylain  
       180 天前 via Android
    仅按照 id 查询,是主键或唯一索引 id 吗,是的话才查几百个,不至于会超过 1min 吧
    OysterQAQ
        4
    OysterQAQ  
    OP
       180 天前
    @lovelylain 是主键 先通过 nebula 进行随机游走得到 id 大概需要 1.2s 之后就是通过 id 到 mysql 查询了,其实测试了我十个请求一起也是 1min 左右平均耗时,在想要不要试试做个从库或者是找个别的小心的 btree 数据库同步过去
    chendy
        5
    chendy  
       180 天前
    看描述有点离谱
    看需求可能直接用文件更合适
    OysterQAQ
        6
    OysterQAQ  
    OP
       180 天前
    @chendy 说大不大 说小也不小 就是图片的 2000 维的 float 特征和一些小型文本特征,mysql 没有数组 只能用 longblob 存(主要这特征其实是三个部分组成,所以三个 longblob 字段) 也到不了文件那个级别
    spediacn
        7
    spediacn  
       180 天前 via iPhone
    查库干嘛,按 id 前两位+id 存为文件是不是更合适,磁盘索引速度远大于数据库检索速度的。如果数据有冷热之分就上个高速缓存来做热数据检索即可
    OysterQAQ
        8
    OysterQAQ  
    OP
       180 天前
    @spediacn 在数据库里统一一些,千万条数据放文件也太怪了,而且没有到文件的体积
    XiLingHost
        9
    XiLingHost  
       180 天前
    如果只查 id 不查别的字段,你这个比较适合用 mongo 或者 es 这种文档数据库
    OysterQAQ
        10
    OysterQAQ  
    OP
       180 天前 via iPad
    @XiLingHost 我想找一个 btree 存储模型的轻量 kv 数据库,感觉更加合适
    XiLingHost
        11
    XiLingHost  
       180 天前
    @OysterQAQ 那其实这种需求自己实现一个存储服务也许性能会更好
    kuituosi
        12
    kuituosi  
       180 天前
    明显文件啊
    sujin190
        13
    sujin190  
       180 天前 via Android
    可以把 id 存库,查询和管理迁移方便,数据确实还是存文件更好,想要速度多机并行化就是了,缓存也更容易做,还可以用 hbase 之类的分布式存储,oss 服务之类的,扩展能力安全性效率都更好
    GeekGao
        14
    GeekGao  
       180 天前
    尝试一下分表呢
    LUO12826
        15
    LUO12826  
       180 天前
    你想要的东西是不是叫“向量数据库”。可以搜一下,已经有一些产品了
    mysunshinedreams
        16
    mysunshinedreams  
       180 天前
    ID->对象存储唯一标识,东西存对象存储上面
    OysterQAQ
        17
    OysterQAQ  
    OP
       179 天前 via iPhone
    @LUO12826 不是这个,这个我在用 milvus ,主要是反过来用向量查 id 的
    lsk569937453
        18
    lsk569937453  
       179 天前
    其实 16 楼已经给出答案了,就是 mysql 只存储标识,id+标识。一般不会把二进制数据存储在 mysql 中。

    还有我怀疑你这个耗时 1min 钟,是传输的数量太大导致的,毕竟 mysql 也要把数据从磁盘读出来。
    Desdemor
        19
    Desdemor  
       179 天前
    clickhouse 贼快
    8355
        20
    8355  
       179 天前
    如果可以格式化成 json 推荐 MongoDB
    如果是大文本推荐对象存储
    815979670
        21
    815979670  
       179 天前
    @Desdemor ClickHouse 快 但应该不符合 op 的需求,ClickHouse 是做 OLAP 场景的 如果是条数多还行,但是单条的内容多 可能不是很合适
    OysterQAQ
        22
    OysterQAQ  
    OP
       179 天前
    @8355 我不知道算不算大文本 三个 longblob 字段分别是 1024 维的 float 数组 512 维 float 数组 256 维 flost 数组

    @Desdemor olap 适合数据聚合分析而不是单条查询吧
    MidGap
        23
    MidGap  
       179 天前
    想判断是否是字段太大,这个思路靠谱么?建一张一样的表,存小的数据同样的查询比较一下,感觉光“觉得”没法找到有效解决办法呢~
    flmn
        24
    flmn  
       179 天前
    这种场景,很明显是 HBase 最适合的。

    但是 HBase 的开销不小。

    我想问下,在一个请求里一次性查几百个 id ,是查所有维度,还是单个或者几个维度?
    thevita
        25
    thevita  
       179 天前
    数千个维度 大概 数 K-数十 k, 典型小对象,存取, 数百个 也就 几十 MB ,mysql 要一分钟, 应该就是 io 次数多一点.
    用 object store 或者 kv ?

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

    再,看读上是否有写 固定模式,可以适当做一些读优化设计(毕竟说 读多写少)
    charslee013
        26
    charslee013  
       179 天前
    > 主要是反过来用向量查 id 的 #22

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

    在 milvus 进行向量查询之后根据返回的 ID 字段来反向查询 mysql 数据库 🤔
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1330 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 23:58 · PVG 07:58 · LAX 16:58 · JFK 19:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.