分布式数据库优化

分布式数据库优化（精选12篇）

分布式数据库优化 篇1

信息技术的快速发展推动着数据库技术不断发展, 分布式数据库的应用越来越广泛, 已经成为信息化建设非常重要的一个组成部分。对数据库查询是最为常见的操作, 同时也对操纵和维护数据库有着重要的作用。因此对查询进行优化, 使得查询速度得到提升, 对数据库管理系统的性能提升有着积极的作用。

1 分布式数据库的组成

分布式数据库属于比较复杂的一个计算机系统, 关于这个系统主要包括下面几个组成部分。

1.1 硬件

硬件是分布式数据库完成其功能的物质条件, 分布式数据库要实现其预定的目标, 必然要依赖对应的硬件, 这里的硬件环境是分布的。硬件包括CPU和内存以及外存等, 不同站点选择其硬件要能够与本地的应用规模相适应, 同时也需要充分考虑全局应用规模, 要根据站点实际的需要来选择最佳的通信设备。

1.2 软件

分布式数据库在具备硬件条件以后还需要对应的软件来辅助其功能的实现, 每一个站点需要配备一定的操作系统还有数据库管理系统, 这样站点才能满足其自身的需要。为更好的处理和完成全局事务, 高层的分布式数据库管理系统也是必不可少的。只有将软件和硬件有效的结合起来, 才能真正的发挥其作用。

1.3 数据

数据是分布式数据库基本的组成部分, 根据其存放形式可以将数据分为局部数据与全局数据两大类。局部数据是以局部数据库的形式存放, 全局数据是以全局数据库的形式存放。

1.4 人员

分布式数据库需要很多的人员, 只有多层次的才能满足分布式数据库需要, 各个环节都需要人员来完成, 各个层次的人员要进行分工合作, 通过共同的努力来实现数据库查询的需要。

2 分布式数据库具有的特征

分布式数据库属于数据集合, 从物理的角度上来看分布式数据库是分散的, 但是从逻辑上来看分布式数据库又是统一的。尽管分布式数据库将各自数据分布在多个站点, 但是其是基于一个统一的逻辑框架上面的。分布式数据库具有这么几个方面的特征:

2.1 数据分布性

分布式数据库系统里面的数据分散被分散在各个站点上面, 各个站点之间是通过计算机网络来进行连接的, 因此分布式数据库的数据具有分布性的特征。

2.2 逻辑关联性

尽管分布式数据库的数据分布在不同的站点, 但是其从逻辑上来看属于是一个统一的整体, 所有的数据都存在于一个统一的逻辑框架上面。

2.3 站点自治性

分布式数据库的不同站点属于独立的数据库系统, 每一个站点都有属于其自身的数据库, 也有属于自身的软件和硬件, 因此其具有非常强的自治性。

3 分布式数据库查询的层次结构

分布式数据库查询处理有查询分解、数据本地化、全局优化、局部优化四个层次。

4 分布式数据库查询优化办法

关于对分布式数据库查询优化可以采取的方式可以从下面几个具体方面来进行。

4.1 优化索引来提升查询速度

数据索引对分布式数据库查询发挥着非常重要的作, 对索引进行优化可以有效的提升查询速度, 使得查询需要的时间大大缩短。对索引进行优化需要遵循这么几个方面的原则:对于没有指定为外键, 但是实际上连接又非常频繁的地方设置索引, 在不常用于连接的字段可以由DBMS自动生成索引;在需要频繁进行排序和分组操作的列设置索引;在排序列数较多时可以设置复合索引。

4.2 避免和简化排序操作

大型数据表如果要是进行排序会对数据库查询速度有着非常大的影响, 为了提高数据库的查询速度, 在可能的情况下要尽可能避免对大型数表进行排序。通过索引根据一定的次数输出这种方法就可以在很大程度上来代替排序操作, 既实现了排序操作的目标, 又对数据查询速度没有太大的影响。索引增加对排序操作的避免有重要的作用, 还可以对数据表进行合并, 使得排序的次数降低, 当然这些操作必须在适当的范围内, 不能因为单纯避免排序而成为一种累赘。在实际中有时候排序操作是无法避免的, 如果要是排序操作无法避免, 那么要采取相应的措施来简化排序操作, 可以适当的去缩小排序范围, 适当排序的部分被简化, 那么对数据库查询速度的影响会降到最低。

4.3 尽量避免顺序存取大型数据表

嵌套查询的顺序存取会对降低数据查询效率, 使得数据查询的速度受到很大的影响, 为了避免分布式数据库查询效率受到影响, 要尽量避免顺序存取大型数据表。通过对存在连接的列建立索引以及利用索引路径处理查询的办法来避免顺序存取大型数据表, 这样就可以大大降低嵌套查询的顺序存取造成的影响。

4.4 构建临时表

对数据表的子集重新排序, 并且构建临时数据表会使得分布式数据库查询效率得到有效的提升。

4.5 简化嵌套层次

为提升分布式数据库查询效率, 那些困难的正规表达式和相关子查询要尽量避免, 查询嵌套层次要做到优化, 嵌套层次要尽量的去简化。嵌套层次多的时候就会出现重复操作的现象, 为避免主查询与子查询有不必要的重复, 要尽量减少主查询里面的子查询。

5 结论

计算机与网络技术的发展, 推动着分布式数据库系统也在快速发展。在对分布式数据库进行查询的时候, 因为物理分布的不同会大大增加数据的查询难度。分布式数据库查询优化对数据库的性能高低有直接的影响, 采取不同的查询方式, 其效率有很大的差别, 采取有效的数据库查询方式可以使得查询效率明显提升, 因此本论文提出的优化方式具有很重要的现实意义。

摘要：本文对分布式数据库的基本概念进行阐述以后, 提出了相应的优化方式, 采取这些优化办法会使得分布式数据库查询效率得到有效提升。

关键词：分布式数据库,查询,优化

参考文献

[1]赵荣.分布式数据库查询优化方法[J].科技视界, 2013 (03) .

[2]任诗兵, 邹海.基于关系代数的分布式数据库查询优化[J].福建电脑, 2008 (02) .

分布式数据库优化 篇2

第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协作，帮 助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你可以通过一些主键来组织海量数据，并实现高效的 查询。Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。

项目主页：www.open-open.com/lib/view/home/1339253305568

分布式数据库系统的安全策略研究 篇3

【关键词】分布式数据库系统：安全策略：网络

【中图分类号】TP313 【文献标识码】A 【文章编号】1672-5158（2013）04-0403-01

0、引言

分布式数据库系统（Distributed Database System，DDBS）是指物理上分布于多个网络站点而逻辑上统一的数据库系统。分布式数据库系统逻辑上属于同一系统，而地址上它们又分散在用计算机网络连接的各个场地上，并统一由分布式数据库管理系统（DDBMS）管理。随着Internet的高速发展，分布式数据库系统也得到了迅猛发展，同时也对分布式数据库系统的安全性提出了挑战。数据库系统在为用户提供完善方便的信息和数据服务，实现数据信息共享的同时，还要保证合法用户对数据的有效存储，拒绝非法用户的攻击企图。

1、分布式数据库系统

分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的若干个站（节点）连接起来，组成统一的数据库系统。这些站通过网络互联在一起，每个站都拥有各自的数据库、中央处理机以及局部数据库管理系统，因此分布式数据库系统可以看作若干个集中式数据库系统的联合，是计算机网络与数据库系统的有机结合，它具有物理分布性、逻辑整体性、站点自治性等特点。

2、分布式数据库系统的不安全因素

虽然现有的数据库软件在保障数据安全方面可以提供不同程度的服务，但再优秀的软件也难以防范计算机环境中的所有不安全因素，或多或少存在缺陷，因此正确识别不安全因素所带来的威胁对于抵抗网络攻击和防止数据侵害是至关重要的。分布式数据库系统主要具有以下不安全因素：窃听、重发攻击、假冒攻击、越权攻击、迂回攻击。

3、分布式数据库系统的安全策略

3.1 身份验证

为了防止各种假冒攻击，在进行数据访问操作前，需要在用户和数据库服务器间进行双向身份验证。识别系统授权的合法用户，防止非法用户访问数据库系统，从而进一步判断该用户的访问权限。另外，由于分布式数据库系统的服务器之间要进行数据传输、分配事物处理等活动，因此在服务器与服务器之间也要进行相互身份验证。

3.2 保密通信

为了防止黑客在网络信道上监听窃取数据、对抗报文重发攻击，可以采用保密通信技术。即在通信双方之间建立保密信道，对数据进行加密传输。应用于各协议层的加密技术有：加密机，加密卡；IPSEC协议规范的安全路由器和通信软件；安全套接字协议（SSL）；安全代理软件等。

3.3 访问控制

在一般的数据库管理系统中，为了抗击越权攻击，任何用户不能直接操作数据库数据。用户的数据访问请求要先发送到访问控制模块进行审查，然后系统的访问控制模块代理有访问权限的用户区完成相应的数据操作。这个过程是系统根据合适的访问控制模型和机制对用户的数据访问请求进行是否授权检查，通过检查的请求才能被系统执行相应的操作。访问控制模型主要有自主访问授权控制和强制访问授权控制；常见的访问控制机制有用户验证机制、主存隔离访控机制、数据库内部的访控机制等。

3.4 库文加密

为了对抗黑客利用网络协议、操作系统安全漏洞绕过数据库的安全机制而直接访问数据库文件，可以采用库文加密技术。库文加密是将需要保护的数据在密钥的作用下按照一定的加密算法变换成他人无法识别和伪造的密码文。只需要选择具有一定强度的加密算法并保管好密钥，就可以有效提高分布式数据库系统中重要数据的安全性。

3.4.1 加密算法选择

系统应同时提供几种不同安全强度、速度的加/解密算法，这样用户可以根据数据对象的重要性程度和访问速度要求来设置适当的算法。

3.4.2 加密粒度

