XML地图 黑帽SEO培训为广大SEO爱好者提供免费SEO教程,致力于SEO优化、SEO服务
首页 > SEO培训 » 搜索引擎云存储与云计算

搜索引擎云存储与云计算

2018-10-12T06:04:34 | 人围观 | 关键词:搜索引擎云存储与云计算--SEO培训


  云存储与云计算
 

  “秋水时至,百川灌河;泾流之大,两涘渚崖之间不辨牛马。于是焉河伯欣然自喜,以天下之美为尽在己。顺流而东行,至于北海,东面而视,不见水端。于是焉河伯始旋其面目,望洋向若而叹曰:野语有之曰,‘闻道百,以为莫己若’者,我之谓也。且夫我尝闻少仲尼之闻而轻伯夷之义者,始吾弗信;今我睹子之难穷也,吾非至于子之门则殆矣,吾长见笑于大方之家。”
 

  [图片]庄子·《秋水》
 

  对于Google这种大型搜索引擎服务提供商来说,需要处理的数据已超百亿,而且绝大部分数据是网页这种无结构或者半结构化的数据。如何构建存储平台和计算平台,使得存储和管理这些海量数据简单化,‍就成为了重要问题。云存储与云计算平台就是为了解决这个问题而提出的技术方案。目前来说,能够提供一套高效的云存储与云计算平台,已成为搜索引擎公司的核心竞争力。
 

  云存储与云计算是目前非常流行的技术概念,一些国外的大型互联网公司在此走在前列,最典型的是Google公司和亚马逊公司,这两个公司是首先应用并大力倡导云计算的领头企业。尽管2011年4月亚马逊公司‍的云计算服务出现了大规模的故障,导致很多构建在其上的互联网公司停止服务,这为云计算领域的发展蒙上了本章以Google提‍供的一整套云存储与云计算技术框架为主,来介绍相关的核心技术,不仅对GFS/BigTable/MapReduce三驾马车给出了详细说明,还对Google刚部署不久的咖啡因系统及更进一步的MegaStore存储系统等新披露的技术进行了讲解。除此之外,还对另外一些有特色的云存储平台进行了介绍,比如亚马逊公司的Dynamo,雅虎公司的PNUTS及Facebook公司的HayStack存储平台,这些技术各有特点,是非常有代表性的云存储与云计算平台,基本能够概括云计算领域的技术现状。但是有一点需要读者注意:本章所说的云计算是狭义的,不包括虚拟化等云计算关键技术,总体而言,本章以云存储作为讲解重点。
 

  7.1 云存储与云计算概述
 

  本节从云存储与云计算的基本假设、理论基础、数据模型及基本问题等方面开始,使得读者对这个计算领域有个宏观的整体性认识,同时本节对Google的整套技术框架做出概述性的说明。
 

  7.1.1 基本假设
 

  云存储与云计算首先由大型互联网公司提倡并推行,是由于互联网数据的爆炸性增长导致的。互联网服务和传统软件行业提供的服务有很大差异,也有其特点,所以云存储与云计算平台的设计和构建都遵循以下一些基本假设与要求。
 

  1.由大量廉价PC构成传统的海量数据存储与管理,往往会选择商用数据库,但是现代云计算和云存储平台与此思路不同,往往使用大量廉价PC作为基本的存储节点。一方面这样可以节省企业数据存储和计算的成本;另外一方面,数据库的扩展性不能满足拥有海量数据的互联网企业要求,这是云存储与云计算平台兴起的一个基本背景。
 

  2.机器节点出现故障是常态
 

  由于是大量普通PC构成的分布式系统,众所周知,PC的故障率很高,尤其是这种众多PC协同提供服务的模式,随时都有可能某台机器出现故障,所以云存储与云计算技术方案在设计之初,就应该将这种经常性的机器故障作为一个设计考虑因素,在这个约束前提下提供可靠服务,必须要考虑到数据的可用性与安全性。
 

  3.水平增量扩展
 

  互联网服务随时都要响应用户的请求,随着数据量的不断增大,需要靠增加机器来承载更多数据,即使这样,也不可能中断服务来进行,所以必须在用户无察觉的情况下实现增量扩展。而对于云存储与云计算平台,应该做到简单增加机器就可以自动实现增量扩展,这往往是通过数据的水平分割实现的。
 

  4.弱数据一致性
 

  云存储与云计算平台有其优势:高可用性、易扩展性、容错性能好。但这种优势并非是无代价的,其付出的代价就是数据的弱数据一致性。数据库提供了数据的强数据一致性视角,并在此基础上提供了事务支持,而云计算平台则放松这种强数据一致性,这主要是因为很多互联网服务并不要求这种强数据一致性。
 

  5.读多写少型服务
 

  互联网服务有个特点,即读多写少,也就是说大量的请求是读取数据,少量的服务是对数据做出更改。所以在设计云存储与云计算平台时,应该考虑到这个特点,做出有针对性的优化,保证系统效率。
 

  7.1.2 理论基础
 

  CAP、BASE、ACID及最终一致性等这些基础原理对于深入理解云存储与云计算技术有重要指导作用。
 

  CAP是对Consistency/Availability/Partition Tolerance的一种简称,其分别代表:一致性、可用性和分区容忍性(参考图7-1)。研究者已经证明,对于一个数据系统来说,CAP 3个要素不可兼得,同一个系统至多只能实现其中的两个,而必须放宽第3个要素来保证其他两个要素被满足。对于分布式系统来说,分区容忍性是天然具备的要求,所以在设计具体技术方案时,必须在一致性和可用性方面做出取舍,要么选择强数据一致性减弱服务可用性,要么选择高可用性容忍弱数据一致性。一般认为,传统的关系数据库在三要素中选择AP两个因素,即强数据一致性、高可用性但是可扩展性差。而云存储系统往往关注CA因素,即高可扩展性、高可用性,但是以弱数据一致性作为代价。

 

  

 

  BASE原则是和ACID原则相反的基本原理,我们先介绍什么是ACID原则,ACID是关系数据库系统采纳的原则,也是一种简称,其代表含义如下。
 

  原子性(Atomicity):是指一个事务要么全部执行,要么完全不执行,也就是不允许一个事务只执行了一半就停止。以银行转账为例,这是一个典型的事务,它的操作可以分成几个步骤:首先从A账户取出要转账的金额,A账户扣除相应的金额之后,将其转入B账户的户头,B账户增加相同的金额。这个过程必须完整地执行,否则整个过程将被取消,回退到事务未执行前的状态。不允许出现从A账户已经扣除金额,而没有打入B账户这种情形。
 

  · 一致性(Consistency):事务在开始和结束时,应该始终满足一致性约束条件。比如系统要求A+B=100,那么事务如果改变了A的数值,则B的数值也要相应修改来满足这种一致性要求。
 

  · 事务独立(Isolation):如果有多个事务同时执行,彼此之间不需要知晓对方的存在,而且执行时互不影响,不允许出现两个事务交错,间隔执行部分任务的情形。
 

  · 持久性(Durability):事务的持久性是指事务运行成功以后,对系统状态的更新是永久的,不会无缘由回滚撤销。
 

  数据库系统采纳ACID原则,获得高可靠性和强数据一致性。而大多数云存储系统则采纳BASE原则,这种原则与ACID原则差异很大,具体而言,BASE原则是指:
 

  · 基本可用(Basically Available):在绝大多数时间内系统处于可用状态,允许偶尔的失败。
 

  · 软状态或者柔性状态(Soft State):数据状态不要求在任意时刻都完全保持同步。
 

  · 最终一致性(Eventual Consistency):与强数据一致性相比,最终一致性是一种弱数据一致性,尽管软状态不要求任意时刻数据保持一致同步,但是最终一致性要求在给定时间窗口内数据达到一致状态。
 

  BASE原则与ACID原则不同,是通过牺牲强数据一致性来获得高可用性的。尽管大多数云存储系统采纳了BASE原则,但是有一点值得注意:云存储系统的发展过程正在向逐步提供局部ACID特性发展,即全局而言符合BASE原则,但是局部支过程正在向逐步提供局部ACID特性发展,即全局而言符合BASE原则,但是局部支持ACID原则,这样就可以吸取两者各自的好处,在两者之间建立平衡,从Google的MegaStore可以看出这种发展趋势。
 

  大多数云存储系统采纳了最终一致性,在分布式存储架构中,每份数据都要保留多个备份,但是由于客户端程序是并发对数据读/写,可能同时有多个客户端将数据更新到不同的备份中,这可能导致数据的不一致状态,如何维护数据保持一致是个核心问题。所谓强数据一致性,就是要求后续的读取操作看到的都是最新更新的数据;而弱数据一致性则放宽条件,允许读取到较旧版本的数据,最终一致性则是给出一个时间窗口,在一段时间后,系统能够保证所有备份数据的更新是一致的。
 

  7.1.3 数据模型
 

  所谓数据模型,就是云存储架构在应用开发者眼中是何种形式,比较常见的数据模型有两种:Key/Value模式和模式自由(Schema Free)列表模式。图7-2展示了两者的区别,Key/Value模式是一种比较简单的数据模型,每个记录由两个域构成,一个是主键Key,作为记录的唯一标识,另一个字段则存储记录的数据值;模式自由列表模式情况则复杂一些,同样地,每个记录由一个唯一的主键标识,不同点在于数据值,类似于关系数据库,数据值由若干个列属性构成,但是与数据库不同的是:数据库一旦确定列包含哪些属性,就固定不变,而云存储系统则不受此约束,可以随时增加或者删除某个列属性,同时每一行只存储部分列属性,不必完全存储。

 

  

 

  在云存储系统内部实现存储结构的时候,最终可以归结为两种实现方式:哈希加链表或者B+树的方式。哈希加链表查询速度较快,但是一次只能查询一条记录,无法支持批量顺序查找记录(Scan方式),而B+树则支持这种查找方式,但是其管理方式相对复杂,所以两种方式各擅胜场,适合不同的应用场合。
 

  7.1.4 基本问题
 

  对于一个由大量廉价PC构成的分布式存储系统来说,不管具体方案采取何种技术路线,都面临一些共同的问题,这些问题包括。
 

  1.数据如何在机器之间分布
 

  由于数据量巨大,单个机器很难承担存储全部数据的责任,所以必须将数据进行切割,将大数据切割成小份,并将其分配到其他机器上,数据的分布策略是首先要考虑的问题。
 

  2.多备份数据如何保证一致性
 

  在由大量廉价PC构成的分布式存储系统中,随时都可能有PC出现故障,放置在故障机器上的数据会因此不可用,出于数据可用性方面的考虑,现代云存储系统必须将数据做多备份,并将备份数据放置在不同机器上。而云计算环境下,很多客户端程序会并发对数据进行读/写,这样数据的多个备份之间如何保证其状态是一致的就成了云存储系统的核心问题。
 

  3.如何响应客户端的读/写请求
 

  几千台机器构成了云存储与云计算平台,对于客户端的数据读/写请求,如何将请求在不同功能的机器之间转发,并做出针对性响应,同时读/写延迟尽可能短,数据尽可能保证正确,这些都是云存储与云计算平台需要提供的基本功能和保证。
 

  4.加入(或者坏掉)一台机器如何处理
 

  既然是由大量PC构成的系统,随着数据量不断增加,需要的机器也随之增长,如果新加入存储机,系统应该将之纳入管理范围,并自动为其分配任务;同样地,如果某台机器因故障不可用,如何识别这种状态及如何对其负责存储的数据进行迁移与备份,这也是云存储平台的重要问题。
 

  5.如何在机器之间进行负载均衡
 

  大量PC共同承担数据存储与读/写响应,很容易出现分工不均的情况,导致有些机器非常繁忙,而有些机器则很空闲,这样的话,繁忙机器很易成为系统瓶颈,而闲置机器资源又没有充分利用起来,所以如何在机器之间进行负载均衡,使得不会出现瓶颈节点的同时又能充分利用机器资源,这同样是需要考虑的重要问题。
 

  7.1.5 Google的云存储与云计算架构
 

  Google对于推动云存储与云计算贡献了很大力量,而且到目前为止,也是在相关技术方面积累最深厚的公司,图7-3展示了Google的一整套云存储与云计算技术体系。

 

 

 

  从大的角度划分,可以将这些技术划分为两类:一类是云存储技术,另一类是云计算技术。云存储技术包括:GFS文件系统、Chubby锁服务、BigTable及MegaStore等一系列不断进化的存储系统;云计算体系则包含MapReduce、Percolator及Pregel等互补的计算模式。
 

  GFS是一个分布式文件系统,对海量数据提供了底层的存取支持,至于文件内容本身则不做格式要求;BigTable提供了数据的结构化和半结构化视图,其数据模型与具体应用更贴近,同时BigTable提供了记录行内针对列属性的原子操作,即实现了基于行的事务,但不提供行间或者表间的事务支持;MegaStore则在BigTable基础上在事务支持方面又向数据库方向前进了一步,支持对数据的分组,组内数据支持ACID原则,同时强调局部数据的强数据一致性和高可用性,可在此基础上直接提供面向用户的实时交互服务。Chubby则在GFS和BigTable中起到了很重要的作用,包括主服务器的选举、元数据的存储、粗粒度的锁服务等。
 

  MapReduce和Percolator这两个模型则是在以上的云存储架构下的计算模型,两者都是后台计算模型,即其实时性不够,比较适合做后台运算。MapReduce适合做大规模数据的全局统计,对于数据的增量更新无法支持。而Percolator则是对MapReduce计算模型的补充,可以对已有数据做部分更新,并在BigTable的行事务基础上提供行间事务和表间事务,同时利用观察通知的方式来组织运算系统。而Pregel计算模型则是专门针对大型图结构研发的云计算技术。另外,Google正在进行第二代GFS及代号为Spanner的第二代BigTable的研发。
 

  受Google云存储与云计算架构的启发,开源界组织起功能类似的Hadoop项目,其项目分支和Google相应技术的对比见图7-4。其中HDFS类似于GFS文件系统的功能,HBase则是仿照BigTable设计的,Zookeeper起到类似于Chubby的功能,同时Hadoop也支持MapReduce计算模型。
 

  
 

  Hadoop得到雅虎公司的资助,近些年获得了很快的发展,很多大的互联网公司都采用它来做大规模数据的后台计算,比如Facebook和百度公司就使用Hadoop,并对这一系统做出了有针对性的改进。
 

相关内容推荐:

Top