欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜：Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
Google File System
小 (→链接) |
|||
| （未显示2个用户的8个中间版本） | |||
| 第1行： | 第1行： | ||
| − | + | {{top news}} | |
| + | {{SeeWikipedia}} | ||
| + | Google File System | ||
| + | [[Image:google-file-system.png|right|thumb|GFS Architecture]] | ||
Google File System (简称GFS) 是由 Google Inc. 设计并实现的一个分布式文件系统，基于大量安装有Linux操作系统的普通PC构成的集群系统。整个集群系统由一台Master(通常有几台备份)和若干台TrunkServer构成。GFS中文件备份成固定大小的Trunk分别存储在不同的TrunkServer上，每个Trunk有多份(比如3)拷贝，也存储在不同的TrunkServer上。Master负责维护GFS中的 Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的 TrunkServer通信，获取文件数据。 | Google File System (简称GFS) 是由 Google Inc. 设计并实现的一个分布式文件系统，基于大量安装有Linux操作系统的普通PC构成的集群系统。整个集群系统由一台Master(通常有几台备份)和若干台TrunkServer构成。GFS中文件备份成固定大小的Trunk分别存储在不同的TrunkServer上，每个Trunk有多份(比如3)拷贝，也存储在不同的TrunkServer上。Master负责维护GFS中的 Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的 TrunkServer通信，获取文件数据。 | ||
高可靠性是GFS最重要的特点。GFS使用的是可靠性较差的普通PC，节点失效属于正常现象，起中很大一部分设计就是要解决单节点甚至双节点同时实效的问题。 | 高可靠性是GFS最重要的特点。GFS使用的是可靠性较差的普通PC，节点失效属于正常现象，起中很大一部分设计就是要解决单节点甚至双节点同时实效的问题。 | ||
| − | 鉴于Google Inc. 的特殊应用环境，需要处理海量数据，经常有大文件(几十G)的操作，而且常是多台机器同时数据输出到一个大文件中，供后面的流程使用。GFS也对这种特殊的应用需求做了很多优化，保证往大文件并发追写数据时的可靠和高效。 | + | 鉴于Google Inc. 的特殊应用环境，需要处理海量数据，经常有大文件(几十G)的操作，而且常是多台机器同时数据输出到一个大文件中，供后面的流程使用。GFS也对这种特殊的应用需求做了很多优化，保证往大文件并发追写数据时的可靠和高效。 |
| − | + | ||
| + | GFS 以64M为一个Chunk(Block)，每个Chunk至少存在于三台机器上，交互的简单过程见图: | ||
| + | |||
| + | 目前Google拥有超过200个的GFS集群，其中有些集群的计算机数量超过5000台。Google现在拥有数以万计的连接池从GFS集群中获取数据，集群的数据存储规模可以达到5个PB，并且集群中的数据读写吞吐量可达到每秒40G。 | ||
| + | |||
| + | == 设计 == | ||
| + | GFS专门为Google的核心数据即页面搜索的存储进行了优化。数据使用大到若干G字节的大文件持续存储，而这些文件极少被删除、覆盖或者减小；通常只是进行添加或读取操作。它也是针对Google的计算机集群进行的设计和优化，这些节点是由廉价的“常用”计算机组成，这就意味着必须防止单个节点的高损害率和随之带来的数据丢失。其它设计理念包括高数据吞吐率，甚至这带来了存取反应期变差。 | ||
| + | |||
| + | 节点分为两类：''主''节点和''Chunkservers''。Chunkservers存储数据文件，这些单个的文件象常见的文件系统中的簇或者扇区那样被分成固定大小的数据块（这也是名字的由来）。每个数据块有一个唯一的64位标签，维护从文件到组成的数据块的逻辑映射。每个数据块在网络上复制一个固定数量的次数，缺省次数是3次，对于常用文件如可执行文件的次数要更多。 | ||
| + | |||
| + | 主服务器通常并不存储实际的大块数据，而是存储与大块数据相关的元数据，这样的数据如映射表格将64位标签映射到大块数据位置及其组成的文件、大块数据副本位置、哪个进程正在读写特定的大数据块或者追踪复制大块数据的“快照”（通常在主服务器的激发下，当由于节点失败的时候，一个大数据块的副本数目降到了设定的数目下）。所有这些元数据通过主服务器周期性地接收从每个数据块服务器来的更新（“心跳消息”）保持最新状态。 | ||
| + | |||
| + | 操作的允许授权是通过限时的、倒计时“租期”系统来处理的，主服务器授权一个进程在有限的时间段内访问数据块，在这段时间内主服务器不会授权其它任何进程访问数据块。被更改的chunkserver——总是主要的数据块存储器，然后将更改复制到其它的chunkserver上。这些变化直到所有的chunkserver确认才存储起来，这样就保证了操作的完整性和自动性。 | ||
| + | |||
| + | 访问大数据块的程序首先查询主服务器得到所要数据块的位置，如果大数据块没有进行操作（没有重要的租约），主服务器回答大数据块的位置，然后程序就可以直接与chunkserver进行联系接收数据（类似于[[Kazaa]]和它的超级节点）。 | ||
| + | |||
| + | ==链接== | ||
*http://labs.google.com/papers/gfs.html | *http://labs.google.com/papers/gfs.html | ||
*http://labs.google.com/papers/gfs-sosp2003.pdf | *http://labs.google.com/papers/gfs-sosp2003.pdf | ||
| + | |||
| + | {{comment}} | ||
| + | |||
| + | [[category:google]] | ||
| + | [[category:file system]] | ||
2013年2月10日 (日) 03:24的最后版本
|
您可以在Wikipedia上了解到此条目的英文信息 Google File System Thanks, Wikipedia. |
Google File System
Google File System (简称GFS) 是由 Google Inc. 设计并实现的一个分布式文件系统，基于大量安装有Linux操作系统的普通PC构成的集群系统。整个集群系统由一台Master(通常有几台备份)和若干台TrunkServer构成。GFS中文件备份成固定大小的Trunk分别存储在不同的TrunkServer上，每个Trunk有多份(比如3)拷贝，也存储在不同的TrunkServer上。Master负责维护GFS中的 Metadata，即文件名及其Trunk信息。客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的 TrunkServer通信，获取文件数据。
高可靠性是GFS最重要的特点。GFS使用的是可靠性较差的普通PC，节点失效属于正常现象，起中很大一部分设计就是要解决单节点甚至双节点同时实效的问题。
鉴于Google Inc. 的特殊应用环境，需要处理海量数据，经常有大文件(几十G)的操作，而且常是多台机器同时数据输出到一个大文件中，供后面的流程使用。GFS也对这种特殊的应用需求做了很多优化，保证往大文件并发追写数据时的可靠和高效。
GFS 以64M为一个Chunk(Block)，每个Chunk至少存在于三台机器上，交互的简单过程见图:
目前Google拥有超过200个的GFS集群，其中有些集群的计算机数量超过5000台。Google现在拥有数以万计的连接池从GFS集群中获取数据，集群的数据存储规模可以达到5个PB，并且集群中的数据读写吞吐量可达到每秒40G。
[编辑] 设计
GFS专门为Google的核心数据即页面搜索的存储进行了优化。数据使用大到若干G字节的大文件持续存储，而这些文件极少被删除、覆盖或者减小；通常只是进行添加或读取操作。它也是针对Google的计算机集群进行的设计和优化，这些节点是由廉价的“常用”计算机组成，这就意味着必须防止单个节点的高损害率和随之带来的数据丢失。其它设计理念包括高数据吞吐率，甚至这带来了存取反应期变差。
节点分为两类：主节点和Chunkservers。Chunkservers存储数据文件，这些单个的文件象常见的文件系统中的簇或者扇区那样被分成固定大小的数据块（这也是名字的由来）。每个数据块有一个唯一的64位标签，维护从文件到组成的数据块的逻辑映射。每个数据块在网络上复制一个固定数量的次数，缺省次数是3次，对于常用文件如可执行文件的次数要更多。
主服务器通常并不存储实际的大块数据，而是存储与大块数据相关的元数据，这样的数据如映射表格将64位标签映射到大块数据位置及其组成的文件、大块数据副本位置、哪个进程正在读写特定的大数据块或者追踪复制大块数据的“快照”（通常在主服务器的激发下，当由于节点失败的时候，一个大数据块的副本数目降到了设定的数目下）。所有这些元数据通过主服务器周期性地接收从每个数据块服务器来的更新（“心跳消息”）保持最新状态。
操作的允许授权是通过限时的、倒计时“租期”系统来处理的，主服务器授权一个进程在有限的时间段内访问数据块，在这段时间内主服务器不会授权其它任何进程访问数据块。被更改的chunkserver——总是主要的数据块存储器，然后将更改复制到其它的chunkserver上。这些变化直到所有的chunkserver确认才存储起来，这样就保证了操作的完整性和自动性。
访问大数据块的程序首先查询主服务器得到所要数据块的位置，如果大数据块没有进行操作（没有重要的租约），主服务器回答大数据块的位置，然后程序就可以直接与chunkserver进行联系接收数据（类似于Kazaa和它的超级节点）。
[编辑] 链接
<discussion>characters_max=300</discussion>