系统应能调整被加密数据时象的粒度，这样能够在保证重要数据对象安全性的同时提高访问速度。例如一个关系中有某个字段或记录的数据重要，那么就可以针对该字段、记录进行加密，而没有必要加密整个关系。

3.4.3 密文索引

数据库的加密不能过分降低对数据库的访问速度，加快访问速度的关键是加快检索的速度。对加密的数据巧妙地建立加密的密文索引，就可以利用索引进行密文的快速检索。

3.4.4 加密方式

对于依赖于操作系统进行数据管理（包括文件管理）的数据管理系统来说，库外加密是大多数数据库管理系统采取的策略。库外加密方式的优点是，对数据库管理系统DBMS的特殊要求较少，实现时只要增加一个中间层次负责加解密数据即可。相对于其它加密方式，密钥的管理也简单得多，与操作系统内部文件加密的密钥管理基本相同。但是，由于数据在查找时必须全部进行解密操作，因此往往需要付出较大的时空代价。此外，在实现数据完整性约束条件时，数据字典中的数据和数据库内的数据的同步问题也需要额的代价，必须在算法或系统内部处理上加以安排。为了提高时空效率，可以采用库内加密的方式。实现方法是在数据库的内模式和存储模式之间增加一个加密层负责加解密数据。库内加密依赖于数据库管理系统，实现复杂，但安全性更高。不论采用哪种加密方式，均可以用硬件加密的方式来实现。硬件加密主要解决静态数据加密问题。总之，分布式数据库系统加密的主要特点是字段加密、多级密钥结构和密钥动态管理等。

4、结束语

分布式数据库查询优化方法 篇4

近年来, 随着计算机网络和数据库技术的发展, 对分布式数据库的应用越来越广泛;随着应用不断扩大, 数据的查询也越来越复杂, 对查询的效率要求也越来越高, 因此查询处理成为分布式数据库系统中的一个关键性的问题[1]。在分布式数据库中, 由于数据的分布与冗余, 使得查询处理中一般需要站点间的数据传递及通信费用, 成为查询优化的主要矛盾;另一方面, 数据的分布与冗余也增加了查询的并发处理的可能性, 从而可以缩短查询处理的响应时间, 提高处理速度。总之, 分布式查询的规模与优化的因素, 都与集中式查询优化不同, 因此许多数据库专家学者致力于研究分布式数据库查询优化技术这一重要课题, 并且己经在这一领域作了大量的工作, 也找到了规律, 包括一些大家公认的经典算法;然而由于分布式数据库本身的灵活性, 要想设计一个算法对于各种情况都是最优的几乎不太现实, 只能说设计一个较优的优化算法, 它可以解决某一类型的问题[2]。分布式数据库中查询优化是一项复杂问题, 已经被证明属于NP完全问题, 至今都没有得到彻底地解决, 里面尚有许多问题值得研究和探讨。

1 分布式查询优化的目标

分布式数据库系统的查询优化有两种不同的目标:一种目标, 是以总代价最小为标准;另一种目标, 是以查询响应时间最短为标准, 这一点在分布式数据库系统中具有重要的意义。因为分布式数据库系统是由多台计算机组成的系统, 数据的分布和冗余也增加了查询的并行处理的可能性, 从而可以缩减查询处理的响应时间, 加快查询处理速度。在分布式查询优化中也常同时使用这两种标准, 根据系统应用的不同, 一种作为主要标准, 另一种作为辅助标准[3]。在分布式数据库系统中, 查询优化包括两个内容:查询策略优化和局部处理优化, 而查询策略优化尤为重要。分布式查询策略的优劣将直接影响计算机网络资源耗费的多少。

在集中式数据库系统中, 查询优化的目的可以总结为以下三个方面:

1) 为每个用户查询寻求总代价最小的执行策略;

2) 总代价是以查询处理期间的CPU代价和I/O代价来衡量的;

3) 总代价最小就意味着查询的响应时间最短。

从上可看出, 在集中式数据库系统中, 一个查询策略的选择是以执行查询的预期代价为依据的。由于系统大都运行在单个处理器的计算机上, 所以查询执行总代价为CPU代价加I/O代价[4]。而在分布式数据库系统中, 由于数据的分布在多个不同的站点上, 使得查询处理中需要考虑站点间传输数据的通信费用, 所以除了考虑CPU代价和I/O代价之外, 还应该包括数据在网络上的传输代价。所以在分布式数据库系统中, 常以两种不同的目标来考虑查询优化:以总代价最小为标准和以每个查询的响应时间最短为标准。这样分布式查询优化可用以下四个参数来衡量:

1) CPU代价, 即占用的CPU处理周期, 记做Ccpu;

2) I/O代价, 记做Ci/o;

3) 通信代价, 记做Cmsg;

4) 传输的数据代价, 记做Cbt。

2 分布式查询优化的基本方法

在分布式查询处理技术中, 查询优化有两种基本方法:第一, 是查询转化, 即以不同的顺序执行关系操作, 如连接和投影操作:第二, 是查询映射, 即使用一系列高效的算法来存取各种设备和实现关系操作。查询转化是指关系运算集合运算顺序的改变, 对查询的性能有重要影响[5]。在多站点下, 查询转化可以减少通信量, 从而达到减少查询代价的目的[6]。查询映射则是针对关系的存取方法和操作的执行算法进行决策。

2.1 查询转化的处理过程

查询转化处理一般经历三个阶段:

1) 建立关系代数表达式。根据查询问题, 编写关系代数表达式。

2) 建立查询语法树。根据关系代数表达式, 生成查询语法树。

3) 全局优化。按照优化策略, 对查询语法树进行全局优化。

优化策略:查询优化策略按以下步骤进行:

1) 将关系代数表达式转换成选择串接形式。

2) 尽可能把选择和投影操作移近树的叶端, 即尽可能早地执行选择和投影策略, 以得到较小的中间关系, 减少运算量。

3) 把选择和投影合并成单个选择、单个投影或一个选择后跟一个投影。使多个选择和投影能同时执行或在一次扫描中同时完成。

4) 将上述步骤得到的查询语法树的内结点分组。每个二元运算结点与其直接祖先的一元结点分为一组。如果它的子孙结点一直到叶结点都是一元运算符, 则并入该组。

5) 生成一个程序, 每一组结点的计算是程序中的一步, 各步的顺序是任意的, 只要保证任何一组不会在它的子孙组之前计算。

2.2 查询优化的三种典型算法

2.2.1 INGRES算法

INGRES算法是动态的优化算法。这个算法主要分为两个步骤:

(1) 将含有多个变量的查询分解为一系列的只含有一个变量的单关系查询。

(2) 通过执行其每一个单关系查询:用启发式的方法选择一个初始化的执行计划, 通过中间关系的大小来确定查询执行的顺序。

首先来看分解的详细过程:用一系列的单关系查询qi取代n个变量的查询q, 就比如:q1->q2->…->qn, 其中qi使用qi-1的执行结果。

它主要有两个基本的动作:分离与元组替换。

分离:查询q分解成q’和q’’, 当q’和q’’有一个共同的量在q’的结果里。

查询分解算法:

元组替换:用元组的实际值来替换并且简化查询, q (R1, R2, …Rn) 被{q’ (t1i, R2, …, Rn) , t1i∈R1}

2.2.2 System R*算法

System R*算法是源于美国CA州的IBN San Jose Research Laboratory开发System R*系统, System R*系统是采用直接连接作为查询处理策略的分布式数据库系统, 其最重要的目标是提供地点自主权。当每个地点既能控制由另一个地点上对其数据的访问, 也能在不受任何其它地点限制的条件下处理自己的数据时, 也就实现了地点自主权。R*系统完全实现了第一个目标。但它仅仅是部分地实现了第二个目标。

R*系统由3个主要部分组成:局部DBMS、提供信息传输的数据通信部分和能协调实现多地点事务处理的事务处理管理程序。局部DBMS可分为两个部分:存储系统 (用于数据的存储与检索) 和数据库语言处理器 (用于将高级SQL语句转换成存储系统上适用的操作命令) 。R*方案中采用的存储系统叫RSS*, 是以系统R的存储系统为基础。R*各地点通过CICS的系统间通信 (ISC) 设备进行通信。每一个R*地点都在一个CICS地址空间运行, 而CICS控制终端I/O和信息通信。假定该通信是不可靠的 (不能保证所传输的信息总能送到) , 但可以假定所送到的信息是正确的、不重复的, 并以与发送它们的相同次序接收。一个应用程序在其局部地点执行所有对R*系统的数据库访问请求。所有地点间的通信均在不同地点的R*系统之间进行。因为是R*、而不是应用程序负责为分布式数据定位。这样, 在R*环境中不需要远程应用程序。应用地点的事务处理管理程序, 把未包括在明确定义的事务处理中的第一个SQL语句看作是事务处理的开始, 隐含地执行一个开始一一事务处理。当用户完成一次会话后, 就假定一个隐含的结束一一事务处理, 并提交所有已经完成的工作。

R*系统的另一个重要问题是位置透明性 (用户并不知道数据的实际位置) 。这样, 从程序员的观点来看, 使用R*系统与使用集中式系统基本一样。虽然在R*系统中引入的附加语言特性极少, 但R*系统的主要成就是在分布式环境中提供了SQL/DS的大多数功能。在R*系统中, SQL查询既可以静态地进行编译 (n个执行编译一次) , 也可以动态地进行编译 (在单个执行前立即进行编译) 。前一种情况用于重复查询;后一种情况用于预先不知道的查询。在R方案中, 重复查询的重要性比预先不知道的查询高得多。在这两种情况下, 非过程型SQL语句被转换成访问计划, 该计划规定访问关系的次序进行访问的地点, 完成每一个操作的方法及在RSS*中检索或处理元组的访问路由。

2.2.3 SDD-1算法

SDD-1算法由两部分组成:基本算法和后优化。基本算法是根据评估所缩减程序的费用, 效率, 收益估算等几个因素, 给出全部的半连接缩减程序集, 决定一个最有益的执行策略, 但效率不一定理想。主要包括三个基本步骤:

