[关闭]
@zhouyy 2017-02-08T02:58:48.000000Z 字数 1569 阅读 567

分布式数据库及其技术

IT


数据的分布

数据分布的主要目的是提高访问的局部性。即通过数据的合理分布, 尽可能地使更多的数据能够就地存放, 以减少远距离的数据访问;目的是为了就地访问, 而不是分布访问。只是有时为了提高可用性或者达到各个节点的负载均衡, 才分布数据
数据分布的方式大致有三种
①划分式:按照数据的来源, 将其分布在各个节点上, 特点是分布方
式简单, 访问的局部性好, 全局性能差, 灵活性小。
②全重复式:每个节点都存储全部数据的一个复本。特点是读事务简单开销小, 更新事务复杂开销大。
③部分重复式:这种方式介于上两种方式之间, 有些数据分布在某一节点上, 有些数据分布在多个节点上。特点是复杂性高, 灵活性大, 所引起的问题较多。

数据的分割

并发控制

分布式系统中实现并发控制的技术有很多, 在以往的集中式数据库系统
中, 多采用封锁法,这是一种较为成熟并且应用较多的方法。
下面以封锁法为例做一简要讨论。
在分布式数据库系统中, 一个全局事务在执行时,必须对其要访问的数据申请适当的锁,这些锁一直保持到全局事务结束。但是由于数据的分布,加锁的方法也不同于集中式数据库系统。而必须保持多个复本的数据同时加锁。

事务处理与恢复技术

我们把这种要么一起成功(A帐户成功减少1000,同时B帐户成功增加1000),要么一起失败(A帐户回到原来状态,B帐户也回到原来状态)的操作叫原子性操作
在分布式系统中, 事务之间多是并行的,那么势必产生这样的问题:当某一个全局事务在执行时, 某些节点不能完成指定的操作,为维护事务的原子性, 如何恢复这些被操作的数据到操作的前一状态? 这就是如何实现数据库恢复的问题。
实现全局事务恢复有两种较好的技术。
(1)两阶段提交协议:为保证多节点协调一致, 指定其中的任意一个节点为“ 协调者” , 其它节点为“参与者” 。
首先由协调者向参与者发Prepare 消息, 参与者接到Prepare 消息后, 根据本节点的子事务的执行是成功还是失败回答O .K 或者Not O .K ,如果所有的参与者都发来O .K 消息, 则协调者发COMMIT 命令,如果任意一个参与者发来Not O .K消息, 则参与者发ROLLBACK 命令。成功的子事务不能自行提交, 须等到协调者确认所有的参与者都发来O .K 消息, 并发出COMMIT 命令,才能提交。失败的子事务可以直接卷回, 而不必等待协调者的命令。可见, 整个协议分两步:第一步, 确定各子事务都已成功执行; 第二步, 发COMMIT 命令。因此本协议称为两步提交协议, 或称两阶段提交协议。
(2)三阶段提交协议:两阶段提交协议中, 当协调者在某些特定情况下(站点故障或网络不畅)失效时, 有可能导致大量的事务堵塞。为克服此缺点, 提出了三阶段提交协议。
同两步提交协议一样,第一步为协调者发Prepare消息,如果任意一个节点回答Not O .K , 则进入第三步, 协调者发ROLLBACK 命令;如果所有的参与者都回答O .K , 则进入第二步, 有协调者发Prepare to COMMIT , 参与者接到此消息后, 将此消息记录在本节点运行记录中, 同时回答ACK,当协调者收到所有参与者的ACK 信息后, 向参与
者发COMMIT 命令。由于提交时须经过上述三步,故称为三步提交协议, 或三阶段提交协议。该协议不会产生事务的阻塞现象。
两阶段和三阶段提交协议都可保证全局事务的原子性, 但是各个子事务只有在失败时才能自行结束, 成功时不能自行提交, 必须等到协调者发命令, 这无疑会影响分布式数据库系统的性能。一种解决方法是:对于只读子事务, 无论成功与否, 都可以自行结束, 对于更新子事务, 则受两阶段或三阶段提交协议的约束。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注