适合Web内容的分布式文件系统-从google文件系统想开去

rel="File-List" href="file:///C:%5CDOCUME%7E1%5C%E4%B8%B0%E5%9B%BD%E6%A0%8B%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml">

基于专用设备的存储系统有DAS（直接存储系统，Direct Attached Storage）、NAS（网络存储系统，Network Attached Storage）、SAN（存储区域网络，Storage Area Network）；基于SAN和NAS的分布式文件系统有惠普公司开发的DiFFS，SGI开发的CXFS等。Google文件系统是一种专门针对大文件存储和大数据量的访问而设计的文件系统。GFS将一个大文件分割成若干个固定大小的chunk，存储到不同的Chunk Server上。GFS Master中存储三种重要的元数据：文件和chunk的命名空间、文件到chunk的映射表以及chunk及其备份的位置信息（为了提高文件存储的可靠性，GFS中对同一份数据一般存储在三台不同的主机上）。Chunk Server中每个chunk大小为64MB，关于每个chunk大小的具体数值选择并不是随意的，而是很有技巧。GFS中执行一个简单的数据读取操作工作流程如下：首先，客户端把要访问数据在文件中的偏移量转换成chunk索引号，向GFS Master发送请求文件名和chunk索引号；GFS Master收到请求后查询元数据表，反馈给客户端该chunk所在位置；之后，客户端就可以直接与存储该chunk的Chunk Server请求数据了。但是GFS并不适合其他的开发者来研发服务于分布式网络搜索引擎的分布式存储系统。

1.GFS不是直接针对Web对象存储

  为了存储Web对象，需要将Web对象打包成大文件，然后再存储到Google文件系统。也就是说，需要在Google文件系统基础之上再建立一个Web对象管理系统。Google文件系统本来就是二层构架的，再加上Web对象管理系统，应用客户端，则会形成四层构架。虽然在逻辑上划分为四层，但是为了提高数据访问效率，在数据交互上却并不是按照分层而隔离，应用客户端仍然要与最底层的GFS Chunk Server交互。整个系统过于复杂，开发难度大，可靠性难以保证。

2. Master数据同步的问题

  Google文件系统为了简化设计采用单Master方式。但是为了保证系统可靠性，除了主服务Master之外，往往还需要若干备份Master。在主服务Master当机之后，备份Master需要能够及时代替主服务Master，因此主服务Master与备份Master之间需要完全的数据同步。虽然GFS Master只管理元数据（meta data），并使用比较大的chunk（64MB）来分隔大文件，以减少元数据，但元数据量仍然很大，各Master之间的数据同步还是很复杂。

  如果Master只制订和发布分布式策略，完全不再参与数据访问。而每个Slave都按照策略来提供服务，客户端按照策略直接访问Slave提供的服务，Slave将成为一个高度自治的系统，简化Master的管理。Master不再是系统中的焦点，极大的提高了系统的服务效率和可靠性。

分布式存储系统的目标：

1.       大容量

2.       高性能

3.       高可靠性

4.       好的扩展性

5.       兼容性

Reference:

Google文件系统

http://blog.csdn.net/wishfly/archive/2007/08/06/1727869.aspx