(1) 初始化:已准备好从查询数转换的优化模型, 且所有关系已完成局部缩减。

(2) 优化:根据初始条件, 构造可能的半连接缩减程序;按半连接缩减程序的静态特性表, 分别计算其代价和产生的益处, 从其中选取一个半连接程序, 设为S;以S完成缩减以后, 又用重新产生的一组新的静态特性表再进行计算, 再从其中选取一个合适的半连接程序, 但每一个都只做一次;循环下去, 直到没有半连接缩减程序为止。

(3) 结束:以最后一次缩减关系的静态特性表为基础, 进行费用计算, 选择场地。后优化是将基本算法得到的解进行修正, 已得到更合理的执行策略。包括两种修正:一种, 是如果最后一次半连接程序缩减关系的所在场地恰好是被选中的执行场地, 则最后一次半连接可以取消;另一种, 修正是在基本算法的流程图进行修正, 因为某一个半连接缩减程序的代价可能很高, 就必须修正半连接的操作序。

SDD-l算法:

SDD-1算法支持关系数据模型。全局关系能以两个步骤分段 (首先水平分段, 然后垂直分段) , 能以冗余方式存储各段。SDD-1能提供段存储透明性 (用户不知道段和段的分配) 利用数据语言, 即适用于数据计算机的高级过程语言实现关系控制。

SDD-1算法的体系结构是基于三个相对独立的虚拟机:数据模块、事务处理模块和可靠的网络。这种体系结构允许把分布式数据库管理问题分成三个系统, 以限制相互的影响。

SDD-1算法存在一个严重问题, 那就是它的算法的复杂性。当元组数目很大时, 进行查询搜索的代价进迅速增加, 使系统无法承受。当然, 对于这种搜索模式, 可以找到最佳的路经去进行查询。为此, 我们在此基础上对它进行改进, 降低它的时间复杂度。在人工智能里面的A*算法可以引入到SDD-1算法中来, 当元组数目不是很大时, 可以采用A’算法的思想对它进行查询优化, 在此基础上能找到最优的方法去进行路径搜索和优化, 而当元组数目非常多的时候, 还是用以前的方法。

3 结束语

分布式数据库系统的查询处理是用户与分布式数据库系统的接口, 查询处理策略的好坏直接影响到系统的执行速度。本文通过实例重点讨论了在分布式数据库系统中应用优化策略, 减少运算数据量和网络资源的耗费, 提高了查询效率。至于对于给定的查询, 应该怎样选择好的查询策略, 进行分布式查询优化, 我们可以根据已有的优化算法和分析各种查询策略的特点来选择一个较好的查询策略。

摘要：本文介绍分布式数据库系统查询优化的目标、策略, 着重讨论了一种分布式数据库系统查询优化策略是如何影响查询的, 并对分布式数据库系统的查询优化的典型方法进行了分析、总结。分布式数据库系统由于数据的分布和冗余使得分布式查询处理增加了许多新的内容和复杂性, 对于一个给定的查询, 通常会有多种可能的策略, 查询优化就是从这许多策略中找出最有效查询计划的一种处理过程。并针对分布式数据库系统的查询优化, 讨论了三个典型的算法:INGRES算法、SystemR*算法、SDD-1算法。

关键词：分布式数据库,分布式查询,查询优化,查询处理策略,算法

参考文献

[1]徐俊刚, 邵佩英.分布式数据库系统及其应用[M].北京:科学出版社, 2012, 4.

[2]申德荣, 于戈.分布式数据库系统原理与应用[M].北京:机械工业出版社, 2011, 8.

[3]王丽艳, 郑先锋, 刘亮.分布式数据库系统及其应用[M].北京:机械工业出版社, 2013, 2.

[4]吴溥峰, 张玉清.数据库安全综述[J].计算机工程, 2006, 32 (12) .

[5]O’NeilP, O’NeilE.数据库原理、编程与性能[M].北京:机械工业出版社, 2002.

分布式数据库优化 篇5

Mnesia试图解决典型电信系统的数据管理问题，具备一些在传统数据库中通常找不到的特性。电信应用有许多不同于传统数据库管理系统的需求。用Erlang语言实现的应用程序需要具备宽广的特性，这是传统数据库管理系统无法满足的。

Mnesia的设计要求如下：

快速实时的键(key)/值(value)查找

主要用于运营和维护的非实时复杂查询

由于分布式应用导致的分布式数据

高容错

动态重配置

复杂对象

Mnesia与其它大部分数据库管理系统的区别在于其是被设计用于解决电信应用中的典型数据管 理问题，

因此，Mnesia有许多传统数据库的概念，如事务和查询，也有许多电信应用数据管理系统的概念，如高速实时操作，可配置的容错等级(在复制的意 义上)以及不停机进行重新配置的能力等。Mnesia与Erlang编程语言是紧耦合的，使得Erlang几乎成为数据库编程语言。其最大的好处是在操作 数据时由于数据库与编程语言所用的数据格式不同而带来的阻抗失配问题完全消失。

介绍内容来自百度百科

项目主页：www.open-open.com/lib/view/home/1331130157624

分布式数据库优化 篇6

关键词：分布式数据库 安全性 防护策略

【中图分类号】TP311.13

分布式数据库系统（DDBS）是数据库技术和网络技术两者相互渗透和有机结合的结果。涉及数据库基本理论和网络通信理论。分布式数据库由一组数据组成，这些数据在物理上分布在计算机网络的不同节点上，逻辑上是属于同一个系统。这些节点由通讯网络联接在一起，每个节点都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。分布式数据库存在于开放的网络环境中，这就对安全性以及防护策略提出了越来越高的要求。本文针对网络环境中分布式数据库的不安全因素以及相应的防护策略进行探讨。

一、分布式数据库系统的特点

1、数据独立性。数据独立性是数据库方法追求的主要目标之一，在分布式数据库中，数据独立性这一特点更加重要。并且有更多的内容，数据独立性亦称分布透明性，分布透明性的优点就是很明显，有了分布透明性，用户的应用程序书写起来就如同数据没有分布一样，当数据从一个场地移动到另一个场地时不必改写应用程序，当增加某些数据的重复副本时也不必改写应用程序，数据分布信息系统存储在数据字典中，用户对非本地数据的请求由系统根据字典予以解释、转换、传送。

2、集中与自治相结合的控制系统。数据库是用户共享的资源，分布式数据库系统常常采用集中和自治相结合的控制结构，同时，系统又没有集中控制机制，协调各个局部的工作，执行全局应用。

3、全局的一致性、可串行性与可恢复性。分布式数据库中各个局部数据库应满足集中式数据库的一致性、可串行性和可恢复性。因此在分布式数据库系统中一个业务可能由不同场地上的几个操作组成。

二、分布式数据在库的安全性。

在开发分布式数据库系统中，保证数据库中数据安全是一项非常重要的工作。一个好的分布式数据库，必须能确保系统数据的完整性、有效性、安全性。防止未授权用户对其访问，跟踪用户对其访问的情况，控制授权用户仅能对自己所拥有权限的子系统和数据进行访问，使系统免于因各种破坏而造成数据的丢失和窃取，这也是分布式数据库系统安全管理必须要解决的问题。一般情况下，分布式数据库面临三大安全问题：

1、保障数据库数据的可靠性、完整性，预防和减少因为软、硬件系统误差所造成的数据库恶性破坏。

2、来自于本机或者网络上的人为攻击，也就是黑客攻击，当前网络黑客攻击的方式主要包括：窃听、假冒攻击、破译密文、越权攻击、以及重发攻击等几种主要的形式。攻击者通过不断的发送大量的报文来使得客户计算机或者是服务器来使得通信线路端口发送堵塞，然后冒充被攻击的客户或者是服务器来对分布式数据库系统当中的其他正常运行的站点进行骚扰，进行非法访问，从而来获取其中的机密数据信息。

3、数据库管理系统自身的安全脆弱性，现阶段系统的安全与操作系统的安全是相互配套的，由于数据库管理系统所存在的操作系统的结构多样，一个可以打补丁和可渗透的操作系统是难以从根本上解决安全问题的，因此，数据库的管理系统也是脆弱的。

4、信息流动风险增加。分布式数据库系统是基于整个系统的数据共享而建立起来的，而这些数据一般都不是由同一个用户加以存储的，而是分布于各个不同的站点之中，且同一个数据对各个不同用户所要求的安全等级不一样，而系统设置的自主访问控制授权机制将使得访问者可能自主的将其访问权限间接或者直接的转交给无法访问权限的用户，增加了信息流动的风险。

三、针对以上问题所采取的防护策略

1、加强身份验证。加强身份验证主要是针对攻击者采取的针对性措施。它主要是在用户提出数据访问时，在用户和数据库系统之间设置一道程序进行身份验证，以确保用户真实身份的合法性，之后再对用户权限进行定义与设置，确保其对有限资源进行访问。

2、加强通信保密。在系统内部进行通信的双方之间建立起一道保密同道，在完成了信息访问者的身份确认，并确认信息访问者的权限之后，就可以授权访问者获取数据了。但是，为了防止通信过程中出现数据窃取以及重发等问题，还应该在通信双方之间建立起通信保密同道，对两者之间进行的数据传输进行加密处理。

3、访问控制与审计。在对数据库进行管理的过程中，为了抵御黑客采取越权攻击的方式，在对其管理进行设置时就应采用所有用户都不可以对数据库中存储的数据进行直接操作的方式，而是通过在系统中嵌入一个对访问进行控制的模块，当用户发出数据访问的请求后，首先将其提交给模块，然后由这个模块来进行对应的数据访问操作，这样就可以有效的防范分布式数据库系统被黑客攻击。

4、对存储数据进行加密。为了防止攻击者利用网络协议以及数据库自身存在的漏洞来窃取存储在其中的数据库文件，应该对其中的数据进行加密处理，并保证加密算法的加密强度，尽量减小被攻击的威胁程度。

