关于Hadoop做分布式文件服务器的问题考虑

南老頭 2013-12-05 10:59:17

本人菜鸟，最近在学习hadoop的知识，
因为公司项目的特殊性，文件存储占用特大的空间，TB级别以上，单个文件小到几kb,大到几个g,
目前采用的FTP方式存储，不管是磁盘空间、还是并发量的问题，迟早有一天会承受不了跨了，
于是突然有个想法，用hadoop的dfs来取代ftp搭建一个分布式的文件服务器，不用它的map/reduce,
从实现上来说没什么问题，不过不知道其他方面有没有什么问题或不适合的，比如hdfs的优势是否在于这层面\并发量等等。
请高手不吝赐教，小弟感激不尽。

...全文

7489 32 打赏收藏转发到动态举报

写回复

用AI写文章

32 条回复

切换为时间正序

请发表友善的回复…

发表回复

孤好梦中杀人 2013-12-16

打赏
举报

貌似openstack适合大量的小文件存量，它也可以作为分布式存储来用

blackkettle 2013-12-16

打赏
举报

路过

qq120848369 2013-12-16

打赏
举报

可以不可以在应用层做改进呢，比如多张小图合并为一张大图，或者更简单的多张小图打包成tar再存入gridfs.

云满笔记 2013-12-13

打赏
举报

Hadoop 好像很热门的样子

nettman 2013-12-13

打赏
举报

qq120848369 2013-12-13

打赏
举报

可以用mongodb的底层gridfs，适合大量小文件。

lzldf 2013-12-13

打赏
举报

感谢分享@！~~

南老頭 2013-12-13

打赏
举报

引用 9 楼 tntzbzc 的回复:

[quote=引用 5 楼 soflytanny 的回复:] [quote=引用 4 楼 tntzbzc 的回复:] 并发问题是否能解决，和hadoop没有直接关系虽然HADOOP结构解决了部分底层问题，但最终的系统并发能力和码农、运维的能力息息相关 HDFS做网盘的很多，但是！！！ HDFS不是对外出口，对外一般都有封装举个最简单的例子，HDFS就无法直接解决断点下载的问题。办法有很多推荐一个HDFS+HBASE的办法，让HBASE最为数据元存大数据（或小数据），HDFS作为文件系统底层这个办法不管是大文件还是小文件，几百GB或者几KB的文件，都可以通吃。。。呵呵，一行百万列文件数据就是这么诞生了。。。。

兄台用HBase是作为文件元数据存储用吗，比如文件名称、大小、存储路径、类型等，如此产品已经使用了oracle，是不是能直接取代HBase在此处的用途，请兄台赐教！[/quote] 对，用HBASE存文件。。Byte,KB,MB,GB(甚至TB，理论上可以，还没碰到过单个文件超过TB的) 只有实现过的童鞋才知道这种实现方式的强大，无需其他文件系统支持，HADOOP生态链直接搞定。。是不是能取代你的ORACLE，这需要更具你的业务需求以及团队技术能力，不能强求[/quote] 多谢撸大湿耐心的指点，不过我说的是在此处以oracle替代hbase,而不是反向替换，不知道在此处，这样是否能达到hbase 结合 hdfs的效果

南老頭 2013-12-13

打赏
举报

引用 19 楼 qq120848369 的回复:

可以用mongodb的底层gridfs，适合大量小文件。

引用 6 楼 soflytanny 的回复:

[quote=引用 3 楼 zhoutai1989 的回复:] 如果有大量的小文件，比如那些几十KB的文件要存，不适合使用HDFS，怎么处理可以找一些HDFS处理小文件的方式，或者针对这些文件选择更好的存储系统。还有就是看支持什么样的访问模式吧，不同的访问模式也会决定到底HDFS好不好用。

一般都是些OFFICE\图片图像、以及1/3的是视频文件，未来的话视频的容量应该会不断扩大，以前用过 mongodb 来实现分布式，最后用了一段时间发现问题太多最后换掉了，比如存储的图片，在产品页面上进行一个展示时，从mongodb里面读出来再以流的方式响应到客户端，效率非常底，因为图片多，一个页面几十几百个图片时，加载一个页面需要读几十、几百次数据库[/quote] 之前用过gridfs，但遇到了问题，在6楼说到了

南老頭 2013-12-13

打赏
举报

引用 16 楼 5653325 的回复:

用淘宝的TFS啊，开源的 http://tfs.taobao.org/

TFS怎么样，阁下在用吗？

陪代码一起浪迹天涯 2013-12-12

打赏
举报

最近在学习hadoop的知识，看下

tzlcy168 2013-12-12

打赏
举报

引用 8 楼 jiangheng0535 的回复:

为什么不分类存储呢？大文件放hdfs，小文件存其它系统，这样不行吗？何必把不同的东西放在一起啊，分开能解决很多问题吧？
引用 10 楼 nettman 的回复:
引用 8 楼 jiangheng0535 的回复:
为什么不分类存储呢？大文件放hdfs，小文件存其它系统，这样不行吗？何必把不同的东西放在一起啊，分开能解决很多问题吧？

tzlcy168 2013-12-12

打赏
举报

引用楼主 soflytanny 的回复:

本人菜鸟，最近在学习hadoop的知识，因为公司项目的特殊性，文件存储占用特大的空间，TB级别以上，单个文件小到几kb,大到几个g, 目前采用的FTP方式存储，不管是磁盘空间、还是并发量的问题，迟早有一天会承受不了跨了，于是突然有个想法，用hadoop的dfs来取代ftp搭建一个分布式的文件服务器，不用它的map/reduce, 从实现上来说没什么问题，不过不知道其他方面有没有什么问题或不适合的，比如hdfs的优势是否在于这层面\并发量等等。请高手不吝赐教，小弟感激不尽。

引用 10 楼 nettman 的回复:

nettman 2013-12-12

打赏
举报

撸大湿 2013-12-12

打赏
举报

引用 5 楼 soflytanny 的回复:

[quote=引用 4 楼 tntzbzc 的回复:] 并发问题是否能解决，和hadoop没有直接关系虽然HADOOP结构解决了部分底层问题，但最终的系统并发能力和码农、运维的能力息息相关 HDFS做网盘的很多，但是！！！ HDFS不是对外出口，对外一般都有封装举个最简单的例子，HDFS就无法直接解决断点下载的问题。办法有很多推荐一个HDFS+HBASE的办法，让HBASE最为数据元存大数据（或小数据），HDFS作为文件系统底层这个办法不管是大文件还是小文件，几百GB或者几KB的文件，都可以通吃。。。呵呵，一行百万列文件数据就是这么诞生了。。。。

晚起的鸟 2013-12-12

打赏
举报

为什么不分类存储呢？大文件放hdfs，小文件存其它系统，这样不行吗？何必把不同的东西放在一起啊，分开能解决很多问题吧？

Touch_l 2013-12-12

打赏
举报

不了解。。

franwee 2013-12-12

打赏
举报

HDFS不适用条件如下：低延迟数据访问 HDFS是为了达到高数据吞吐量而优化的，这是以延迟为代价的，对于低延迟访问，可以用Hbase（hadoop的子项目）。大量的小文件由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总量受限制于namenode的内存容量多用户写入，任意修改

踏平扶桑 2013-12-12