系统设计高频:设计分布式文件系统Google File System

欢迎回看本文原始视频   今天我们来一起解读一下《The Google File System》。这是来自Google内部的一篇论文,我们在最后给出了参考文献。 Google有三剑客,GFS,BigTable以及MapReduce。这三个在一起组成了Google最早期的三篇论文的基础架构。     今天我们会一起解读第一篇文章,希望大家在阅读的过程中不是背诵它,而是学会寻找特定问题的特定方案。接下来我们一起看看如何回归生长的观点,去理解Google的底层支撑架构。   搜索引擎的支撑架构到底是什么?     如果想解决这类问题,从计算机来看,最底层无非是个文件。这种文件系统就是Google File System。往上一层就需要把数据模型抽象出来,便于更好地使用,这就是BigTable。而再往上就是算法。算法除了能够和数据模型直接挂钩,它也能直接访问底层文件系统,所以它和底层文件系统是有连接的。继续往上就是各式各类的应用,来进行计算。   如何保存一个文件?   所以我们会选择一种自下而上的方法来进行设计,首先设计Google File System。解决Google File System,如果从所有数据的本源来看,我们如何保存一个文件?     首先我们有一个硬盘,硬盘需要一些原始信息,比如某个文件叫什么名字,什么时候被创建的,大小是多少,这些都是数据。为了寻找这些数据在硬盘中的位置,就需要索引。索引就是这些数据在硬盘上存在的位置,比如Block23,24,25,所以通过这些硬盘上的的偏移量以及每一块,就可以找到这个文件的所有信息。总结起来,我们这里所说的“一块”,在传统意义上是指1024Byte。   如何保存大文件?     以上我们谈到的是小文件,接下来我们看一看如何保存大文件。对于大文件来说,我们不能保存小块,因为块数太多了,所以我们只要将每一块变成大块,就是64MB,就变成大文件了。   这里的大块叫Chunk,相当于6万多个小块,这样可以极大地节省你的空间和原始信息大小。以前一个大块需要存6万多个索引的位置,现在只需要存一个了。   这个方案的优点是减少了元数据的大小,也减少了如果以后需要传递的话,传递的流量信息。但是一个明显的缺点就是,如果你存了一个小文件,你会浪费空间。比如只存一个1k的小文件,也要浪费一个64MB的大块。   如何保存超大文件?     问题再变一下,如果要保存一个超大型的文件呢?那我们就不能在1G上存了,因为超大文件往往1个G存不下去。这时我们就需要一个主从结构。Master是保存所有原始信息的地方,这里会存一个文件,包括它的尺寸,大小,它的索引也可以一样建立,但它的索引指向的信息是各个Chunk Server,也就是大块的服务器,上面有它的偏移量。   所以说,架构其实是一模一样的,只不过把索引信息放到了大的Master上,将数据分布到不同机器上,我们只需在偏移量前面记录机器的偏移量,就可以解决同样的问题。   这相当于是一个Master + many Chunk Servers结构,缺点很明显:你会发现Chunk Server里任何的数据变化都要通知Master,因为Master保存了Chunk Server里的每一个偏移量,这样就会浪费Master的存储空间以及相关传递的流量。如何解决这个问题呢?   如何减少Master存储的数据和流量? […]

All Rights Reserved ©2017 BitTiger, Inc.