5、故障恢复。虽然有很多方式可以保护分布式數据库系统的安全，但是由于一些软件、硬件本身的错误以及黑客攻击和操作失误等造成的不安全因素不可避免，因此分布式数据库系统需要具备系统故障修复的能力，将数据库系统的错误恢复到一个已知的正确状态中。

四、结束语

浅谈分布式数据库系统查询优化 篇7

分布式数据库系统(Distributed Database Management System,DDBMS)是地理上分散而逻辑上集中的数据库系统。即通过计算机网络将地理上分散的各局域结点连接起来共同组成一个逻辑上统一的大数据库系统。因此可以说，分布式数据库系统是计算机网络技术和数据库技术的结合的产物。

分布式数据库系统的查询优化，就是要寻找执行代价(费用和时间)最小的查询执行策略，使系统执行效率达到最高。它包括局部执行代价的优化和网络传输代价的优化。其中局部执行代价：主要指输入/输出次数(I/O代价)及CPU处理代价。网络传输代价：主要指传输启动代价和数据传输代价。

2 查询优化的必要性

2.1 局部执行策略优化

我们通过一个例子来说明局部执行策略优化的必要性。

例2.1.1设有一供应关系数据库，有供应商和供应两关系，如下：

下面进行局部代价计算(不考虑CPU代价)。

首先我们假定：在内存中，同时可存放5块SUPPLIER元组和1块SUPPLY元组，其中1个内存块可以装10个SUPPLIER元组或100个SUPPLY元组。另假定SUPPLIER有1000个元组，SUPPLY有10000个元组，其中PNO=100的有50个元组。假定计算机每秒可读写20块，而数据只有读到内存才能进行操作。

计算Q1的I/O代价(计算广义笛卡尔积代价)：

读取总块数为：1000÷10+[1000÷(10×5)]×(10000÷100)=2100;需时间t1=2100/20=105s;

按条件：笛卡尔积计算后的元组个数为：103×104=107，连接后的中间结果内存放不下，需暂时写到外存，若每块可装10个完成笛卡尔积后的元组，则写这些元组需：t2=(107÷10)/20=5×104s

进行选择操作：读回需t3=5×104s，假设选择后剩50个元组，均可放在内存进行投影操作。

因此Q1查询共花费：t=t1+t2+t3=105+2×5×104≈105s≈28小时。

计算Q2的I/O代价：

计算对SUPPLY做选择运算的代价,需读SUPPLY到内存进行选择运算,读SUPPLY块数为:10000/100=100,花费为:t1=100/20=5s。

选择结果为50个SC元组，均可放在内存。

计算和SUPPLIER自然连接的代价,需读SUPPLIER到内存进行连接运算,读SUPPLIER块数为:1000/10=100,花费为:t2=100/20=5s。

连接结果为50个元组，均可放在内存进行投影运算。

因此Q2总花费为：t=t1+t2=5+5=10s。

从上述两种策略看，虽然都能实现所要完成的功能，但两种实现方法所须的代价却相差很大。

2.2 网络传输优化

我们依然通过一个简单例子来说明网络传输优化的必要性。

例2.2.1有全局关系EMP{ENO,ENAME,BIRTH,SALARY,DNO}，分别代表(主键)雇员编号、雇员姓名、出生日期、工资和部门号，及全局关系DEPT{DNO,DNAME}，分别代表(主键)部门号和门名称。

查询要求：查询每个雇员的姓名及所在单位。

则：1)SQL语句：SELECT ENAME,DNAME FROM EMP,DEPT WHERE EMP.DNO=DEPT.DNO;

2)关系表达式：∏ENAME,DNAME(EMP∞DEPT)。

选择策略(设结果为R，以传输代价为主)。

假设：

1)EMP：元组数：10000，元组大小：100B，关系大小：100×10000=1000KB。

2)DEPT：元组数：100，元组大小：35B，关系大小：35×100=3.5KB。

3)结果元组大小40B,S3为查询场地，结果关系大小：40×10000=400KB。

存在三个场地，S1、S2和S3。如图1所示。

策略1:S3为执行场地，则需传输EMP、DEPT，传输量=1000K+3.5K=1003.5K。

策略2:S2为执行场地，则需传输EMP到S2，结果R传输到S3。传输量=1000K+400K=1400K。

策略3:S1为执行场地，则需传输DEPT到S1，结果R传输到S3。传输量=3.5K+400K=403.5K。

从上面三个策略看，选择不同的执行场地，传输代价差别很大。

分布式系统是多用户、多应用需求的复杂任务，那么采用不同的实现策略会相差更大，将直接影响整个系统整体性能。因此，进行分布式数据库系统的查询优化是分布式数据库系统必须重视的一个环节。

3 查询优化的方法

3.1 基于查询树的等价变换

基于查询树的等价变换，是将用户请求利用查询树来进行表示，然后再逐步对查询树进行等价变换，最终得到最优的查询策略。

查询树表示方法规则为，在查询树中，叶子表示关系，中间节点表示运算，前序遍历关系表示运算次序。

3.1.1 将用户请求构成的查询树进行等价变换，得到全局优化后的查询树

变换通用准则为：1)尽可能将一元运算移到查询树的底部(树叶部分)，使之优先执行一元运算。2)利用一元运算的重复律，缩减每一关系，以减少关系尺寸，降低网络传输量和I/O大小。

在这里我们依然以例2.1.1进行说明。

查询要求：找出AREA在"北方"且PNO为100号零件的供应商的信息。

SQL查询语句:SELECT SNO,SNAME FROM SUPPLIER,SUPPLY WHERE AREA="北方"AND PNO=100 AND SUPPLIER.SNO=SUPPLY.SNO

等价的关系表达式：

Q1：∏SNO,SNAMEσAREA="北方"σPNO=100(SUPPLIER∞SUPPLY)

查询树如图2。

利用变换规则进行等价变换后得到最终优化后的查询树Q2如图3所示。

3.1.2 利用全局关系与其片段关系的等价关系，将全局查询中的全局关系替换为对片段关系，得到对应于片段查询的查询树，经过等价变换，得到优化后的片段查询树

全局查询与片段查询对应的等价关系为：

1)对于全局关系R的水平分片R1、R2、…、Rn，表示为：R=R1∪R2∪…∪Rn。

2)对于全局关系R的垂直分片R1、R2、…、Rn，表示为：R=R1∞R2∞…∞Rn。

片段查询优化准则：1)对于一元运算，根据一元运算的重复律，将叶子节点之前的选择运算作用于片段，如果不满足片段的限定条件，则置为空关系。2)对于联接运算的树，若联接条件不满足，则将其置为空关系。3)在查询树中，将联接运算(∞)下移到并运算(∪)之前执行。4)消去不影响查询运算的垂直片段。

3.2 基于半联接技术的分布式查询优化

半联接技术的优化就是通过减少联接操作的操作数，来降低传输费用的优化技术。

半联接优化算法原理如下：

输入信息：位于不同场地上的两个关系R和S;输出信息：实现R∞S(R.A=S.B);算法过程(设S的尺寸小于R):1)在S所在场地上计算S'=∏B(S),2)传送S'到R场地，3)在R场地上计算R'=R∞S'=R∝S,4)将R'传到S所在场地，5)在S所在场地上计算

网络传输代价的比较：

假设：关系R和S分别在不同的场地上，C0为启动代价，C1为单位传输代价，设：在S所在的场地上执行。

则传输关系R实现R∞S的代价为C=C0+C1*Size(R)。

采用半联接的传输代价C∝=CS'+CR'。=2C0+C1*(Size(S')+Size(R'))。

因此如果有：C0/C1+Size(S')+Size(R')≤Size(R)，则可用半联接技术来降低传输费用。

合理的采用半联接技术可以有效控制传输代价。

4 查询优化综合分析

那么现在的问题是，在设计查询执行策略时，是不是一定要寻找执行代价(费用和时间)最小的查询执行策略呢?我认为，软件系统的发展是以硬件系统的发展为基础的，不同阶段的硬件基础决定了相应的软件策略，我们之所以设计各种优化方法，就是因为我们的硬件条件没有达到我们需要的理想状态，所以我们需要软件的优化来弥补硬件的不足。我们知道优化的算法肯定不是最简单的算法，那么随着硬件条件的变化，我们在考虑执行代价的同时也要考虑算法的便捷度，在执行代价和便捷度之间取最佳执行方案，不能一味追求代价最小，做一些华而不实的优化策略。

这里有几个假设：1)假设我们的服务器的读取速度和处理速度可以达到无限快，那么我们就不用考虑局部处理优化。2)假设我们的网络带宽可以满足任何传输需求，那么我们就不需要进行网络传输优化。3)假设我们的存储器无限大，我们就可以存储任何信息，那么就不需要根据不同需求程度进行删减了。

如果满足上面3个假设，会得出什么结论呢?我们会发现不需要研究分布式数据库系统了，因为谁都知道分布式数据库的运行维护代价和出错频率要远远大于集中式数据库。即使达不到上面的理想状态，随着硬件的发展，软件简单化也必然是一种发展趋势。

或许大家觉得这是无稽之谈，我们回顾一下计算机软件的发展史我们会发现，早在计算机发展初期，机器处理速度非常低，内存用于数据交换的容量非常小，作为一个程序员，大部分精力都用在了研究算法上，写的程序尽可能简洁高效，在内存管理上更是倍加谨慎，不会轻易浪费一个字节的内存。现在又怎么样了呢?仅仅过了几十年时间，随便一台家用计算机可以有几GHZ的处理器以及几GB的内存，现在谁会去在乎一个程序是循环100次还是10000次，会注意一个程序是占用1KB内存还是1MB内存?我们现在关注的是程序的结构框架，关注的是实现的结果，对于具体算法实现过程往往很少在意。我们再回顾一个分布式数据库系统的典型实例———银行通存通兑系统，早在几年前，几乎每个大中城市都会有各自的数据库分片(副本节点)，用户的一个存兑请求都作为一个事务在本地数据库分片上先操作，然后各个数据库分片(副本节点)之间会在一个约定的时间里，按照一定的更新算法进行传播更新，由于其间需要相互更新的数据量很大，而服务器性能不高，网络带宽也不够，因此我们的一个跨省市存款请求往往需要几天的时间才能完成。而现在由于服务器性能和网络带宽都显著提高了，很多数据库分片(副本节点)都已经取消了或者变成了全复制副本节点，通过提高硬件的性能来简化分布式数据库系统的组织结构，从而简化了软件系统的复杂程度，使得各种存兑操作都变得非常方便快捷。

