分布式数据采集（精选12篇）
分布式数据采集 篇1
1引言
随着移动互联网、电子商务、社交网络等互联网新兴技术普及和应用,图像、视频、日志等网络数据呈现爆炸性增长。淘宝网近4亿的会员每天产生的商品交易数据约20TB, Facebook约10亿的用户每天产生的日志数据超过300TB[1]。大数据时代已然来临,大数据领域也成为当今热门的研究课题。而数据是实现大数据研究的基础,传统的数据采集技术方案已经难以满足快速采集高质量的数据集的需求。所以如何高效地采集海量的高质量数据对大数据应用与研究具有极其重要的作用。
本文提出一种高效新型的大数据采集技术方案。主要是采用分布式结构,在解析模块中提出了基于标签树节点权重的正文提取算法。该算法通过比较标签树节点的权值, 然后剪枝掉无用的信息块,从而能快速地定位正文信息内容,免去无用信息的解析时间,提高解析的速度。而针对网页的访问频数限制,引入IP代理池技术。通过代理池流入流出更新机制来保证池中代理的可用性。通过切换代理来保证系统能持续工作,消除限制时间的等待,这将大大提高系统的采集效率。
2系统框架设计
2.1整体架构
系统的整体框架如图1所示,主要包括5个模块: 抓取模块、IP代理池模块、解析模块、URL处理模块和数据存储模块。其中抓取模块从URL队列中获取要爬取的URL。然后调用从IP代理池中获取的可用代理,从互联网中抓取原始的数据,并交由解析模块处理。解析模块首先对数据进行预处理,去掉一些明显的噪声。然后通过基于标签树块节点权重的正文提取算法来提取正文信息。 URL相关数据交由URL处理模块处理,而基本数据则由数据存储模块处理。URL处理模块主要用于对分布式抓取的控制。而数据存储模块则对数据进行规则化和持久化, 为后续的分析和处理奠定基础。
2.2分布式架构
系统采用主 / 从的分布式架构,如图2所示,主控制节点从待爬URL队列中提取URL分配给各抓取主机。然后由抓取主机完成采集任务和解析任务并将已经成功抓取的URL和提取到的新的URL交由主控制节点处理。成功抓取的URL缓存到已爬集合中,再根据已爬集合过滤出新的URL,并将它们缓存到对应的待爬队列中。其中待爬队列和已爬集合均使用内存数据库redis来实现。待爬队列采取先存先分配的策略,用于后续的爬取。
3正文信息提取
在正文信息提取这方面,国内外学者已经做了大量的工作研究。文献 [2-5] 采用的是基于视觉特征的算法。 该类算法是在微软研究院提出的VIPS(vision-based page segmentation) 网页分块算法的基础上提出的。虽然可以达到很好的效果,但VIPS算法相对复杂,且迭代次数较多, 同时其还依赖浏览器内核代码,故需消耗较长的时间。而文献 [6] 根据相似度对网页进行归类,对每类网页训练得出模板,然后根据模板对未知的网页进行提取。该方法无法适用于结构不同的网页正文提取。文献 [7] 则使用基于标记窗的方法。标记窗的提法不错,但其对每个标记窗文本都要先分词,然后计算词序列距离。不仅对分词技术有比较高的需求,同时也存在效率不高问题。
基于上述算法存在通用性和效率的问题,本文提出一种高效通用的基于标签树块节点权值的正文提取算法。其根据特定的标签对网页进行分块,并构建标签树。然后自底向上计算标签树节点的权值,通过比较权值、剪枝,最终保留正文信息的子树。实验证明该算法能在短时间提取到正文信息,从而提高解析的效率。
3.1构造标签树
目前大部 分网页布 局的主流 分块标签 是 <div>,<table>,<p>。故只使用这些标签来构建标签树。在构造标签树前,还要对源HTML文档先做预处理,去除一些明显的噪声。如文档中的内部样式文本 <style> 块,头标记 <head> 块,Java Script脚本 <script> 块和注释 <!--…--> 块等。本文使用正则表达式的方法去除这些噪声。
构造标签树时,使用堆栈作为辅助空间。具体构造步骤如下:
(1)将根标签 <HTML> 入栈。
(2)当遇到分块开始标签,将该分块作为栈顶块节点的子节点。并将该块标签入栈。
(3)当遇到分块结束标签,栈顶出栈。
(4)若栈为空,构造结束。否则继续扫描,遇到分块开始标签跳(2),遇到分块结束标签跳(3)。
具体构造情况见图3。其中 (a) 为HTML源文档。A— G为分块标签。而 (b) 则是由 (a) 而构建出来的标签树。
3.2正文信息提取算法
因为正文信息均是所含内容最多的部分,故一般大部分网页经过分块处理后,正文信息块总是包含分块数最多的那一颗子树,并且该子树比与其同层的兄弟子树块数差异较大。故本文提出基于标签树块节点权值的正文提取算法。在构造好标签树的基础上,自底向上给每个块节点赋予权值。赋值规则为:
若该块节点为叶子节点,则其权值wi=1 。
若该节点为非叶子节点,且N为该节点的所有子节点集合,则其权值
(1) 在给块节点赋值的同时,还要将其与兄弟节点间最大权值的节点进行比较。设i节点的权值为wi,其兄弟节点的最大权值为wmax。令变量R为
(2) 当变量R <Q时,便对i节点进行剪枝。其中Q为由经验设定的阀值。
图4为阀值Q=4时的具体剪枝情况。显而易见,通过剪枝,可以减少对5个无用块的解析。只需对含正文信息的9个节点进行解析就好。因此我们通过正文提取算法提高了35.7% 的解析效率。所以当无用信息块节点相对较多的时候,那么解析效率还会有更大的提升。可见通过调用正文提取算法,不断地剪枝,便可以去除广告、导航链接、版权信息等无用信息节点,从而得到最终的正文信息节点。这将减少无用信息的解析,从而不必浪费时间去解析无用信息,大大加快网页解析的速度。
4IP代理池
一些网站为了保护自身数据的安全或减轻网站的负担,其对同一IP的访问次数会有所限制。当一个IP所访问请求超过其承受范围时,该网站会采取拦截措施,禁止该IP对网站进行访问,待一定时间后才会释放该IP的限制。为解决IP限制问题,本文使用IP代理池机制,即使用一个公共的代理池来切换代理。每次抓取一定数量数据或一定时间后,或出现IP限制情况时,便从代理池中获取一个新的可用的代理,并切换到该代理继续访问。
代理池里面的代理不是固定不变的,它会不断地从相关代理网页中获取可用代理注入到代理池中。且还会自动定时对池中代理进行检测更新,并把一些无用的代理删除。如图5所示,池中每个代理均有一标记 (flag) 记录着该代理的状态:可用 (useful)、正在使用 (using) 和无用 (useless)。每次从池中抽取标记为useful的代理分配给抓取主机,并修改该代理标记为using。若因IP限制而从抓取主机返回的代理标记为useless,否则正常返回标记为useful。当自动更新触发时,则对池中所有标记为非using的代理进行检测。检测后无用的代理均从池中删除掉。
使用IP代理池机制可以尽量避免IP限制情况发生, 若IP限制发生,其也可省去等待IP限制释放的时间,这确保了抓取主机持续的运作,从而保证了抓取的数据量。 同理,当一些需要登录才能访问的网站,如微博,可加入类似的用户账户池,定时切换用户进行访问。
5实验分析
本文以新浪微博为例,验证方案的可行性。实验集群机器CPU为Intel(R) Xeon(R) 2.60GHz,内存为2GB, 操作系统为centos 6.5。其中用1台机器采集用户信息, 1台机器采集微博信息,2台机器采集评论信息。程序用java开发,打包成jar放到机器集群上运行。集群持续运行12小时。
采集的数据量见表1。根据表1的数据量与文献[9]结果进行对比得到图6a、图6b。可见在采集速率和持续稳定性上,本文方案基于文献[9]有不错的提升。主要是因为本文提出了基于标签树块节点权值的正文提取算法,其大大减少无用的非主题信息块,从而加快解析的速率。而引入IP代理池技术则保证的系统的持续性和稳定性。
为验证系统的可扩展性,我们将采集评论信息的机器由2台增加到4台。则每小时平均评论采集量由12.83万条增加到23.54万条。虽然性能只达到1.8倍提升,并没有达到理想2倍的提升,其原因可能是带宽或网络原因所致。但也可见系统具有好的扩展性。因此,在带宽支持的情况下,可通过简单的增加采集机器便可得到数据量的相应提升。
6结束语
本文提出了一种高效的大数据采集技术方案,并在解析模块中提出了基于标签树块节点权值的正文提取算法。该算法可以剔除无用的非正文信息块,从而提升了解析效率。而针对IP限制问题引入代理池技术,保证系统的持续性和稳定性。方案基于并行的分布式爬取方式, 具有强的可扩展性。在带宽允许情况下,通过简单增加爬取节点就可提升采集的数据量。实验已经证明该方案有强可用性,为后续的大数据研究奠定了强有力的基础。
分布式数据采集 篇2
第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协作，帮 助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你可以通过一些主键来组织海量数据，并实现高效的 查询。Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。
项目主页：www.open-open.com/lib/view/home/1339253305568
分布式数据采集 篇3
关键词：分布式数据库；数据分片；数据分配；分布透明性
中图分类号：TP311.13 文献标识码：A文章编号：1007-9599 (2011) 07-0000-03
Discussion on Comparison of Data Partitioning and Distribution Relationship in Distributed Database
Wang Baoping
(Tarim Southwest Company,Petro China Tarim Oilfield Company,Xinjiang 844804,China)
Abstract:This paper compares dist ributed database with cent ralized database and indicates data of ragment and allocation isthe important aspect in designing dist ributed database.Then,it gives purpose principle and technique of data of ragment and allo2cation,explains the transparency of dist ributed data,and illuminates the relation between data fragment and allocation simply.Finally it outlines some problems about data fragment and allocation in dist ributed database design.
Keywords:Dist ributed database;Data f ragment;Data allocation;Dist ributed transparency.
分布式数据库系统通过把分布在计算机网络的不同结点或场地，物理上属于多个数据子集，逻辑上属于同一系统之数据集合的海量数据实现数据应用，以实现比集中式数据库系统更好的性能、可扩充性、可用性和自治性[1]。从数据意义上讲，数据分布即数据分片与分配的合理与否或者说合理性的高低，不仅影响着访问的局部性，即尽可能地把用户要求访问的数据就在本结点或本场地，而且也制约着数据查询及事务处理的效率。
以关系数据库为例， 在关系型分布式数据库系统（RDDB）中，简单地说，数据分片是从逻辑上将全局关系划分为逻辑片断即子关系，而数据分配就是再以一定的冗余度将子关系分配到多个结点上，数据分布即数据分片与数据分配的总和。
单纯从数据分布的角度看，集中式数据库系统可以看作分布式数据库系统的一个特例，是集中式还是分布式，最终的目的都是为了使数据可以更好地服务于应用，而数据分片与分配就是达成此目的的方法。数据分片是一种对关系的划分，在集中式数据库中可以将所有的表视为一个总全局表的逻辑子表，而总全局表是这些子表的并集，其属性包括这些子表的所有属性，元组包括这些子表的所有元组，对应的在这个总全局表上元组的非空值呈块状区域分布。数据分配则是将这些子表以不同的冗余度存放在一个或多个场地或节点，区别在于集中式数据库不存在数据复制的问题，不需要存在多副本，但也会出现表名不同，但表属性和属性值完全相同。
一、数据分片
（一）数据分片原则
实现对全局关系的逻辑划分，以用户需求为目标，尽可能的提高系统的可用性，适应分布式的事务处理数据查询。
（二）数据分片原则
设全局关系R 被分片为逻辑片断集合S={S1，S2，⋯，Sn}，则S满足：
1.完整性t∈S，vSi∈S有t∈Si。
2.不可相交性Pt∈Si，ôvSj有∈Sj，i≠j。
3.重构型存在函数g，使得R=g（S1，S2，⋯，Sn）[2]。
（三）数据分片方法
1.独立分片。Ri=Π（U）（σ（A）（
U为属性表；A为条件集合；R为关系名；U={U1，U2，⋯，Un}；A ={A1andA2and ⋯andAn}。
2.关联分片。Ri=Π（U）（σ（A）（））。
二、数据分配
（一）数据分配目的
通过一定的冗余片断在各结点上的分布，提高系统的可靠性，缩短局部应用的响应时间，尽可能地提高数据的安全性，减少系统的数据通信代价。
（二）数据分配准则
1.处理局部性。数据分配时应尽量提高数据的局部性，使应用在本结点或相邻的节点处理，以尽可能的减少因为对其他节点数据访问而产生的通信代价。
2.数据可用性和可靠性。尽量提高数据只读应用的可靠性，减少因数据检索和更新不同步造成的“脏数据”或“过时数据”。尽可能提高系统的可用性，使系统的管理和存储代价降低。
3.工作负荷分布均匀性。使各结点的负载（各结点所担负的全局应用和局部应用的规模）均匀化，尽量提高系统的并行处理能力，但这有可能降低处理的局部性，增加系统的通信开销。
一般情况下，上述的3个准则不可能同时满足，应该根据具体的客户需求和系统的主要目标，以一个为主要，其他的可以作为约束条件[3]。
（三）数据分配类型
1.集中式数据有划分。但是划分后的逻辑片断依然完全集中在一个结点，即有分片无分配，如同集中式数据库。
2.划分式。数据按应用需求和来源，分布在各个结点上，彼此之间没有重复数据。
3.全重复式。每个结点都有一个全部数据的副本，可以完全做到数据检索的局部访问，但更新代价太大。
4.部分重复式。分片后的逻辑片断按用户需求和应用需要分配，需要共享的片断通过数据复制产生副本放置到不同的结点，私有的片断只放置需要的结点[4]
表1中给出了不同的数据分配类型的比较
（四）数据分配方法
从用户需求和应用需要考虑，数据分配必须尽可能地强调局部自治性，即必须尽可能地减少远程的检索操作，以降低网络通信代价。
1.无副本分配。假设只考虑检索更新的代价，可以选择访问最频繁的结点作为逻辑片断的存放地，一般可对各种分配方案进行比较，以客户需求和应用需要为主要目标，选取最适宜的方案。但是这种情况忽略了给定结点存放的逻辑片断或者关系之间存在一定的关联，一种目标的达成有可能造成另外的开销剧增。
2.多副本分配。副本可以提高检索的局部性，但是却又增加了更新的开销。多副本分配的一般原则是计算副本添加到给定结点时，收益与开销之差，如大于零则放入，小于零则另选结点。
总之，由于客户需求和用户需要所导致的优化目标的不同，数据分配的方法也不同，但大体思想和上文所述类似[5，6]。
三、数据分布透明性
在四层模式中，全局概念层是分布式数据库增加的部分，其余则是集中式数据库原有的部分。
由上面的DDBS 的模式结构图4个映像可以看出，分布透明性包括分片透明性，位置透明性，局部数据模型透明性[5]。
（一）分片透明性
分片透明性是分布透明性的最高层次。其指的是用户或应用程序不用去考虑关系是如何分片以及具体的分片情况，就可以对全局关系进行操作。当系统由于用户需求或其他原因而使分片模式发生了改变，此时由于全局概念模式分片模式的映像（映像2），全局概念模式不变，这样应用程序就不需要改写了，从而增强系统的可用性，方便应用程序的开发。
（二）位置透明性
位置透明性处于分片透明性的下一层次，也可以称为分配透明性，指的是用户或者应用程序不用去考虑逻辑片断存储在哪个具体的结点，当存储结点发生改变时，由于分片模式3/分配模式的映像（映像3） ，不需要考虑应用程序中添加查找逻辑片断的程序段，这样就减少了程序的规模和复杂性，以利于应用。
（三）局部数据模型透明性
局部数据模型透明性指的是用户或者应用程序不需要了解局部数据库使用的是何种数据模型，不同数据模型的转换和数据库语言的转换由映像4完成，这就保证了分布式异构数据库系统的数据查询及事务处理的有效完成[6]。
由上面分布式数据库系统模式结构图的4 层模式，对应的在分布式数据库系统设计中有4级透明，具体评价如表2 ：
从表2可以看出，透明性越高越有利于应用程序的开发，因为在编程的时候如果不考虑程序所调用的数据的来源与位置，做到“随需所用”这样会极大的缩小程序的规模，提高程序的可用性；但与此同时，这样会使系统负担大大增加，数据的查询和提取将耗费系统绝大部分资源，使得系统的效率大为降低，因此数据的透明性必须适宜，在进行数据分片与分布设计时与执行效率反复权衡，求得平衡点[7]。
四、分片与分配关系
从分布式数据库模式结构图可以看出，在分布式数据库的设计中分片与分配模式的设计是其中间环节，一个较优的、基本符合用户需求和应用程序需要的分片与分配设计可以极大地提高系统的可靠性和可用性。对一个关系或文件进行划分，不仅分布式数据库有这种问题，在集中式数据库中有时为了提高数据库的性能也会把一个关系进行独立分片。在分布式数据库设计中，分片设计的目的就是为了分配设计，就是为了让数据访问具有较优的局部性。数据如何分片，如何分配，必须对各种不同收益开销比的方案进行权衡比较，最后根据客户需要和应用程序的需求确定最终的较优方案。数据分片与数据分配虽然是两个不同的概念，但是两者紧密相连，不能截然孤立，没有初步的分片设计就无法进行分配设计，不经过各种分配方案的比较，也就无法确定分配的方案。
一般情况下，分片与分配设计之间采用启发式的方法，首先对应用进行分析评估，提出初步的可行的有利的分片方案，然后根据用户或应用设定的目标再比较分配设计方案的收益开销比，最后确定分片与分配设计方案。如果初步的分配设计方案不可取，可调整分片设计方案，直到达到较优为止。
五、数据分片与分配产生的问题
分布式数据库的分片与分配使数据可以更好地进行局部应用和全局应用，但是也产生了如何保持分布一致性和多副本一致性，以及全局查询处理，分布事务管理的问题。
（一）保持多副本一致性
保持多副本一致性即如何解决读写矛盾问题。分布式数据库的数据分配通过多副本来实现，这在增强了数据访问局部性的同时也造成了在数据更新时为了使不同结点的多个副本内容保持一致，就必须增加开销，因而造成系统效率下降。
（二）保持分布一致性
数据更新后，关系的属性值发生变化，独立分片和关联分片产生的逻辑片断可能出现数据的重新分布。
（三）全局查询处理
在全局查询中涉及全局关系，如果系统提供全透明，那么关系是否分片，关系或逻辑片断在哪个结点，对用户是透明的，即全局关系转化为逻辑片断，选择副本，全局查询转化为自查询都由分布式数据库管理系统来完成。
（四）分布事务管理
数据是分布在不同的结点，处理数据的事务也是分布的。这就涉及到并发控制和恢复技术。
六、结束语
分布式数据库系统符合当今信息系统应用的要求，符合当今企业组织的管理思想和管理方式。但由于分布式数据库系统并不是网络技术与集中式数据库系统的简单结合，他的实现有一定难度，经过近20年的努力，分布式数据库管理系统（DDBMS）的大部分基本问题已得到解决，但迄今为止尚没有一个在市场上被人们完全接受的、完全的DDBMS 产品[8]。分片与分配直接关系到数据的应用，设计建立分布式数据库的重要环节是处理好分片与分配设计，因此必须加强对相关领域的商用化设计的研究与实践。
参考文献：
[1]郑振楣,于戈,郭敏.分布式数据库[M].北京:科学出版社,1998
[2][美]塞里.分布式数据库原理和系统[M].关英春,译.北京:中国水利电力出版社,1989
[3]刘广钟,刘方鑫,施小龙.分布式数据库系统中数据分布模型的研究与建立[J].小型微型计算系统,2001,22(1):710
[4]赵葆华,王于同.一种分布式查询处理的数据划分策略[J].杭州电子工业学院学报,1999,19(2)
[5]陈楠.分布式数据库系统数据分布策略分析[J].计算机时代,1998,10
[6]肖凌,刘继红.分布式数据库系统的研究与应用[J].计算机工程,2001,27(1)
[7]周龙骧.分布式数据库管理系统实现技术[M].北京:科学出版社,1999
分布式数据采集 篇4
关键词：分布式数据库,数据复制,数据分片
通常，分布式数据库系统需要维护数据库的多个副本，保持数据库多个副本间的数据一致性是分布式数据库系统维护的重点。数据复制能够将数据副本建立在不同的节点上，是重要的分布式数据库应用技术，能够避免因为某一个节点失效而导致分布式数据库崩溃的情况出现。在不同的数据副本上操作不同节点上的事务，进行单副本串行是保持数据库中不同数据副本间的一致性的重要方法。利用SQL Server 2000中的数据复制功能，可以把主要精力放在本地副本更新上，由分布式数据库系统完成其余副本的更新。
1 数据复制概述
数据复制能够将数据库中的数据备份到互联网、广域网或是局域网连接的服务器、站点的数据库当中，是强大的、重要的分布式数据库应用技术。数据复制能够保证各个副本之间数据的一致性，保持数据的同步。数据复制具有提高分布式数据库系统的性能，提高数据可用性，提高数据查询的速度等优点。通常，分布式数据库中，以数据更新传播的不同方式为依据，将数据复制分为异步复制和同步复制两大类。数据同步复制是事务执行的内容之一，其将每一个更新操作同时传送至其他副本的另外节点之上，并同时提交全部副本的更新。数据异步复制不同于数据同步复制，其将所有更新纳入到一个事务中，然后传送至副本的另外节点，使通信量降低，并且减少事务回滚而导致的代价。数据复制能够将已有中心数据库中的信息备份到各级拥有信息需求的不同数据库当中，也能够把各级分布数据库中的信息备份到中心数据库当中，从而有利于进行全局联机的决策支持分析与事务处理。
2 数据复制在SQL Server 2000中的应用
在维护同一个数据库多个副本间的一致性方面，SQL Server 2000提供了较为完备的复制功能。SQL Server 2000中数据复制的相关主体是发布者、分发者和订阅者。在SQL Server 2000中，用户能够利用数据库中已有的数据。用户处理数据时，即使断开了连接也能够进行数据副本处理。只要在重新连接后，用户将更改的内容传送至数据库当中就可以了。这样充分确保了各个分布数据间的独立性。SQL Server 2000中主要有事务复制、快照复制与合并复制三种类型的数据复制模式。首先，事务复制模式。在订阅服务器上进行数据初始快照运行，如果在发布服务器上进行数据更改，就使用事物日志对个别事务进行捕获，然后将个别事务传送至订阅服务器。其次，快照复制。直接分发数据位于某个时刻的状态，不对数据更新进行监视。把发布器中的数据复制到订阅服务器中进行数据复制。快照复制适合更新次数较少的大量数据的数据复制。最后，合并复制。在订阅服务器接收数据的过程中，不论订阅和发布服务器之间是否进行了有效的连接，数据更新都可以照常进行。在订阅服务器和发布服务器连接时，合并复制能够合并所有的更新。
这些复制类型都能够保证各个层次数据一致性的需求，为事务的ACDI属性提供了相应的功能。事务复制、快照复制与合并复制所具有的特点和功能都能够满足独立性与一致性的数据复制的要求。其中，事务数据复制是常用的便捷的数据复制方法。事务数据复制能够将数据库中的数据传送至其他的数据库，能够记录DELETE、UPDATE、INSERT等不同类型的数据操作。在维持数据复制的一致性方面，事务复制采用异步复制方式，将数据分发至订阅服务器，并进行增量修改。事务复制在SQL Server 2000中主要由三部分构成：日志读取代理、分发代理和快照代理。快照代理能够形成数据文件和描述文件，与新的订阅数据库保持同步。日志阅读器代理能够在分布数据库中插入事务日志中的事务。分发代理能够将复制事务从数据库中传送至订阅者。快照代理、日志读取代理和分发代理相互协调，保证各个副本的传输数据保持同步。
3 基于XLM的中间件模型及数据分片
3.1 基于XLM的中间件模型
基于XLM的中间件模型的主要功能模块包括：全局DOM树、中心处理模块、局部DOM树以及包装器。首先，全局DOM树。W3C组织推荐的DOM是一组用于合法HTML文档与XML文档的编程接口。全局DOM树允许脚本与程序进行动态访问、结构更新、文档内容更新和类型更新。其次，中心处理模块。中心处理模块是中间件模型的核心模块，它按照相关的数据分片策略，参照XML或DTD提供的路径模式信息，处理全局DOM树上的路径实例，在各个站点上分布每种模式的路径实例。第三，局部DOM树。在数据分片完成之后，在各个站点上利用DTD模式信息重新构建和全局DOM结构相同的局部DOM树。局部DOM树是全局DOM树的子集，如果把所有站点上的局部DOM树合并在一起，就能够得到全局DOM树。最后，包装器。通常，数据源均具有自己的包装器，在获得查询请求之后，就会从数据源中进行数据检索，找出所需的数据，并且将数据转化成XML形式。此外，数据源中的包装器能够进行数据源和DOM树之间的转换操作。从纵向来看，包装器、局部DOM树与其所对应的数据源共同形成了一个处理单元;从横向来看，包装器、局部DOM树、核心出来模块与全局DOM树共同组成了XML的中间件层。
3.2 数据分片
数据分片是分布式数据库的重要技术之一。传统的数据分片技术有Hybrid-Range分片策略、Range分片策略、Round-Robin分片策略。这些分配策略适用于有着固定模式的数据库，而不适用于无固定模式的、半结构化的XML文档。HRPS是一维分片方法，其划分的根据是关系中的某一个属性值，划分好的每个子空间内的数据元组数量相同，数据元组的值域互不相交。查询响应时间极小化是HRPS的重要目标，在查询数据时应当注意网络通信、磁盘I/O、CPU这些基本资源的占用。HRPS在XLM中间件基础上的扩展方法——EHRPS。EHRPS划分全局DOM树遵循以下原则：子空间包含路径实例数量大致相同的局部DOM树;子空间均只包含路径实例不重复的集合;根据DTD提供的路径模式信息，在不同站点上进行路径实例分配。由于中间件是统一的数据模型，在DOM树查询的相应时间当中会发生中间件系统资源消耗。DOM树的合并和XML文档生成DOM树的时间影响着DOM查询的响应时间。
4 结束语
综上所述，数据复制与数据分布在分布式数据库中有着广泛的应用。分布式数据库中，根据数据更新传播的方式将数据复制分为异步复制、同步复制两大类。在SQL Server 2000中的数据复制的主要有事务复制、快照复制与合并复制三种类型。事务型数据复制能够从一个数据库向其他的数据库分发数据，是一种较为理想的数据复制方法。在SQL Server 2000中事务复制主要由日志读取代理、分发代理和快照代理三个有机环节组成。全局DOM树、中心处理模块、局部DOM树和包装器是基于XLM的中间件模型的主要功能模块。Hybrid-Range分片策略等传统的数据分片技术适用于有着固定模式的数据库。EHRPS是HRPS基于XLM中间件的扩展方法，适用于无固定模式的、半结构化的文档，能够降低查询难度，提高查询的准确度。
参考文献
[1]朱丽丽.分布式数据库在高校的应用策略[J].科技信息 (科学教研) , 2008 (17) .
[2]涂承胜.基于VB的数据库的图像处理技术[J].计算机工程与设计, 2003 (6) .
[3]王祥武.数据复制技术比较[J].信息系统工程, 2010 (3) .
[4]勒敏, 刘建辉.分布式数据库系统数据一致性维护方法[J].科技广场, 2008 (3) .
[5]张建飞.数据复制系统的研究[J].才智, 2011 (11) .
[6]刘荣.分布式数据库系统数据复制技术的研究[J].电脑知识与技术, 2009 (7) .
[7]徐丽萍, 袁刚, 卢炎生.DRMDP:一个基于动态优先级的反射式数据复制中间件[J].计算机工程与科学, 2009 (2) .
分布式事务处理数据库教程 篇5
分布式事务处理
张健姿 01-6-22 下午 04:48:27
美 国Sybase 公 司 于 今 年 七 月 发 布 了PowerBuilder 6.0 的Beta 版， 正 式 的 版 本也 将 于 不 久 的 将 来 推 出， 其 中 对 分 布 式 事 务 处 理 的 支持 是 新 版 本 中 增 强 得 最 多 的 功 能， 早 在1995 年，PowerSoft 公司 就 提 出 了 在“ 分 布 式 事 务” 方 面 的 发 展 战 略， 并 在1996 年 发 布 的PowerBuilder 5.0 中 支 持 了 分 布 式 事 务 处 理 的 功 能，笔 者 在 以 前 的 讲 座 中 也 曾 经 讨 论 过 有 关 如 何 创 建 分布 式PowerBuilder 应 用 的 问 题， 但 是 得 到 读 者 反 馈 意 见 却 很少。 以 往， 一 个 使 用PowerBuilder 开 发 客 户/ 服 务 器 应 用 软 件的 程 序 员 是 较 少 会 想 到 使 用 分 布 式 事 务 来 分 割 应 用的， 因 此 一 般 的 用 户 对 分 布 式 事 务 的 概 念 和 意 义 也 不甚 了 解， 这 里 我 们 来 进 一 步 讨 论 一 下 分 布 式 事 务 处 理及 其 应 用。 三 级 体 系 结 构 首 先我 们 介 绍 三 级 体 系 结 构 这 一 概 念。 所 谓 级 是 指 一 种 功能 划 分， 我 们 以 往 所 开 发 的 数 据 库 应 用 软 件 一 般 是 基于 客 户/ 服 务 器 结 构 的， 我 们 称 之 为 两 级 体 系 结 构。 也就 是 说 整 个 系 统 可 以 分 成 两 个 功 能 块， 第 一 级 包 括 了软 件 的 应 用 层 和 表 现 层， 驻 留 于 客 户 端。 我 们 使 用PowerBuilder 开 发 出 的 应 用 主 要 用 于 第 一 级， 运 行 于 客 户 端。 第 二级 包 含 数 据 库 和 服 务 器 的 组 件。 一 个 基 于SQL 的 数 据 库管 理 系 统 一 般 安 装 在 服 务 器 端， 应 用 软 件 在 服 务 器 端进 行 的 操 作 主 要 是 数 据 存 储 和 检 索。 在 两 级 模 式 中 会有 一 些 应 用 逻 辑 以 存 储 过 程 和 触 发 器 的 形 式 存 储 在服 务 器 端， 以 优 化 服 务 器 的 性 能， 但 绝 大 多 数 的 应 用逻 辑 是 放 在 客 户 端 的。 三 级模 式 是 将 系 统 分 为 有 三 个 不 同 的“ 级”： 表 现 级， 商业 逻 辑 级 和 数 据 访 问 级。 表 现 级 是 处 理 用 户 界 面 的 功能； 数 据 访 问 级 是 数 据 源， 在 通 常 状 况 下 指 数 据 库；商 业 逻 辑 级 是 新 增 加 的 一 级， 指 程 序 中 作 出 智 能 决 策的 那 一 部 分 功 能。 在 早 期 的 应 用 中， 这 一 部 分 的 功 能并 不 十 分 复 杂， 一 般 将 其 放 在 表 现 级 即 可， 另 有 少 量以 存 储 过 程 或 触 发 器 的 形 式 放 在 数 据 访 问 一 级， 而 随着 软 件 工 程 的 发 展， 软 件 的 日 益 复 杂， 软 件 中 功 能 增加 最 多 的 就 是 在 这 一 级。 一 个MIS 系 统 的 功 能 由 早 先 的对 某 一 个 表 的 简 单 查 询， 发 展 到 涉 及 多 个 表 的 分 类 统计 求 和， 根 据 复 杂 的 公 式 分 析 计 算， 进 行 决 策 支 持等， 如 将 这 些 增 强 的 功 能 仍 全 部 放 置 在 表 现 级， 会 使得 客 户 机 越 来 越 不 堪 重 负， 因 此 就 有 人 提 出 在 系 统 中将 商 业 逻 辑 分 离 出 来， 单 独 形 成 了 一 级， 这 就 形 成 了三 级 结 构。 随 着 三 级 结 构 的 进 一 步 发 展， 一 般 总 是 把运 行 在 商 业 逻 辑 级 的 软 件 编 写 成 为 了 一 个 为 客 户 机所 调 用， 能 够 完 成 一 定 的 逻 辑 功 能 的 专 用 软 件， 同 数据 库 服 务 器 相 区 别， 我 们 称 之 为 应 用 服 务 器。 在 一 个网 络 中， 可 以 有 着 多 个 不 同 功 能 的 应 用 服 务 器， 为 客户 机 或 其 它 的 应 用 服 务 器 提 供 专 业 服 务， 这 样， 三 级结 构 就 发 展 成 为 了N 级， 这 就 是 所 谓 的 分 布 式 计 算 方式。 分 布式 计 算 的 优 势： 采 用 分 布 式 计 算 有 着 多方 面 的 技 术 优 势， 包 括： 逻 辑封 装 性： 这 是 分 布 式 模 式 中 最 具 诱 惑 力 的 特 征， 这 种模 式 的 根 基 在 于 将 以 往 全 部 由 客 户 机 完 成 的 事 务 逻辑 中 的 一 部 分 从 客 户 端 分 开。 当 使 公 司 需 要 动 态 改 变一 个 应 用 软 件 的 商 业 逻 辑 规 则 时， 只 要 改 变 一 个 应 用服 务 器 的 程 序 即 可， 而 不 需 要 更 改 客 户 端 用 户 界 面，这 样 就 无 需 中 断 用 户， 为 最 终 用 户 重 新 发 放 新 的 界 面软 件 或 亲 自 上 门 为 其 安 装 调 试 并 重 新 培 训 用 户， 提 高了 工 作 效 率。 这 种 多 级 模 式 对 于 需 经 常、 快 速 改 变 应用 程 序 的 行 业 很 有 帮 助。 瘦 客 户 机： 这 种 类 型 的 应 用在 运 行 时 最 显 著 的 特 点 就 是 减 少 甚 至 消 除 了 传 统 的两 级 体 系 结 构 中， 以 客 户 机 为 中 心 或 称 为“ 肥 客 户” 的 模 式， 减 轻 了 客 户 机 的 功 能 负 担， 使 其 消 肿 成 为了“ 瘦 客 户”，
分布式数据采集 篇6
摘 要：为了提高电力行业网络各类监控设备告警信息和告警事件的处理速度，本文设计了由中心控制节点、计算节点、配置服务节点等构成的海量数据处理平台。通过中心控制节点实现任务的分解与控制，计算节点实现任务计算。使用基于文件格式的方式进行数据采集，利用Map/Reduce的模型进行数据汇总。采用本平台能够实现对海量告警信息的捕获和处理，保证告警分析的效率。
关键词：海量告警；分布式；数据处理
中图分类号： TP311 文献标识码： A 文章编号： 1673-1069（2016）35-175-2
0 引言
随着当今世界互联网的迅猛发展，电力行业也开始运用现代信息技术对电网的运行状况进行监控，电力网络各类监控设备每天都会产生大量的告警信息和告警事件，这些信息的采集、清洗、分析以及汇总所包含数据的计算与处理复杂度非常高，计算量非常大，所以会对计算机硬件性能有很高的要求。分布式计算技术能够将一些本身适合分解成大量更小计算片段的复杂问题进行分解，然后再将这些更小的计算片段分配到多个计算资源上，利用多个计算资源分别对这些小的计算片段进行分布式求解，这样不但有效的利用了各个闲置的计算资源，也加快了计算执行的效率，充分发挥了计算的高并行性。为此我们可以将分布式计算技术引入到电力行业告警信息和告警事件的处理中，提高信息的处理速度，为电力系统的运维监管提高效率。
本文是通过对当前已有的成熟的分布式计算系统如google的map/reduce架构以及hadoopDB等系统的研究调查，借鉴了map/reduce的基本思想，针对电力行业运维监控中的各种海量告警数据处理的业务，提出的分布式海量数据处理系统平台。
1 总体结构设计
海量分布式处理平台完成数据采集、任务分发、任务处理以及任务汇总等多项内容。平台主要包括了中心控制节点、计算节点、配置服务节点、拆分节点、日志节点、数据采集传输部件以及电信网络单元这七大部分。各部分之间互相通信，互相配合完成任务的拆分，发送及执行。其中Master为中心控制节点，CU为计算节点，CS为配置服务节点，TS为拆分节点，LS为日志节点，MED为数据采集传输部件，NES为电信网络单元，能独立完成一定的传输功能。
2 节点设计
2.1 中心控制节点
在整个系统中，中心控制节点是核心，负责系统中所有资源的调度，并根据计算节点的状态分配系统中的任务，进行相关的数据分析和计算，协调系统的整体运行。同时，为了防止主控节点意外挂机导致的数据丢失的现象，采用双机热备的机制来作为主控节点的备份。
Master中包含的主要子模块有通信、任务调度、任务管理、定时器和Corba、锁管理等模块。
①通信子模块：主要负责的是Master和其他子模块之间的通信，负责分发和接收模块间的消息报文；②任务管理子模块：主要负责对系统中处理任务的管理，包括最初的任务创建、任务运行过程中的状态保持、大任务的分解、所有任务的维护以及任务执行等功能。③任务调度子模块：主要完成任务调度的相关工作，包括依据任务的优先级对系统任务进行调度安排，锁进程的管理与维护，维持进程间的通讯等。④定时器模块：主要负责检查系统是否超时，以及处理超时后触发的事件等问题，定时的检测系统的各种状态等。⑤Master-Standby同步模块：主要负责同步Master上的任务到Standby，以减少因为Master出故障后造成的损失。
2.2 分布式计算节点
计算节点负责的是对海量数据进行具体的计算分析以及对数据的具体任务处理，涉及到最初的数据采集、计算完毕后的数据汇总、汇总结束后的数据备份以及最终结果的查询等阶段。计算节点是整个系统中的基础，是任务执行的基本单元，节点在运行的过程中，要分别与中心控制节点、外部模块以及参数配置节点等部分进行消息通讯，在处理这些信息的同事，还要通过任务调度实现对任务的并行处理调度。一个完整的计算节点通常由任务管理模块、通讯模块、数据操作模块以及定时器构成。计算节点中采用多线程技术实现以上的各项功能。
CU的主要作用就是并行高性能化地执行各种小作业，当有小作业需要被执行时，CU的具体执行流程为：①通过负载均衡模块，计算节点CU主动向Master主控节点请求作业，并获去作业的相关任务；②Master向主控进程中通信模块的Master Agent发送分配的新作业，并为其分配新的任务；③主控进程中通信模块的Progress Agent接收到在作业管理调度模块根据申请过来的作业生成对应的XXTask，然后将作业通过长连接的方式发送给工作进程Progress Agent；④作业管理模块受到已接收到新作业的工作进程的调度，生成工作进程相对应的XXTask；⑤新作业生成的Request被工作进程的作业管理模块通过管道放入MiddleServer中间层的请求队列中；⑥Request队列中所有的请求都是通过线程池模块调用自己相应的处理函数aio_process_request（）来处理的，为了保证不同的小作业可以多线程并行地处理，线程池根据服务器的性能设置了线程的数量。⑦具体的作业通过线程池调用DB数据处理模块来执行，比如数据创建，数据查询等等。⑧最终的执行结果是在作业执行完毕后一层层的向上层返回的，数据结果还是被线程池通过管道机制逐层返回给Master
3 数据采集处理
平台的数据采集功能是采集网元数据，然后，根据不同的网元类型和网元号，对不同设备的性能数据以及告警数据，进行数据过滤分析并存入到平台数据库中，为管理人员实现数据的结构化管理提供基础，方便管理人员数据操作、分析以及领导的决策。本文数据采集采用的是一种基于文件格式的采集方式。采集任务的方案是计算节点主动从FTP服务器上取数据，然后将数据采集入库。数据采集流程步骤为：第1步：外部系统Med中间层接收到RNC因产生原始数据，形成数据文件而发来已经准备好的通知， 然后将请求转发到本系统Master控制节点。第2步：任务拆分服务器TS收到Master因采集请求生成的大任务， 在将其拆分多个小任务之后返还给Master，Master将小任务放入任务队列中。第3步：Master接收到计算节点CU主动申请的采集任务，Med将执行该任务的CU信息进行记录。第4步：CU从指定的FTP服务器上下载RNC上传的数据，为了能够使数据以结构化的形式入库，调用解析库对数据进行解析。第5步：CU在采集任务完成后，向控制节点发送任务执行完成报告，在收到任务消息报告之后，Master将从队列中移除任务。
4 数据汇总处理
系统的数据汇总是在对网元采集的数据计算处理后，进行一系列的有条件和逻辑顺序的数据加工和整合。本文采的数据汇总采用的是Map/Reduce的模型，在执行的过程中，采用临时表存储Map任务计算的临时结果，然后再通过Reduce任务，根据临时表中的数据计算汇总。通常情况下，策略数据汇总是具有一定策略的，最常用的汇总策略有时间维度和对象维度两种，可以按照时间（天）或者采集对象（网元）来进行汇总。
Reduce的机制来将汇总任务分解成多个Map和Reduce小任务，以解决汇总任务包含表格查询跨库跨表格的问题，让计算节点进行归并被拆分成四个小任务的Task1。
可以根据Map/Reduce的机制来将汇总任务分解成多个Map和Reduce小任务，以解决汇总任务包含表格查询跨库跨表格的问题，图6中给出了发给计算节点，让计算节点进行归并被拆分成四个小任务的Task1。
数据汇总的具体过程为：①计算节点CU接收到Map小任务，先生成临时表，然后执行。②当Master确定所有Map任务完成以后，再发送reduce任务，CU此时执行Reduce操作，汇总中间临时表中的数据，生成用户需要的最终结果集。
5 结论
本文设计了由中心控制节点、计算节点、配置服务节点等构成的海量数据处理平台。通过中心控制节点实现任务的分解与控制，计算节点实现任务计算。使用基于文件格式的方式对网元进行数据采集，利用Map/Reduce的模型进行数据汇总，实现数据的整合。采用本平台能够实现对海量告警信息的捕获和处理，保证告警分析的效率，为电力系统的运维监管提供数据支撑。
参 考 文 献
[1] 丁兆云，贾焰，周斌.微博数据挖掘研究综述[J].计算机研究与发展，2014，51（4）：691-706.
[2] 黄斌，许舒人，蒲卫.基于MapReduce的数据挖掘平台设计与实现[J].计算机工程与设计，2013，34（2）：495-501.
[3] 朱姣姣，叶猛.多模式匹配及其改进算法在协议识别中的应用[J].电视技术，2012，36（7）：60-6.
分布式数据库数据同步的应用分析 篇7
信息技术的发展促进了信息的交流和共享, 在人们分享数据信息和上网检索资料的过程中, 离不开数据库的支持和辅助。而随着Internet技术的迅速发展和信息共享要求的不断提高, 对于数据库系统的功能和结构等的要求也越来越高, 如今, 数据库系统发展的主要趋势包括了大型化与分散化两个方向, 分布式数据库能够有效地安排处理来自不同地区的相关数据信息, 可以给人们的生活和工作带来很多的便利和好处。在本文中, 将对分布式数据库的含义和特点进行介绍和分析, 并对分布式数据库数据同步技术进行简单介绍, 最后以计生系统为例来分析如何应用分布式数据库数据同步技术。
一、分布式数据库的简单介绍
(一) 分布式数据库的含义
单从分布式数据库的名称来看, 人们常常会觉得分布式数据库中的数据主要是呈分散状态的, 其中的数据规律性并不强, 实际上分布式数据库内部的数据在分散状态的表象下是非常严谨的逻辑思考和安排, 具有比较强的内在规律性。
具体来说, 分布式数据库是一种把不同地理位置上的数据通过网络技术整合连接起来的数据库系统, 即分布式数据库的不同站点上的数据代表着不同地区的数据, 由于各个地区地理位置的不同, 在分布式数据库中的数据呈现出一定的分散性, 为了方便使用者的查询和检阅, 在整合分布式数据库时会按照相应的逻辑和规律进行, 使各个不同站点上的数据形成一个有机的整体, 最后利用网络技术和计算机技术把经过安排的不同地理位置的数据连接起来形成一个数据系统。
在理解分布式数据库的含义时应该注意两个方面的内容:一方面, 分布式数据库中的站点是指按照地理因素把数据联系起来的逻辑单位, 站点也可以称为结点, 分布式数据库中的站点可以是分散在不同地理位置的国家, 也可以是不同的城市, 甚至也可以是一个建筑物内部的不同位置, 人们可以根据具体的需要来安排和选择站点所代表的地域, 但是无论怎样选择站点所代表地域, 分布式数据库中的数据都必须是经过逻辑思考而进行安排和整合的;另一方面, 在一个完整的分布式数据库系统中, 数据信息和计算机网络是两个必不可少的重要因素, 如果没有数据信息只有计算机网络就不可以称之为一个分布式数据库, 如果没有计算机网络而只有数据信息, 就不能满足人们信息共享和信息查阅的需要, 这样的数据库的存在也是没有意义的。
(二) 分布式数据库的特点
分布式数据库的结构组成决定了分布式数据库主要有以下五个特点:一是, 分布式数据库系统中的数据并不是储存在某个地区的一台电脑上, 分布式数据库中的数据可以根据需要储存在不同地区的多台计算机上;二是, 分布式数据库中的数据虽然是分布在不同地区的独立数据, 但是这些数据之间具有内在的相关性;三是, 经过相关人员的整合, 展现在使用者眼前的是一个完整的分布式数据库系统, 在使用者使用分布式数据库时完全不会受到数据异地存储的影响;四是, 分布式数据库系统中的每个站点既具有自身的独立性又是整个分布式数据库系统中不可或缺的一部分, 即分布式数据库中的每个站点既可以满足局部的要求也能够满足整个系统的要求;五是, 分布式数据库中的数据存在一定程度的冗余, 如果能够把这种冗余控制在适当的范围内, 分布式数据库系统的效率和可靠性都会得到大幅度的提升。
(三) 分布式数据库的优势
近些年来, 分布式数据库之所以得到人们高度的关注, 并且应用领域得到了不断的拓宽, 主要是因为分布式数据库自身存在着一些优势, 概括来说分布式数据库的优势主要包括三个方面。第一, 分布式数据库的可靠性很高, 这主要是因为分布式数据库由多个独立的站点有机组合而成, 信息和数据的存储不局限于某一台计算机上, 当某个节点或者某一台存储数据的计算机发生故障时, 其余的站点和存储数据的计算机并不会因此而受到影响, 某个站点或者存储数据的计算机出现问题只会对局部的使用产生影响, 而不会使整个分布式数据库系统面临瘫痪的风险, 这就增加了分布式数据库的可靠性和稳定性, 而且分布式数据库中存在的冗余对于提高分布式数据库的可靠性也是有帮助的。第二, 分布式数据库中结点的分地区分布能够在帮助用户减少通信费用的同时为用户提供更多的便利, 因为不同地区的用户对于数据和信息的需求都是不尽相同的, 在局部结点上安排局部用户经常访问的内容, 不仅可以减少用户的通信费用, 也增加了用户检索数据的便捷程度。第三, 分布式数据库系统中包含多个结点, 可以根据用户的需求来调节结点的内容和数量, 使分布式数据库具有很强的灵活性。
二、分布式数据库数据同步技术的简单介绍
(一) 分布式数据库数据同步技术的含义
分布式数据库数据同步技术是一种能够让分布式数据库各个结点数据同时更新的技术。分布式数据库中各个站点数据和信息能否同步更新直接影响用户使用的便捷性, 在分布式数据库中由于各个结点上存储着不同地区的数据, 而且不同地区的数据也存储在不同的计算机上, 这就使分布式数据库系统中个地区数据的同步更新成为了一个集重点和难点于一身的问题。
分布式数据库数据同步技术通过同步更新不同结点的数据, 不仅让用户可以在本地数据服务器上查询到最新的数据和信息, 而且也增加了分布式数据库的透明度和公信力。分布式数据库数据同步技术的工作原理是:把分布式数据库中的数据分为源数据和副本, 把源数据存储在需要经常进行操作和更新的站点上, 在更新数据或者修改数据时, 只需对源数据进行更新或者修改即可, 对于副本来说只能进行复制操作。
(二) 分布式数据库数据同步技术的分类
分布式数据库数据同步技术主要包括多副本间严格一致和多副本间近似一致等方式。
首先, 多副本间严格一致的方案是通过两阶段提交协议或者三阶段提交协议来实现的, 在两阶段提交协议中, 分布式数据库中各个结点数据的更新和修改是完全同步的, 这种方法的优点是能够保证各个结点的数据的更新和修改实现完全的同步, 但是这种方法的缺点是在进行数据更新和修改时, 分布式数据库中所有的服务器都必须同时处于联机状态, 如果某一个站点在联机时出现问题就会使其他所有结点的更新数据不能提交, 导致分布式数据库更新速度慢和效率低等问题出现, 除此之外多副本间严格一致的方案需要非常大的工作量, 在进行各结点数据的更新和修改时, 需要对所有的副本都要进行改动。
其次, 与多副本间严格一致的方案不同的是多副本间近似一致的方案, 在采用多副本间近似一致的方法时, 每个副本的修改并不是完全同步的, 在实际操作和应用中, 除了一些临界数据的副本其他的大量非临界性副本只要可以保持模糊的一致性就能够维持系统的运行, 多副本间近似一致方案与多副本间严格一致方案相比具有一定的优势, 一方面利用多副本间近似一致的方法进行数据的更新和修改时可以避免因各个站点同时提交更新内容而导致的网络阻塞和瘫痪, 虽然一些副本的修改时间并不是完全同步的, 但是在整个系统完成更新之后, 各个站点的副本能够保持一致, 另一方面, 多副本间近似一致方案下分布式数据库各个结点的自治性有所提升。
三、以武汉市计生系统为例分析如何应用分布式数据库数据同步技术
(一) 分析武汉市计生系统网络结构
在构建分布式数据库, 并应用数据同步技术实现分布式数据库数据同步技术之前, 首先要分析的就是具体数据库系统所面临的具体社会网络环境, 武汉市计生系统是以市级计生系统信息中心为核心, 通过网络技术与计生委的其他业务处室和辖区计生委相连, 武汉市计生系统是一个包括三个级别的网络体系, 而且这三个级别的网络结构呈现出树形结构, 这三个级别分别是市级信息中心、区级信息中心、街道信息中心。
首先, 市级信息中心是武汉市计生系统的一级结构, 也是武汉市计生系统的信息中心, 因此在进行建设时需要考虑市级信息中心的访问量和数据特点, 市级信息中心存储的数据量和访问量一般情况下都比较大, 因此市级信息中心的网络主要由数据库服务器、DNS服务器、WEB服务器、EMAIL服务器以及办公自动化服务器等组成, 为了保证市级信息中心能够在较大的访问量下还能够安全稳定的运行, 市级网络中心还设置了后备数据库和磁盘阵列等, 而且通过TCP/IP协议以及ISDN等方式, 市级信息中心还能够与湖北省计生信息网络和Internet直接相连。
其次, 区级信息中心是武汉市计生系统的二级机构, 区级信息中心主要可以实现各区之间的信息交换功能, 由于各区的计生数据存储量比市级信息中心的数据存储量要小, 而且访问量也不大, 区级信息中心的网络规模并不大, 而且相关配置也没有市级信息中心网络的配置高, 只是在本区范围内形成一个小型的局域网络, 区级信息中心网络体系在与市级信息中心网络相连时可以根据每个区规模的大小选择不同的网络连接方式, 如果一个区的面积较大人口较多则可以选择利用光纤专线的方式与武汉市市级计生系统信息中心的网络相连, 如果一个区的面积较小而且人口不多则可以选择利用ADSL宽带的方式与武汉市市级信息中心网络相连。
再次, 作为武汉市计生网络系统的三级结构, 街道信息中心主要负责街道范围内的信息存储和交换, 因为街道信息网络信息中心的访问量和数据存储数量都比较小, 因此街道信息中心通常情况下采用单台微机的方式, 利用windows操作系统完成相关的工作, 由于街道信息中心的数据存储量和访问量并不是很大, 则可以选择较为经济实惠的方式将街道信息中心与相应的区信息中心进行连接, 如通过PSTN拨号的方式, 这种方式既可以满足需要也可以降低成本, 是一种非常实用的网络连接方式。通过上述的分析可以发现武汉市计生系统中由于PSTN与公共网络等连接方式的存在, 武汉市计生系统的可靠性并不是很强, 需要通过分布式数据库数据同步技术来进行完善。
(二) 武汉市计生系统对数据同步的需求
武汉市计生系统进行数据的统计和分析的主要对象包括数据类别、数据量、数据流动方向等, 而需要进行数据同步处理的数据主要包括了武汉市流动人口信息、武汉市计生系统统计报表、相应的代码数据、武汉市市区内流动人口的相关数据等。其中流动人口信息是进行数据同步时必须及时更新的数据, 流动人口信息的收集流程主要是街道计生办对街道范围内的人口流动信息进行收集和统计并上传至区计生办, 区计生办把街道计生办上传的信息及自身收集的信息上传至市计生办, 最后在武汉市计生系统中会呈现出街道、各区以及市信息中心收集和整理的所有信息, 在这个过程中无论是街道计生办还是区计生办在向上一级传输数据和信息时应该把数据制成统计报表的形式。代码是一种可以降低信息处理工作量的特殊数据, 在数据处理过程中可以用代码来代替的可以是性别、职业等, 如可以把男生的代码设置为1, 女生的代码设置为2。武汉市市区内的人口流动数量信息也是非常重要的信息, 需要利用数据同步技术进行数据同步的设置。
(三) 应用分布式数据库数据同步技术实现武汉市计生系统的数据同步
根据上述的分析可知武汉市计生系统主要分为街道、区、市等三个级别, 这三个级别的运行单位分别是街道计生办, 区计生办以及市计生办, 在每个级别的信息系统中都需要统计的信息是流出人口情况与流入人口情况, 结合武汉市计生系统的具体情况, 在对武汉市计生系统进行数据同步时可以实现的数据同步主要包括两个内容:街道级别数据与各区级别数据的同步, 各区级别数据与市级别数据的同步, 为了实现这些数据的同步可以采用的方法主要有数据管道以及XML等方法。
第一, 可以利用数据管道的方式来实现街道级别数据与各区级别数据的同步, 数据管道是一种能够有效转移和传输数据的工具, 这种方式的主要流程是从服务器中下载相关的数据, 或者是把本机中需要转移的数据直接上传到服务器即可, 这种方式简单易行, 而且能够安全高效地传输数据, 对硬件的要求也不是非常高。
第二, 在进行区级别与市级别之间的数据传输时, 数据量是非常大的, 利用数据管道传输大量数据时很容易造成网络的阻塞和瘫痪, 因此为了实现区级别与市级别之间的数据同步, 应该采用XML的方式, 在利用XML方式时需要相关单位配置WEB服务器, 同时也应该配置质量较高的硬件设备, 而武汉市的区级计生机构和市级计生机构拥有这些设备, 因此在此可以利用XML的方式来实现区级别与市级别之间的数据同步。
结语
通过本文的研究, 可以看到分布式数据库在实际生活中所发挥的重要作用。但对于实际的使用者来说, 要想能够很好地利用分布式数据库数据同步技术, 不仅应该了解分布式数据库的含义与特点, 还应该了解分布式数据库同步技术的工作原理和流程, 在利用分布式数据库数据同步技术时应该先分析某个分布式数据库的具体结构和内在特点, 找到需要进行数据同步处理的部分, 最终选择出最佳的方式实现某个分布式数据库的数据同步。
参考文献
[1]康瑞华, 尹帆, 薛胜军等.基于B/S模式和分布式数据库技术的物流信息系统[J].武汉理工大学学报 (交通科学与工程版) , 2003, 27 (6) :860-863.
[2]周自斌, 朱方洲.分布式数据库的数据同步技术研究和应用[J].电脑学习, 2004, (2) :22-23.
[3]侯素新, 陈焜.分布式数据库技术在图书资料管理系统中的应用[J].江汉大学学报 (自然科学版) , 2005, 33 (3) :55-58.
[4]戴婉荣.基于分布式数据库的数据同步机制的研究与应用[D].武汉理工大学, 2010.
[5]苏汉辉.基于分布式数据库的通信工程设计项目管理系统的设计与实现[D].华南理工大学, 2013.
[6]田淼.分布式异构数据库同步中间件的设计与实现[D].西安电子科技大学, 2012.
分布式数据采集 篇8
随着特高压电网的发展,“国、网、省、地、县”5级调度之间的联系越来越紧密,一体化调度运行的要求越来越高[1]。其中地县一体化主站系统是:地级调度(地调)自动化主站系统与其所辖县级调度(县调)自动化主站系统通过网络延伸互联,使之逻辑上成为一套调度自动化系统,从而实现地调、县调的数据资源、技术资源、设备资源共享的调度自动化主站系统[2]。
常见地县一体化主站的建设模式有2种。一是远程工作站模式,撤销了县调系统,县调所辖厂站直接接入地调系统。各个县调作为地级电网调度自动化系统的远程工作站,在光通信设备的支持下,远程接收数据,同时具有操作系统对象的功能[3]。但是,若县调系统与地调系统的网络通信断开,县调系统将会丧失全部功能,其相应的生产调度任务只能由地调人员暂时承担[2]。二是分布式拼接模式,地调、县调系统分别建设,独立运行,然后通过拼接方式实现图形、模型共享,通过转发方式实现数据实时共享。但是,由于拼接技术较复杂,系统维护较难,且各系统多次输入、模型不统一导致数据信息易错。
针对以上2种建设模式特点,本文提出了地县一体化系统建设的分布式数据采集模式,将系统的数据库和应用服务器部署在地调,模型、图形一次输入并统一管理,数据采集服务器和通道设备分布在地调和各个县调,形成若干个数据采集子系统,子系统所采集的实时数据无需转发即可在全系统内共享。当地调、县调系统间出现系统解列时,还能够保证解列的地调、县调可独立运行,县调仍然可独立完成监控功能。
1 分布式数据采集的原理
分布式数据采集方法将网格技术运用到地县一体化调度自动化系统的数据采集中。网格技术对于网络资源具有巨大整合力,如应用到电力系统中,可为不同调度系统间信息和资源共享带来方便,并可成为广域电网分布式电力系统计算和仿真的支撑平台。将网格技术作为技术支撑平台,以此构建未来互联大电网监控系统——广域分布式能量管理系统(EMS),实现各级电网调度自动化系统和调度员培训仿真(DTS)系统动态形成虚拟的大规模EMS,共享资源和协同分析,保证电网的安全稳定运行和控制。网格技术的引入,对于解决中国电力系统超大规模电网的数据共享和计算分析问题,具有非常重要的意义。利用网格技术可以动态地实现包括计算、数据、存储等在内的资源共享,而无须事先定义和维护需要共享的数据,使目前的信息“需则共享”模式转变为“需则可知”模式,加强电力信息化程度,从而使信息共享的紧密耦合走向松散耦合[4]。
地县一体化调度自动化系统需要接入地调、县调所辖厂站,且每个厂站一般都是多通道配置,将造成系统数据采集任务的异常繁重。因此,根据网格技术原理,将系统统一的数据采集系统分割成若干个数据采集子系统,每个子系统的数据采集任务就不会很重。同时,由于地调和各个县调分布在不同的地理位置上,将这些数据采集子系统布置在地调和各个县调也可以更好地利用原有通道资源。
系统实现分布式数据采集的具体步骤如下。
1)按照需要设置多个数据采集区,分布在地、县各区域范围内。
2)每个数据采集区包括若干数据采集服务器和数据采集通信设备,数据采集服务器负责初始化下属各数据采集通信设备。数据采集服务器运行时互为热备用,保证数据处理的可靠和高效。
3)数据采集服务器运行时首先读入所属的数据采集区信息,初始化本区域的数据采集通信设备,之后再与本区域厂站建立通信链接,而且只处理与这些厂站相关的测点信息和命令。同时,实时判断这些测点、通信和厂站的各种状态,不属于采集区的所有通信设备、通信状态、测点和命令一律不处理。
4)各个数据采集区将采集、处理后的实时数据送往数据采集与监控(SCADA)系统应用,集中处理后存入系统数据库服务器并展示。全系统的任意一个节点上,利用提供的工具都可查询所有数据采集信息,并可查看各厂站通信报文和远程终端设备(RTU)上送数据。系统自动从相应数据采集区获取相关信息,不需额外人工操作。
2 分布式数据采集的结构
分布式采集地县一体化调度自动化系统中的前置数据采集服务器,不再集中置于一地,也不再局限于2～4台,而是按需要分布在若干个地方。数据采集服务器并不是进行了简单的数量扩充,每台数据采集服务器也不是处理相同的任务,而是对数据采集功能进行分区域设置,将整个调度自动化系统的数据采集部分划分成若干个数据采集区子系统,各区域协同工作,共同完成整个系统的数据采集工作。每个数据采集区子系统都有自己独立的若干数据采集服务器和采集设备,每个区域只处理自己区域内的任务及自己管辖的厂站和测点。在每个数据采集区子系统内,数据采集服务器采用多机热备用的方式运行,其他区域的各种信息和运行状态不会影响本区域的正常运行和资源消耗[5]。
如图1所示,数据采集区Ⅰ的A,B这2台数据采集服务器只处理厂站A的2个通信通道,数据采集区Ⅱ的A,B这2台数据采集服务器只处理厂站B的2个通信通道,数据采集区Ⅲ的A,B这2台数据采集服务器只处理厂站C的2个通信通道。在数据采集区Ⅰ的数据采集服务器工作时,内存中没有厂站B,C的任何参数和数据,也不会处理厂站B,C的任何控制命令。
在任意一个数据采集区内,为了保证数据采集的可靠性,一般都采用多机配置,正常运行时多机之间会相互交换所需的各种数据,相互监视其他机器的运行状态,共同完成本数据采集区的所有数据采集任务。当任何一台数据采集服务器故障时,其数据采集任务会自动分配到剩下的其他服务器上,即使本数据采集区只剩下1台前置数据采集服务器也能完成本数据采集区的所有数据采集任务。
数据采集区可以方便地在线增加、删除和修改,而不会对其他无关区域的正常工作产生任何影响。如图1所示,如果要在数据采集区Ⅰ新增对厂站D的接入处理,只需要将新增的厂站D的通信通道设置属于数据采集区Ⅰ即可。当所有设置保存之后,数据采集区Ⅰ的数据采集服务器会自动增加处理厂站D的通信通道和数据,此过程不会对数据采集区Ⅱ和Ⅲ各台数据采集服务器的正常运行产生任何影响。同样,厂站D的修改和删除也不会对其他数据采集区的正常运行产生任何影响。
当地级、县级区域间的主干网络故障发生系统解列时,成为孤岛的县调仍具有数据采集能力。县调的前置服务器仍正常工作,可完成所属厂站的数据采集任务,并将数据送往县调的工作站,使县调系统仍然可以独立完成监控功能。
在分布式采集模式地县一体化系统中,各数据采集区处理完的数据以及各种状态都会送往系统平台集中进行下一步处理和展示。系统平台发往各厂站的命令也会由各数据采集区进行甄别后经由相应数据采集服务器发往厂站端,在系统内任意节点人工查询前置数据时无需进行区域选择。数据汇集和命令分区工作由系统自动完成,无需人工转发设置。
通过分布在各处的数据采集区协同工作,共同完成了整个系统的数据采集任务,任意位置采集的数据可共享至全网。
3 分布式数据采集的实现
目前,在南通分布式地县一体化系统中,已经实现了分布式数据采集。
3.1 硬件构成
南通地县一体化系统建设初期划分了南通、海门和如东3个数据采集区,每个数据采集区有前置服务器2台,相应的终端服务器和路由器分别用于串口通道通信和网络通道通信,如图2所示。
每个数据采集区仍然通过原有县调的通道资源采集厂站端的数据,3个数据采集区共同完成所有厂站的数据采集任务。
3.2 数据库设计
1)区域信息表:
设置不同的数据采集区的信息,初期有3条记录,分别为南通、海门和如东。
2)前置数据采集服务器表:
设置每台数据采集服务器的各种参数,如机器名称、编号等,另外还包括每台数据采集服务器所属的数据采集区。初期有6条记录,前置服务器ntfes1-1和ntfes2-1属于“南通”数据采集区,前置服务器hmfes1-1和hmfes2-1属于“海门”数据采集区,前置服务器rdfes1-1和rdfes2-1属于“如东”数据采集区。
3)前置数据采集设备表:
设置每台终端服务器的各种参数,如终端服务器名称、编号等,另外还包括每台终端服务器所属的数据采集区。如终端服务器ntts1属于“南通”数据采集区,终端服务器hmts1属于“海门”数据采集区,终端服务器rdts1属于“如东”数据采集区。
4)前置通道表:
设置每条通道的各种参数,如通信方式、通信协议等,另外还包括每条通道所属的数据采集区,分别属于3个数据采集区的通道有很多。
3.3 程序流程
1)程序启动时首先读入前置数据采集服务器表,根据本机的机器名在表中查找相应记录,得到本机所属数据采集区,以及在本区域内还有哪些数据采集服务器,写入内存。
2)读入前置数据采集设备表,根据本机的数据采集区域查找本区域内的终端服务器,写入内存。
3)读入通道表,根据本机所属数据采集区查找本区内的通信通道,写入内存,并根据通道参数初始化相应的终端服务器。
4)读入厂站表,根据厂站所关联的通道是否属于本区域来判断表中的哪些厂站属于本区域,并将其写入内存。
5)读入遥测、遥信定义表,根据这些测点所关联通道是否属于本区域来判断表中的哪些测点属于本区域,并将其写入内存。
6)与本区域各通道建立通信,解析实时数据,将值班通道的熟数据送往SCADA系统应用,将控制命令发往相应通道。若某通道或数据采集服务器发生故障,则在本区域内进行相应切换,消除故障。
3.4 运行效果
南通地县一体化调度自动化系统建设初期接入的厂站数目约为250座,每个县调管辖的厂站数目约为40座。后期又接入了2个县调的数据,目前接入的厂站数目大于300座。
在运行过程中,地调及各县调的数据采集相对独立,互不影响,南通地调侧的前置服务器只处理所属近200座厂站的数据采集任务,各县调侧的前置服务器也只处理各自所属近40座厂站的数据采集任务。因此,对于地调、县调的前置服务器来说并没有增加额外的数据采集任务。但对于一体化系统来说,任一节点上都可得到系统内所有数据,实现系统内所有功能。即使远程互联的网络中断,系统解列成多个孤岛时,各解列部分的数据采集工作仍然能够正常运行,保证各解列区域系统数据的正常刷新,系统仍可正常使用。
地调侧和县调侧可选用不同的硬件平台,目前支持Alpha、SUN、IBM、HP及PC等硬件平台,支持各类UNIX、Linux等操作系统,系统可屏蔽硬件和操作系统的差异,具备良好的软硬件无关性。系统具备良好的可扩展性,可以方便地接入新的县调节点,满足整体设计、分步实施的要求。
经过一段时间运行,南通地县一体化调度自动化系统中的分布式数据采集模式展现出以下特点。
1)大量节约通道资源。
县调有相当数量的专线通道,若全部集中到地调,通道建设成本高,因此按就近采集原则进行分布式采集可有效节约投资。
2)有效分担采集任务。
降低了地调主系统采集负担,扩展性较强,地调主系统的采集性能不会随县调规模的扩大或互联县调节点的增加而降低。
3)具备独立运行能力。
在地调主系统异常或地县联网中断等故障导致的分区解列运行情况下,依赖2台数据采集服务器,县调子系统具备短期独立运行能力,实时监控功能仍可正常运行,可将故障带来的影响降至最小。
4)灵活适应管理体制。
可以很好地适应管理体制,在当前地、县分级调度体系下,县调的自动化人员除了维护调度自动化系统外,还承担了其他系统维护职责。若管理体制发生变化,县调自动化人员全部集中到地调,系统软件也无需额外修改,只需把县调相应的采集设备集中到地调即可。
摘要：随着电网的快速发展,电网信息量急剧增大,利用传统集中式数据采集方法采集数据致使数据采集服务器负载问题越来越突出。为解决上述问题,提出在分布式地县一体化系统中采用分布式数据采集方法,将数据采集任务在地、县范围内进行区域分解,每个数据采集区只处理自己区域内的数据采集任务,区域间各种信息和运行状态互不影响。各数据采集区协同工作,共同完成整个系统的数据采集工作,所有分区实时采集的数据自动在全系统内共享,无需人工设置。
关键词：调度自动化,地县一体化,分布式,数据采集
参考文献
[1]钱君霞,徐春雷,余云川,等.地、县一体化调度自动化系统建设方案[J].电力建设,2010,31(12):65-67.QIAN Junxia,XU Chunlei,YU Yunchuan,et al.Constructionscheme for unified city and county dispatching automationsystem[J].Electric Power Construction,2010,31(12):65-67.
[2]黄邵远.地县级调度自动化一体化主站系统建设思路[J].电力系统自动化,2009,33(20):100-103.HUANG Shaoyuan.Integrated dispatching automation masterstation system for prefecture and county power networks[J].Automation of Electric Power Systems,2009,33(20):100-103.
[3]张永忠.EMS系统分区管理模式[J].内蒙古电力技术,2006,24(3):58-59.ZHANG Yongzhong.Sectional management mode on EMSsystem[J].Inner Mongolia Electric Power,2006,24(3):58-59.
[4]姚建国,杨胜春,高宗和,等.电网调度自动化系统发展趋势展望[J].电力系统自动化,2007,31(13):7-11.YAO Jianguo,YANG Shengchun,GAO Zonghe,et al.Development trend prospects of power dispatching automationsystem[J].Automation of Electric Power Systems,2007,31(13):7-11.
基于分布式数据库数据处理的研究 篇9
关键词：分布式数据库,数据拆分,数据整合
0 引言
由于数据量和并发访问量的急剧增加, 数据库的连接遇到瓶颈, 大数据量的表访问速度慢、效率低的问题日益突出。对于海量数据的处理, 非关系型数据库使用日益增多, 如何部署分布式数据库, 解决关系数据库和非关系数据库的共同使用以及大数据量的表访问效率低的问题已成为重中之重, 通过把数据拆分到不同的数据库, 在应用层对不同数据源整合的方案, 是解决数据层性能问题的关键。
1 数据拆分
随着网络流量爆发式的增长, 业务拆分势在必行。拆分的业务形成一个个独立的子系统, RS10系统包括生产、物流、财务等子系统, 每个子系统之间耦合度低, 功能模块划分清晰, 数据易于拆分。把生产、物流、财务等子系统的数据从存放在一个数据库服务器上拆分成存放在不同的数据库服务器上, 通过中间数据层框架进行数据整合, 使得业务层访问数据仍像访问单个数据库一样, 不造成任何影响。业务分级与关联是业务划分、信息共享和资源整合的过程, 使用数据层框架解决分布式数据库对业务分级和关联带来的影响。通过分库分表、读写分离, 数据库的性能问题也迎刃而解。
数据拆分就是通过某种特定的条件, 将我们存放在同一个数据库中的数据分散存放到多个数据库 (主机) 上面, 以达到分散单台设备负载的效果。数据拆分同时还可以提高系统的总体可用性, 即使单台设备崩溃之后, 只是总体数据的某部分不可用, 而不是所有数据。
数据拆分根据其拆分规则, 可以分为两种拆分模式。一种是按照不同的表拆分到不同的数据库 (主机) 之上, 这种拆分称之为数据的垂直拆分;另外一种则是根据表中的数据的逻辑关系, 将同一个表中的数据按照某种条件拆分到多台数据库 (主机) 上面, 这种拆分称之为数据的水平拆分。
1.1 垂直拆分
数据的垂直拆分也称纵向拆分, 数据库是由很多个数据块组成, 我们垂直地将这些数据块拆开, 将它们分散到多台数据库主机上面。
一个架构设计较好的应用系统, 其总体功能肯定是由很多个功能模块所组成的, 而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。不同功能模块的数据存放于不同的数据库主机, 可以容易避免跨数据库的连接存在。
垂直拆分的架构, 如图1所示。垂直拆分的优点表现在:
1) 数据库的拆分简单明了, 拆分规则明确;
2) 应用程序模块清晰明确, 容易整合;
3) 数据维护方便易行, 容易定位。
垂直拆分的缺点则表现在:
1) 部分表关联无法在数据库级别完成, 需要在程序中完成;
2) 访问及其频繁且数据量超大的表依然存在性能瓶颈;
3) 事务处理相对更加复杂。
1.2 水平拆分
水平拆分主要是将某个访问及其频繁的表再按照某个字段的某种规则来分散到多个表中, 每个表中包含一部分数据。
数据的水平拆分是按照数据行的拆分, 将表中的某些行拆分到一个数据库, 而另外的某些行拆分到其他的数据库中。为了我们容易判定各行数据放在数据库中, 拆分需要按照特定的规则来进行。如根据公司号或者用户编码等进行拆分。
基于用户的编码进行数据水平拆分, 如图2所示。
水平拆分的优点表现在:
1) 表关联基本能够在数据库端全部完成;
2) 不存在超大型数据量和高负载的表;
3) 事务处理相对简单;
水平拆分的缺点则表现在:
1) 切分规则相对更为复杂, 很难抽象出一个满足整个数据库的切分规则;
2) 后期数据的维护难度有所增加, 人为手工定位数据更困难;
3) 应用系统各模块耦合度较高, 对数据的迁移拆分造成一定的困难。
1.3 联合拆分
在实际的应用场景中, 系统的业务逻辑比较复杂, 系统负载比较大, 无法通过单独的一种数据拆分方式来实现, 需要两种拆分方法结合使用, 分布式数据库应采用垂直拆分与水平拆分联合使用, 如图3所示。
联合拆分的优点:
1) 可以充分利用垂直拆分和水平拆分各自的优势而避免各自的缺陷;
2) 让系统扩展性得到最大化提升;
联合拆分的缺点:
1) 数据库系统架构比较复杂, 维护难度更大;
2) 应用程序架构也相对更复杂。
2 数据整合
数据库在经过垂直和 (或) 水平拆分被存放在不同的数据库之后, RS10系统最大的问题是访问业务数据, 让业务数据得到较好的整合, 因此, 存在两种解决方案:
第一种方案, 在每个子系统中配置和管理需要的数据源, 直接访问各个数据库, 在每个子系统内完成数据的整合;
第二种方案, 使用数据层框架来统一管理所有的数据源, 数据库集群对每个子系统透明。
针对RS10, 我们采用第二种解决方案来实现数据的整合。
3 分布式数据库层架构
在选择通过数据库的中间代理层来解决数据的拆分和整合方案之后, 我们选取开源的Amoeba框架, 在它基础上开发出适合RS10的数据拆分和整合方案。
Amoeba是一个基于java开发的, 专注于解决分布式数据库数据源整合的开源框架, 可用来监视、分析或者传输他们之间的通讯信息, 实现连接路由、Query分析、Query过滤和修改、负载均衡以及基本的HA机制等。
所有客户端请求都是通过这个中间层, 然后经由中间层进行相应的分析, 判断出是读操作还是写操作, 然后分发到相应的数据库服务器上, 我们基于这个框架来实现和部署RS10的分布式数据库, 架构图如图4所示。
Amoeba能解决RS10以下问题:
1) RS10分库分表以及拆分之后数据的整合;
2) 提供了数据拆分规则, 降低拆分规则给数据库带来的影响;
3) 减少了数据库与客户端的连接数, 用户只访问自己需要的数据;
4) 通过中间层代理, 实现读写分离。
基于这个开源框架我们能开发出同时连接不同的数据库的数据源为前端应用程序提供服务, 我们通过Amoeba框架分析Query语句, 根据Query语句中所请求的数据来自动识别Query语句的数据源是什么类型数据库, 在哪个物理主机上面, 然后选择特定的JDBC驱动和相应协议连接后台数据库。
通过数据的垂直和水平拆分, 增强数据库的整体服务能力, 通过数据层框架解决数据拆分和整合, 使数据库很容易扩展, 只需要增加廉价的PC服务器, 即可线性增加数据库集群的整体服务能力, 从而实现分布式数据库的部署和扩展。
4 结束语
目前, 关于分布式数据库系统数据处理的研究很多, 针对RS10大数据量的性能以及并发访问效率低的问题, 基于Amoeba框架, 对大数据量的表进行拆分, 对集中式部署的数据库采用分布式部署, 有效的解决数据量大、并发访问效率低的问题。分布式数据库对数据的拆分和整合是最关键的环节, 只有充分解决这个问题, 分布式数据库才能得到有效地使用。
参考文献
[1]http://info.52z.com.[EB/OL.]
[2]MySql数据切分及整合方案—IT科技以人为本[J], 2009.
分布式数据采集 篇10
关键词：数据同步通信,分布式,实时数据库
1 前言
随着信息技术的发展以及国家对企业安全生产信息化要求的提高, 我国大多数企业生产过程中基本都采用了各种各样的监测监控系统, 由于管理和技术的原因, 这些系统分散在各个相关职能部门, 形成了多个“信息孤岛”, 严重影响了企业安全生产管理水平的提高, 阻碍企业信息化进程。
分布式实时数据库系统DRTDBS (Distributed Realtime Database System) 的出现为各种监测监控系统提供了统一的数据平台, 以便数据的查看和使用不受监测监控系统专有技术、网络、协议的制约, 达到实时数据真正共享的目的。并确保所传输数据的实时性、准确性、有效性, 为企业上层应用提供可靠的支持。
DRTDBS按照各监控设备区域分布情况, 将整个企业的实时数据进行区域划分, 由若干实时数据库服务器 (以下简称数据服务器) 加以管理。DRTDBS的网络分布结构如图1所示。
在每个数据服务器管辖区域内, 数据采集工作站将现场设备的物理信息和实时数据上传到数据服务器, 由数据服务器统一管理。区域内的监控站点如监控开发工作站, 监控应用运行服务器、现场监控工作站点等与数据服务器通信, 从中读取所需实时数据。若监控站点想跨区域访问实时数据, 例如, 区域1的监控开发工作站想访问区域2的实时数据, 则通过两区域内数据服务器的数据同步
通信来完成实时数据的访问操作。
由于在DRTDBS中数据不仅具备分布性, 同时还具备实时性, 因此, 如何在有效的时限范围内, 使各分布站点能进行准确无误的数据通信是实现DRTDBS的关键技术之一。但由于DRTDBS数据的双重特性, 迄今为止在这方面的研究还比较薄弱, 所以数据同步通信成为了DRTDBS的一大研究难点。在此背景下, 本文对已有的分布式数据库数据同步技术进行研究, 提出了适用于DRTDBS的数据同步方案, 并给出了较详细的设计步骤。
2 影响数据同步性能的因素
由于DRTDBS中数据具有实时性, 因此衡量数据同步性能的一个重要指标就是系统中所有参与数据同步的服务器完成一次数据同步所需最大时间tmax。又由于DRTDBS处于企业局域网中, 因此本节着重讨论在局域网内影响tmax的因素, 并定性分析这些因素对tmax的影响程度, 以此作为选用数据同步策略的参考。
图2, 给出了参与数据同步的服务器 (以下简称数据服务器或服务器) 的网络链路图。在图中S1、S2、S3……Sn为数据同步服务器。为简化分析, 在此我们仅考虑极端状态即每个服务器都与其它所有服务器进行数据同步的情况。Si代表服务器Sj到服务器Wij的链路带宽。Kij代表每个服务器的数据同步率 (服务器i每次向服务器j提供的同步数据量, 单位bit) 。根据图2可以得出各服务器链路带宽矩阵 (图3) 和各服务器的数据同步率矩阵 (图4) 。
根据服务器Si到Sj的一次数据同步时间, 可得整个局域网内数据同步时间矩阵:
根据图5得整个局域网中所有数据同步服务器一次数据同步后, 所需最大时间为:
即tmax为tij中最大值。可根据tij, 做适当的假设, 分析影响tmax的各大因素, 并定性分析各大因素对tmax的影响程度。假设如下:
(1) 网络稳定, 且每条链路所占带宽相等为2B/n (n-1) , 其中为网络总带宽, n (n-1) /2为网络总链路数。
(2) 在理想情况下, 不考虑网络传输延迟问题, 不考虑主机处理同步数据耗时。则Si到Sj的一次数据同步时间为:
一次数据同步中, Si向其它所有服务器提供同步数据总量为, 那么所有服务器提供同步数据总量为:
由公式 (2) 可得出以下结论:
(1) 当n恒定且K
(2) 当K
从tmax角度分析, 影响数据同步性能主要有3大因素, 数据同步率Kij, 数据同步服务器数目n和网络带宽B。选定局域网后, 在理想状态, 即网络带宽B不变的情况下, 提高数据同步性能集中在数据同步率Kij和数据同步服务器数目n两大因素上。由结论 (1) 可以总结出, 在设计数据同步方案时, 要尽量减少数据同步率, 但前提是不
会造成主机处理时间延长, 以至成为影响数据同步性能的主要因素之一。由结论 (2) 可以总结出, 在设计同步方案时, 应根据公式 (2) 估计在一次数据同步过程中能允许的数据同步服务器数目, 然后根据实际情况对服务器数进行适当控制调整。
3 数据的同步策略
(1) 为方便起见, 定义如下概念:
(1) 主服务器:是指那些提供同步数据的服务器, 如图8所示。
(2) 从服务器:指引进同步数据的服务器, 如图4-11中的服务器A, B, C和D。
(2) 主服务器和从服务器之间具有如下关系:
(1) 主服务器和从服务器都是数据同步服务器;
(2) 一个主服务器可以拥有多个从服务器, 因为它可以向多个从服务器提供同步数据;
(3) 一个从服务器可以有多个主服务器, 因为它可能拥有来自不同服务器的数据备份;
(4) 一个主服务器即可以是某些数据的主服务器, 也可以是另一些数据的从服务器, 即它可以向其它数据同步服务器提供同步数据, 也引进其它数据同步服务器提供的同步数据。
(3) 完全同步法 (Completion Synchronization, C_Syn)
完全同步法是指每次进行同步操作的时候, 主服务器都将生成完整的同步数据集合MD={MR1, MR2……, MR3, }, 并用M D完全刷新从服务器上的同步数据集合SD={SR1, j, SR2, j, ……, SR3, j}, 使主服务器与从服务器的数据同步起来。其优点是实现简单;缺点是数据同步率Kij增大时, 同步时间正比增加, 当存在大量同步数据时, 采用完全同步法效率低下, 对数据同步性能影响较大。若数据同步服务器数量n也增加时, 完全同步法将严重影响数据同步性能。
因此, 该方法仅适用于主从服务器之间需同步的数据量较少的情况。
(4) 差异同步法 (Difference Synchronization, DS)
为了克服完全同步法每次同步操作都完全刷新同步数据集的缺陷, 差异同步法并不将整个同步数据集应用于从服务器, 而是不停地监视自上一次同步操作以后主服务器同步数据集的变化, 在下一次同步操作的时候, 将这些变化应用到从服务器。
与完全同步法相比, 差异同步法最大的好处在于只需要同步变化了的数据即可, 从而大大减少了数据同步率Kij, 提高了数据同步的效率。
为实现差异同步法, 本文为每个需要同步的实时数据添加了跟踪因子, 每个负责监视一个同步数据的的更新情况。=实时数据索引号nm+更新标志。每经历一次实时数据更新, 每个实时数据值都要和上一次更新时的值进行比较, 若有更改则跟踪因子的更新标志置1, 若无更改, 则置0。之后把凡是置1的实时数据发送给相应的从服务器。
4 数据同步实现
每个服务器既可是主服务器又可是从服务器, 因此, 每个服务器数据同步模块功能相同, 由两大模块组成:通信处理模块、通信接收模块。
(1) 通信处理模块
主要负责命令、配置数据、实时数据的传输与相关处理。
(2) 通信接收模块
主要负责对命令、配置数据、实时数据的接收工作。该模块采用DCOM Server形式, 可被远程调用。
4.1 协议说明
要完成整个数据的访问通信需要以下几条最基本的命令:
(1) 请求命令:有关远程实时数据访问的请求命令。
(2) 回复命令:对远程实时数据访问的有关回复命令。
(3) 数据传输命令:实时数据、配置数据及配置数据修改信息的发送。
(4) 数据传输应答命令:数据接收方的应答命令, 表明是否接收到数据。
协议制定时应考虑到协议要包含必要信息, 简洁、清晰、易于处理。协议定义如下:
Cmd ID;Local ID, Cmd, Time;
Cmd ID:命令的标识, “Request”表示请求命令;“Response”表示回复命令;“Req Data”表示数据发送;“Res Data”表示数据接收应答。
Local ID:命令发送方标识。
Cmd:具体命令内容, 可以带参数, 详细Cmd命令如下:
Time:命令发送的系统时间。
4.2 通信连接建立
用户只需选择主服务器和具体请求命令, 按发送键即可, 剩下的工作都由通信处理模块和通信接收模块完成。在数据同步之前, 因各服务器处于非连接状态, 这就需要建立通信连接。通信建立过程如图9所示。
这里服务器A为主服务器, 服务器B为从服务器。因各从服务器与主服务器通信连接建立过程相同, 故仅讨论一个从服务器与主服务器通信连接建立过程。
1.首先从服务器B向主服务器A发出“请求查看配置表”RT命令;
完整的命令为:Request;2, RT, 2008-1-23 14:3:0 (其中2为服务器B标识) 。其命令解读为在2008-1-23 14:3:0, 服务器B向A发送了“请求查看配置表”命令。
2.服务器A通信接收模块接收到请求命令后, 由通信处理模块识别发送方, 并对其命令作出回应:
(1) 若服务器A允许服务器B查看配置表 (YRT命令) , 则服务器A与服务器B间通信连接建立成功。完整命令为:
Response;1, YRT, 2008-1-231 4:4:10 (其中1为服务器A标识) 。解读为在2008-1-2 314:4:10, A向B作出回应, 允许B查看配置表。
(2) 若服务器A不允许服务器B查看配置表 (NRT命令) , 则通信连接建立失败。完整命令为:Response;1, NRT, 2008-1-2314:4:10。
4.3 配置数据的选取
当通信连接建立后, 从服务器即可访问主服务器A的配置数据库。因各从服务器的访问过程相同, 故也仅讨论从服务器B对主服务器A配置数据库选取过程。服务器B从主服务器A的配置数据库中选择感兴趣的数据, 在内存中建立临时配置信息库, 暂存相关同步配置信息, 并在本服务器配置数据库中做好备份, 然后把指定的配置信息自动发送给服务器A。A收到后, 也在内存中建立临时配置信息库, 暂存B选定的配置数据, 并在自己的配置数据库中做好指定配置数据备份工作。最后A向B发送“YSTD”选定配置信息已收到命令。实现过程如图10所示。
具体命令为:
ReqData;2;SSTD, 1, a, 2, b 3, c…….;20 0 8-1-2314:5:12 (其中1, a, 2, b 3, c……为选定的配置信息) 。在2008-1-2314:5:1 2, B向A发送选定配置信息1, a, 2, b, 3, c……。
Res Data;1;YSTD;2006-5-20 15:31:24, 解读为在2008-1-23 14:5:20, A向B发送配置信息已收到命令。
4.4 多服务器实时数据同步更新
在此, 所谓多服务器实时数据同步更新是指以服务器数据更新周期为期限, 当主服务器数据更新后, 在不超过主服务器数据更新周期的时间内, 对从服务器上的引进实时数据进行更新。
首先, 服务器间要进行时钟同步操作, 统一各服务器时钟, 然后按照图11进行多服务器实时数据同步更新操作。
(1) 主服务器A实时数据库通知通信处理模块实时数据已更新 (1) 。
(2) 根据同步数据量多少分两种情况讨论:
(1) 若同步数据量较少时, 采用完全同步法。通信处理模块读取临时配置信息库中的配置数据 (2) ;接着根据配置数据, 读取相应实时数据 (3) ;然后发送各从服务器指定的实时数据 (4) ;
(2) 若同步数据量较大时, 采用差异同步法。通信处理模块读取临时配置信息库中的配置数据 (2) , 根据配置数据, 仅读取数值有更新的实时数据并发送给相应的从服务器。
(3) 各从服务器定时判断是否收到实时数据, 分别向主服务器A发送“YRTD/NRTD收到/未收到实时数据”命令, 由服务器A通信接收模块接收命令 (5) 。
(4) 通信处理模块定时从通信接收模块读取命令, 若有从服务器未收到实时数据, 并且服务器A实时数据库未进行下一次更新, 则重新发送指定的实时数据到相应从服务器。
以上整个过程应在主服务器下一个数据更新周期前完成。若某从服务器数据更新超时, 则舍弃接收到的实时数据。
5 结论与展望
本文从分析影响DRTDBS数据同步通信的因素入手, 根据DRTDBS的实际情况采取了两种数据同步策略, 并给出了差异同步法的实现方法。最后提出了设计实现DRTDBS数据同步的详细方案。实践证明该方案已取得了初步的成效。
今后应在DRTDBS的时钟同步、实时事务的并发控制等方面进行深入研究, 逐步完善DRTDBS数据同步功能。
参考文献
[1]闫晓多.非连接分布式数据库环境下的数据同步策略[D].青岛海洋大学硕士学位论文, 青岛海洋大学图书馆, 2002.
[2]王岳斌, 潘久辉.分布式环境下数据同步技术的设计与实现[J].南京大学学报 (自然科学) , 2001年10月, 37卷:276-279
[3]丁鲲, 严浩, 刁兴春.分布式数据库数据同步技术研究[J].海军工程大学学报, 2004年9月, 1卷5期:100-104
[4]谢坤武.基于组件技术的数据同步分析[J].武汉科技学院学报, 2004年6月, 3期:46-48
分布式数据库在网络教学中的应用 篇11
关键词:分布式数据库;网络教学;CSCW;应用
中图分类号:TP393 文献标识码:A文章编号:1007-9599 (2010) 04-0000-01
The Application of Distributed Databases in the Network Teaching
Zhou Gang
(The second mechanic school in Hangzhou,Hangzhou311203,China)
Abstract:With the global popularity of computer and the quick speed for computer network technology, distributed database comes up with the times demand. Today, the network distributed database has been successfully applied to teaching, and promoted the teaching of comprehensive reform of the network. This article outlined the characteristics of the distributed database, distributed the situation of distributed databases in the network teaching, and analyzed the achievement of distributed database in the network teaching, which is based on CSCW.
Keywords:Distributed database;Network Education;CSCW;Application
数据库以及网络技术的飞速发展,标志着信息时代的到来。对于网络教学来说,将网络技术融入到教学中,全面促进了教育事业的发展。尤其是基于分布式数据库技术,应用在网络教学中,全面革新了传统的课堂教学以及教学思想,形成了全新的教育模式。分布式数据库成功应用于网络教学中,是教学体制的全面更新的重要基础。
一、分布式数据库概述
(一)分布式数据
数据库系统的发展使得计算机产生了全新的变更,当前形势下,绝大多数的数据处理都离不开数据库的发展。分布式数据库(DDB),毫无疑问,是全面融合数据和网络技术。传统意义上的数据库技术是数据集中管理,通过集中的方式,达到共享有关数据,比较抽象,给使用用户提供的是一个统一的、整体的管理方法。对于网络技术而言,计算机网络偏于分散,需要理由可靠的网络来连接和处理计算机之间的相关数据(即分布式数据及程序),来满足分散用户的需求。
(二)CSCW的分布式教学
首先,CSCW(Computer一Supported,CooperativeWork),其旨在计算机网络条件下,对群体用户提供相关支持,即在计算机环节中,协调完成相关任务。CSCW能将分散的各个群体,通过计算机网络相关技术,融合起来,然后协同合作完成某一固定任务。CSCW的分布式数据库应用于教学,其可以不同时间不同地点进行教学活动,是融合计算机网络、数据库以及多媒体相关技术。应用全新的分布式教学方式,对于教学而言,完全脱离传统教学方式,任何时间地点来安排教学进度和方法;对于学习而言,学生可以全面衡量自身的专业水准,以此来自由安排学习时间,制定学习计划,按照自己的学习进度来进行相关知识的学习。因此,教育部一九九八年十二月二十四日,将网络教学(分布式或e一leaming)列入二十一世振兴行动计划中,并把分布式教学方式作为终身教学的机构。CSCW硬件平台包含五个部分:传递、处理、存贮、交互和表示(见图1)。
二、基于CSCW分布式数据库的网络教学应用
CSCW的分布式教学,其整体系统(见图2)分为四个方面:首先是系统界面,用于用户注册和登录,进入系统操作前的必备工作,以便身份核实。然后是数据库系统,数据库系统信息量大,除了包含用户资料相关信息外,更主要涉及教学方面的内容,比如教学资源,教学内容,教学任务等,CSCW系统中,更包括分布式数据计算以及分布式服务器相关信息。其次是教学区,主要内容为教学设计以及各用户制定的教学安排,进行教学目的以及方式的选择。最后是协作区,该部分主要是针对学员而言,用于统一学员思想,让学员进行相互间的交流,得出的相关结论再提交给数据库,然后再分配到教学区,如此循环,有利于提高教学质量。
(一)分布式多数据库应用
多数据库是CSCW教学系统的最大特点,所以,分布式多数据库的应用,能充分实现CSCW教学的教学要求。多数据库系统(MDBS:Multi一DatabaseSystem),包含以下几个方面:
1.行为筛选数据库:该数据库主要针对用户的行为,对其分析和筛选,获取有效信息,然后预处理相关资料。
2.行为处理数据库:该数据库对用户的某一行为进行相关储存,并采取相关处理方式,来支持相关行为。若有用户对于教学系统不熟悉,该数据库会在行为筛选数据库的基础上,自动处理相关数据,引导用户做出正确的点击。
3.系统结构数据库:基于CSCW导航,做出相应的信息链接。
4.问题/答案库:作为教学系统考核标注数据库,其在cscw的分布式教学系统中的地位是可想而知的,作为考核学生的标准。
5.教学策略库:是CSCW系统核心部分,作为教育的主要模块,指导学员进行系统的学习,系统的教授学生相应的知识,并进行考核。
6.协作策略库:对所有用户进行相关分组,然后每组用户采用协同交流的方式完成相应的任务。
7.学生档案库:该数据库主要记录的是学生有效信息,作为协作策略库的基础,为其作出分组依据。学生档案库的相关信息的分析,便于查找特定用户。
8.学生特征库:全面分析学生的相关信息,自动理解学生的认知能力、知识结构层面以及学习技能所用方法,根据相关特性,为学生分组提供参考。
9.材料库:也就是通常所说的教材信息、专业知识信息、讲义笔记信息以及给系统进行改进反馈的相关数据等。
10.社区资源库和空间:为用户提供自由空间,相当于BLOG(博客)一样,为用户提供抒发自身情感的平台,以及管理员联系用户的基本窗口。
(二)CSCW分布式数据库应用实践
就使用角度来说,CSCW的网络教学所提供的功能包括:信息的浏览、资源搜索,资源信息的批量链接等等。从数据库管理角度来说,CSCW的网络教学其相关功能包含:资料的存储、增减、资源数据的计算、信息审计、维护用户等等。然而,就CSCW分布式网络教学而言,随着计算机网络教学的普及以及计算机网络、数据库分布式的发展,人们对不同时段、不同地域间的资源共享需求量越来越大,种类也越来越多,资源共享也成了最需克服的技术难点。
三、结束语
基于网络的教育不仅是对传统教育领域的挑战,同时也是教育领域的一个新的机遇,使网络发展的一个重要方向,基于CSCW的分布式网络教学实现,更是革新了网络教学体系。随着信息化进程的深入,计算机应用从传统的单机模式向多用户、网络化发展。这种基于CSCW的思想对于解决目前的分布式数据库网络教学存在的种种问题,有着十分巨大的优势。虽然CSCW网络教学或许存在相关问题,但是随着技术的更新,相信分布式数据库应用网络教学中的效果会更上一层楼!
参考文献:
[1]何彤宇.基于分布式数据库的网络教学资源系统设计与研究[D].贵州师范大学,2004
[2]郑妹,刘晨.远程教学管理系统的设计[J].无锡职业技术学院学报,2007,(2):35-36
[3]张艳,张丽,顿文涛.CSCW在网络教育中的应用[J].河南教育学院学报:自然科学版,2005,(2):68-69
分布式数据采集 篇12
1 分布式数据库的不安全因素
虽然现有的数据库软件在数据安全方面已经提供了不同程度的服务，但正如微软的Windows系统也会死机一样，即使再优秀的软件也难以对渗透到整个计算机环境中的不安全因素明察秋毫，都或多或少的存在缺陷。它所提供的安全服务只是避免了大多数的常见问题，而在各类信息系统实际运行时出现的各种不容易被发现、却非常致命的问题往往被疏忽掉，缺乏灵活性。所以，正确地识别不安全因素所带来的威胁对于抗击和防止数据侵害是至关重要的，因此在讨论安全策略之前，先来分析一下各种分布式数据库的不安全因素。
1.1 操作系统安全的脆弱性
这是由操作系统的结构体制———操作系统的程序是可以动态连接，可以创建进程，提供远过程调用(RPC)等所造成的。一个可以打补丁和可渗透的操作系统是不可能从根本上解决安全问题的，但是，操作系统支持程序的动态连接和数据动态交换是现代系统集成和系统扩展的需要，显然这与安全是相矛盾的。
1.2 数据库管理系统安全的脆弱性
目前流行的商用数据库管理系统的安全级别，一般达到美国国防部颁发的可信计算机系统评估标准(TCSEC)中的CZ级要求。即使有更高安全级别的DBMS，也大都直接应用于军方。而且数据库管理系统的安全与操作系统的安全应该配套(此观点有争议)，即如果DBMS的安全级别是BZ级，那么OS的安全级别也应该是BZ级。因为数据库的安全管理也是建立在分级管理概念上的，也要依靠可信计算基(TCB)方式，所以数据库管理系统也是脆弱的。
1.3 网络协议的脆弱性
网络协议的脆弱性反映在网络协议安全保障的低水平。例如：TCP/IP在该协议设计之初，就没有将安全因素考虑进去。TCP/IP服务的内在问题、主机配制的复杂性、软件开发过程中引入的脆弱性以及多变性的实际因素等，都会使有关的站点无法抵御“闯入者”的连接或相关问题。
1.4 网络口令的破译
通过信道窃取口令。例如当用户使用TELNET或FTP连接在远程主机上的账号时，Internet上传输的口令是没有加密的，通过监视用户携带的IP包就可获取它们;然后再通过这些用户名和口令合法方式登录到系统，成千上万的系统就是被这种方式入侵的。
2 保证分布式数据库安全的策略
分布数据库的安全策略是涉及信息访问的最高指导，这些策略根据用户需求、安装环境、建立规则和法律等方面的限制来制定的，用于描述访问规则和访问特征的关系。主要有：
(1)安全规律策略：安全管理策略可分为集中式控制和分布式控制。对于集中式控制，一个授权管理员或组，控制着系统的所有安全;对有分布式控制，不同的授权管理员或组，控制着数据库安全的不同部分。
(2)最小特权策略：系统中主体执行授权任务时，应该授予他完成任务所需要的最小特权。
(3)访问控制分类策略：限制主体访问客体使做到“知必所需”，就要对主体访、客体和访问权限进行分类，分类策略包括分类的粒度、分类的方法和授权的方法等。
访问控制策略：访问控制策略与访问控制分类策略密切相关，访问控制策略定义主体对客体访问规则的集合。为了灵活控制数据库数据的安全性，数据库管理系统应该提供动态的安全机制，例如动态授权方式。
从现有的DBMS实现的角度来看，基于这些策略实现数据库安全的基本方法有：身份认证、存储访问控制、敏感数据加密、审计跟踪与攻击检测。
2.1 身份认证
在开放共享的多用户系统环境下，数据库系统必须要求用户进行身份认证是一个访问数据库的第一道防线，目的是防止非法用户访问数据库。可以说身份认证是安全系统防止非法用户侵入的第一道安全防线，它的目的是识别系统授权的合法用户，防止非法用户访问数据库系统。用户要登录系统时，必须向系统提供用户标识和鉴别信息，以供安全系统识别认证。
2.2 访问控制
所谓访问控制，一般是指系统内部的访问控制，或者说，是系统内部主体对客体访问所受到的控制。实施访问控制，是维护系统安全、保护系统资源的重要技术手段，也是计算机系统中数据库系统安全机制的核心。保护的主要目标是被访问的客体;其主要任务是对存取访问权限的确定、授予和实施;其目的就是在保证系统安全的前提下，最大限度地给予资源共享。
访问控制的基础，是主体和客体的安全属性。实施访问控制，侧重保护的是客体。每个需要加以保护的客体，都得按安全要求，预先标识一组相应的安全属性，并以此鉴别、确定对客体访问的允许与否。这个标识安全属性称为访问控制表;同样，每个主体也应当设有相应的访问控制表，用以标明它访问客体的能力。此处标识的作用就是“授权”，用以标明哪些主体有权访问。所确定的访问权限实际是允许的访问方式，即读、写、查询、增加、删除、修改等操作的组合，还有安全的访问过程等。
访问控制机制的建立，应当遵循如下的安全原则：
(1)授予最小特权：系统中用户为其代表的用户进程实施存取控制时，只能拥有最小的必需特权。
(2)对存取控制的验证：实施必要的、严格的验证，是与特权授予的配套措施。验证的主要内容是主体的身份、权限和访问方式是否合法，以及客体的操作允许性。
(3)访问控制的可靠性：防止主体能够经由被允许的其它访问路径，迂回地实现某些越权的非法访问。另外，还应当经得起可能出现的恶意攻击。
(4)实体权限的时限性：是指实体拥有的权限不能永远不变，应当及时修改或为权限设置最短的时限。
(5)可用性：在应有的权限范围内，不使用户感到运用的诸多限制和不便。
在当前流行的这几种RDBMS中，主要采用任意访问控制和强制访问控制这两种方法来实现。
2.3 数据加密
一般而言，上述提供的安全技术还能够基本满足一般的数据库应用，但对于一些重要部门或敏感领域的应用，仅靠上述措施还是难以完全保证数据的安全性。因为所有数据都以可读的原始形式存储在数据库中，所以某些用户尤其是一些内部用户(包括DBA)或者高明的入侵者仍可以从数据库系统的内存中导出所需要的信息，或者采用其它方式越权打入数据库，从系统的后备存储器上窃取数据或篡改数据。这样也没法保护数据的真实性、可靠性。因此，对于敏感数据的加密保护，也成为数据库安全策略的重要任务之一。
2.4 审计追踪和攻击检测
虽然存取控制在经典和现代安全理论中都是实施安全策略的最重要手段，但软件工程技术目前还没有达到形式证明一个系统的安全体系的程度，因此不可能保证任何一个系统完全不存在安全漏洞，也没有一种可行的方法，可以彻底地解决合法用户在通过身份认证后滥用特权的问题。因而，大型DBMS提供的审计追踪和攻击检测便成了一个十分重要的安全措施，也是任何一个安全系统中不可缺少的最后一道防线。
审计功能在系统运行时，可以自动将数据库的所有操作记录在审计日志中，用来监视各用户对数据库施加的动作。攻击检测系统则是根据审计数据分析检测内部和外部攻击者的攻击企图，再现导致系统现状的事件，分析发现系统安全的弱点，追查相关责任者。采用两种方式的审计，即用户审计和系统审计。用户审计时，DBMS的审计系统记下所有对自己表或者视图进行访问的企图(包括成功的和不成功的)及每次操作的用户名、时间、操作类型、操作代码等信息。审计的结果存储在数据库的审计表中，用户可以利用这些信息进行审计分析。系统审计由系统管理员进行，其审计内容主要是系统一级命令以及数据库对象的使用情况等信息。
2.5 数据库备份与恢复
数据备份与恢复是实现信息安全运行的重要技术之一，能保证信息系统因各种原因遭到破坏时，能尽快投入使用。任何一个数据库在使用过程中，都可能因各种原因而使数据库受到破坏，导致系统崩溃，这时就需要对数据库进行相应的安全恢复。一般来说，数据库的恢复可以通过磁盘镜像、数据库备份文件和数据库在线日志三种方式来完成。在数据库优化设计中，应该同时考虑数据库的恢复能力和性能，找到二者的平衡点。
摘要：数据库在当今的信息社会中应用十分广泛, 但随之而来的就是数据库的安全问题。针对如何保证分布式数据库环境下的数据安全这一问题, 从分布式数据库环境出发, 探讨了数据安全策略。
关键词：分布式数据库,数据安全策略,身份识别,访问控制
参考文献
[1]邵佩英.分布式数据库系统及其应用[M].北京:科学出版社, 2000.
[2]贾焰, 王志英.分布式数据库技术[M].北京:国防工业出版社, 2000.
[3]李平安.分布式数据库系统概论[M].北京:科学出版社, 1992.
【分布式数据采集】推荐阅读：
分布式数据服务05-08
分布式数据处理及采集08-02
分布式数据处理06-14
分布式数据库系统07-18
分布式并行数据库07-13
分布式数据库技术07-30
分布式数据流系统分析07-16
分布式数据库安全问题06-11
分布式传感器数据库论文06-01
分布数据查询07-03