还剩5页未读,继续阅读
文本内容:
:为交互式服务提供可扩展、高可用时存储M㊀g astor㊀摘要是为满足当今交互式在线服务的需求开发的存储系统它融M eg asto re合了数据存储的扩展性和老式的便捷性,提供了强一致NoSQL RDBMS性保证和高可用性在一种细粒度的数据分区内提供完全串行化的AC ID这种分区容许在大规模网路中,以合理日勺延迟进行同步复制写操作,并且在数据中心之间支持无缝曰勺故障切换这篇论文描述了的语义M egostor㊀以及复制算法,并且描述了支持许多服务产品的经Mega stor eGoogle验序论交互式在线服务使得存储面临从桌面应用迁移到云中日勺新需求像、emcii I合伙文档、社交网络的规模指数倍的增长,考验着目前的基础架构满足这些服务的存储需求是一项非常具有挑战性日勺工作一方面,因特网带来了庞大的顾客群,因此应用必须具有高扩展性一种服务可以使用作为它MySQL的数据库迅速开发,但是扩展这个服务到上百万日勺顾客需要对它日勺存储架构进行重新设计第二,服务必须竞争顾客,这就需要服务能迅速开发并迅速投入市场第三,服务可以高响应,即存储系统必须低延迟第四,服务需要为顾客提供数据日勺一致性视图,即更新可以立即可见并且持久存储最后,服务必须高可用,面对多种故障服务可以进行容错解决这些需求是矛盾的一方面,老式日勺关系数据库提供了丰富的特性来以便建立应用,但是它们很难扩展到上百万的顾客;另一方面,数据库,像的的No SQLGoogl㊀Bigtoble,A pacheH Bos e,的等具有高扩展性,但是它们有限时和弱Facebook Cassandr AP I一致性给应用开发带来了复杂性「是满足当今交互式在线服务需求的存储系统它的独特性Megas to㊀体目前融合了数据存储的扩展性和老式的便捷性它运N SQLRD BMS用同步复制来活得高可用性和数据一致性简言之,它对物理距离远的副本以足够低日勺延迟,提供完全串行化日勺语义,以次来支持交互式应用AC ID我们通过采用一种在和之间的中间立场,来实现这种设RDBMS N oSQL计:我们把数据存储进行了分区,并且单独时复制每一种分区,在分区内提供完全的语义,但是分区之间是有限的一致性保证我们提供了老式的数ACID据库特性,例如辅助索引,我们觉得大多数服务数据都能被W In ternW合适时进行分区,使得这种措施切实可用与老式的设计比较,我们采用算法为交互式应用建立一种高可用日勺Pax s系统,当在分布式日勺数据中心之间同步复制写操作时,可以提供合理的延迟虽然诸多系统使用算法进行封锁、主节点选举、复制元数据并且进行Paxos配备,我们觉得是使用算法部署的对每一种写操作Mega stro eP axos穿过数据中心进行复制的最大的系统在内部已经被广泛部署使用了数年它每天解决超过M㊀gcistore Google三十亿的写操作和二百多亿的读操作,存储接近穿过1PT全球数据中心日勺数据这篇论文的重要奉献:为迅速开发具有高可用性和扩展性的交互式应用设计了一种数据模型和存
1.储系统实现了复制,为提高系统的高可用性,对一致性算法在穿过地
2.POX S理上分布日勺数据中心之间日勺操作进行了延迟优化在内部部署的体验报告
3.Goo gIe M e gastore论文的组织构造如下:第二部分描述了如何运用分区提供可Mega store用性和扩展性,并且证明了对于许多交互式在线应用我们设计的有效性第三步分简介的数据模型和特性第四部分具体简介复制Megastore算法,并且评价了现实中日勺执行效果第五部分总结了开发这个系统的经验第六部分有关工作回忆第七部分总结可用性和扩展性2对比我们对存储平台的规定可靠的、全局的、任意时增大规模,我们的硬I件部分一般具有物理位置日勺限制、容易发生故障、有限日勺容积我们必须把这些部件封装为一种整体来提高系统吞吐量和可靠性我们采用一种具有两方面特性日勺措施可靠性实现了一种同步的,容错时日记复制器,并且对长距离日勺网络连接进行了优化扩展性:我们把数据分区为许多小时数据库,每个拥有它自己的复制日记,存储在数据中心N SQL复制
2.1在一种数据中心穿过主机内进行数据复制,克服了主机节点故障,提高了可用性对于云存储来说,为了满足可用性的需求,服务提供商必须在较大地理范畴内进行数据复制方略
2.
1.1有几种常见日勺适于大范畴地理空间内数据复制日勺方略异步主从式:一种主节点复制日记项到至少一种从节点在主节点的日记追加确认和往从节点发送是并行的主节点支持事务,但是在主节点ACID发生故障切换到此外一种从节点时,有数据丢失日勺风险需要一致性合同来协调它们之间日勺关系同步主从式:主节点等待所有更新在从节点上都得到映像后才确认它主节点和从节点的故障需要及时时被一种外部系统进行监测乐观复制副本组中的成员,任何一种都可以接受更新,更新在组内异步传播可用性和延迟都较好,但是在提交时刻,全局更新序列不懂得,因此不适合事务我们避免采用在发生故障时丢失数据日勺方略,并且抛弃不支持事A CID务的方略尽管最后一致性带来操作上的优势,但是在迅速应用开发中很难放弃“读-修改-写”模式我们也排除使用主节点的选择,故障切换需要一系列高延迟阶段,常常导致顾客可用性中断,并且带来大量复杂性我们决定使用一种被证明优化日勺、容错时一致性算法不需要一Paxos,种特别的节点我们在一组对称的节点之间,复制预写日记mcis ter任何一种节点都可以发起读写操作每一种日记项日勺追加来自于一种副本集合多数派的确认,多数派中日勺副本尽它们所能进行追加操作算法固有的容错性消除了对一种特殊的“错误”状态的需要在中具体简介了P ax算法的一种新颖的扩展,容许本地读取任何最新副本数据此外一种扩展s体目前只需要一轮写操作虽然算法具有容错性,使用一种单一日记仍由限制副本在大范Pa xos畴距离内传播,通讯延迟限制了系统吞吐量并且,当没有副本是最新的或者副本日勺一种大多数派对于写操作没有确认,那么进程就会收到阻碍老式日勺数据为成千上百万日勺顾客服务,使用一种同步复制时日记,SQL将有大范畴中断的风险于是,为了提高可用性和吞吐量,我们使用一种多副本日记,每一种副本管理自己分区的数据集分区和放置
2.
2.为了扩展我们的复制模式,最大化数据存储的性能,我们给应用对它们的数据分区和放置一种细粒度的控制权
2.
3.1entity gro u p为了扩展吞吐量和局部化中断,我们将数据分区为日e n t i ty group勺集合每个集合在数据中心间独立日勺同步复制底层数据在每个数据中心都存在一种可扩展的数据存储中(见表NoSQL1在一种内日勺更新运用一阶段事务(提entity groupent itie sACID交记录通过进行复制)跨日勺操作依托代价Paxos entity gro up较高的但一般运用有效日勺异步消息机制发送方2PC,Mega store的一种事务,把一种或多种消息放在队列中,接受方en t ity group㊀「中的事务,自动时收到这些消息并且应用接下来的更新nti t y goup注意:我们在逻辑上独立的实体之间使用异步消息机制,而不是物理上日勺实体数据中心之间日勺网络负载,来自复制操作,这些复制都是同步且一致的一种的局部索引遵循语义,穿过enti ty groupACID e n tityg r则具有弱一致性图描述了之间的多种操作oup2e ntity g r oup定义
2.
2.2e ntity group为迅速操作,定义了一组数据如果定义的粒度太细,E ntity group会带来大量日勺跨日勺操作,但是如果定义的粒度太粗,需要串group行化许多无关的写操作,减少系统日勺吞吐量下面的例子描述了几种应用对的定义entitygr oup每个帐户形成一种在一种帐户内Email:ema iI ent ity g roup,部的操作时事务时也是一致的一种顾客发送或者标记的消息,虽然在发生故障切换时也能保证观测到这个变化外部的路由管理器解决帐户ma iI之间的通讯一种应用可以使用多种类进行建模Blogs:blogg ing eitygroup每个顾客有一种简介,形成他自己的然而,是合㊀ntity groupob Iogs伙型的,不也许只有一种永久所有者我们创立第二类e ntit ygroup来解决每个曰勺公示和元数据第三类容许每一种blog entitygroup拥有多种名字应用依赖异步消息和来满足多种操作口勺事bl go2PC务解决:一种地图应用通过将全局分为不重叠的小块创立Map sentity groupo对于块之间的操作,应用使用保证它们日勺原子性块日勺大小必须2PC适中不同与前面日勺例子,的数量不会随着使用规㊀nti tygroup模的增长而增长,因此必须在初始时为后期有效的吞吐量汇集创立足够的entitygroup几乎所有的部署在上曰勺应用都以合适的方式描述了Megastore ent的定义ity group物理布局
2.
2.3在一种独立的数据中心,我们使用的来做可扩G gleB ig table展的容错存储通过传播操作跨过多行,来支持任意日勺读写吞吐量我们通过让应用控制数据的位置,最小化了延迟并且最大化吞吐量为了最消化延迟,应用尽量让数据接近顾客,并且副本也彼此接近应用给每个分派日勺区域是它们存取最多的地址在这个en titygroup区域中,它们将三个或四个副本放在故障完全隔离的数据中心内为了保证低延迟、有效日勺缓存、高吞吐量,一种内entit ygroup日勺数据在中被放置在相邻的范畴的行我们的模式语言,Big tabI e让应用控制级联数据的位置,常在一起访问时数据存储在相邻的行,或者非正规化到同一行。
个人认证
优秀文档
获得点赞 0