因为硬件条件变化了，我们关注的点也变化了，当我们的硬件条件可以允许适当的浪费的时候，我们就会进一步考虑便捷性了。

5 结论

分布式数据库系统的查询优化，就是要寻找执行代价(费用和时间)最小的查询执行策略，使系统执行效率达到最高，优化的思想和方法在分布式数据库系统中必将得到广泛的应用和发展，优化的具体策略会随着硬件条件的发展而发展，从而实现既高效又便捷的分布式数据库系统。

参考文献

[1]邵佩英.分布式数据库系统及其应用[M].2版.北京:科学出版社,2005.

[2]郑振楣,于戈.分布式数据库[M].北京:科学出版社,1998.

[3]贾焰,王志英,韩伟红,等.分布式数据库技术[M].北京:国防工业出版社,2001.

[4]萨师煊,王珊.数据库系统概论[M].3版.高等教育出版社,2000.

分布式数据库优化 篇8

由于数据库应用需求快速发展,特别是计算机网络和数字通信技术的飞速发展,在20世纪70年代中期人们开始对分布式数据库系统进行研究。分布式数据库是数据库技术和网络技术两者相互渗透和有机结合的结果,是数据库领域中的重要分支,并且已经成为了计算机技术最活跃的研究领域之一。分布式数据库系统中的数据库被分布在不同物理位置的各个节点中,但在逻辑上又将各个节点的数据库统一成一个集中的数据库。[1]我们可以通过分布式数据库管理系统对分布式数据库进行建立、查询、更新、复制、维护等操作。而数据库查询操作又是数据库的核心操作。在分布式数据库系统中,查询优化处理一直研究的热点之一。

2 分布式查询优化的代价估算方法和重要性

2.1 分布式查询优化的代价估算方法

分布式数据库系统的查询优化的准则是使通信费用最低和响应时间最短。在查询优化算法中估算查询代价的方法是:

设一个查询执行的预期代价为QC,则

在集中式中:QC=I/O代价+CPU代价

在分布式中:QC=I/O代价+CPU代价+通信代价

通信代价可用如下公式作粗略估算:TC(X)=C0+C1×X

其中:X为数据的传输量,通常以bit为单位计算;

C0为两站点间通信初始化一次所花费的时间,以秒为单位;

C1为传输率,即单位数据的传输时间,单位是b/s。[1]

2.2 分布式查询策略的重要性

在分布式数据库系统中,查询优化包括两个内容:查询策略优化和局部处理优化,而查询策略优化尤为重要。在分布式数据库系统中,同一查询有很多的执行策略,查询的执行策略不同,其系统资源耗费及响应时间也不相同。下面我们以一个简单的教学数据库系统为例,说明查询优化的重要性。

两个站点上的关系分配如表1所示。

假设元组的长度为100b,通信系统的传输速度为104b/s,通信延迟时间1s。

现在要查询的是所有选修了“ENGLISH”课的男学生的学号和姓名。我们假设选修了“ENGLISH”课的男学生有10名。

根据TC(X)=C0+C1×X对所有可能的查询存取策略进行计算,结果见表2。

由表2见,不同的查询策略通信时间相差很大,达多个数量级,因此查询策略的优化非常重要。

3 基于传输代价最小原则的查询优化处理

分布式查询中,连接操作是常用而且代价较高的一种操作,分布式查询处理中的连接操作是影响分布式查询效率的最关键因素。当前对连接操作的优化有降低通讯费用的半连接技术和直连技术两种趋向。我们这里主要讨论基于传输代价最小原则的半连接算法。

3.1 采用半连接算法优化连接操作的基本原理

半连接(semi-join)操作是由投影和连接操作导出的一种关系代数操作。采用半连接操作,在网络中只传输参与连接的数据。在一个关系传输到另一场地后,并非每个数据都参与连接操作或都有用。因此,不参与连接的数据或无用的数据不必在网络中来回传输。[2]

假定有两个关系R和S,在属性R.A=S.B上做连接操作(这里“关系”也可以指片段)可以表示为:

或S∞A=BR=(S∝A=BR)∞A=BR

其中R∝A=BS、S∝A=BR为半连接操作,起含义为:

或S∝A=BR=∏S(S∞A=BR)=S∞A=B(∏A(R))

由上可以看出半连接操作是不具有对称性的,即R∝S≠S∝R。用半连接表示连接的过程为:

或S∞A=BR=(S∝A=BR)∞A=BR=S∞A=B(∏A(R))∞A=BR

采用半连接方法表示连接操作的过程如图1所示。[3]

从图1可以发现,半连接算法有两次通信过程,但是每次传递过程都是经过了筛查的。下面结合公式T=C0+C1×X,分析半连接算法的传输总代价。

1)在站点2上做关系S在R和S公共属性集B上的投影∏B(S),并把∏B(S)结果送到站点1,代价为:

Size(B)为B属性的长度,val(B[S])为关系S中属性B上不同值的个数。

2)将站点1半连接结果R′=R∝A=BS送到站点2的代价是:

C0+C1×size(R)×card(R′)其中card(R′)为R′的元组数

采用半连接算法的总代价为

或T半S=2C0+C1×(size(A)×val(A[R])+size(S′)×card(S′))

3.2 半连接算法优化连接操作的举例

下面以一个简单的分布式药品采购数据库系统为例,来估算通过对两地三个关系的连接操作的传输代价。其站点关系如表3所示。[4]

现在要查询的上所有采购产地为杭州且剂别为片剂的药品品号和品名。假设:每个元组中每个属性的值均为20bit,通信系统的传输速率为104bit/s,通信延迟时间为1s,剂别为片剂的药品元组有1000个,产地为杭州的药品元组有1000个,产地为杭州且剂别为片剂的药品元组有500个。

1)把A站点的YP和CG连接后筛选出来的“药厂编号”传送到B站点进行半连接,其传输代价为:

2)把B站点的“药厂编号”送到A站点进行半连接,其传输代价为:

3.3 多关系半连接查询优化算法思考

由于半连接查询优化算法的不对称性,在多关系连接查询中,如果采用半连接查询优化算法,采用不同的半连接执行策略会有不一样的传输代价。为了在复杂的多关系连接查询中能找出最好的半连接执行策略,可以采用最小生成数算法。[5]

给定一个多元自然连接查询Q,设Q涉及的关系为{R1,R2,R3,…,Rn}用连接图表示这n个关系以及关系之间可能的连接,图的顶点表示关系,边表示关系之间的连接。通过两个关系半连接的代价估算,预先估计连接的代价作为边上的权值。对于n个关系的连接图可以建立许多不同的生成树,每一棵生成树都可以是一种连接方式。最小生成树算法就是得到一个全局上的最佳连接次序,使查询Q的总代价最小。

4 总结

采用半连接方法表示连接操作需要两次数据库传输:连接属性投影结果和半连接结果。但在通常情况下,这两次数据传输的总量要远远小于传输一个整关系的数据量。所以一般有T半﹤﹤T全。所以,如果只需要一个关系中的一小部分元组参与和另一个关系连接的话,采用半连接算法是一个使数据传输量最小化的非常有效的方案。

半连接算法是一种基于传输代价最小化的查询优化算法,它不考虑局部处理的费用,所以在低速窄带广域网中,采用半连接方案处理策略是比较有利的,如果认为局部处理费用是主要的连接查询中采用半连接算法就不可取了。

参考文献

[1]邵佩英编著.分布式数据库系统及其应用[M].2版.北京:科学出版社,2005.

[2]萨师煊,王珊.数据库系统概论[M].3版.北京:高等教育出版社,2001.

[3]陈志东.基于半连接的分布式查询优化[J].大众科技,2007(01).

[4]黄月华,周萍.基于传输代价最小原则的分布式数据库查询优化[J].中国西部科技(学术),2007(09).

分布式数据库优化 篇9

随着计算机程序开发技术的快速改进和提升,分布式管理系统功能越来越多,系统集成也变得更加复杂。云计算、B/S体系架构等技术的诞生,将分布式管理系统划分为多层次架构,这样就可以把数据存储、访问和操作独立出来,形成一个逻辑独立的体系架构。因此,数据库作为分布式管理系统的一个重要组成部分,数据的访问、操作速度直接影响系统响应能力。数据库操作优化可以尽可能地缩小数据库连接、插入、删除、修改和查询时间,提高数据库执行速度,从而改进系统响应能力。

2 数据库在分布式管理系统中的应用

数据库在分布式管理系统的应用主要包括以下几个方面:

(1)数据库连接。分布式管理系统前台页面输入请求信息之后,Web服务器接收该信息,并且按照Web服务规则对逻辑业务请求进行解析,将数据库处理信息分离出来,并且请求数据连接,以便建立一个访问数据库的桥梁。

(2)数据库插入。数据插入是分布式管理系统更新操作之一,其可以利用SQL程序设计的INSERT语句将数据插入到数据库中,实现分布式管理信息添加功能。

(3)数据库删除。数据库删除操作可以根据用户请求,利用DELETE语句将数据信息删除。数据库删除操作可能涉及多个数据表,因此操作时间非常长,容易造成系统处理瓶颈,大大地降低响应速度。

(4)数据库修改。数据库修改操作可以利用UPDATE语句修改相关的数据信息,以便能够更新数据库的相关内容。

(5)数据库查询。数据库查询操作可以利用SELECT语句查询数据信息,并且将结果封装到一起反馈给用户,供用户查看数据库查询信息。

