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

2020-10-10 17:33:02 +08:00
 alexanderchiu

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

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

3568 次点击
所在节点    问与答
26 条回复
heyjei
2020-10-10 17:39:20 +08:00
啥学校啊,你们的毕设都这么高端嘛?

按你导师的想法来就好了啊,NoSQL 套一层 vfs 。这里的 NoSQL,你可以换成其他的 key value store 的数据库,比如 levelDB,这样好集成一点,不然,你搭建一个 hbase,麻烦的要死,等你把 hbase 搞明白,估计 vfs 的兴趣劲也过了
alexanderchiu
2020-10-10 17:44:47 +08:00
@heyjei 上海某 985... 哎不过 levelDB,rocksDB 这种基于 LSM 的存储引擎场景好像都是写大于读的?读放大可能比较严重? 嗯嗯不过这个思路是不错,hbase 太他妈麻烦了哈哈哈哈哈
heyjei
2020-10-10 17:53:34 +08:00
@alexanderchiu 中间加一个 cache,这个 cache 就是你论文的亮点和难点
kuro1
2020-10-10 17:54:44 +08:00
badger
stephenxiaxy
2020-10-10 18:00:35 +08:00
clickhouse ?
alexanderchiu
2020-10-10 18:05:25 +08:00
@heyjei 好思路 我研究下
alexanderchiu
2020-10-10 18:06:17 +08:00
@kuro1 这个好 刚好我就想用 go 来写毕设
alexanderchiu
2020-10-10 18:08:38 +08:00
@stephenxiaxy clickhouse 我理解还是偏数仓,不像 nosql 一样提供 kv 这种关系模式而是用传统关系模型 不知如何结合起来呢
AngryPanda
2020-10-10 18:08:56 +08:00
本科毕业设计这个难度的确可以
zmxnv123
2020-10-10 19:24:48 +08:00
盲猜上交? 其实这种毕设比各种基于机器学习的 xxx 有意思多了,要是我本科能遇到这种毕设就好了。
alexanderchiu
2020-10-10 19:28:39 +08:00
@zmxnv123 猜错了 hh 我也觉得做偏 system 的会更有意思哈哈
XiaoxiaoPu
2020-10-10 19:36:49 +08:00
这个“海量”是多海量?要是海量到单机存不下,可能还得考虑分布式吧。
alexanderchiu
2020-10-10 19:44:35 +08:00
@XiaoxiaoPu 老师要求的是分布式。但毕竟是本科毕设所以要求可能会低一点...测试数据量可能就几个 G 或者十几 g,然后每个文件几十 kb-几 mb
twl007
2020-10-10 19:54:00 +08:00
套个 rocksdb 也没啥不好的 参考 Ceph 的 OSD 部分 实现 用 rocksdb 去缓存整个存入文件的索引 可以看看老版本基于 Filesystem 的实现

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

简单点的实现可以参考下 Minio ?但是那个是对象存储 不知道是不是符合你导师的意思就是了…… 看你导师的意思应该是让你实现个基于块存储吧
XiaoxiaoPu
2020-10-10 19:59:21 +08:00
分布式的话,需要注意到 LevelDB 、RocksDB 是单机嵌入式 KV 存储引擎,分布式相关的工作需要你自己做。
twl007
2020-10-10 20:02:26 +08:00
LevelDB RocksDB 不要直接拿来存文件 用来存你具体文件的 block 的索引就好 Ceph 的 BlueStore 底层就是用 RocksDB 来存文件块索引的 相当于 XFS 里面 inode

分布是的话你套两层就行了 第一层是分布式的 key-value 数据库 用来记录所有文件的记录以及这些文件存在哪些节点上方 在单个节点上你可以直接把文件按照一定规则写入到不同的目录下面 然后有一个 daemon 一类的帮你存取文件 如果真的是真海量的话 你具体的 storage node 上面其实也需要一套 RocksDB 来帮你缓存具体的文件位置来加快索引速度 如果问减少的话其实按照一定 hash 来存就行 你甚至可以在每个机器上面跑一个 Minio 然后再用一个集中化的数据库来管理那些文件存到那个 Minio 上面都行……
twl007
2020-10-10 20:11:17 +08:00
开源的话有个符合你要求的
https://github.com/chrislusf/seaweedfs
catror
2020-10-10 20:14:11 +08:00
要分布式,还是部署 HBase 吧,或者其他的分布式 KV 存储也行,都一样。先别考虑太多,能把流程跑通再优化。
alexanderchiu
2020-10-10 20:14:16 +08:00
@twl007 老哥牛逼 大概有了比较清晰的认识。写入不同目录的话用 hash ? 嗯由于想用 go 写,感觉可以试试楼上提的 BadgerDB,也是类似于 rocksdb 。 是不是可以这么理解,第一层的数据库的 key 是文件名,value 是节点名 /目录名 第二层数据库的 key 是文件名,value 是 block 的位置?
alexanderchiu
2020-10-10 20:14:42 +08:00
@catror 好可以先试试 hbase

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/713740

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX