导师大概给了一个这么一个课题： 做一个 vfs 或者 fuse 兼容的海量小文件存储系统，文件要按照目录结构组织，场景是读远大于写。 导师给的基本想法就是数据存在 hbase 中，上面套一层 fuse 或者 vfs 。 不知道大家有没有其他更好的数据库选型推荐？最好开源，可以魔改。
最近在看 facebook 的 haystack，不过那个其实有点老了。
按你导师的想法来就好了啊，NoSQL 套一层 vfs 。这里的 NoSQL，你可以换成其他的 key value store 的数据库，比如 levelDB，这样好集成一点，不然，你搭建一个 hbase，麻烦的要死，等你把 hbase 搞明白，估计 vfs 的兴趣劲也过了
基本就是文件切块直接存盘到系统 fs 上面 然后按照一定规则生成目录 避免 fs 在某个目录下太多文件导致效率降低 然后利用 key-value 一类的数据库来存文件的具体索引 分布式的话就在上面再套一个 你可以试试 Cassandra 或者选其他的分布式 key-value 数据库 记录一下某个文件具体落到某个那个位置去就行 然后具体位置再由具体的 key-value 去把文件块找出来返回就行
简单点的实现可以参考下 Minio ？但是那个是对象存储 不知道是不是符合你导师的意思就是了…… 看你导师的意思应该是让你实现个基于块存储吧
分布是的话你套两层就行了 第一层是分布式的 key-value 数据库 用来记录所有文件的记录以及这些文件存在哪些节点上方 在单个节点上你可以直接把文件按照一定规则写入到不同的目录下面 然后有一个 daemon 一类的帮你存取文件 如果真的是真海量的话 你具体的 storage node 上面其实也需要一套 RocksDB 来帮你缓存具体的文件位置来加快索引速度 如果问减少的话其实按照一定 hash 来存就行 你甚至可以在每个机器上面跑一个 Minio 然后再用一个集中化的数据库来管理那些文件存到那个 Minio 上面都行……
用 Hash 得话稍微注意一下文件目录的数量就行 或者你可以换个别的方式 Hash 的问题就是在于你的一些参数变了可能所有文件的位置都要重新来一遍 不过因为是毕业设计所以应该也不用去考虑这些复杂的问题 但是如果文件数目多的话你要注意具体的 Node 上面单个目录下文件的数量 具体的设计可以参考 Ceph 的 Filestore 的实现