V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
LeeReamond
V2EX  ›  程序员

有什么适合管理大量二进制文件的数据库解决方案吗?

  •  1
     
  •   LeeReamond · 2023-02-16 13:45:55 +08:00 · 1468 次点击
    这是一个创建于 647 天前的主题,其中的信息可能已经有所发展或是发生改变。

    需求:有大量零散二进制文件,每个体积不大大概 16KB 左右,但是数量比较多有大概 5 千万-6 千万个。业务上并发访问量比较大,需要一个读取场景下性能优化最多的数据库。。。。

    同事出了两个方案,一个是用 oracleDB 一个是用 mongoDB ,但是感觉都有一点点合适,但是又不太合适,所以感觉很别扭。

    mongoDB 的缺点在于,我们的数据是结构化的,每个文件体积都是精确相同的,mongoDB 似乎对于这种结构化场景没有做较多优化,读取性能可能无法胜任高 qps 。

    oracleDB 也能索引二进制数据,但是我们的数据整体关系上是非常简单的,基本就是 kv 索引,最多再加个时间范围,oracle 对复杂关系做了很多优化似乎也是我们用不上的,同样担心无法胜任高 qps 。另外 oracle 的水平扩展也没有前者舒服,成本也是一方面问题。

    ========

    可能有朋友会说直接用操作系统的文件管理系统。。。我们业务上没这么做过不知道行不行,但是感觉大量并发读取和少数写入并发的时候,这东西稳不稳啊。。。而且没有内存缓存之类的,感觉很亏,系统有个 iobuffer 但是比数据库的内存缓存要小太多了。。。

    16 条回复    2023-02-16 20:24:32 +08:00
    opengps
        1
    opengps  
       2023-02-16 14:00:28 +08:00
    数量总量太大,存入你的数据库之后索引文件本身也会大,这时候相比文件系统直接读取,就多了一层扫描大索引的过程,实际效果未必更快。
    如果服务器内存足够大,你可以尝试下 redis ,直接内存操作必然比硬盘读写快很多,而且 redis 天然支持的分布式也有利于你增加机器实现集群效果
    cheng6563
        2
    cheng6563  
       2023-02-16 14:08:30 +08:00
    不追求高可用的话,放文件系统就是最舒适的了,多建几层文件夹当目录就行。

    操作系统的文件缓存是把所有未使用的内存拿来当缓存的。
    flashBee233
        3
    flashBee233  
       2023-02-16 14:25:24 +08:00
    不知道 OSS+CDN 能不能行
    israinbow
        4
    israinbow  
       2023-02-16 14:25:25 +08:00
    HDFS 上套 Hbase, 如果读写小文件是有规律结构的还可以套 HAR 上去, 这算是数据库的解决方案吧.
    opengps
        5
    opengps  
       2023-02-16 14:27:01 +08:00
    @flashBee233 #3 op 的用法,oss 的 https 请求次数会太贵
    deltadawn
        6
    deltadawn  
       2023-02-16 14:33:17 +08:00
    Cassandra
    MoYi123
        7
    MoYi123  
       2023-02-16 14:47:52 +08:00
    这个问题的关键点在你要怎么查,
    如果只需要遍历, 那直接压缩了就行了.
    如果要查就要考虑怎么做索引, 直接放文件系统只靠目录确定能查到吗?
    BeautifulSoap
        8
    BeautifulSoap  
       2023-02-16 14:50:11 +08:00
    小文件直接写到文件系统里其实还行,除了会浪费很多空间。但是一旦写了就再也别再想着迁移到其他分区或硬盘了。真这么干过过的人表示你这么做的话,迁移文件的时候就是一场噩梦。

    选择专门存储小文件的分布式文件系统就行了。Hadoop HDFS ,minio 之类的
    tool2d
        9
    tool2d  
       2023-02-16 14:52:26 +08:00
    5 千万级别肯定选数据库啊,存文件系统想什么呢?

    就算文件再小,只要数量上去了,NTFS 的 MFT 表也是有开销的。

    如果我是 OP 同事,就上定制化 KV 数据库,二进制文件只要把索引整好就可以了。
    pragmatwice
        10
    pragmatwice  
       2023-02-16 14:55:52 +08:00 via Android
    opengg
        11
    opengg  
       2023-02-16 14:57:05 +08:00
    用分布式的 KV 数据库就行。
    makelove
        12
    makelove  
       2023-02-16 15:22:18 +08:00
    最大 5000w 好象也不是很多,要求不严的话文件系统也能用的吧,我以前小鸡上试过上千 w 的没什么问题,一开始不懂用了 ext4 直接 inode 爆了,后来只能转 reiserfs 这类无限 inode 的 fs
    dx3759
        13
    dx3759  
       2023-02-16 19:02:09 +08:00
    小文件,找一个分布式 KV 数据库就够,才 5000w
    LeeReamond
        14
    LeeReamond  
    OP
       2023-02-16 19:11:32 +08:00
    @tool2d 有具体推荐吗,没啥研究,都是数据炸了之后才开始想办法。。。
    LeeReamond
        15
    LeeReamond  
    OP
       2023-02-16 19:16:39 +08:00
    @BeautifulSoap hadoop 感觉可能是很适合这种场景的解决方案,但查了查感觉它宣称的几个缺陷,一个是入库后无法修改,二是宣称低延迟场景无法实现,我们业务上就需要查询快速出结果
    PythonYXY
        16
    PythonYXY  
       2023-02-16 20:24:32 +08:00
    感觉 hbase+mob 就可以吧。你们的查询 QPS 有多少,主要是点查还是范围查询?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   904 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 22:04 · PVG 06:04 · LAX 14:04 · JFK 17:04
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.