Google Megastore介绍
Google Megastore介绍概述策略对比异步主从 Asynchronous Master/Slave同步主从 Synchronous Master/Slave乐观复制 Optimistic ReplicationMegastore的选择Megastore系统架构实体组EG并发控制(事务)读事务写事务索引协调者读写流程读流程写流程Megastore总结概述Megastore是在Bigtabl
Google Megastore介绍
概述
Megastore是在Bigtable的基础上提供了友好的数据库功能支持。是介于关系型数据库(RDBMS)和NoSQL之间的存储技术。其引入了实体组(Entity Group EG)的概念,每一个用户的所有数据构成一个实体组。每个EG中可能会有多张表。多数情况下同一个EG只有一个子表,分布在一台bigtable TabletServe上,如果EG比较大,导致子表分裂,会分布到多台机器上。同一个EG内保证强一致性,多EG之间只保证最终一致性
Megastore研发的目的是为了支撑谷歌每天30亿次的写请求和200亿次的读请求,并且要支撑PB级别的跨可用区数据规模
策略对比
论文开头作者就对比了分布式系统各种共识方案:
异步主从 Asynchronous Master/Slave
通过一致性协议选主并复制日志,WAL日志至少要写到一个slave上去。这种方式master可以做到很快的ACID事务,但是节点发生变动或者leader变化的时候会导致有一定的时间不可服务,并且由于各节点的副本状态不是强一致,其丢数据的风险要比一般的强一致系统要大。
同步主从 Synchronous Master/Slave
主将数据复制到所有的从节点后操作才算完成。需要有外部服务及时检测各个节点的状态(节点下线、路由变更、修复)。由于使用强同步协议,丢数据的风险大大降低,随之而来的是延迟的增大
乐观复制 Optimistic Replication
wiki中定义为:
Optimistic replication, also known as lazy replication,is a strategy for replication, in which replicas are allowed to diverge.
Traditional pessimistic replication systems try to guarantee from the beginning that all of the replicas are identical to each other, as if there was only a single copy of the data all along. Optimistic replication does away with this in favor of eventual consistency, meaning that replicas are guaranteed to converge only when the system has been quiesced for a period of time. As a result, there is no longer a need to wait for all of the copies to be synchronized when updating data, which helps concurrency and parallelism. The trade-off is that different replicas may require explicit reconciliation later on, which might then prove difficult or even insoluble.
个人理解意味副本中的内容只保证最终一致性,如果各个副本中内容不一致,需要有额外的机制去解决冲突。这种模型意味着可用性和延迟都是最好的,但是就别想做事务了
Megastore的选择
- 不能丢数据并且要支持ACID事务
- 不要外部的master服务去监控节点运行状态,这种检测故障、修复的failover机制通常会带来用户可以感知到的高延迟,并且会增加系统的复杂程度
所以最后的方案系统中并没有master节点,并且使用paxos协议复制数据,并在集群中增加协调者处理、优化读写请求。
Megastore系统架构
AppServer
:客户端库,Megastore的大部分功能集中在客户端,包括映射Megastore操作到bigtable,事物及并发控制,基于Paxos的复制,将请求发送给各个复制服务器,通过协调者实现快速读等。ReplicationServer
:复制服务器,接受客户端请求并写入对应的bigtable实例。Coordinator
:协调者,存储每个机房EG是否处于最新状态,用于实现快速读。
megastore的功能主要分为以下三部分:
- 映射Megastore数据模型到Bigtable
- 事务及并发控制
- 跨机房数据复制及读写优化
实体组EG
- 每个EG内的操作日志采用paxos协议进行复制到多个机房,保证强一致性(strong consistency),并且提供序列化(serializable)隔离级别的ACID特性的事务
- 在EG内,通过REDO日志实现事务,客户端写完REDO日志后,事务操作成功,然后在回放REDO日志进行写入,这里的REDO日志就相当于WAL日志
- 如果REDO日志回放失败(比如发生了宕机),后面的读需要先回放REDO日志,才能保证读取到最新的数据
- EG之间通过分布式队列的方式(推荐使用这种方式)保证最终一致性,或者2PC的方式实现布式事务
- 如果要实现分布式事务(强一致性),就只能用2PC加锁协调了。
- replication server有定时扫描线程,发现没有完成的写操作,并通过paxos发送no-op给其他no-op,用来打平版本
并发控制(事务)
读事务
Megastore提供了三种读取模式:
- 最新读取(current read):读取最新的版本(必须applied)
- 快照读取(snapshot read):也是读取最新版本,但有可能读到transaction完成但是没有applied的日志
- 非一致性读(inconsistentread):不考虑redolog的状态直接读,有可能读到不完整的事务
写事务
Megasttore的所有写操作都要先写redo log,然后采用paxos复制到集群中。流程大概如下:
- 读取:获取最后一次提交事务的时间戳和日志位置
- 应用逻辑:从Bigtable读取并将写操作聚合到日志缓冲区中
- 提交:将缓冲区中的操作日志追加到多个机房的Bigtable集群中,通过paxos保证一致性
- 生效:apply redo log。更新eg和索引
- 清理:删除不再需要的数据
由于Megastore从上层应用的角度设计出了EG的概念:同一时间多个客户端对统一EG发出修改请求的概率较低。所以事务冲突概率较低。
Each Megastore entity group functions as a mini-database that provides serializable ACID semantics. A transaction writes its mutations into the entity group’s write-ahead log, then the mutations are applied to the data.
索引
megaStore主要提供以下2类索引
- 局部索引(local index):单个EG内部的索引
- 全局索引(global index):横跨多个EG
协调者
MegaStore的一大两件就是在集群中引入了协调者的概念,引入协调者后:
- 快速读:协调者可以记录当前节点存储的某个EG的数据是否是最新的,从而用local read加速读取。免去了每次读都要走paxos协议的繁琐过程。当EG有更新操作时,需要首先将协调者记录的EG状态更新为无效。如果某个机房的Bigtable写入失败,需要首先失效对应的协调者,才能返回客户端。
- 协调者的可用性:由于每次写操作都要涉及协调者,因此协调者出现故障会导致集群不可用。Megastore使用chubby提供的锁服务。协调者启动时在chubby获取锁,如果协调者失效,那么锁会失效(类似zookeeper的connection lost事件),这时写操作可以忽略协调者。当然,这里面肯定会涉及到一个失效的超时时间的问题。从协调者不可用到锁失效有几秒钟的时间。这期间的写操作都会失败。
- 竞争:对于协调者的协议必须满足一些列条件,失效总是安全的,但是生效必须谨慎对待。在异步网络环境中,消息可能乱序到达协调者,所以每条生效和失效操作都必须携带日志信息,如果协调者先收到较晚的失效操作再收到焦躁的生效操作,生效操作会被忽略。
读写流程
读流程
- 读流程首先检查协调者,查看是否本地EG处于最新状态
- 如果本地最新,可以直接使用local read
- 如果本地不是最新,需要对读操作应用paxos协议,做一个majority read
- 追赶:读取最新EG后,需要通过获取最新redo log,然后apply redo log到本地的方式将本地EG更新,并通知协调者
- 如果本地最新,可以直接使用local read
写流程
写流程就是对paxos组写入。对某个EG执行paxos协议,不再赘述。
Megastore总结
分布式存储系统有两个目标:一个是可扩展性,最终目标是线性可扩展,另一个是功能,最终目标是支持全功能SQL。Megastore是一个介于传统关系型数据库和分布式NoSQL系统之间的存储系统。融合了SQL和NoSQL两者的优势。
Megastore的是构建与Bigtable之上的系统,其创新点主要包括:
- 提出了EG的数据模型,通过EG划分数据,EG内维持关系型数据库的ACID特性,EG之间维持类似NoSQL的弱一致性。有效的融合了SQL和NoSQL两者的优势。
- 使用paxos做到了较好的Availability和Consistency,并且通过协调者优化了读写性能。
- 继承了Bigtable的有点和缺点。
更多推荐
所有评论(0)