数据库操作作为分布式事务处理过程,一个分布式事务可以划分为多个子事务,这样每一个事务都包含了多个操作命令,为了能够将分布于不同位置的数据库集成到一起,每个子事务就必须加载到相关的关联场地,并且在场地中激活每一个子事务。分布式数据库事务处理过程中,需要尽可能地保证分布式事务的原子性、一致性、独立性和持久性。因此,分布式管理系统数据库事务处理存在两个关键问题,分别是分布式事务的管理、网络中各个场地的局部数据的集成。分布式管理系统引入移动Agent技术之后,可以把每一个子事务都封装到一个移动的Agent中,移动Agent能够在分布式网络中进行自由的移动,将移动Agent分发至数据库事务处理的场地,子事务将会在产地上得到有效的处理并且将处理结果反馈给移动的Agent,如果任意一个子事务需要与其他子事务进行分布式计算,则可以移动Agent到新的场地,执行相关的运算,然后携带计算结果返回到原场地。

3 数据库操作组件优化

为了提高数据库操作速度,提出采用移动Agent方法改进数据查询、插入、修改、删除和连接操作。移动Agent分布式数据库事务处理模型包括3个方面,分别是方案Agent、协调Agent和全局数据管理Agent,这3个构件可以形成一个群体,负责全部或局部更新、查询操作,实现对数据库的集中管理、分布式映射和数据控制等功能。另外,通信管理Agent、监控Agent、局部数据管理Agent和局部方案Agent也构成了一个局部群体,可以负责数据库场地自治、转换和交互。分布式数据库引入移动Agent后操作处理流程如图1所示。

具体的数据库执行过程中各个Agent功能描述如下:

(1)方案Agent。方案Agent的功能是维护全局和局部数据目录,比如能够管理数据库全局模式、局部名映射、描述分配、数据库存取方法、完整性约束信息、数据表达格式等信息。从全局方面管理数据库操作信息,便于用户处理。

(2)协调Agent。协调Agent的功能是控制和协调分布式数据库事务处理流程、规则,以便按照正确的顺序提交、处理和终止数据处理过程,进一步改进数据库的操作有序化、规范化。

(3)全局数据处理Agent。该Agent的相关功能是完成数据库数据信息的查找、定位操作,以便协调各个Agent之间的信息交互管理功能,通过方案Agent查询全局或局部数据库目录,进一步实现数据转换功能。

(4)调度Agent。调度Agent可以负责局部数据库的操作链接功能,并且能够将逻辑业务请求发送给相关的局部数据处理Agent,这样就可以实现程序调度和管理。

(5)监控Agent的功能是负责实时监控局部数据库的变化,并且将相关的状态信息通知给方案Agent,促使其改变全局或局部数据库目录。

(6)通信管理Agent的功能是负责各个场地之间的数据传输等功能,当监控Agent监控到局部数据发生变化时,通信管理Agent可以将变化传递给其他关联场地副本,如果需要对其他的局部数据库实施操作,还可以移动到其他的场地。

(7)局部数据处理Agent的功能是更新、查询局部数据库,并且能够实现数据转换等功能。

数据库任务查询设计的物理表很多,因此查询过程中需要进行严格优化操作,数据库事务查询引入移动Agent之后,可以采用的查询方式包括普通查询模式和增强型查询模式。普通查询模式可以将查询任务划分为多个逻辑独立的子查询任务,因此一个主Agent可以创建多个逻辑独立的子Agent,每一个Agent能够完成一个子查询任务,并且通过分布式网络可以将查询任务分发到多个目标场地进行执行,然后主Agent可以集成和封装子Agent的查询结果,并且按照组装规则生成一个完整的查询结果,如图2所示。

数据库任务查询的另一种模式是增强查询模式,主Agent创建一个增强型的主Agent,增强型主Agent创建多个子增强Agent,并且将逻辑独立的子查询任务加载到子增强Agent上,将其分发至每一个目标场地。查询事务完成之后,由增强型的主Agent负责操作、组合查询结果,并且将最终的结果反馈给主Agent。由于增强型的主Agent无需在客户端上组装,因此可以保证客户端操作的完全透明性。如图3所示。

为了显示算法的优越性,论文设置了一个100次的数据库删除操作,传统的数据库处理时间为26.7s,引入移动Agent模型之后执行时间为14.2s,大大地降低了执行时长,提高分布式事务处理速度。

4 结语

数据是分布式管理系统加工、处理的对象,因此数据库的处理速度直接影响分布式管理系统的响应时间。为了提高系统处理效率,引入了移动Agent优化数据库操作过程,实现数据分布式、透明化处理,实验结果显示算法可以改进系统处理时间,进一步改进算法优化效率。

摘要：互联网、大数据、云计算等技术的快速发展,促进了分布式管理系统在电子商务、电子政务、金融证券、电力通信等领域得到广泛普及和使用,取得了显著的应用成效。分布式管理系统在数据处理过程中,数据库是最为关键的一个重要组成部分,其承载着系统数据的连接、查询、删除、修改、插入等操作功能,直接影响分布式管理系统的操作性能。分析了数据库在分布式管理系统中的应用,提出了利用Agent技术优化数据库操作组件,提高系统数据加工的速度,进一步提升系统性能。

关键词：数据库,分布式管理系统,Agent技术,操作组件

参考文献

[1]孔令媛.远程分布式数据库查询系统的设计研究[J].信息通信,2015,(12):133-134.

[2]申毅,武小年.分布式异构数据库数据同步系统的实现与优化[J].桂林电子科技大学学报,2014,(4):285-289.

[3]李春晓.基于Hive的分布式空间数据库的研究与优化[D].河南大学,2015:1-7.

[4]周跃,臧斌宇.分布式No SQL系统写操作性能优化设计与实现[J].计算机应用与软件,2014,(11):25-28.

论分布式数据库 篇10

当今社会是信息的社会,随着科技的进步,随着网络的发展,信息的地位已经成为比能源、物资更重要的资源,以信息价值的生产为中心,以信息工业为支柱和主导,促进信息高速发展成为至关重要的课题。

如何更好的管理众多的信息,如何更好的存储大量的数据,特别是如何让大量的有用信息可以让大众共享,也就同时成为当今研究的重要项目之一。

分布式数据库的研究和应用已经成为这个项目的重要研究领域。为此,我们就需要对分布式数据库的优点,缺点详细了解,从而使分布式数据更好的为我们服务。

2 什么是分布式数据库系统

要研究分布式数据库首先就要先知道什么是分布式数据库。打个比方说,一个学校对学生进行管理工作,就是把学生安排在多个班里,每个班都是一个独立的数据库,而多个班合起来就是一个学校学生的整体数据库。这种分布处理的方式,能更好的对学生进行管理。

通过上面的例子我们可以看出,所谓分布式数据库系统就是由分布于多个计算机结点上的若干个数据库组成,每个子数据库系统都是一个独立的数据库系统,它们都拥有各自的数据库、中央处理机、终端,以及各自的局部数据库管理系统,分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。简单的说,分布式数据库系统是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统,但在物理结构上是分布式的。

3 分布式数据库的前提———“分”

数据库技术主要研究的对象就是数据,那么如何处理数据就成为数据库技术主要面对的问题。在分布式数据库中,我们要进行的前提就是如何实现数据的“分”。

3.1 数据分片问题

从分布式数据库的定义中,我们知道,所谓的分布式简单的说,就是把一个整体分成多个独立的个体,所以对于分布式数据库系统来讲,就是把一个大片数据分成多个独立的小数据存放在网络中的各个主机上,我们把这个过程就称为数据分片。那么下面我们就来看看在分布式数据库系统中,是如何实现对数据的分片的。

1)水平分片

所谓水平分片就是按一定的条件把全局关系的所有元组划分成若干不相交的子集,每个子集为关系的一个片段,简单地说,就是按关键字的特征来划分全局数据库。

2)垂直分片

所谓垂直分片就是把一个全局关系的属性集分成若干子集,并在这些子集上作投影运算,每个投影称为垂直分片。

我们现在仍然用上面的例子对垂直分片的方法进行说明如下图所示,全局数据库XSXX,按字段名分成两片局部数据库,这里面学号和姓名字段出现重复,在对数据库分片时,最好应避免出现过多的重复字段,但这种重复又是必要的,因为它们能够表达记录特征,使局部数据库之间的记录能一一对应,这样的字段要求其值相对固定,不要随意改动。

3)导出分片

又称为导出水平分片,即水平分片的条件不是本关系属性的条件,而是其他关系属性的条件。(也可以归为水平分片的特例)

4)混合分片

在分布式数据库应用中,仅仅进行单一的水平分片或垂直分片往往是不够的,在数据库设计的时候,一般都同时用到这两种方法,这就是混合分片的方法。所谓混合分片,简单地说就是以上三种方法的混合。可以先水平分片再垂直分片,或先垂直分片再水平分片,或其他形式,但他们的结果是不相同的。

我们还是通过上面的例子来理解混合分片的方法。

3.2 数据在进行分片时的要求

在对数据“化整为零”的过程中,并不是简单的水平,垂直分成多份就可以了,在“分”数据时必须有一定的要求和规则。

1)完整性要求

必须把全局关系的所有数据映射到片段中,决不允许有属于全局关系的数据却不属于它的任何一个片段。

2)可重构要求

必须保证能够由同一个全局关系的各个片段来重建该全局关系。对于水平分片可用并操作重构全局关系;对于垂直分片可用联接操作重构全局关系。即,“化整为零”的数据,还要能够再“化零为整”。

3)不重复要求

要求一个全局关系被分割后所得的各个数据片段互不重叠(对垂直分片的主键除外)。

3.3 数据的分配方法

1)集中式:所有数据片段都安排在同一个场地上。

2)分割式:所有数据只有一份,它被分割成若干逻辑片段,每个逻辑片段被指派在一个特定的场地上。

3)全复制式:数据在每个场地重复存储。也就是每个场地上都有一个完整的数据副本。

4)混合式:这是一种介乎于分割式和全复制式之间的分配方式。

4 分布式数据库的应用———“查”

