金融级分布式数据库架构设计
目录
1.行业背景 (3)
2.数据库分布式改造的途径 (3)
3.分布式数据库总体架构 (4)
4.两阶段提交的问题 (5)
5.CAP与BASE的抉择 (7)
6.raft的优势 (8)
6.1. Leader选举 (9)
6.2. 日志复制 (10)
6.3. 安全性 (11)
7.分布式数据库如何实现PITR (16)
1.行业背景
银行业从最初的手工记账到会计电算化，到金融电子化，再到现在的金融科技，可以看到金融与科技的结合越来越紧密，人工智能、大数据、物联网、区块链等新兴技术改变了金融的交易方式，为金融行业的创新前行提供了源源不断的动力。同时互联网金融的兴起是一把双刃剑，带来了机遇的同时也带来了挑战。普惠金融使得金融的门槛降低，更多的普通大众参与到金融活动中，这让金融信息系统承受了越来越大的压力。于是我们可以看到大型商业银行、保险公司、证券公司、交易所等核心交易系统都在纷纷进行分布式改造，其中数据库作为有状态的应用，成为了信息系统中唯一的单点，承担了所有来自上层应用的压力。随着数据库瓶颈的凸显，进行分布式改造迫在眉睫。
2.数据库分布式改造的途径
数据库进行分布式改造主要有三种途径：分布式访问客户端、分布式访问中间件、分布式数据库。由于其分布式能力实现在不同的层次（应用层、中间层、数据库层），对应用程序有不同的侵入程度，其中分布式访问客户端对应用侵入性最大，改造难度最大，而分布式数据库方案对应用侵入性最小，但是架构设计及研发难度最大。
3.分布式数据库总体架构
其实当前市面上的分布式数据库总体架构都是类似的，由必不可缺的三个组件组成：接入节点、数据节点、全局事务管理器。总体架构如下，协调节点负责sql解析，生成分布式执行计划，sql转发，数据汇总等；数据节点负责数据存储与运算；全局事务管理器负责全局事务号的生成，保证事务的全局一致性。这个架构或多或少都受到了google spanner F1论文的影响，这篇文章主要分析了这几个组件在实现上有什么难点，该如何进行架构设计。
4.两阶段提交的问题
我们知道两阶段提交是阻塞性协议，这也是它最大的问题。下图pgxc架构下的两阶段提交为例，主要分为下面几个阶段：
①：CN prepare ->②：所有DN prepare ->③：CN commit->④：所有DN commit
试想一下如果在cn commit阶段发生cn/dn宕机会发生什么？
如果在cn下发完cn commit命令后宕机，这时dn收到commit命令后会进行提交，但是返回commit ok时发生cn宕机，事务进入阻塞状态。如果cn下发commit之后某个dn发生宕机，则会造成某些dn commit成功，某些dn commit失败，造成不一致，但是如果dn重新启动后会继续去cn上拿事务提交信息，发现是commit状态，则会继续执行commit操作，提交之前的事务。在这个地方我们可以探讨一个更极端的情况，如果此时cn也宕机了，那么失败的dn重启后去cn拿状态发现拿不到，这是这个失败dn上的事务就处于一个未决态，不知道是应该提交还是回滚，这时候应该有一个进程能够从其他dn上发现该状态并报告给故障dn，通知它进行提交。这个角色就是pgxc_clean进程，其实之前几种情况下的事务的回滚也是该进程的工作。那我们再深入一下，如果该dn是事务的唯一参与者，那么此时pgxc_clean 就无法从其他dn以及cn获取状态，这时该dn就是真正的未决态了。
为了解决两阶段提交的阻塞问题，出现了三阶段提交，三阶段提交在commit之前引入了cancommit的过程，同时加入超时机制。因为如果协调者发生宕机，参与者无法得知协调者到底发出的是commit还是abort，三阶段提交cancommit过程就是告知参与者我发送的是commit或者abort命令，这时如果协调者发生失败，参与者等待超时时间后可以选出新的协调者，而该协调者是知道应该发出什么命令。
虽然三阶段提交解决了阻塞问题，但是无法解决性能问题，分布式系统中为了保证事务一致性需要跟每个参与者通信，一个事务的提交和参与需要分布式系统中每个节点的参与，必然带来延时，不过在万兆、infiniband、roce高速网络的支持下已经不再是问题了。
5.CAP与BASE的抉择
我们知道分布式系统无法战胜CAP。那么在设计分布式系统的时候该如何进行取舍？首先P （分区容错性）是必须保证的，因为分布式系统必然是多个节点（分区）通过网络进行互联，而网络是不可靠的，分布式系统是为了避免单点故障，如果因为网络问题或者某些节点失败造成整体系统不可用，那么也不符合分布式系统的设计初衷。如果保证A（可用性），那么当网络失败时，网络隔离的不同区域就要继续提供服务，那么就会造成不同分区的数据不一致（脑裂）；如果保证C（一致性），那么网络失败时，就需要等待不同网络分区的节点同步完数据，如果网络一直失败，那么系统就会因为无法同步而一直不可用。
2PC就是典型的牺牲可用性保证一致性的例子，而BASE（basically available，soft state，eventual consistency）就是牺牲一致性保证可用性的例子，因为做到实时的强一致要牺牲的代价太大了，它允许数据在某些时间窗口内的不一致，通过记录窗口内的每一个临时状态日志做到在系统故障时，通过日志继续完成未完成的工作或者取消已经完成的工作回退到初始状态，这种方式保证了最终一致性。BASE与传统ACID理论其实是背离的，满足BASE理论的事务也叫柔性事务，在遭遇失败时需要有相应的补偿机制，与业务耦合性较高，其实我并不是很赞同BASE的做法，因为它已经背离了数据库最基本的设计理念。
6.raft的优势
不管是上面的XA还是BASE都无法彻底解决一致性问题，真正意义上的强一致一定是基于强一致协议的。paxos和raft是目前主流的两种共识算法。Paxos诞生于学院派，是分布式环境下基于消息传递的共识算法，它设计之初是考虑一个通用的模型，并没有过多的考虑实际的应用，而且paxos考虑了多个节点同时写入的情况，这就使得paxos的状态机异常复杂，所以难以理解，不同的人可能理解出不同的意思，这一点一直遭人诟病，比如MGR引入write set 的概念来处理多点写入冲突的问题，这在高并发热点数据的场景下是不可接受的。因为paxos 的难以理解，斯坦福的两名大学生设计了raft算法，相比来说，raft是工业派，同一时刻leader 只有一个，follower通过日志复制实现一致性，相比paxos来说raft的状态机更加简单易懂，实现起来也更加简单，因此在分布式环境上有着广泛的应用，例如TiDB、RadonDB、etcd、kubernetes等。
Raft协议将共识问题分解为三个子问题分别解决：leader选举、日志复制、安全性。
6.1.Leader选举
服务器节点有三种状态：领导者、跟随者和候选者。正常情况下，系统中只有一个领导者，其他的节点全部都是跟随者，领导者处理全部客户端请求，跟随者不会主动发送任何请求，只是简单的响应来自领导者或者候选者的请求。如果跟随者接收不到消息（选举超时），那么他就会变成候选者并发起一次选举。获得集群中大多数选票的候选者将成为领导者，领导者一直都会是领导者直到自己宕机了。Raft 算法把时间分割成任意长度的任期（term），每一段任期从一次选举开始，一个或者多个候选者尝试成为领导者。如果一个候选者赢得选举，然后他就在这个的任期内充当领导者。要开始一次选举过程，跟随者先要增加自己的当前任期号并且转换到候选者状态，然后他会并行的向集群中的其他服务器节点发送请求投票的RPCs 来给自己投票，候选者会继续保持着当前状态直到以下三件事情之一发生：(a) 他赢得了这次的选举，(b) 其他服务器成为领导者，(c) 没有任何一个候选者赢得选举。当一个候选者获得了集群大多数节点针对同一个任期号的选票，那么他就赢得了选举并成为领导者。然后他会向其他的服务器发送心跳消息来建立自己的权威并且阻止新的领导人的产生。下图为三种角色的转换状态机。
6.2.日志复制
当leader被选举出来，他就作为服务器处理客户端请求。客户端的每一个请求都被看成复制状态机所需要执行的指令。领导者把这条指令作为一条新的日志条目附加到日志中去，然后并行的发起附加条目RPCs 给其他的服务器，让他们复制这条日志条目。当这条日志条目被安全的复制，领导者会应用这条日志条目到它的状态机中然后把执行的结果返回给客户端。如果跟随者崩溃或者网络丢包，领导者会不断的重复尝试附加日志条目RPCs （尽管已经回复了客户端）直到所有的跟随者都最终存储了所有的日志条目。下图为复制状态机模型。
6.3.安全性
安全性指的是每台复制状态机都需要按照同样的顺序执行相同的指令，以保证每台服务器数据的一致性。假想一台跟随者在某段时间处于不可用状态，后来可能被选为领导者，这时就会造成之前的日志被覆盖。Raft算法通过在leader选举时增加一些限制来避免这个问题，这一限制保证所有领导者对于给定的任期号，都拥有了之前任期的所有被提交的日志条目。日志条目只会从领导者传给跟随者，不会出现因为新领导者缺日志而需要跟随者向领导者传日志的情况，并且领导者从不会覆盖本地日志中已经存在的条目。Raft 算法使得在投票时投票者拒绝掉那些日志没有自己新的投票请求，从而阻止该候选者赢得选票。
CN的设计
接入节点的设计可能看起来很简单，但是里面有些地方内容还是有些玄机的。设计cn需要重点考量的地方主要是cn到底是做重还是做轻。这是把双刃剑，主要有下面两方面问题。
No.1
如何做到sql语法兼容性？
接入节点主要负责sql的解析、执行计划的生成与下发，这些东西其实是sql解析器做的事情，我们可以直接将mysql或者pg的解析器甚至server层拿过来做sql解析和执行计划生成，而且就天然的兼容了mysql或者pg的语法。
No.2
如何处理元数据的问题？
上面的方案看似很完美的事情，但是有个问题：如果直接将mysql或者pg的server层搬过来的话，元数据怎么办？cn上到底放不放元数据？如果不放元数据，那么就需要一个统一的存放和管理元数据的地方，我在cn上建的表需要到某个固定地方更新元数据信息，查询也是一样。如果cn上存放元数据，那么元数据的更新就需要在各个cn之间进行同步，如果发生某个cn宕机，则任何ddl操作都会hang住，这时就需要有一个机制：在cn超时无响应后将cn 剔除出集群。
DN的设计
数据节点的设计主要考虑下面几个方面问题。
No.1 数据节点如何做高可用？
数据库的数据当然是最宝贵的，任何数据库都要有数据冗余方案，数据节点一定要有高可用，在保证rpo=0的基础上尽量缩短rto。细想一下，其实每个dn其实都是一个数据库实例，这里以mysql或者pg为例，mysql和pg本身是有高可用方案的，不管是基于主从半同步还是流复制，都可以在dn层面作为数据的冗余和切换方案。当然还有些数据库在dn层面引入了paxos、raft、quorum等的强一致方案，这也是在分布式数据库中很常见的设计。
No.2 如何做到在线扩容？
在线扩容是分布式数据库的一项巨大优点，而扩容数据节点必然涉及到数据向新节点的迁移，目前市面上的分布式数据库基本上都做到了自动的数据重分布。但是做到数据库自动重分布还不够，如何做到只迁移少部分数据以降低服务器IO压力成为关键问题。传统的散列方式是根据分区键哈希值对分区数量进行取模操作，得到的结果就是数据应该落入的分区，但是这种分布方法在增加删除节点时会造成大量的数据重分布，而一致性哈希的核心思想是每个分区不再是对应一个数字，而是对应一个范围，对计算的散列值进行范围的匹配，大体思路是将数据节点和键的hash值都映射到0~2^32的圆环上，然后从映射值的位置开始顺时针查找，将数据保存到找到的第一个节点上。如果超过2^32仍然找不到服务节点，就会保存到第一个节点上。
一致性哈希最大程度解决了数据重分布问题，但是可能会造成节点数据分布不均匀的问题，当然针对这个问题还有一些改进，比如增加虚拟节点。
GTM的设计
GTM顾名思义是一个全局概念，分布式数据库本来就是为了可扩展、提升性能、降低全局风险，然而GTM这个东西打破了这一切。
No.1 为什么需要GTM？
简单一句话总结就是：GTM是为了保证全局读一致性，而两阶段提交是为了保证写一致性。这里我们可能有个误区，如果没有gtm那么会不会造成数据不一致？会，但是只是某个时间点读的不一致，这个不一致也是暂时的，但是不会造成数据写的不一致，写的一致性通过两阶段提交来保证。
我们知道postgresql通过快照（snapshot）来实现MVCC与事务可见性判断。对于read commit隔离级别，要求每个事务中的查询仅能看到在该事务启动前已经提交的更改，以及当前事务中该查询之前所做的更改，这都要通过快照来实现。快照的数据结构中会包含事务的xmin（插入tuple的事务号）、xmax（更新或者删除事务的事务号）、正在运行的事务列表等相关信息。pg的每条元组（tuple）头信息中也会记录事务的xmin和xmax信息。Pg取得snapshot后会进行事务可见性判断，对于所有id小于xmin的tuple对当前快照可见，同时
id大于xmax的tuple对当前事务可见。当前扩展到分布式集群后，每台机器上都存在pg的实例，为了保证全局的读一致性，需要一个全局的组件来负责snapshot的分配，使得快照信息在各个节点之间共享，这就是gtm的工作。
No.2 GTM高可用的问题？
GTM作为分配全局快照和事务id的唯一组件，只能有一个，当然gtm可以做主备高可用，但是同一时刻只能有一个gtm在工作，gxid信息在主备之间进行同步，而且必须是实时强同步，这样就造成一个问题，虽然其他节点都分布式了，但是gtm始终是一个单点，单点故障时就会涉及到切换，切换过程是影响全局的，而且为了保证切换后gxid信息不丢失，gtm之间必须做到gxid的同步。针对高可用这块问题，可以将gtm的事务号存储信息剥离，将事务号信息存在第三方存储中，例如etcd就是个很好的选择，etcd是个强一致高可用的分布式存储集群，etcd比较轻量，适合用来存储事务号信息，同时它自身保证了高可用与强一致，这时gtm就不需要在主备之间同步gxid，如果发生主备切换，新主gtm只需要再去从etcd中取得最新事务号，写事务号也同理，主gtm会向主etcd节点写入事务号信息，通过etcd自身的raft复制协议保证一致性。这样的设计使得gtm的压力减轻很多。
No.3 GTM性能的问题？
GTM是大部分分布式数据库的性能瓶颈，它使得一套集群的整体性能甚至不如一台单机。也很好理解，任何一个事务开启都要先通过cn到gtm取事务号和快照信息，然后结果解析后下发到dn执行，然后cn进行汇总再返回给应用，路径很明显变长了，那么效率肯定变低，目前
优势在于可以利用多台机器的组合能力进行计算，计算资源得到了扩展。针对gtm的瓶颈问题当然也有解决方案，比如华为GaussDB就提出GTM-Free和GTM-Lite，gtm-free是在那种强一致读要求不高的场景下关闭gtm的功能，所有事物都不走gtm，这种情况下性能基本能够得到线性提升，该功能已经实现；gtm-lite是将事务分类，全局事务就走gtm，本地事务就直接下发，因为大多数情况下都是本地事务，所以性能提升也很明显，该功能还在研发阶段。
7.分布式数据库如何实现PITR
数据库的PITR一般都是通过一个基础备份加上持续不间断的wal归档来做到的，这个基础备份可以是在线的，因为它并不需要数据库当时处于一致性状态，一致性可以通过replay redo来实现，所以基础备份可以是文件系统tar命令而不需要文件系统级别的快照。PITR是通过基础备份加上redo日志能够恢复到任意时间点，这个任意时间点不同数据库有不同定义，可能是某个lsn，可能是某个snapshot，可能是某个timestamp。Postgresql数据库中能够基于redo恢复到任意的timestamp。
分布式数据库的PITR理论上和单机区别不大，每个节点备份自己的基础数据，这个数据不需要一致性，但是要考虑到分布式事务的问题，在做基础备份的时候必须保证之前的分布式事务（如果存在）已经全部完成，因为分布式事务是走两阶段提交协议，2pc在提交阶段不同的机器commit肯定有时间差，如果在这个时间差做了备份，会发现最后一台机
器有这个事务的redo，另一台没有，这样恢复的话就会造成数据不一致。这个问题可以通过pg中一个barries的概念实现，在分布式事务结束后打一个barrier，获得一致性点，然后再进行基础备份。对于redo的前滚来说，只需要将所有节点的redo前滚到一个一致性点即可。
一、何为分布式数据库系统？一个分布式数据库系统有哪些特点？ 答案：分布式数据库系统通俗地说，是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来，共同组成一个统一的数据库系统。因此，分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。一个分布式数据库系统具有如下特点： 物理分布性，即分布式数据库系统中的数据不是存储在一个站点上，而是分散存储在由计算机网络连接起来的多个站点上，而且这种分散存储对用户来说是感觉不到的。 逻辑整体性，分布式数据库系统中的数据物理上是分散在各个站点中，但这些分散的数据逻辑上却构成一个整体，它们被分布式数据库系统的所有用户共享，并由一个分布式数据库管理系统统一管理，它使得“分布”对用户来说是透明的。 站点自治性，也称为场地自治性，各站点上的数据由本地的DBMS管理，具有自治处理能力，完成本站点的应用，这是分布式数据库系统与多处理机系统的区别。 另外，由以上三个分布式数据库系统的基本特点还可以导出它的其它特点，即：数据分布透明性、集中与自治相结合的控制机制、存在适当的数据冗余度、事务管理的分布性。 二、简述分布式数据库的模式结构和各层模式的概念。 分布式数据库是多层的，国分为四层： 全局外层：全局外模式，是全局应用的用户视图，所以也称全局试图。它为全局概念模式的子集，表示全局应用所涉及的数据库部分。 全局概念层：全局概念模式、分片模式和分配模式 全局概念模式描述分布式数据库中全局数据的逻辑结构和数据特性，与集中式数据库中的概念模式是集中式数据库的概念视图一样，全局概念模式是分布式数据库的全局概念视图。分片模式用于说明如何放置数据库的分片部分。分布式数据库可划分为许多逻辑片，定义片段、片段与概念模式之间的映射关系。分配模式是根据选定的数据分布策略，定义各片段的物理存放站点。 局部概念层：局部概念模式是全局概念模式的子集。局部层：局部模式 局部模式是分布式数据库中关于物理数据库的描述，类同集中式数据库中的模式，但其描述的容不仅包含只局部于本站点的数据的存储描述，还包括全局数据在本站点的存储描述。 三、简述分布式数据库系统中的分布透明性，举例说明分布式数据库简单查询的 各级分布透明性问题。 分布式数据库中的分布透明性即分布独立性，指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关心全局数据的分布情况，包括全局数据的逻辑分片情况、逻辑片段的站点位置分配情况，以及各站点上数据库的数据模型等。即全局数据的逻辑分片、片段的物理位置分配，各站点数据库的数据模型等情况对用户和用户程序透明。
基于MyCat 分布式数据库解决方案的学汇总 最近公司推荐了mycat分布式中间件解决数据库分布式方案，今天到mycat官网学了一翻 （https://www.doczj.com/doc/3f2711692.html,），汇总下几个重点： 1、mycat是什么？ mycat是一个开源的分布式数据库系统,是一个实现了MySQL 协议的Server,前端用户可以把它看作是一个数据库代理,用MySQL 客户端工具和命令进行访问,后端可以用MySQL 原生(Native)协议访问数据库（不限于MYSQL数据库）, 其核心功能是分表分库,即将一个多表水平分割为N 个小表,存储在后端的数据库中。 以下是几种通俗的方式介绍MYCAT： 1）对于DBA 来讲: Mycat 就是MySQL Server,而Mycat 后面连接的MySQL Server,就好象是MySQL 的存储引擎,如InnoDB,MyISAM 等,因此,Mycat 本身并不存储数据,数据是在后端的MySQL 上存储的,因此数据可靠性以及事务等都是MySQL 保证的,简单的说,Mycat 就是MySQL 最佳伴侣,它在一定程度上让MySQL 拥有了能跟Oracle PK 的能力。 2）对于开发来讲:
Mycat 就是一个近似等于MySQL 的数据库服务器,你可以用连接MySQL 的方式去连接Mycat(除了端口不同,默认的Mycat 端口是8066 而非MySQL 的3306,因此需要在连接字符串上增加端口信息),大多数情况下,可以用你熟悉的对象映射框架使用Mycat,但建议对于分片表,尽量使用基础的SQL 语句,因为返样能达到最佳性能,特别是几千万甚至几百亿条记录的情况下。 3）对于架构师来讲： Mycat 是一个强大的数据库中间件,不仅仅可以用作读写分离、以及分表分库、容灾备份,而且可以用于多租户应用开发、平台基础设施、让你的架构具备很强的适应性和灵活性,借助于即将发布的Mycat 智能优化模块,系统的数据访问瓶颈和热点一目了然,根据返些统计分析数据,你可以自动或手工调整后端存储,将不同的表映射到不同存储引擎上,而整个应用的代码一行也不用改变。 2）双活部署 mycat、zk均采用双中心部署 3、常见的数据库切分优化方案 传统数据库存在着先天性的弊端,但是NoSQL 数据库又无法将其替今,NoSQL 只能作为传统数据的补充而不能将其
论分布式数据库的设计与实现 摘要：本文讨论某高校管理信息系统中分布式数据库的设计与实现。该系统架构设计采用C/S与B/S混合的架构方式。在全局数据与各院系的数据关系中，采用水平分片的方式；在全局数据与各部门之间，以及数据库服务器与Web数据库服务器的数据关系中，采用垂直分片的方式。设计过程中采用了基于视图概念的数据库设计方法。开发过程中在数据集成、测试、分布式数据库部署等方面做了大量的工作。并使用合并复制的方式有效地解决了分布式数据库中数据同步的问题。 关键词：分布式数据库架构设计应用数据集成合并复制 针对某高校管理信息系统的开发，该高校共有三个校区，总校区和两个校区，教务处等校级行政部门在总校区办公，15个院、系分布在两个校区。在工作中它们处理各自的数据，但也需要彼此之间数据的交换和处理，如何处理分散的数据和集中的管理是一个难题。学校信息系统中复杂而分散的数据信息之间的交换、相互转换和共享等问题是系统开发要解决的关键性问题，分布式数据库系统技术为解决这个问题提供了可能。 1、系统的架构设计 采用分布式的C/S与B/S混合的架构方式。各院系、部（室）通过局域网直接访问数据库服务器，软件采用C/S架构；其它师生员工通过Internet访问Web 服务器，通过Web服务器再访问数据库服务器，软件采用B/S架构。学校各部门之间工作时数据交互性较强，采用C/S架构可以使查询和修改的响应速度快；其它师生员工不直接访问数据库服务器，能保证学校数据库的相对安全。 2、数据的分布 从全局应用的角度出发，将局部数据库自下而上构成分布式数据库系统，各系部存放本机构的数据，全局数据库则存放所有业务数据，并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。 将关系分片，有利于按用户需求组织数据的分布，根据不同的数据关系采用了不同的分片方式： （1）在全局数据与各院系的数据关系中，由于各院系的数据是全局数据的子集，采用了水平分片的方式。 （2）在全局数据与教务处、总务处等各部门之间，数据是按照其应用功能来划分的，所以采用了垂直分片的方式。在数据库服务器与Web数据库服务器
近年来，计算机技术的发展日新月异，借助于计算机网络而崛起的数据库技术已不断渗透到了社会生活的各个领域．分布式数据库系统是数据库技术的一种，它的产生，使在地理上、组织上分散的单位得以实现信息、数据共享，使系统的可靠性、可用性等得到了明显的改善和提高．因此，如何优化分布式数据库系统，如何更高效地实施数据库查询等问题便显得尤为重要，它关系着整个系统性能和系统效率等诸多关键因素的完善和提高．1分布式数据库的定义 分布式数据库系统的基础是集中式数据库，但是比集中式数据库具有更大的可扩展性，它适用于单位和企业的各下属、分散部门，允许将分工后的针对性较强的各部门数据存储在本地存储设备上，从而提高用户操作应用程序的反馈速度，在一定程度上降低网络通信费用． 分布式数据库系统可以分为两种：一是物理分布逻辑集中，即在物理上是分布的，在逻辑上是一个统一整体，这类数据库系统比较适用于用途单一、专业性强的中小企业或部门；二是无论在物理上或是逻辑上都是分布的，这种分布式数据库系统类型称为联邦式，此类型主要用于集成大 范围数据库，因为该系统主要由用途迥异、 差别明显的数据库组成． 分布式数据库的物理分布性主要表现在数据库中的数据分别存储在不同的地域内或主机上，而逻辑集中性主要表现在无论用户处于哪个位置或使用本局域网中的哪台主机，都可以通过应用程序对数据库进行操作，但这些数据库具体的分布位置用户并不需要知道，就如同数据库存储在本机，并且由本机的数据库管理系统进行管理．2分布式数据库系统的特点 ２．１数据的独立性和分布的透明性 数据的独立性可以说是分布式数据库系统的核心和目标，而分布的透明性表现在用户在操作带有数据库的应用程序时，不必了解数据存储的具体物理位置，不必关心数据逻辑集中的区域，也不必验证本地系统支持哪些数据模型．分布透明的特点，在很大程度上增加了应用程序的可移植性． ２．２集中和自治相结合 对于分布式数据库系统来说，数据共享分为两层：局部共享和全局共享．局部共享是相对于局部数据库而言的，存储在局部数据库中的一般是专门针对本地用户的常用数据；全局共享就是说在各个分布的数据库区域，也能够支持 系统在全局上的应用，可以存储可供本网中其他位置的用户共享的数据．那么对于这两层数据共享的分类，就有相应的两种控制方式，即集中和自治，各个局部的数据库管理系统可以对本区域的数据库实施独立管理，称为自治；与此同时，为了协调各个局部数据库管理系统，为了宏观、整体地把握各局部数据库的运行情况等，系统还设置了集中控制的工作方式． ２．３易于扩展性 由于单位、 企业等的数据量越来越庞大，对于数据库服务器的需求也越来越多．如果服务器的应用程序支持水平方向的扩展，那么就可以通过多增加服务器来分担数据的处理任务． 3分布式数据库系统的设计３．１设计的原则 ３．１．１分布式数据库系统的主要设计原则是本地和近地．所以，在设计的过程中，应当尽量实现数据的本地化，这样可以有效减少数据节点之间的相互通信，从而提高整个系统的效率． ３．１．２为了改善和提高数据库数据的可用性和可靠性，有时候在分布式数据库系统中可以将数据保存为副本，如果数据的其中一个副本被损坏或者不能使用，那么在网络环境中的另一个节点中可以对损坏的副本进行恢复．不过，在恢复的同时有可能增加冗余的数据，所以在设计分布式数据库系统时应当全面考虑最优的数据冗余程序，从而减少数据库更新的成本． ３．１．３在用户通过应用程序对数据库进行操作的时候，分布式数据库系统应当将总的工作量分流到网络环境中的各局域节点，从而提高了应用程序的执行效率、扩大了数据传输的并行度、充分利用了各局域节点计算机的资源．因此在设计分布式数据库系统的同时，要将负荷合理地分流． ３．１．４在设计分布式数据库系统时，要对网络各局域节点进行存储能力的统筹，对有限的存储控件进行合理的规划．３．２设计的内容 与集中式数据库的设计相类似，分布式数据库系统也包括了数据库和应用．其中，数据库的设计又包括全局的模式设计和局部的模式设计．分布式数据库系统设计的关键是 Ｖｏｌ．２８Ｎｏ．１０ Ｏｃｔ．２０１２ 赤峰学院学报（自然科学版）ＪｏｕｒｎａｌｏｆＣｈｉｆｅｎｇＵｎｉｖｅｒｓｉｔｙ（ＮａｔｕｒａｌＳｃｉｅｎｃｅＥｄｉｔｉｏｎ）第２８卷第１０期（下） ２０１２年１０月分布式数据库系统的设计与优化 左 翔，姜文彪 （安徽医科大学计算机系，安徽 合肥 ２３００３２） 摘要：分布式数据库是数据库技术和网络技术相结合的产物，本文从分布式数据库系统的定义和特点入手，介绍了其设计、优化的目标以及优化的方法． 关键词：分布式数据库系统；设计；优化中图分类号：ＴＰ３１０ 文献标识码：Ａ 文章编号：１６７３－２６０Ｘ（２０１２）１０－００２０－０２ ２０－－
高并发分布式服务架构方案 下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取 分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格， 适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过 读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案， 但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对
于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。 基础服务 基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时 定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源 开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高 可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。 应用层 应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群， 可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。
分布式数据库技术在大数据中的应用
分布式数据库技术在大数据中的应用 摘要随着当前运营商对数据管理和应用需求的不断增加，分布式数据库技术得到极大的发展。在本文中首先对当前大数据环境下的分布式数据库技术进行介绍，然后分析分布式数据库技术在大数据中的具体应用。 关键词分布式数据库；数据管理；数据处理 中图分类号 TP3 文献标识码 A 文章编号 1674-6708（2016）165-0108-01 随着当前移动互联网技术的迅猛发展，数据的种类和数量呈现快速的增长，传统的处理方式逐渐的不能够适应当前的发展需要，基于此种背景下，分布式数据库技术需要得到更快的发展，以达到对大数据的存储、管理以及分析等处理要求。 1 大数据中发展分布式数据库的意义 在面对当前的大数据时代，传统的集中式数据库已经逐渐的不能够满足人们的使用要求，需要找到新的处理方式来进行更新，分布式数据库就是在这样的背景下逐渐的被发展和应用。分布式数据库在使用中有着许多传统集中式数据库不具备的优点：第一，分布式数据库有着极为强大的扩展能力，这是传统数据库所不具备的，在数据的存储方面表现出巨大的优势；第二，来自于成本上的优势。
在大数据中，如果仍旧采用原有的数据库，在进行扩容的时候，会花费大量的资金，使得成本上花费巨大，而且所取得的效果也是有限的。分布式数据库则只需要较少的资金就能够完成扩容处理，占据着特别大的优势[1]；第三，分布式数据库在用户上有着很大的优势，分布式数据库让人们对大数据的存储、分析和处理变得容易和快捷。 2 分布式数据库技术分析 在大数据中，分布式数据库技术得到极大的发展，也正是由于分布式数据库技术表现出来的先进性能，才使得分布式数据库得到广泛的使用。在分布式数据库中，其由很多个并行的处理单元组成，而且每个处理单元都是一个完整的系统，其中包括数据的存储，数据的分析等，对于每一个处理单元来说，其所处的位置和作用都是对等的，而且是相对独立的。混合存储技术：突破传统行存的限制，实现行列混合存储。该项技术对于分布式数据库的性能有着很大的提升，使得分布式数据库在运行速度和运行的灵活性上都有很大的提高。再就是智能索引技术，该种技术所占用的空间减少，并且能够很好的解决后面数据库慢的问题，不会对后面的索引数据造成影响[2]。除此之外，分布式数据库中还具有许多先进的技术，如并行处理技术、高效透明压缩技术等，都是传统数据库中所不具备
分布式数据库设计报告
目录 1案例背景 (1) 需求分析 (1) 2 分布式数据库设计 (2) 设计目标 (2) 总体设计目标 (2) （4）可靠性： (3) 完成方式及周期 (3) 分布式数据库架构图 (4) 物理设计施工 (5) 3 总结 (5) 4所用设备汇总 (7) 5所使用软件 (7)
成品车间分布式数据库设计 1案例背景 随着成品车间信息化程度越来越高，我们的传统集中式数据库系统的缺点逐渐体现出来主要有: 1、所有数据处理、存储集中在一台计算机上完成，一旦机器损坏或系统崩 溃数据数据很难恢复。 2、单台机器写入/查询处理能力不足，一台机器既要读取数据，又要写入数 据，遇到大批量超过单台数据库的处理能力，就会出现卡顿，在生产时 间不敢批量制造/查询数据。 3、硬件性能瓶颈，包括(硬盘、CPU、内存)，使用升级硬件的方法效果有限。 4、出现故障没有备用服务器可以替代。 5、当前成品车间存在2种数据库，oracle，sql sever，交叉使用不方便管 理维护，出现问题排查困难。 6、由于数据库初期创建数据库/表比较混乱，现在对数据的统计管理需要在 两台服务器之间交叉进行，统计难度高，效率低。 需求分析 成品车间信息化程度越来越高，各个节点产生的数据量越来越大，对数据系统要求越来越高，我们所使用的传统集中式数据库已经无法从容应对越来越大的数据。 成品车间生产线数据库主要有oracle和sql server两种，分别分布在2台计算机中，柔性线、自动线、三相线交叉使用两种类型数据库，主要出现的问题有; 1、一旦其中一个数据库出现问题，那么就有很大的几率导致三条线体 的某个节点或全部节点失去数据服务，导致停线。 2、数据库出现故障，必须停线，故障修复之后才可以上线使用。
1.大型分布式数据库解决方案 企业数据库的数据量很大时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影响最终用户的体验；当数据量很大的时候，对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服务或者高负荷运转很长时间，影响数据库的可用性和易管理性。 分区表技术 让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器的硬件资源，不能从根本上解决问题。 分布式分区视图 分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数
据完整性约束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。对于全局查询并不是并行计算，有时还不如不分区的响应快。 库表散列 在开发基于库表散列的数据库架构，经过数次数据库升级，最终采用按照用户进行的库表散列，但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。 面对海量数据库在高并发的应用环境下，仅仅靠提升服务器的硬件配置是不能从根本上解决问题的，分布式网格集群通过数据分区把数据拆分成更小的部分，分配到不同的服务器中。查询可以由多个服务器上的CPU、I/O来共同负载，通过各节点并行处理数据来提高性能；写入时，可以在多个分区数据库中并行写入，显著提升数据库的写入速度。
金融级分布式数据库架构设计
目录 1.行业背景 (3) 2.数据库分布式改造的途径 (3) 3.分布式数据库总体架构 (4) 4.两阶段提交的问题 (5) 5.CAP与BASE的抉择 (7) 6.raft的优势 (8) 6.1. Leader选举 (9) 6.2. 日志复制 (10) 6.3. 安全性 (11) 7.分布式数据库如何实现PITR (16)
1.行业背景 银行业从最初的手工记账到会计电算化，到金融电子化，再到现在的金融科技，可以看到金融与科技的结合越来越紧密，人工智能、大数据、物联网、区块链等新兴技术改变了金融的交易方式，为金融行业的创新前行提供了源源不断的动力。同时互联网金融的兴起是一把双刃剑，带来了机遇的同时也带来了挑战。普惠金融使得金融的门槛降低，更多的普通大众参与到金融活动中，这让金融信息系统承受了越来越大的压力。于是我们可以看到大型商业银行、保险公司、证券公司、交易所等核心交易系统都在纷纷进行分布式改造，其中数据库作为有状态的应用，成为了信息系统中唯一的单点，承担了所有来自上层应用的压力。随着数据库瓶颈的凸显，进行分布式改造迫在眉睫。 2.数据库分布式改造的途径 数据库进行分布式改造主要有三种途径：分布式访问客户端、分布式访问中间件、分布式数据库。由于其分布式能力实现在不同的层次（应用层、中间层、数据库层），对应用程序有不同的侵入程度，其中分布式访问客户端对应用侵入性最大，改造难度最大，而分布式数据库方案对应用侵入性最小，但是架构设计及研发难度最大。
3.分布式数据库总体架构 其实当前市面上的分布式数据库总体架构都是类似的，由必不可缺的三个组件组成：接入节点、数据节点、全局事务管理器。总体架构如下，协调节点负责sql解析，生成分布式执行计划，sql转发，数据汇总等；数据节点负责数据存储与运算；全局事务管理器负责全局事务号的生成，保证事务的全局一致性。这个架构或多或少都受到了google spanner F1论文的影响，这篇文章主要分析了这几个组件在实现上有什么难点，该如何进行架构设计。
分布式数据库管理系统简介 一、什么是分布式数据库： 分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。 分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。 分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。 在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体：即在用户面前为单个逻辑数据库，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲，不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统(DBMS)管理一样，用户并没有什么感觉不一样。 分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。 分布式数据库系统是一个客户/服务器体系结构。 在系统中的每一台计算机称为结点。如果一结点具有管理数据库软件，该结点称为数据库服务器。如果一个结点为请求服务器的信息的一应用，该结点称为客户。在ORACLE客户，执行数据库应用，可存取数据信息和与用户交互。在服务器，执行ORACLE软件，处理对ORACLE 数据库并发、共享数据存取。ORACLE允许上述两部分在同一台计算机上，但当客户部分和服务器部分是由网连接的不同计算机上时，更有效。 分布处理是由多台处理机分担单个任务的处理。在ORACLE数据库系统中分布处理的例子如： 客户和服务器是位于网络连接的不同计算机上。 单台计算机上有多个处理器，不同处理器分别执行客户应用。
分布式数据库在学生信息管理系统中的应用 班级: 姓名: 设计时间: 指导教师: 评语:_________________________________ 评阅成绩:＿＿＿＿评阅教师:＿＿＿＿＿ 目录 摘要 (2) 第一章绪论 (4) 1．1课题研究的意义 (4)
1．2分布式数据库技术国外发展现状 (5) 1．3分布式数据库技术国内发展现状 (5) 1．4分布式数据库技术发展动向 (5) 第二章分布式数据库理论 (7) 2．1分布式数据库理论 (7) 2．1．1分布式数据库系统的有关概念 (7) 2．1．2分布式数据库系统的特点 (7) 2．1．3分布式数据库数据分片 (9) 2．1．4分布式数据库数据分布 (9) 2．1．5数据分布设计策略 (10) 第三章系统总体设计 (13) 系统功能设计 (13) 系统结构设计 (13) 系统概念设计 (14) 系统逻辑设计 (14) 系统物理设计（表设计） (14) 第四章系统实现 (19) P OWER B UILDER开发工具简介 (19) P OWERBUILDER 9应用程序开发的基本步骤 (19) 编码规范 (20) 应用程序对象A PP_MAPBEX (20) 具体窗口的实现 (21) 摘要 社会在飞速的发展，计算机的应用正深入到人们生活的每一个角落。我们作为当代的大学生，更应该推动和实践计算机信息系统在生活在的应用，为将来的工作和学习打好基础。
本系统为简易的分布式学生信息管理系统，实现学生的基本信息管理和学生成绩管理。 本系统采用了Power Builder9＋SQL2000的结构来开发程序。Power Bulider(以下简称pb)做为应用程序开发工具和程序界面开发工具，pb具有功能强大，集成性好的优点，很适合小型系统的应用开发和界面开发。后台数据库使用SQL 2000系统，Microsoft SQL Server 2000是美国微软公司推出的使用相当广泛的数据库管理系统，包含一套图形工具，如服务器管理（用于启动和关闭数据库服务）、企业管理器（用于创建和修改数据库及备份数据库等）和查询分析器（用于交互执行Transact-SQL 语句和过程并提供图形查询分析功能）等。本报告说明了整个系统从分析到设计再到实现的具体步骤和过程，从中我学到了很多知识和技能。 关键词：分布式信息管理系统 PB+SQL2000
分布式数据库系统(DDBS概述 一个远程事务为一个事务,包含一人或多个远程语句,它所引用的全部是在同一个远程结点上.一个分布式事务中一个事务,包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据. 在分布式数据库中,事务控制必须在网络上直辖市,保证数据一致性.两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句. ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性,利用视图、同义词、过程可提供ORACLE分布式数据库系统中的位置透明性. ORACLE提供两种机制实现分布式数据库中表重复的透明性：表快照提供异步的表重复;触发器实现同步的表的重复。在两种情况下，都实现了对表重复的透明性。 在单场地或分布式数据库中，所有事务都是用COMMIT或ROLLBACK语句中止。 二、分布式数据库系统的分类： (1 同构同质型DDBS：各个场地都采用同一类型的数据模型(譬如都是关系型，并且是同一型号的DBMS。 (2同构异质型DDBS：各个场地采用同一类型的数据模型，但是DBMS的型号不同，譬如DB2、ORACLE、SYBASE、SQL Server等。 (3异构型DDBS：各个场地的数据模型的型号不同，甚至类型也不同。随着计算机网络技术的发展，异种机联网问题已经得到较好的解决，此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据。 三、分布式数据库系统主要特点： DDBS的基本特点： (1物理分布性：数据不是存储在一个场地上，而是存储在计算机网络的多个场地上。 逻辑整体性：数据物理分布在各个场地，但逻辑上是一个整体，它们被所有用户(全局用户共享，并由一个DDBMS统一管理。 (2场地自治性：各场地上的数据由本地的DBMS管理，具有自治处理能力，完成本场地的应用(局部应用。 (3场地之间协作性：各场地虽然具有高度的自治性，但是又相互协作构成一个整体。 DDBS的其他特点 (1数据独立性 (2集中与自治相结合的控制机制 (3适当增加数据冗余度
根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。而传统数据库保证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大的NoSQL运动，就是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。 但是，对于CAP理论也有一些不同的声音，数据库大师Michael Stonebraker就撰文《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》，表示为了P而牺牲C是不可取的。事实上，数据库系统最大的优势就对一致性的保证，如果我们放弃了一致性，也许NoSQL比数据库更有优势。那么，有没有可能实现一套分布式数据库集群，即保证可用性和一致性，又可以提供很好的扩展能力呢？回答是：有的。 目前，有很多分布式数据库的产品，但是绝大部分是面向DSS类型的应用，因为相比较OLTP应用，DSS应用更容易做到分布式扩展。Michael Stonebraker提到了一种新型的数据库VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世，但是从技术资料上来看，它有几个特点： 1.采用Share nothing架构，将物理服务器划分为以CPU core为单位的Virtual node，采用Sharding技术，将数据自动分布到不同的Virtual node，最大限度的利用机器的计算资源； 2.采用内存数据访问技术，类似于内存数据库(In-memory database)，区别于传统的数据库(Disk-based database)，消除了传统数据库内存管理的开销，而且响应速度非常快； 3.每个Virtual node上的操作是自治的，利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销(比如Latch和Lock)； 4.数据同步写多个副本，不存在单点故障，而且消除了传统数据库需要记录redo log的开销。
山西大学研究生学位课程论文（2014 ---- 2015 学年第 2 学期） 学院（中心、所）：计算机与信息技术学院 专业名称：计算机应用技术 课程名称：分布式数据库技术 论文题目：分布式数据库研究现状及发展趋势授课教师（职称）：曹峰（） 研究生姓名：刘杰飞 年级：2014级 学号：201422403003 成绩： 评阅日期： 山西大学研究生学院 2015年 6 月17日
分布式数据库研究现状及发展趋势 摘要随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，特别是计算机网络与数字通信技术的飞速发展，卫星通信、蜂窝通信、计算机局域网、广域网和激增的Intranet及Internet得到了广泛应用，使分布式数据库系统应运而生。为了符合当今信息系统的应用需求和企业组织的管理思想和管理模式。分布式数据库提供了解决整个信息资产被分裂所成的信息孤岛，为孤岛联系在一起提供桥梁。本文主要介绍分布式数据库的研究现状，存在的一些问题以及未来的发展趋势。 关键词分布式数据库；发展趋势；现状及问题 1.引言 随着信息技术的飞速发展，社会经济结构、生产方式和消费结构已经发生了重大变化，这些变化深刻地影响着人民生活的方方面面。尤其是近十年来人们对计算机的依赖性越来越强，同时也对计算机提出了更高的要求。随着数据库在各个行业中的不断发展，各行业也对数据库提出了更高的要求，数据量也急剧增加，同时有关大数据分析的讨论正在愈演愈烈。甚至出现了爆炸性增长的趋势，一方面是由于移动互联网和移动智能终端的普及发展，数据信息正以每年40%的速度增长，造成数据量庞大；同时，数据种类呈多样性，文本、图片、视频等结构化和非结构化数据共存；另一方面也要求实时交互性强；最重要的是大数据蕴含了巨大的商业价值。相应的对于管理这些数据的复杂度也随之增加。同时各行业部门或企业所使用的软硬件之间的差异，这给开发企业管理数据库管理软件带来了巨大的工作量，如果能够有效解决这个问题，即使用同一模块管理操作不同的数据表格，对不同的数据表格进行查询、插入、删除、修改等操作，也即对企业简单的应用实现即插即用的功能，那么就能大大地减少软件开发的维护和更新费用，缩短软件的开发周期。分布式数据库系统的开发，降低了企业开发的成本，提高了软件使用的回报率。当今社会已进入了信息时代，人们将越来越多的信息存储在网络中的计算机上。如何更有效地存储、管理、共享和提取信息，越来越引起人们的关注。集中式数据库已经不能满足人们的需求，因此分布式数据库系统应运而生，并且得到迅速发展。 分布式数据库系统的出现，有效地利用企业现有资源和网络资源。分布式数据库系统是一个面向地理上分布而在管理上需要不同程度集中的处理系统，主要解决在计算机网络上如何进行数据的分布和处理。由于分布式数据库有许多突出的优点，因此，分布式数据库系统可以广泛地应用于大企业，多种行业及军事国防等领域，这对建立集约型社会，加快社会主义现代化建设，将具有重要的现实意义。。
第一章 1.1 采用分布式数据库系统的主要原因是什么？ 集中式数据库系统的不足：1.数据按实际需要已经在网络上分布存储，如果再采用集中式处理，势必造成附加成本和通信开销，2,。应用程序集中在一台计算机上运行，一旦该计算机发生故障，将会影响整个系统的运行，可靠性不高。3集中式处理导致系统的规模和配置都不够灵活，系统的可扩展性较差。 1.2 分布式数据库系统有哪几种分类方法？这些方法是如何分类的？ 1.按局部数据库管理系统的数据模型的类型分类。 （1）同构型：同构同质型：各个站点上的数据库的数据模型都是同一类型的，而且是同一种DBMS。 同构异质型：各个站点上的数据库的数据模型都是同一类型的，但不是同一种DBMS。 （2）异构型：各个站点上的数据库的数据模型各不相同。 2.按分布式数据库系统全局控制系统类型分类 （1）全局控制集中型DDBS （2）全局控制分散型DDBS （3）全局控制可变型DDBS 1.3 什么是分布式数据库系统？它具有那些主要特点？怎样区分分布式数据库系统与只提供远程数据访问的网络数据库系统？ 分布式数据库系统是物理上分散而逻辑上集中的数据库系统，其可以看成是计算机网络和数据库系统的有机结合。 基本特点：物理分布性、逻辑整体性、站点自治性。 导出特点：数据分布透明性、集中与自治相结合的机制、存在适当的数据冗余度、事务管理的分布性。 区分：分布式数据库的分布性是透明的，用户感觉不到远程与本地结合的接缝的存在。 1.6分布式DBMS具有哪些集中式DBMS不具备的功能？ 数据跟踪，分布式查询处理，分布式事务管理，复制数据管理，安全性，分布式目录管理 1.14分布式数据库系统的主要优点是什么？存在哪些技术问题？ 分布式数据库系统优点：良好地可靠性和可用性；提高系统效率，降低通信成本；较大的灵活性和可伸缩性；经济型和保护投资；适应组织的分布式管理和控制；数据分布式具有透明性和站点具有较好的自治性；提高了资源利用率；实现了数据共享。
从Google Spanner漫谈分布式存储与数据库技术 文/曹伟 Spanner 的设计反映了 Google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 Megastore 的数据模型，Chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 BigTable 中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner 代表了分布式数据库领域的新趋势——NewSQL。 Spanner 是 Google 最近公开的新一代分布式数据库，它既具有 NoSQL 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 SQL 的查询语言、支持表连接、支持事务（包括分布式事务）。Spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 Spanner 集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google 广告业务的后台（F1）已从 MySQL 分库分表方案迁移到了Spanner 上。 数据模型 传统的 RDBMS（例如 MySQL）采用关系模型，有丰富的功能，支持 SQL 查询语句。而NoSQL 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner 继承了 Megastore 的设计，数据模型介于 RDBMS 和 NoSQL 之间，提供树形、层次化的数据库 schema，一方面支持类 SQL 的查询语言，提供表连接等关系数据库的特性，功能上类似于 RDBMS；另一方面整个数据库中的所有记录都存储在同一个key-value 大表中，实现上类似于 BigTable，具有 NoSQL 系统的可扩展性。 在 Spanner 中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表——用户表（Users）和相册表（Albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一
大型分布式数据库应用的案例 做大型数据库应用的时候，随着数据量越来越大，计算越来越复杂，对于性能的挑战越来越大。我们只能去使用现有的数据库方案：比如SQL SERVER Cluster或者Oracle RAC等,但是这也就等于走上了一条烧钱的道路，小则几十万，大则上百万乃至更多，另外还是解决不了维护的问题，要改一个表或者还原一次数据库都得几个小时或者更长的时间。最根本的办法还是像google那样有成千上万的中小型机器来代替超大型机器，每一次查询都会由几十台上百台机器来负载的分布式计算才是趋势。这里给大家介绍一个类似的数据库上的相关案例 1 背景 我们知道数据是一个公司的命脉，随着业务越做越大，数据量也会越来越大，计算也会越来越复杂，性能，可靠性，可扩展性的需求就会越来越强烈，这个时候一个集中式的数据库显然已经满足不了需求了。对于技术决策者来说有两条路可以走，第一：按照现有的大型数据库的解决方案，比如SQL SERVER Cluster或者Oracle RAC 等,但是这也就等于走上了一条烧钱的道路，小则几十万，大则上百万乃至更多；第二：使用真正能够扩展的分布式数据库，利用中小型服务器甚至是PC机的累加来替代大型的服务器，这也是很多公司希望的，却苦于没有合适产品，现在有了ClusterKiller，用它真正能给您带来：高性能，高可用性，高扩展性，高性价比。 2 方案比较 2.1 SQL SERVER的集群模式 这种结构只能说是一种故障转移的机制，当有一个节点出现问题后把负载转移到另一个节点上。在负载能力上和扩展性上没有任何办法，而且还浪费了硬件资源
2.2 Oracle Real Application Clusters (RAC) Oracle Rac最多可支持64个节点，基本上算是解决了性能，扩展性的问题了，但是它在存储上还是一个单点，且不说出现故障怎么办，IO也可能会成为性能瓶颈。我们都知道一个数据库大到一定程度的时候，在物理上分区才能从根本上解决问题，对几十万数据进行查找和几百万上千万的数据进行查找在系统的消耗上以及响应时间上有着几何级的降低。 2.3 Cluster Killer 从图例中可以看出，下面的像网格一样的机器叫数据层，每个机器上存储着数据全集的一个分区，每一行组成一个数据全集，每一列是某个分区的多份相同的数据从而达到查询时负载均衡的效果，同时也是高可用性的保障：某个列的机器出现问题后其他的机器会负载访问。为了不让这样一个复杂的结构暴露给应用程序，在数据层上面又放了一层机器叫中间层，中间层机器的数据库中驻留着的中间件来处理SQL语句，根据SQL语句的类
一、填空 分布式数据库系统按局部数据库管理系统的数据模型分类，可以分为和两类。 同构型DDBS 异构型DDBS 分布式数据库系统按全避控制系统类型分类，可以分为、 和三类。 全局控制集中型DDBS 全局控制分散型DDBS 全局控制可变型DDBS 分布式数据库是分布式数据库系统中各站点上数据库的逻辑集合，它由和组成。 应用数据库描述数据库 数据分片的三种基本方法是：、和三类。 水平分片垂直分片混合分片 分布式数据库中的数据分布策略有：、、 和四层。 集中式分割式复制式混合式 分布式数据库是多层模式结构，一般划分为、、 和四层。 全局外层全局概念层局部概念层局部内层 一个分布式数据库管理系统一般应包括、、 和四个基本功能模块。 查询处理模块完整性处理模块调度处理模块可靠性处理模块 分布透明性包括、和三个层次。 分片透明性位置透明性局部数据模型透明性 分布式数据库系统的创建方法，大致可分为和两种。 组合法重构法 集中式数据库设计一般包括：需求分析，概念设计，逻辑设计和物理设计四个阶段，分布式数据库设计除了上述四个阶段外，还需增加一些个新的阶段，它位于和之间。 分布设计逻辑设计物理设计 水平分片的方法可归为和两种。 初级分片导出分片 DATAID-D相对于DATAID-1增加了和两个阶段。 分布要求分析分布设计 DATAID-D中的分布设计分成、、 和四个阶段。 分片设计非冗余分配冗余分配局部模式的重新构造 分布式查询优化的准则是。通信费用和响应时间最短 在分布式系统中，查询代价QC＝。I/O代价+CPU代价+通信代价 在分布式环境下，查询可分为、和三种类型。局部查询远程查询全局查询 分布式查询处理可以分为、、和四