本科毕设做一个海量小文件存储系统，数据库选型？ paper 推荐？

[alexanderchiu]

导师大概给了一个这么一个课题： 做一个 vfs 或者 fuse 兼容的海量小文件存储系统，文件要按照目录结构组织，场景是读远大于写。 导师给的基本想法就是数据存在 hbase 中，上面套一层 fuse 或者 vfs 。 不知道大家有没有其他更好的数据库选型推荐？最好开源，可以魔改。

最近在看 facebook 的 haystack，不过那个其实有点老了。

[heyjei]

啥学校啊，你们的毕设都这么高端嘛？

按你导师的想法来就好了啊，NoSQL 套一层 vfs 。这里的 NoSQL，你可以换成其他的 key value store 的数据库，比如 levelDB，这样好集成一点，不然，你搭建一个 hbase，麻烦的要死，等你把 hbase 搞明白，估计 vfs 的兴趣劲也过了

[alexanderchiu]

@heyjei 上海某 985... 哎不过 levelDB,rocksDB 这种基于 LSM 的存储引擎场景好像都是写大于读的？读放大可能比较严重？ 嗯嗯不过这个思路是不错，hbase 太他妈麻烦了哈哈哈哈哈

[heyjei]

@alexanderchiu 中间加一个 cache，这个 cache 就是你论文的亮点和难点

[kuro1]

badger

[stephenxiaxy]

clickhouse ？

[alexanderchiu]

@heyjei 好思路 我研究下

[alexanderchiu]

@kuro1 这个好 刚好我就想用 go 来写毕设

[alexanderchiu]

@stephenxiaxy clickhouse 我理解还是偏数仓，不像 nosql 一样提供 kv 这种关系模式而是用传统关系模型 不知如何结合起来呢

[AngryPanda]

本科毕业设计这个难度的确可以

[zmxnv123]

盲猜上交？ 其实这种毕设比各种基于机器学习的 xxx 有意思多了，要是我本科能遇到这种毕设就好了。

[alexanderchiu]

@zmxnv123 猜错了 hh 我也觉得做偏 system 的会更有意思哈哈

[XiaoxiaoPu]

这个“海量”是多海量？要是海量到单机存不下，可能还得考虑分布式吧。

[alexanderchiu]

@XiaoxiaoPu 老师要求的是分布式。但毕竟是本科毕设所以要求可能会低一点...测试数据量可能就几个 G 或者十几 g,然后每个文件几十 kb-几 mb

[twl007]

套个 rocksdb 也没啥不好的 参考 Ceph 的 OSD 部分 实现 用 rocksdb 去缓存整个存入文件的索引 可以看看老版本基于 Filesystem 的实现

基本就是文件切块直接存盘到系统 fs 上面 然后按照一定规则生成目录 避免 fs 在某个目录下太多文件导致效率降低 然后利用 key-value 一类的数据库来存文件的具体索引 分布式的话就在上面再套一个 你可以试试 Cassandra 或者选其他的分布式 key-value 数据库 记录一下某个文件具体落到某个那个位置去就行 然后具体位置再由具体的 key-value 去把文件块找出来返回就行

简单点的实现可以参考下 Minio ？但是那个是对象存储 不知道是不是符合你导师的意思就是了…… 看你导师的意思应该是让你实现个基于块存储吧

[XiaoxiaoPu]

分布式的话，需要注意到 LevelDB 、RocksDB 是单机嵌入式 KV 存储引擎，分布式相关的工作需要你自己做。

[twl007]

LevelDB RocksDB 不要直接拿来存文件 用来存你具体文件的 block 的索引就好 Ceph 的 BlueStore 底层就是用 RocksDB 来存文件块索引的 相当于 XFS 里面 inode

分布是的话你套两层就行了 第一层是分布式的 key-value 数据库 用来记录所有文件的记录以及这些文件存在哪些节点上方 在单个节点上你可以直接把文件按照一定规则写入到不同的目录下面 然后有一个 daemon 一类的帮你存取文件 如果真的是真海量的话 你具体的 storage node 上面其实也需要一套 RocksDB 来帮你缓存具体的文件位置来加快索引速度 如果问减少的话其实按照一定 hash 来存就行 你甚至可以在每个机器上面跑一个 Minio 然后再用一个集中化的数据库来管理那些文件存到那个 Minio 上面都行……

[twl007]

开源的话有个符合你要求的
https://github.com/chrislusf/seaweedfs

[catror]

要分布式，还是部署 HBase 吧，或者其他的分布式 KV 存储也行，都一样。先别考虑太多，能把流程跑通再优化。

[alexanderchiu]

@twl007 老哥牛逼 大概有了比较清晰的认识。写入不同目录的话用 hash ？ 嗯由于想用 go 写，感觉可以试试楼上提的 BadgerDB，也是类似于 rocksdb 。 是不是可以这么理解，第一层的数据库的 key 是文件名，value 是节点名 /目录名 第二层数据库的 key 是文件名，value 是 block 的位置？

[alexanderchiu]

@catror 好可以先试试 hbase

[twl007]

@alexanderchiu 对 第一层其实存具体的节点和文件位置就行 止痒方便你在 vfs 或者 fuse 上面写的时候能生成具体的目录结构 然后 storage node 上面再去具体负责单个文件的存储 然后用 key-value 的数据库来做索引 负责把文件从具体位置捞出来

用 Hash 得话稍微注意一下文件目录的数量就行 或者你可以换个别的方式 Hash 的问题就是在于你的一些参数变了可能所有文件的位置都要重新来一遍 不过因为是毕业设计所以应该也不用去考虑这些复杂的问题 但是如果文件数目多的话你要注意具体的 Node 上面单个目录下文件的数量 具体的设计可以参考 Ceph 的 Filestore 的实现

[my3157]

tikv + fuse

[GaoGeYang]

巧了，我本科毕设也是类似的选题，不过思路不太一样。文件存储用的是 FastDFS，然后用数据库记录文件目录路径。

[chrislusf]

SeaweedFS filer store 可以支持一般的 key-value store，比如 Cassandra. 现在正好 HBase 的还没有支持。欢迎参与开发！不过工作量可能比较小。加一两个文件就可以了。

[user8341]

@heyjei
就是啊。读远大于写，明显就应该用 cache 。套一层 memcached ？

[peterlitszo]

OP 还在吗，最近本科毕业设计也有点想写偏底层的东西，请问能看看你的论文参考参考咩？