无论建立什么样的数据库,最终的目的就是对它内部数据的使用,当我们把大量数据分成多个部分,分配在各个网络和设备结点,那么在应用某些数据时,如何采用寻找最优解的算法,就成为一个重要的问题。所以如何“查”,就是我们关心的另一个主要问题。

“查”的主要工作就是在执行分布式查询时选择查询执行计划的方法和关系运算符的实现算法。根据系统环境的不同,查询优化所使用的算法也有所不同,通常分为远程广域网环境和高速局域网环境,其区别主要在网络的带宽。对于一元运算符可以采用集中式数据库中的查询优化方法。而对于二元运算符,由于涉及场地间的数据传输,因此必须考虑通信代价。

目前,在分布式查询中常见的连接运算执行策略包括:

1)半连接方法

利用半连接运算的转换方法R∞S=(RµS)∞S。假设场地1和场地2上分别有关系R和关系S,首先在S上执行连接属性上的投影并将结果传输至场地1,在场地1上执行关系R与投影的连接操作,再将结果传输至场地2与关系S执行连接操作。这种方法能够降低执行连接运算时的网络通信代价,主要适用于带宽较低的远程广域网络。

2)枚举法方法

指枚举关系运算符的物理执行计划,通过对比执行计划的代价选择执行算法的方法。其中,连接运算符的物理执行计划包括嵌套循环方法、哈希连接法和归并连接法。枚举法主要适用于以磁盘IO代价为主的高速局域网环境。

5 分布式数据库的特点及应用

从上面的分析,我们已经对分布式数据库系统有了一个大概的了解,从中我们可以看出分布式数据库在现代社会的海量数据管理和使用中,是功不可没的,但同时也面临着许多的问题,下面我们从分布式数据库的“功”与“过”来对它的特点进行一下简单的分析。

5.1 分布式数据库的“功”

1)对网络中各结点的要求不高

由于分布式数据库技术,将大量的数分成多个部分来进行管理,所以对某些结点计算机系统的配置要求可以放低。

2)降低了数据传送代价

大多数的对数据库的访问操作都是针对局部数据库的,而不是对其他位置的数据库访问的,所以降低了数据的传送代价。

3)提高了系统的可靠性

当网络出现故障时,仍然允许对局部数据库的操作,而且一个位置的故障不影响其他位置的处理工作,只有当访问出现故障位置的数据时,在某种程度上才受影响

4)便于扩充

由于在分布式数据库系统中各个数据库的位置是透明的,所以对于数据库的扩充更方便。

正因为分布式数据库有如此多的优点,所以对于数据信息需求日益增多的今天,它已经占有了一块十分重要的领域。但是,有些功能却需要付出更高的代价。

5.2 分布式数据库的“过”

1)事务管理性能要求高

由于,分布式数据库把数据分散到多个网络结点上,所以为了调配在几个位置上的活动,事务管理的性能比在中心数据库时花费更高,甚至抵消许多其他的优点。

2)数据的安全性存在隐患

由于分布式数据库的数是在各个数据库的位置是透明的,所以使大量信息的安全性存在隐患,甚至造成重要信息被泄漏。

我们正是要我利用分布式数据库系统的这些特点使其更好的为我们服务。

6 未来分布式数据库与移动Agent的绑定的展望

研究分布式数据库的目的是为了更好的“为己所用”。所以,我们要做的就是让分布式数据库的优点更可靠,更好的为我们服务,同时更重要的就是了解,发现它的缺点,并想办法来解决这些问题。

这让我想到了,前一段时间看到的移动Agent技术。移动Agent具有可以自由在网络中移动,并当从一个结点到另一个结点后,可以不占用带宽,也就意味着,此时如果断网,也不会影响,Agent的工作,所以如果用移动Agent来寻找数据就可以避免数据信息的泄漏,并且也不用耗费大量的精力来管理调配数据,只需对这种“数据探访”Agent进行控制就可以完成所需的大量工作。

所以,如果能使移动Agent技术与分布式数据库技术绑定,将会使未来的数据库管理技术的发展有着光明美好的前景。

7 结束语

分布式数据库技术是一项仍然会不断发展的技术,从总体上看,分布式数据的研究已经从起步阶段发展到了攻坚阶段,目前急需对分布式技术的某些问题进行深层研究,比如说查询的优化问题,并且同时需要对所存在的问题进行解决,如信息的安全隐患问题,事务管理要求过高的问题。写成本文,主要是为了让更多人关注分布式数据库的发展。我相信,随着研究和开发工作的不断深入,分布式数据库将在实际应用中不断的提高和完善,更好的为我们所用。

参考文献

[1]浙江中控软件技术有限公司.分布式实时数据库在钢铁中的应用[EB/OL]http://www.gkong.com/co/supcon/solution_detail.asp?solu-tion_id=5243.

[2]刘威.分布式数据库及其技术[J].长春大学学报,2000,10(1).

[3]萨师煊,王珊.数据库系统概论[M].北京:高等教育出版社,2006.

分布式数据库优化 篇11

关键词：分布式光伏发电集成系统；优化建议；基本原则

中图分类号：TM727；TN915.5 文献标识码：A 文章编号：1006-8937（2016）12-0016-01

存在于我国中东部的分布式光伏发电集成系统的分布和系统接入问题在整个光伏发电系统的重要性缺乏足够的重视。集成系统各个组件的设计工艺的水平直接决定了工程后期集成系统区域中整体的视觉效果，好的设计在一定程度能够确保集成系统各个组件能够保证规定的使用年限，能够按照工程预期实现整个发电集成系统的效率最大化。本文就工程前期设计中需要遵循的基本原则以及工程中常见的问题进行研究，在光伏集成发电逐渐得到应用普及的现状下探讨对当前分布式发电集成系统的优化问题。

1 分布式光伏发电集成设计遵循的基本原则

1.1 易操作性

分布式光伏发电集成系统的设计必须尽量易于操作，和人口稀少的西部拥有开阔的安装地点不同，这种分布式的发电集成系统一般安装在屋面楼顶等地方，这些地方一般存在一定的倾斜度或者是高度比较高。在这种屋面具有一定的倾斜度并且承重能力有限的情况下工人的施工难度将会增加，所以集成系统在设计之初就要考虑到后期的施工难度，降低操作的难度，并且尽量保证将工程设计控制在一期之内。

1.2 安全性

由于分布式的光伏发电集成系统主要应用于人口和建筑比较密集的中部和东部地区，因此集成系统的安全性问题显得尤为重要。在具有倾斜度的屋顶施工需要将各个部件运送到屋面或楼顶进行施工，在这过程中存在部件因运输而导致损伤和施工人员的安全问题。目前市场上通常采用安装一定的导轨实现与屋面材料进行连接，采用目前市场上较为通用承载力比较高的铝合金的支架结构，它便于安装操作且不易锈蚀损坏，在一定程度上可以减少后期的安全隐患。在施工过程中还存在高空坠物的危险，由于施工地区的人口和建筑物的密度比较大，施工人员高空作业后期会产生废弃的材料，加上屋面的倾斜度会增加高空坠物的隐患，在设计的中要考虑到集成系统的整体性以及将后期的废料收集进行合理的回收设计。

在设计中还需要考虑到各部件的重量是否在屋面的最低承重范围之内，屋面的材料的承重能力会随着雨水阳光等的风化而导致其承重能力的降低，施工人员本身的重量也需要考虑在内，因此在进行集成系统的设计中要考虑到施工地点的最低承重并且把重量控制在这个范围之内。

1.3 一致性

分布式的光伏发电系统将较大数量的太阳能电池串联起来以达到一定高度的电压，然后才能从逆变器的输入端进行输入，这样一定数量串联的子系统再进行并联以达到系统的额定功率。在这个过程中需要数量较大的设备，为了保证系统的稳定，选用的太阳能电池需要是相同的规格和工作性能，同时在设计中要避免互相之间存在遮挡影响工作效率以及方向和角度问题而导致的差异，保持各个子系统运行的一致性。

1.4 可持续发展原则

分布式光伏集成系统存在的区域需要考虑到所在地区可能存在后期进行施工改造问题以及自然灾害等对系统部件的破坏，集成系统存在的大而分散的特点，因此设计既要保证整个系统的整体一致性，整个系统具有稳定性，同时采用并联各个子系统的方式保证其独立性，在某个子系统遭到破坏时其他系统能够不受影响仍然保持正常的运行。另外，采用铝合金或新型的支架考虑到其坚固性的同时还需要考虑到其抗腐蚀和抗氧化性，以及损害后的修复性，尤其是重工业和污染比较严重的地区。

2 当前设计中分布式光伏发电集成设计中遇到的常 见问题

分布式光伏发电集成系统分布占地面积比较大，逆变器和控制装置的数量比较多，线路的串联以及并联比较复杂，而且由于其特殊的位置原因，发生故障时进行排查和修检的困难大。由于中部和东部地区的施工和整修而导致的线路和各个系统部分的运行产生障碍的问题比较多。东部地区比较特殊的天气情况给整个系统的稳定运行带来了挑战，产生的电能不稳定问题给系统接入电网带来新的挑战。

3 针对分布式光伏发电集成常见问题的优化建议

针对分布式光伏发电集成常见系统稳定的问题，在进行前期的设计中需要对控制器进行各项内容的控制，包括故障报警以及定位、测量等，另外采用多功能的汇流箱，进行智能的汇流预警和线路排查。各个光伏发电子系统采用相同规格的电池组件按照相同的设置距离安装构成一个发电矩阵，组成矩阵的各个单元配备完善的逆变器和控制装置尽量减少各个系统的差异而造成系统电压的不稳定。

考虑到东部地区特殊的气候条件，需要具体分析不同型号的太阳能电池板各个性能的强弱的具体数值选择合适型号的太阳能电池组，以下选用东部地区常采用的250 Wp多晶硅太阳能电池板为例将需要考虑的具体方面进行考虑。见表1。

在设计安装过程中，考虑到当地的经纬度位置和屋面的倾斜程度进行合理的方位和角度选取，保持选取方位和角度的一致性。采用可活动的支架来调节夏冬因太阳角度的变化而导致的产生的较大电压差。

