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

[LeeReamond]

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

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

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

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

========

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

[opengps]

数量总量太大，存入你的数据库之后索引文件本身也会大，这时候相比文件系统直接读取，就多了一层扫描大索引的过程，实际效果未必更快。
如果服务器内存足够大，你可以尝试下 redis ，直接内存操作必然比硬盘读写快很多，而且 redis 天然支持的分布式也有利于你增加机器实现集群效果

[cheng6563]

不追求高可用的话，放文件系统就是最舒适的了，多建几层文件夹当目录就行。

操作系统的文件缓存是把所有未使用的内存拿来当缓存的。

[flashBee233]

不知道 OSS+CDN 能不能行

[israinbow]

HDFS 上套 Hbase, 如果读写小文件是有规律结构的还可以套 HAR 上去, 这算是数据库的解决方案吧.

[opengps]

@flashBee233 #3 op 的用法，oss 的 https 请求次数会太贵

[deltadawn]

Cassandra

[MoYi123]

这个问题的关键点在你要怎么查,
如果只需要遍历, 那直接压缩了就行了.
如果要查就要考虑怎么做索引, 直接放文件系统只靠目录确定能查到吗?

[BeautifulSoap]

小文件直接写到文件系统里其实还行，除了会浪费很多空间。但是一旦写了就再也别再想着迁移到其他分区或硬盘了。真这么干过过的人表示你这么做的话，迁移文件的时候就是一场噩梦。

选择专门存储小文件的分布式文件系统就行了。Hadoop HDFS ，minio 之类的

[tool2d]

5 千万级别肯定选数据库啊，存文件系统想什么呢？

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

如果我是 OP 同事，就上定制化 KV 数据库，二进制文件只要把索引整好就可以了。

[pragmatwice]

https://github.com/apache/incubator-kvrocks

[opengg]

用分布式的 KV 数据库就行。

[makelove]

最大 5000w 好象也不是很多，要求不严的话文件系统也能用的吧，我以前小鸡上试过上千 w 的没什么问题，一开始不懂用了 ext4 直接 inode 爆了，后来只能转 reiserfs 这类无限 inode 的 fs

[dx3759]

小文件，找一个分布式 KV 数据库就够，才 5000w

[LeeReamond]

@tool2d 有具体推荐吗，没啥研究，都是数据炸了之后才开始想办法。。。

[LeeReamond]

@BeautifulSoap hadoop 感觉可能是很适合这种场景的解决方案，但查了查感觉它宣称的几个缺陷，一个是入库后无法修改，二是宣称低延迟场景无法实现，我们业务上就需要查询快速出结果

[PythonYXY]

感觉 hbase+mob 就可以吧。你们的查询 QPS 有多少，主要是点查还是范围查询？