1、为何散布式文件系统要采取特定的组织结构来存储文件？
直接依照文件的原始路径进行存储和复制，这样就能够直接通过利用服务进行静态化访问，从而大幅度提升性能。怎样样，这个主张不错吧？
等等，我们好像又绕回去了…..
这样的1个系统，大概是1个同享文件系统?或是1个文件分发系统。
如果只是同享文件系统，文件太多了怎样办？文件访问压力太大了怎样办？文件丢失了怎样办？文件错了怎样办？文件服务器挂了怎样办？
怎样办，怎样办，怎样办？
没有那末多怎样办，所以我们在经历过这些实践和使用以后，结论就是，用散布式文件系统，就这么办。
2、散布式文件系统能够帮我们做甚么（优点）
可以组建包括大量便宜服务器的海量存储系统，这是文件分发和同步不容易做到的；
通过内部的冗余复制，保证文件的可用性，在海量存储系统中，容错能力非常非常重要；
可扩大性很强，增加存储节点和追踪器都比较容易；
在多个文件副本之间就进行负载均衡，可以通过横向扩大来确保性能的提升。
进行特定的索引文件的计算等；
…
3、散布式文件系统的不足或说缺点
低延时访问
散布式文件系统不太合适于那些要求低延时（数10毫秒）访问的利用程序，由于散布式文件系统是设计用于海量数据处理的，这是以1定延时为代价的。对低延时访问，经典和传统的办法就是数据库，我们所爱好的ORACLE就很善于干这个事情。
比如1个支付系统，对它的核心支付体系，后端用P590小型机+ORACLE，当支付的范围愈来愈大的时候。小型机+ORACLE的支付体系会非常痛苦。对数据库横向扩大，水平切分都是方法，但是直接想把核心支付模块切换到散布式文件系统上，确切有挑战，当年没有成功过。（1家之言，说不定你们能弄定，仅供参考）
频繁修改的文件的利用
目前经常使用的散布式文件系统，基本都是“1次写屡次读”的模式，如果触及到大量数据的频繁修改，那末这个问题就相对照较麻烦；
海量小文件
散布式文件系统把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是有限的。1般来讲，每个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每个占据1个Block，你就最少需要300MB内存。当前来讲，数百万的文件还是可行的，当扩大到数10亿时，对当前的硬件水平来讲就很痛苦了。因此由于海量元数据的因素，散布式文件系统对待海量小文件相对照较乏力。
其他
1些直接通过http访问的文件，比如脚本、CSS等。
要进行复杂的计算，比如计算要发射火箭到火星上去，顺便在宇宙飞船上要配置1桌麻将，需要计算有多少的能力，要有多少的着力点；