施工过程中应该对首先对光伏安装组件进行检查，安装过程中对重量比较大的组件进行机械固定，以减少对组件的破坏。在设计施工过程中对工人作业需要使用的脚手架进行系统的防护措施的保护以及工程后期产生的废料进行系统的回收，搭建格挡装置减少高空坠物的危险，完成后要进行严格的验收，运行前进行系统的清洁，保证太阳能组件效能的正常发挥。

4 结 语

随着近年来大规模的光伏电站的建立，对太阳能的开发和利用将成为未来一段时间内新能源领域中重要部分。因此通过不断地对分布式光伏发电集成系统设计的优化能够提高后期施工过程中质量和效率，同时可以减少后期使用中的问题，针对东部和中部地区特殊的气候和条件进行分析是现阶段设计过程中的重要问题，通过设计方案的不断改进，太阳能光伏发电系统能够在施工中缩短施工的难度和时间长度，有效缩减了不必要的成本支出，虽然存在着一定的问题和不完善的地方，但这对以后光伏发电集成系统的设计提供了改进的方向。

参考文献：

[1] 李晶，许洪华，赵海翔，等.并网光伏电站动态建模及仿真分析[J].电力系 统自动化，2008，（24）.

[2] 王一波，李晶，许洪华.考虑电网安全稳定约束的光伏电站最大安装容 量计算与分析[J].太阳能学报，2008，（8）.

分布式数据库安全解析 篇12

伴随着互联网的迅速发展, 分布式数据库系统成为了信息技术领域中一个很活跃的研究方向。“一个分布式数据库系统包括了一个分布式数据库管理系统, 一个分布式数据库和作为连接载体的网络。” (Bhavani Thuraisingham 2000) 在一个集中式数据库中, 数据是保存在一个服务器中的。然而, 分布式数据库将数据保存在多个服务器中。为了给客户提供服务, 很多产业都需要安装分布式数据库系统, 例如银行需要提供给客户在线转账的服务, 跨国公司将员工的信息分散保存在不同的分布式数据库主机中, 等等。我们可以看出通过分布式数据库系统传播的数据大部分是隐私或者保密的, 例如银行的转账记录或用户的个人信息。这些信息通过网络来传播, 因此更容易受到攻击, 我们也必须保证整个系统的安全。本文中, 我将建立一个模型并从四个层次详细分析提升分布式数据库和分布式数据库系统安全性的方法。

2 保障分布式数据库系统安全性的四个先决条件

为了使一个分布式数据库系统安全, 四个先决条件必须满足:首先分布式数据库和分布式数据库管理系统必须配置和维护妥当, 这一部分是保障分布式数据库系统安全的核心。其次操作系统必须拒绝未经授权的连接。接下来运行分布式数据库管理系统的服务器必须在物理上得到有效保护。最后, 作为数据传播媒介的网络必须安全可靠同时运转良好。

3 增强分布式数据库及其管理系统安全的方法

为了增强分布式数据库及管理系统的安全, 需要建立安全模型。本文中我建立的安全模型包括四个层次, 分别是:身份验证、授权、加密和审计。

3.1 身份验证。

在一个用户从数据库获取信息之前, 他的身份必须得以确认。在分布式数据库系统中, 身份验证包括两方面的含义。一方面, 是用户和服务器之间的身份验证。例如当用户通过网上银行系统转账时所发生的验证。另一方面, 是服务器与服务器之间的验证。例如当一台服务器需要连接另一台服务器从而产生正确结果时所用的验证。不同的数据库有不同的身份验证方式甚至一种数据库也会有多种方式去验证用户或者数据库的身份。在这里我拿甲骨文的验证方式举例。当用户对一个数据库发出请求时, 验证就开始了。首先, 他必须选择他在数据库系统中要扮演的角色, 接下来, 透明网络底层 (TNS) 被激活。TNS呼叫服务器, 并将用户的信息 (例如主机名, 操作系统的版本, 等等) 传递给服务器。在这一阶段, 并没有涉及到用户名和密码的传送。当数据库接受了主机名和操作系统信息之后, 用户就可以通过甲骨文的密码传输协议 (O3LOGON) 将用户名和密码传给数据库, 而这个协议也是通过DES算法加密的。 (Ron2005) 数据库和数据库之间的交流对于一个分布式数据库系统来说也是很重要的。当用户登录到系统之后, 用户可能只接连到了数据库A。而当用户需要得到由数据库A和数据库B连接产生的记录时, 分布式数据库管理系统就会在后台做连接操作了。不同的分布式数据库有不同的方法来确保这类连接的安全。例如微软使用远程过程调用协议 (RPC) 来连接不同的数据库, 而数据库之间的身份验证由RPC验证完成。一台服务器发送给另一台服务器一个RPC包裹, 这个包裹包含了两方面的内容:证书和证明。证书是用来识别发送方身份的, 而证明用来证明发送方是真正身份的拥有者。举例来说, 一个警察徽章上的名字就是证书, 其上附带的照片就是证明。服务器接收包裹后, 通过证明来验证证书的有效性。而这个环节就类似于通过照片来验证徽章的携带者。当发送端的数据库服务器身份被确认后, 接收端的数据库服务器就会发送回一个证明给发送端, 然后连接就被建立了。 (Sun Microsystems 1995)

3.2 授权。

当用户的身份被确认之后, 用户就可以从数据库中获得数据了。但是, 数据库会根据用户身份的不同给予不同的使用权限, 例如低级别的用户只能浏览那些非隐私性的数据。在一个分布式数据库系统中, 管理员有着最高级别的权限。他可以对数据库进行所有操作例如更删改查等等。管理员也可以使用GRANT和REVOKE方法去动态的给予和撤销权限。通过GRANT给予的权限是可以累加的, 但是一个REVOKE操作便会将之前所有GRANT的权限撤销掉。数据库管理员的账户是整个分布式数据库中最重要的账户, 因此必须得到有效的保护。另外一种授权的方式就是通过矩阵授权。例如甲骨文就通过两个矩阵给用户授权。一个叫做user_tab_privs矩阵, 这个矩阵保存着用户对表格操作的权限;另外一个叫做user_sys_privs矩阵, 这个矩阵保存着用户对系统操作的权限。 (Oracle 2005) 当用户登录系统后, 分布式数据库管理系统会通过这两个矩阵自动给予用户相应的权限。

3.3 加密。

被分布式数据库管理系统操作的数据大致可以分成两个类型, 一种是储存在分布式数据库中的数据, 另外一种就是在用户和数据库之间传递或者在多个数据库之间传递的数据。不论何种数据, 都需要被加密以获得更高的安全级别。比较常用的数据库内部信息的加密方式为对称密匙加密。用这种方式将明文加密成密文存储在数据库的步骤如下:首先, 选择一个对称密匙。接着分布式数据库管理系统利用用户的公匙对对称密匙加密。用户的私匙也同时被加密。每当用户需要使用对称密匙加密数据的时候, 他需要利用密码短语将被加密的私匙解密, 然后利用私匙将被加密的对称密匙解密。最后, 分布式数据库系统利用对称密匙将明文加密成密文存储。在网络上传递的数据一样也需要加密。这些数据可能是由多个分布式数据库产生并穿梭于多个网络。因此加密和解密的算法会很大程度上影响分布式数据库系统的性能。在这里我拿甲骨文的分布式数据库系统举例如何依赖分布式数据库管理系统对数据加密。甲骨文公司有一个高级安全包的概念, 用于加密传送的数据。发送方需要先告知接收方他支持哪些加密算法, 接下来接收方要检查自己的加密算法, 然后比对发送方提供的算法列表。如果有相同的加密算法, 那么接收方会建立连接;如果没有任何加密算法对应, 则连接会被拒绝。因此如果用户和数据库服务器端都使用甲骨文的分布式数据库管理系统, 在网络上传输的数据就肯定会被加密因为发送方和接收方有着同样的加密算法。

3.4 审计。

审计是四层次模型中的最上层。当前三个层次的安全性都得以保障后, 分布式数据库已经可以正常运转了, 但是我们还需要通过审计去观察分布式数据库管理系统。通常情况下, 分布式数据库管理系统会产生两种审计监控内容。一种是日志, 用来记录用户对敏感信息的获取情况, 例如哪些用户在何时登录登出了系统, 又是在何时对敏感信息进行更新的, 等等。另外一种审计是安全审计, 这种审计用来观察系统的工作状况并扫描漏洞。通过安全审计, 数据库管理员可以更好的监控分布式数据库管理系统的行为。

4 结论

本文通过解析四个层次的安全模型详解了提升分布式数据库及其管理系统安全性的方法。分布式数据库的应用非常广, 如在银行、政府和跨国公司都被广泛使用。而分布式数据库操作的数据大部分都是隐私且价值很高的, 因此我们必须保证数据库及其管理系统运行在一个安全的环境之下。

摘要：伴随着近些年互联网的扩充热潮, 分布式数据库得到了很大的发展。分布式数据库系统要远比集中式数据库系统复杂, 同时也更容易受到侵犯。本文分析了有关分布式数据库安全的各方面, 介绍了增强安全性的主要技术。同时, 本文详细的分析了增强分布式数据库和分布式数据库管理系统安全性的方法。

关键词：分布式数据库,互联网,安全

参考文献

[1]Bhavani Thuraisingham. (2000) , “Security for Distributed Databases”, Information Security Technical Report, Vol 6, No.2 pp.95.[1]Bhavani Thuraisingham. (2000) , “Security for Distributed Databases”, Information Security Technical Report, Vol 6, No.2 pp.95.

[2]Ron Ben Natan. (2005) Implementing Database Security and Auditing, Elsevier, UK, pp.96[2]Ron Ben Natan. (2005) Implementing Database Security and Auditing, Elsevier, UK, pp.96

[3]太阳微系统公司, 提高RPC安全性文档, 1995.[3]太阳微系统公司, 提高RPC安全性文档, 1995.