文档库 最新最全的文档下载
当前位置:文档库 › 分布式数据库查询优化技术

分布式数据库查询优化技术

分布式数据库查询优化技术
分布式数据库查询优化技术

分布式数据库查询优化技术

摘要在分布式数据库中,由于高可靠性和高速度性是其重要特点,所以对查询执行的要求也就更高。而查询执行中查询优化是执行的关键环节,查询优化在很大程度上决定查询的效率或快慢。本文讨论的重点是对分布式查询执行的全局处理策略进行优化,尽可能避免通信代价的开销,并着眼于查询执行的实际代价,从分布式系统中选出一个最优的执行节点。从查询执行的效果出发,通过统计的方式,不断从最近的查询执行代价学习纠正最近查询执行的统计代价,为查询的全局处理提供参考,以达到优化执行、提高执行效率和速度的目的。

1 分布式数据库概述

1.1 分布式数据库的定义

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

1.2 分布式数据库系统的组成

如图1-1所示,分布式数据库系统由以下述成分组成:

(1)多台计算机设备,并由计算机网络连接。

(2)计算机网络设备,网络通讯的一组软件。

(3)分布式数据库管理系统,它包括GDBMS、LDBMS、CM,除了具有全局用户接口由GDBMS连接外,还可以具有自治场地用户接口,由场地DBMS链接,并持有独立的场地目录。

(4)分布式数据库管理者(DDB),包括全局数据库(GDB)和局部数据库(LDB)以及自制场地的自治场地数据库。

(5)分布式数据库管理者(DDBA),它可分为二级,一级为全局数据库管理者(GDBA),另一级问局部或自治场地数据库管理者,统称为局部数据库管理者(LDBA)。

(6)分布式数据库系统软件文档,这是一组与软件相匹配的软件文档及系统各种使用说明和文件。

图1-1 分布式数据库系统的结构

1.3 分布式数据库系统的功能

通常的集中式数据库管理系统应具备以下几个基本的功能[2]:

(1)数据库定义功能;

(2)数据存取功能;

(3)数据库运行管理;

(4)数据库的建立和维护功能。

分布式数据库除了须具备以上集中式数据库的功能外,一般还须具有以下几个方面的功能:

(1)分布在网络中的各节点的数据库,其物理位置对用户透明;

在用户眼里见到的只是整个系统中有哪些数据库,无论是本地还是远程数据库,用户操纵某一数据库就像操纵本地数据库一样。

(2)处于网络中的各数据库共享的数据应保证一致性:

Communication

Network

S S

S

S

当用户操纵(查询、更新、删除等)某一数据库时,整个网络中的各节点如果有该数据库的副本或备份数据库,应进行相应的更新操作,以保持数据一致性。

(3)系统的可靠性应比集中式数据库系统的可靠性更高:

如果因为某种原因,使系统中某一节点数据库崩溃,系统会自动选择另一具有该数据库的节点继续提供原来的服务。

(4)支持多用户的并行访问,或者操作的并行性;

(5)数据的安全性和完整性比集中式数据库要求更高;

由于分布式数据库系统中各节点数据库处于网络环境中,数据受到破坏和窃取以及丢失的可能性大大增加。

2 数据库查询优化技术

2.1 查询优化技术

数据库系统研究的主要目标是尽可能的对用户隐藏数据结构的细节,使数据库系统的应用更能面向各个领域。同样,分布式数据库研究的主要目标之一是隐藏分布式环境的细节,使系统用起来更加简单、有效[3]。

关系数据模型可以为集中式数据库提供一个数据无关的接口关系数据库语言是关系演算,使用该语言进行数据查询时,只需对要查询的数据进行简单的描述,而无须说明如何获取这些数据,SQL 语言就是其中之一。但是,使用这种语言,也要对搜索、存取操作以及数据传输过程进行说明,因此,相应的查询优化技术的研究和发展也在不断进行。

所谓查询优化,就是要保证查询总开销和总时间为最小。查询优化器的主要任务是控制和加快查询的执行和数据的传输过程。

查询优化器(如图2-1)首先以查询的某种表示作为输入,这种表示是查询处理器的语法分析子模块的输出,查询优化器为查询选择一种适当的数据存取策略。然而,查询优化一直是个复杂的问题,理想的全面的查询优化几乎是不可能的,许多专家和学者在这一领域曾做出过不少的研究和探讨,但

总的说来,不尽人意,往往只能达到局部目标的查

询优化效果,甚至有些理论并不适用。

图2-1 查询优化处理

查询优化的基本类型通常包括两类:针对查询

执行代价的优化和针对查询响应时间的优化。针对

查询执行代价进行优化的目标是,使查询执行所使

用的系统资源(总和)尽量地少,从而降低系统开

销,整个系统的开销可以从单个系统资源的开销表

达式中推出。针对查询响应时间优化的目标是尽量

减少查询的响应时间,而不计较系统资源的耗费。

2.2 分布式数据库优化设计分析

在分布式数据库系统中,一方面,许多相对独

立的处理器可能参与数据库操作。分布式数据库可

能提供若干机会[3]:

1)由于在处理一个问题时可以使用多台机器,

并行以及加快查询反应速度的可能性增大。

2)由于数据可以在多个节点上存在副本,系统

可能不会仅仅由于一个节点或部件发生故障而不

得不停止处理。

另一方面,分布式处理增加了分布式系统各个

方面的复杂性,因此即使是DBMS中最基本的组成

部分的设计,也得重新考虑。在许多分布式环境中,

通信开销可能远大于处理开销,因此的问题是消息

如何传送。比如分布式提交和分布式封锁。

查找空间生成

等价的QEP

转化规则

输入查询

代价模型

查找策略

查询重写

优化的逻辑查询计划

(best QEP)

在分布关

在分布关

影响通信开销的因素主要是由于带宽开销迅速减小。某些类型的数据属于电子方式管理的大对象,因此即使在通信开销较小时,以太字节的数据传输开销也是不能忽视的。此外,通信开销常常不仅仅涉及数据传送,还有为数据传送做准备的各层协议、在接受方重建数据以及通信的管理。这些协议各自都需要大量的计算。尽管计算开销也在减小,与数据与关键数据库操作的传统单处理器操作相比,进行通信所需的计算可能仍不能忽视。

分布式数据库查询处理如图2-5,分布特性的存在除带来通信开销外还影响到物理查询计划设计的复杂性和可选方案。在选择物理查询计划时必须考虑的问题包括:

如果某个所需关系R 有多个副本,那么应该从那个副本中获得R 的值。

当在两个关系R 和S 上实施某个操作例如连接时,有多个可选方案而且必须选择其中之一时,一些可能的选项如下:

a)可以将S 复制到R 所在节点,并在该节点执行计算。

b)可以将R 复制到S 所在节点,并在该节点执行计算。

c)可以将R 和S 复制到二者各自所在节点之外的第三个节点,并在该节点执行计算。

哪种选择最好,这依赖于多个因素,其中包括哪个节点上有可用的处理时间以及操作结果是否需要与第三个结点上的数据相结合等。

如果关系R 有分布在若干节点上的片断

n

R R R ,...,,21,构成,那么在选择逻辑查询计划

时,还应该考虑用

n 21...R R R ???

替代查询中使用的R ,替代后的查询或许能很大程度的简化表达式。

3)对局域网来说,通讯代价有着跟数据库的磁盘I/O 代价相比拟的重要性。网络通信代价会随着用户数或负载的变化而改变,所以网络情况变化的随机性对分布式查询处理来说,更应该考虑通信代价。但当某个数据库的查询负载过高时,需要牺牲一定的通讯代价来提高执行的并行度。此外局域网络的广播能力可以用于全局优化更新、收集信息。

图2-5分布式查询处理的通用层级方案

3 分布式数据库查询优化技术研究

3.1 基于分布式数据库分布特点的优化

分布式并行系统处于网络中,处于网络中的各个节点具有单个服务器系统所没有的特性,所要考虑的因素和重点也将有所不同。分布式系统中数据的分布性和操作的并行性。所以既要利用分布并行特点来加快查询执行速度,又要尽量减少分布并行所带来的网络通信延迟代价[3]。 3.1.1 系统环境和约束条件及设计目标 (1)设计目标与系统环境

本分布式数据库管理系统是针对局域网环境,分布式数据库是指分布于局域网络,而非广域网络,分布粒度为库一级,并且基于Mysql 开源数据库来设计。目的是尽量避免数据库分布给查询执行带来的通信开销。 (2)约束条件

在此前提下,须考虑以下一些约束因素: 1.通信代价

分布式数据库不同于集中式数据库,所以通信

代价不得不考虑;但同时它又没有广域网环境中的分布式数据库的通信开销那么大。所以既不能只考虑磁盘输入输出I/O和CPU计算代价的开销,也不能只考虑通信代价的开销,通过参考权威文献和对单机查询代价与数据通信代价的试验分析,二者都应考虑,且同时并重。

由于是库级分布,不是表级分布,所以跨表操作始终只会在一个节点中进行处理。而跨库操作,目前Mysql数据库系统还不支持此种操作。因此,不存在查询时的服务器节点之间通信,因而省去对查询执行时通信代价的考虑。但是,当处理来自本节点没有的数据库时,就有可能了。在这种情况,传统的方式转发查询命令到其它节点上执行,这就要考虑通信代价的额外开销了

2.查询分解

由于是库级分布,某个数据库在某个节点存在,那么这个数据库的所有表都在这个节点上存在

(主本或副本),所以不考虑查询分解。

3.透明访问。

用户访问本分布式数据库系统感觉不到数据库物理位置位于何处,就像访问本地数据库(或集中式数据库)一样。

4.Mysql不支持的特性

Mysql不支持视图、子查询、存储过程和触发器、外键。

(3)优化目标

强调查询快捷,着眼于查询时间的开销;注重整体查询(整个分布式局域网系统和多路多线程的总体查询)效率和吞吐率,而非单机或具体某一条查询语句的执行效率。

系统合理假设

主要针对上层进行优化,而不针对下层,并假定已对查询语句进行了优化。因此,要考虑的关键问题便落在通信代价上,而其它磁盘输入输出I/O 和CPU计算代价的开销,是由下层查询优化去处理。

3.1.2 优化策略研究与设计

下面对启发式查询路径选择的优化策略进行详细探讨和设计。

(1)基本思想

根据最近一段时间的查询代价,推断局域网络中分布式数据库各节点当前的查询处理能力,实质上还是根据资源占用状况来选择一台较优的节点去执行查询处理。

在实现策略上,属于不断学习优化的过程。基于一条基本思想:最近访问的表格,在最近一段时间内,仍处于同一状态(忙),即很可能被再次访问。假如这种判断出现错误,也会仅仅因为一次的查询操作,而只误导一次,在下一次同样的查询,又会转入正确的优化判断。这样的“误判”,仅仅造成一次慢速的查询,不会有太大的损失。

优化的另一策略是尽量避免通信代价的开销,使一个查询尽量不经过查询中转,避免查询结果数据的通信。

(2)优化设计

1.节点代价信息表

为了记录上次访问表的查询代价,及其通信代价,需要设计以下一些表格如表3-1,以记录如下

一些上次访问的历史信息:

说明:(此处的通信代价不是指一次查询的所有数据的通信代价,是单位数据在当时的通信代价) 节点IP:指示局域网中分布式数据库所在的节点的IP地址

数据库:指该节点中存在有哪些数据库

关系表:指该数据库中存在有哪些表

用户数:指该表中当时有几个用户查询的计数

为使各节点便于查询,该表存在于局域网中每一个节点中,而且为了提高查询速度,更快的执行优化选择,该表必须常驻内存。表中记录信息随时更新。全局查询代价由Mysql数据库系统本身的THD 结构获得。某个表的用户计数是通过查询时锁表机制而获得。

值得说明的是为什么不能采用共享数据结构方式?如果分布式网络中各节点共享一张表,表面上看起来,可以节省存储分配,维护单一;实际上,由于该表访问比较频繁,特别是查询用户量增大的时候更是如此,而为了保证数据的一致性,各节点必须互斥访问该表,无论采用锁机制,还是简单的互斥信号量,都会造成访问因竞争而等待,致使服务器处理性能大为降低。因此,它是不符合分布式系统设计思想的。

表3-1 代价信息统计表

节点IP 数据库DB 关系表

table

全局查询代价cost

该表的负载数

count

... ... ... ... ...

2.代价的估算 1)操纵单表的查询语句

一个分布式数据库查询的执行,包括全局处理和本地处理两个阶段,相应的查询代价也包括全局处理代价和局部处理代价两部分,撇开CPU 的开销,可以一个公式近似简化为:

全局查询代价二通信代价+本地执行代价 但基于前面的考虑,不计通信代价,所以只有本地执行代价。

本地执行代价=CPU 计算时间+I/O 等待时间 由于CPU 计算时间相对很小,可以忽略,执行代价近似等于I/O 等待时间。 实现中,统计的代价为:

数据量

本地执行时间O I /=cost

I/O 数据量可以粗略的以一个表的所有元组数计。

2)操纵多表的查询语句

需要注意的是,如果一条查询语句需要操纵不只一个数据库的一个表时,到底以哪个表的代价为准,或者都考虑但多个表之间考虑的偏重程度可能不一样,并不平均对待。所以衡量多个表操纵的查询代价,不能简单的将多个表代价相加之和作为该查询语句的代价。统计操纵多表的查询语句的代价时,很难将总体代价定位在各个表上,一些繁琐的算法既费时,又不准确,所以,基于实际应用上的考虑,略去本次查询的代价统计,而只统计单表操作的代价。

多表属于同一数据库(对库级分布,一定位于同一结点上),理论上,任选其中一个表的代价来衡量,但在实际操作中,为了减少单个表带来的偶然误判,采用累加和。

多表不属于同一数据库(不一定位于同一结点上),此种情况,当然不能像上面一样,任选一个表的代价去衡量,也不能将各表的代价累加之和作为痕量的代价。只能根据哪个表的操作代价高来决定执行节点。但对库级分布的数据库不支持多表不属于一个数据库的情况。 3.负载

这里讨论的负载主要指用户数量,以表作资源对象,用在某个表上的等待的线程(用户数)来度量负载。

计数策略:由于多个查询可能操纵同一表,为

保证数据的一致性,本分布式数据库系统提供了互斥锁(读锁和写锁)机制。当一个操纵某个表的查询请求到来时,就将count 计数作加1操作,当该表的一个操作结束;当解锁一次,就将count 计数作减I 操作。然后定期更新此。ount 计数。为此,需要在THD 的结构里定义一个变量以保存该计数值。 4.统计策略

对代价的统计,取一定时间内,每次查询的代价的平均值。这里的一定时间即为统计周期,也是更新周期。同样,将每次查询的代价记入THD 结构里,也将代价的平均值保存到THD 结构里。以便全局优化器能方便获取所需信息。

采用动态更新,即服务器一启动便开始统计,在服务器运行过程中周期性更新。所以全局代价表从无到有,逐渐增多,随着时间的推移,使查询优化信息越来越完善,越来越准确。另外,如果本次查询的表在全局代价表里尚未存在记录,则该次查询代价立即记入全局代价表中,以被后来的查询参考。不必等到一定周期的统计。

某一次的统计可能不是准确的,但多次大量的统计,正确率总是符合正态分布的,从统计学的角度讲,是正确的、实用的。

另外,为了使统计更为真实和有效,本设计对一些很少出现的一些语句抛弃掉,不予统计。比如像CREATE DATABASE, DROP DATABASE, CREATE TABLEDROP TABLE, ALTER TABLE, CREATE INDEX, DROP INDEX ,等只有再创建数据库时,才会用到的一些命令语句;还有一些显示数据库及其分布信息的查询命令,以及全局视图查询命令,由于较少使用或不涉及具体操纵哪个表,也不予统计其代价信息,如SHOW DATABASE, SHOW TABLES, SHOW GLOBALDBS ,SHOW IPSBYDB 等。 5.更新周期

周期如何确定呢?周期过短可能造成统计的平均值不真实;但周期过长,有可能不能反应当时或最近的服务器节点的处理情况。所以周期既不能过长也不能过短,如何确定一个合适的周期呢?首先,这个周期不能是固定不变的,因为网络情况不是固定不变的,它会随着服务器节点负载而变化,而服务器节点的负载情况完全是随机的,随着用户数量的变化而变化。因此,为了适应变化多端的网络环境及节点资源负载情况,这里使用一种动态策略,以更准确更及时地反应服务器的处理能力。

从实际情况出发,如果前后几次波动很大,超

过一定的值,说明负载变化很频繁,这时,需要缩短统计周期;反之,可以加长统计周期。但为了防止变化过于平凡,造成“抖动”现象,一次不能偏离初始值过大。

怎样确定偏离多大呢?可以以本次估计的代价,与上次代价估计的偏离程度来作调整。当

时,

上次估计代价

上次估计代价

本次估价代价%-P ≥)

上次估价代价

上次估价代价

本次估价代价本次统计周期(下次统计周期-1+

=

这里的P 根据服务器运行情况,可以由系统管理员确定。同样,当

时,

上次估计代价

上次估价代价

本次估价代价%-P <

上次估价代价

上次估价代价

本次估价代价本次统计周期(下次统计周期--

1=

说明,如果本次统计代价与上次统计相比波动较大,偏离程度超过P%,周期变长;反之,周期缩短。初始值可以由系统管理员更改,默认为每30秒更新一次。 6.更新策略

为了保证优化信息的全局一致性,必须将各节点本地的最新统计的优化信息告知分布式系统中其它节点,使得对任何一个节点来,从理论上说,在当前的优化条件下,均会作出同样的选择(某个优化节点)。

由于本文讨论的分布式数据库系统是存在于局域网络中,其可靠性和速度比较高,所以本文采用类似于选路信息协议(RIP)中路由信息在路由器间更新的策略,即广播策略。它避免了设定一张全局唯一的代价信息表,它属于共享资源,必须互斥访问,需要使用互斥锁机制才能实现。

广播周期:为了防止广播风暴,不能频繁的广播消息,但是广播周期过于长,又会使全局优化信息得不到及时更新。设定一个阀值,当改变超过某一阀值时,才广播更新消息。 7.问题简化

1)关于数据库表的索引

如果为数据库的表创建了索引,则在查询执行

时的磁盘输入输出操作会与没有创建索引的表的代价低很多,因为查询时的扫描表分为两种:一种是表一扫描;另一种为索引一扫描。由于索引扫描时,能很快定位所需记录(元组数)所在磁盘块的位置,所以比将整张表的记录都读入内存来查询比较效率要高得多。但创建了索引的表的列较少,大多数表的大多数列没有创建索引。而且对同一个表,每一次查询统计均是以相同的方式统计,所以并不造成影响。

对一些很少使用或者查询不涉及具体哪个表的简单操作,不予统计其代价信息,以尽量减少或避免统计数据的不真实性。 2) CPU 计算代价

由于在查询执行中,CPU 计算时间,比起磁盘输入输出和通信代价来说很小,在通常的优化器设

计中,大都忽略不计,本优化也不予考虑。 8.非更新数据库操作的并行化处理

若某一刻,同时有多个用户查询请求访问同一表,并且是除插入、删除等更新操作以外的操作(非更新操作),将查询命令分发出去并行处理。

尽管单从代价来考虑,可能某一个服务器节点当前是最优选择的节点,但如果同一时刻(或某一段较小时间内)有多个客户请求到达,都要查询某个数据库的某个表,即竞争到同一张表上,必然形成等待队列。如果这些查询不都是更新性表操作,即非更新性操作是可并行化处理的,可以将非更新性操作分发到其它客户数较少的节点上去处理。

如果同一查询语句操纵多个表,遇到此种情况,优化选择时就排除该表不计算其代价。 9.全局优化信息表的存储组织

本表常驻内存,所以其存储组织不能有较大的浪费。如果采用链表方式存储,表大小可以随时增加或减少,内存可以随时申请和释放,得到充分利用,但是,查找速度较慢。另一方面,由于提高查询速度和查询效率是本优化设计的目的,所以如何组织存储结构才能提高查找性能(速度),是首要考虑的问题,所以使用数组存储方式就不太合适。而顺序存储方式比链表检索速度快,而且恰当的利用索引可以更高的提高查找速度。但由于不能事先预知该表信息的大小,而且可能动态改变,怎样解决数组固定大小的问题呢?由于此种变化并不频繁,可以使用new 操作重新分配改变大小后的内存空间,并将原数据拷贝过去。

而且对于本表来说,采用索引顺序存储方式,

比起完全不采用索引的顺序存储方式或链表存储方式来说,避免了较大的不必要的数据重复存储,如表的前两项“数据库名”和“表名”无须重复存储。

存储结构采用索引顺序表组织,分两级索引,如图3-1所示:

图3-1代价信息的索引顺序表存储结构

第一级索引为数据库名,按数据库名的字母顺序有序排列;再按照数据库分成多个二级索引,即表索引,按表名的字母顺序有序排列。然后根据表来查找查询所要操纵的表相应的代价及客户计数及所在节点的IP等优化信息。由于整个系统中不同的数据库、表和节点IP的数量并不太大,所以按照两级索引来查找顺序代价表,很快便能找到优化的表处理节点(IP )。图中右半部分为顺序表,按表的第一项(代价cost)有序排列。

关于索引顺序表的大小的确定:由于本表常驻内存,所以存储空间的分配不能又较大的浪费。所以为了充分利用存储空间,有两种分配方案:一种分配方案是,采用静态数组,但需要预先确定数组大小。在分配顺序表时,要预先确定表及索引的大小。如果是系统中第一个节点初始启动,可以在系统初启时,从Des Mysql底层预先获得数据库、各数据库的表及节点的数目,然后再分配存储空间并初始化各项数据,其中,表中的所有代价初始化为0}(系统初启时,没有任何负载,所以这也是合理的)。如果不是系统中的第一个节点初始启动,只将本节点的所有数据库的所有表设为0,而将其它节点的数据库的表的代价暂定为无穷大;在未来的一段时间内,可以通过别的节点对全局优化信息表的广播信息获取来得到更新。另一种分配方案是,采用顺序表的动态存储分配,在系统启动后,通过分布式系统中其它节点的广播信息,根据需要,临时申请存储分配。这样,表的大小可以不一次性分配完,可以由小到大,随着表信息的不断增加而增大。

10.索引顺序表的操作与互斥锁

1)操作

a)索引查找

才能实现对上述索引顺序表的操纵,设计怎样的数据结构才能达到索引的目的?要索引某一项,需要知道被索引的表的地址,即索引表存放在哪个内存地址段中,可以用一个全局变量来记录;然后才能定位某级索引的相对位置(即地址偏移),以及该级索引所覆盖的范围,即长度。

对第一级索引(数据库索引):

对第二级索引(表索引):

对顺序代价表:

代价信息标志(状态)

说明:对第一、二级索引中增加的“标志位”,指的是表(库)的当前状态:1表示该表(库)存在且可用;0表示该表(库)当前不可用;其中二级索引中新增加的“统计代价”,是指在更新周期内的统计代价,它只作临时记录用,不作优化信息用,等到周期一到,才决定是否将其代价值加到代价Cost 列上。二级索引中新增加的“表大小”,是指表的每条记录的大小与记录数数的乘积;新增加“统计次数”记录该表的被统计的次数。同样,对顺序表的“标志位”,1表示该代价信息可用;0表示该代价信息不可用。顺序代价表的“代价信息”,指的是上图中所列的代价Cost、客户计数Count和节点IP等信息。

注释:为什么要将“统计代价”和“统计次数”两项加到二级索引表中,而不加到顺序代价表中,有两个方面的原因:一是因为这两项查询使用频繁,每次查询都要查找某个数据库的某个表的这两项,用以统计查询代价:第二级索引表的表项数量比顺序代价表小,加之搜索级数低于到顺序代价表的搜索,所以加快了搜索速度。二是因为,将此两项放在顺序代价表里,浪费存储空间,因为只有本节点的数据库中的表才会被统计到(能够查询到本

表名标志(状态)地址(位置)长度表大小统计代价统计次数数据库名标志(状态)地址(位置)长度

节点的自然是本结点上有的数据库及其表),如果将此两项放在代价信息表里,那么必然造成大量的代价表项(其它节点IP)也分配了相同的此两项空白存储空间;而通过前两级索引,已经能够唯一区分本节点各个数据库的各个表的代价信息的记录。

b)更改

删除:如果某个表被删除,首先在标志位置0,然后,将后面的表项依次往前移动;同时,须将顺序代价表中的相应代价节点项全部置为0,但无需将后面的表项往前移动。尽管这种操作,可能较慢,但这样的操作毕竟极少发生,比起大量的查询查询操作来说,可以忽略它。而且对绝大多数查询用户没有删除表的权限。

插入:如果某个表的优化信息是索引顺序表中没有过的,这时,需要在索引表中增加一个表项,记录其优化信息。首先在该数据库的第二级索引表的尾部查找是否有标志位置为0的表项,如果有,将该表项填入,并调整顺序使其有序。如果没有,再在该数据库的第二级索引表段中查找是否有标志位置为0的表项,如果有,将该表项填入,调整顺序使其有序。如果仍然没有,就须重新申请分配更大存储空间,然后将原有的记录项移置过去,并将新的表项按序插入,使其保持有序。此种情况出现的机率虽然极少,但仍可以尽量避免,那就是采用预留策略。即对各个数据库的表段预留一定的空表项,以备插入新的表项用。预留表项的数目保持一个阀值,如果因为出现删除表项,而使得预留的空表项数目大于这个阀值一定数目,就将多余阀值的空表项删除,这时,就须要对索引表作移置操作;反之,如果,因为出现增加表项,而使得预留的空表项数目小于这个阀值一定数目,就将少余阀值的空表项增加一定数目,使其达到阀值数目,这时,仍然要对索引表作移置操作。做了这种防御措施后,就出现移置的机率就更少了。

以上讨论的策略对后面的数据库索引表和顺序代价表同样适用。对数据库索引表来说,稍微复杂一点,即多一个步骤。当某个库被删除之后,先将该库表项的标志位置为0(不可用);再将该库所辖的各表的标志位置为0(不可用);接下来,将置为0的各表所辖的顺序代价信息表段的所有代价信息表项也置为0(不可用)。然后再将顺序代价表置为0的表项“删除”,这里的“删除”是指将后面的表项前移,覆盖废弃的表项,并非真正的删除。接下来该“删除”第二级索引中的废弃(表项标志位置为o}的表项。最后将第一级索引中的废弃表项“删除”。注意,对顺序代价表,可以省去将表项置为0的那一步,直接将它们“删除”。对顺序代价表,当获知某个节点不可用,这时需要搜索整张顺序代价信息表的IP,将IP等于该节点IP的表项全部作“废弃”处理,在这种情况下,就不用先标记为0,再“删除”它们。

如何获知数据库、表以及节点是否“废弃”呢?采用定期监测的策略,在优化器的后台统计进程里周期性的查询分布式数据库系统的全局视图信息,获得有那些数据库,某个数据库有哪些表,有哪些节点目前可用。如SHOWGLOBALDB,SHOW TABLES,SHOW IPSBY DB等

2)访问锁

多个用户同时进行以上的访问操作,操作间须遵循一定的规则:查找操作之间可以共享该表,而更新操作之间或更新操作与查询操作之间则须互斥进行。为此,需要在操作间加锁机制:查找操作加读锁,共享锁;更改操作间加写锁,互斥锁。11.查询代价(查询时间)的获取

利用mydql本身提供的粗略估计执行时间,省去了额外的时间计量的开销。它是从服务器接收到用户查询命令开始计时,经过语法分析和查询执行,然后将结果集组装返回给客户端(Send OK)的整个过程所经历的时间。说它“粗略”,是指它是使用时钟计数的相对值,而不是系统的真正时间,即不是CPU或机器时间。但是,它服务器当前状态的运行性能,所以这对设计的算法并不影响,因为仅仅需要以某种计量单元为单位的相对时间,而无须当前的绝对时间。

[1]庞惠,翟正利.论分布式数据库[J].电脑知识与技术, 2011,Vol.7(ISSN 1009-3044):271. [2]赵光亮.基于半连接算法的分布式数据库系统查询优化技术[D].杭州:浙江工业大学,2013. [3]张旭中.分布式数据库查询优化技术[D].成都:电子科技大学,2003.

[4]Hector Garicia-Molina.数据库系统实现[M].杨冬青,北京,机械工业出版社,2001.

浅析分布式数据库查询优化

分布式数据库查询优化 【摘要】本文针对分布式数据库查询优化进行了分析与探讨,讲述了其特点,与原理供相关计算机方面人员参考。 【关键字】分布式、数据、查询、优化 一、分布式数据库及其特点: 分布式数据库系统是物理学上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来,共同组成一个统一大业的数据库系统。因此,分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。 一个分布式数据库系统应该具有如下特点:数据的物理分布性、数据的逻辑整体性、站点自治性 二、分布式数据库查询基本概念 1.分布式数据库查询优化的研究意义: 分布式查询技术主要把用户提交的全局查询请求翻译为几个相关节点都可以识别的本地查询请求,以及把各个节点的查询结果汇总返回的问题,它包括分布式查询处理和分布式查询优化。分布式查询处理研究整个分布式查询处理的过程和策略;分布式查询优化研究查询策略的优化问题,即如何从多种方案中选择查询代价最少方案。 分布式查询处理作为分布式数据库研究主要问题之一,它是用户与分布式数据库之间的接口,在分布式数据库中由于数据的分布与冗余,使得数据在各站点间的传输代价成为查询处理的主要矛盾;另一方面,数据的分布与冗余也增加了查询的并发处理的可能性,从而可以缩短查询处理的响应时间,提高处理速度。因此,与集中式数据库相比,分布式查询处理增加了不少新内容与复杂性。 2.分布式查询处理的层次结构: 分布式查询处理按不同的层次执行,符合分布式数据库系统的层次结构。分布式查询处理可分为如下所示四个层次结构。 (1)查询分解 查询分解是将查询问题(如SQL语句)转换成一个定义在全局关系上的关系代数表达式。这一层的做法与集中式DBMS相同,因为并未涉及分布问题。本层转换所需要信息在全局概念模式中得到。 (2)数据本地化 数据本地化是把一个在全局关系上的查询进行具体化到合适片段上的查询。这一变换所需要信息在分片模式和片段的分配模式中获得。 (3)全局优化 全局优化输入是分片查询,全局优化是找出分片查询的最佳操作次序,包括使得代价函数最小。全局优化一个重要方面是关于连接操作的优化,全局优化处理层输出是一个优化的、片段上的关系代数查询。这层转换所需要信息来自数据库的统计信息,包括各站点片段统计信息、资源信息和通信信息等。 (4)局部优化 局部优化由与查询有关片段的各个站点执行。它由该站点上的DBMS进行优化,采用集中式数据库系统中查询优化的算法,所需要信息来自于局部模式。 分布式查询优化通常在分布式查询层次结构中的数据本地化层和全局优化层。数据本地化阶段一般采用的是基于关系代数等价变换的优化算法。而全局优化阶段采用的算法,可具

分布式大数据库系统复习题

一、何为分布式数据库系统?一个分布式数据库系统有哪些特点? 答案:分布式数据库系统通俗地说,是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来,共同组成一个统一的数据库系统。因此,分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。一个分布式数据库系统具有如下特点: 物理分布性,即分布式数据库系统中的数据不是存储在一个站点上,而是分散存储在由计算机网络连接起来的多个站点上,而且这种分散存储对用户来说是感觉不到的。 逻辑整体性,分布式数据库系统中的数据物理上是分散在各个站点中,但这些分散的数据逻辑上却构成一个整体,它们被分布式数据库系统的所有用户共享,并由一个分布式数据库管理系统统一管理,它使得“分布”对用户来说是透明的。 站点自治性,也称为场地自治性,各站点上的数据由本地的DBMS管理,具有自治处理能力,完成本站点的应用,这是分布式数据库系统与多处理机系统的区别。 另外,由以上三个分布式数据库系统的基本特点还可以导出它的其它特点,即:数据分布透明性、集中与自治相结合的控制机制、存在适当的数据冗余度、事务管理的分布性。 二、简述分布式数据库的模式结构和各层模式的概念。 分布式数据库是多层的,国分为四层: 全局外层:全局外模式,是全局应用的用户视图,所以也称全局试图。它为全局概念模式的子集,表示全局应用所涉及的数据库部分。 全局概念层:全局概念模式、分片模式和分配模式 全局概念模式描述分布式数据库中全局数据的逻辑结构和数据特性,与集中式数据库中的概念模式是集中式数据库的概念视图一样,全局概念模式是分布式数据库的全局概念视图。分片模式用于说明如何放置数据库的分片部分。分布式数据库可划分为许多逻辑片,定义片段、片段与概念模式之间的映射关系。分配模式是根据选定的数据分布策略,定义各片段的物理存放站点。 局部概念层:局部概念模式是全局概念模式的子集。局部层:局部模式 局部模式是分布式数据库中关于物理数据库的描述,类同集中式数据库中的模式,但其描述的容不仅包含只局部于本站点的数据的存储描述,还包括全局数据在本站点的存储描述。 三、简述分布式数据库系统中的分布透明性,举例说明分布式数据库简单查询的 各级分布透明性问题。 分布式数据库中的分布透明性即分布独立性,指用户或用户程序使用分布式数据库如同使用集中式数据库那样,不必关心全局数据的分布情况,包括全局数据的逻辑分片情况、逻辑片段的站点位置分配情况,以及各站点上数据库的数据模型等。即全局数据的逻辑分片、片段的物理位置分配,各站点数据库的数据模型等情况对用户和用户程序透明。

数据库的查询优化方法分析-2019年精选文档

数据库的查询优化方法分析 i=r 随着计算机应用的深入 ,计算机技术的成熟 , 各种应用软件 的普及,应用数据也随着日常工作而迅速增长 , 作为数据仓库的 数据库的重要性也日益显著。 数据库系统作为管理信息系统的核心 , 各种基于数据库的联 机事务处理以及联机分析处理正慢慢的转变成为计算机应用的 最为重要的部分 ,根据以往大量的应用实例来看 , 在数据库的各 种操作中 ,查询操作所占的比重最大 , 而在查询操作中基于 SELECT 吾句在SQL 语句中又是代价最大的语句。如果在使用中 采用了优秀的查询策略 ,往往可以降低查询的时间 , 提高查询的 效率,由此可见查询优化在数据库中的重要性。本文就数据库查 询优化中的策略进行介绍及探索。 1 基于索引的优化 数据库的优化方法多种多样 , 不同的方法对提高数据库查询 效率也不相同。 索引作为数据库中的重要数据结构 , 它的根本目的就是为 了提高查询的效率。而优化查询的重要方法就是建立索引 因为查询而造成的输入输出开销 , 有效提高数据库数据的查 询速 度, 优化了数据库性能。然而在创建索引时也增加了系统时间和 空间的开销。所以创建索引时应该与实际查询需求相结合 , 这样 才能实现真正的优化查询。 1.1 判断并建立必要的索引 对所要创建的索引进行正确的 判断 ,使所创建的索引对数据库的工作效率提高有所帮助。为了 实现这一点 , 我们应做到以下要求 : 在熟记数据库程序中的相关 适合关系数据库系统的索引 , 这样就可以避免表扫描 , 并减少了 , 建立

SQL语句的前提下,统计出常用且对性能有影响的语句;判断数据库系统中哪些表的哪些字段要建立索引。其次 , 对数据库中操作频繁的表 , 数据流量较大的表 , 经常需要与其他表进行连接的表等,要进行重点关注。这些表上的索引将对 SQL语句的性能产生重要的影响。 1.2对索引使用的一些规则索引的使用在一些大型数据库系统中会经常使用到 , 这样可以有效的提高数据库性能 , 使数据库的访问速度得到提高。但索引的使用要恰倒好处 , 所以我们在使用索引时应遵守使用原则 : 建立索引可以提高数据库的查询速度, 但索引过多 ,不但不能实现优化查询 ,反而会影响到数据库的整体性能。索引作为数据库中实际存在的对象 , 每个索引都要占用一定的物理空间。所以对于索引的建立要考虑到物理空间容量以及所建立索引的必要性和实用性。 1.3合理的索引对SQL语句的意义索引建立之后,还要确保其得到了真正的使用 , 发挥了其应有的作用。首先 , 可以通过 SQL语句查询来确定所建立的索引是否得到了使用,找出没有使用到的索引。分析索引建立但没有使用的原因 , 使其真正发挥作

分布式数据库管理系统简介

分布式数据库管理系统简介 一、什么是分布式数据库: 分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。 分布式数据库系统有两种:一种是物理上分布的,但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的,也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的,这种系统可以容纳多种不同用途的、差异较大的数据库,比较适宜于大范围内数据库的集成。 分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS和分布式数据库(DDB)。 在分布式数据库系统中,一个应用程序可以对数据库进行透明操作,数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的 操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体:即在用户面前为单个逻辑数据库,在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲,不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看,一个分布式数据库系统在逻辑上和集中式数据库系统一样,用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上,有单个数据库管理系统(DBMS)管理一样,用 户并没有什么感觉不一样。 分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。 分布式数据库系统是一个客户/ 服务器体系结构。 在系统中的每一台计算机称为结点。如果一结点具有管理数据库软件,该结点称为数据库服务器。如果一个结点为请求服务器的信息的一应用,该结点称为客户。在ORACL客户, 执行数据库应用,可存取数据信息和与用户交互。在服务器,执行ORACL软件,处理对ORACLE 数据库并发、共享数据存取。ORACL允许上述两部分在同一台计算机上,但当客户部分和 服务器部分是由网连接的不同计算机上时,更有效。 分布处理是由多台处理机分担单个任务的处理。在ORACL数据库系统中分布处理的例 子如: 客户和服务器是位于网络连接的不同计算机上。 单台计算机上有多个处理器,不同处理器分别执行客户应用。 参与分布式数据库的每一服务器是分别地独立地管理数据库,好像每一数据库不是网络化的数据库。每一个数据库独立地被管理,称为场地自治性。场地自治性有下列好处: ?系统的结点可反映公司的逻辑组织。

数据库查询优化实验报告_SQLServer2008

SQL Server 2008数据查询的优化方法研究摘要 随着数据存储需求的日益增长,对关系数据的管理和访问就成为数据库技术必须解决的问题。本文主要论述关系数据库查询优化技术,并从它的优化技术进行深入探讨,对系统实现做了一定的论述,并进行了部分的程序实现。 关键词:数据库查询系统优化 引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统,它是一个全面的、集成的、端到端的数据解决方案,为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前,许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难,但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践,由于初期的数据库中表的记录数比较少,性能不会有太大问题,但数据积累到一定程度,达到数百万甚至上千万条,全面扫描一次往往需要数十分钟,甚至数小时。20%的代码用去了80%的时间,这是程序设计中的一个著名定律,在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略,往往可以使查询时间降为几分钟。而且我们知道,目前数据库系统应用中,查询操作占了绝大多数,查询优化成为数据库性能优化最为重要的手段之一。 影响查询效率的因素 SQLServer处理查询计划的过程是这样的:在做完查询语句的词法、语法检查之后,将语句提交给SQLServer的查询优化器,查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接,并生成若干执行计划,然后通过分析执行开销来评估每个执行计划,从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划,然后在合适的时间提交给系统处理执行,最后将执行结果返回给用户。所以,SQLServer中影响查询效率的因素主要有以下几种: 1.没有索引或者没有用到索引。索引是数据库中重要的数据结构,使用索引的目的是避免全表扫描,减少磁盘I/O,以加快查询速度。 2.没有创建计算列导致查询不优化。 3.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)。 4.返回了不必要的行和列。 5.查询语句不好,没有优化。其中包括:查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 SQLServer数据查询优化方法 1、避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary 是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: select name from employee where salary >60000

海量数据下分布式数据库系统的探索与研究

海量数据下分布式数据库系统的探索与研究 摘要:当前,互联网用户规模不断扩大,这些都与互联网的快速发展有关。现 在传统的数据库已经不能满足用户的需求了。随着云计算技术的飞速发展,我国 海量数据快速增长,数据量年均增速超过50%,预计到2020年,数据总量全球 占比将达到20%,成为数据量最大、数据类型最丰富的国家之一。采用分布式数 据库可以显著提高系统的可靠性和处理效率,同时也可以提高用户的访问速度和 可用性。本文主要介绍了分布式数据库的探索与研究。 关键词:海量数据;数据库系统 1.传统数据库: 1.1 层次数据库系统。 层次模型是描述实体及其与树结构关系的数据模型。在这个结构中,每种记 录类型都由一个节点表示,并且记录类型之间的关系由节点之间的一个有向直线 段表示。每个父节点可以有多个子节点,但每个子节点只能有一个父节点。这种 结构决定了采用层次模型作为数据组织方式的层次数据库系统只能处理一对多的 实体关系。 1.2 网状数据库系统。 网状模型允许一个节点同时具有多个父节点和子节点。因此,与层次模型相比,网格结构更具通用性,可以直接描述现实世界中的实体。也可以认为层次模 型是网格模型的特例。 1.3 关系数据库系统。 关系模型是一种使用二维表结构来表示实体类型及其关系的数据模型。它的 基本假设是所有数据都表示为数学关系。关系模型数据结构简单、清晰、高度独立,是目前主流的数据库数据模型。 随着电子银行和网上银行业务的创新和扩展,数据存储层缺乏良好的可扩展性,难以应对应用层的高并发数据访问。过去,银行使用小型计算机和大型存储 等高端设备来确保数据库的可用性。在可扩展性方面,主要通过增加CPU、内存、磁盘等来提高处理能力。这种集中式的体系结构使数据库逐渐成为整个系统的瓶颈,越来越不适应海量数据对计算能力的巨大需求。互联网金融给金融业带来了 新的技术和业务挑战。大数据平台和分布式数据库解决方案的高可用性、高可靠 性和可扩展性是金融业的新技术选择。它们不仅有利于提高金融行业的业务创新 能力和用户体验,而且有利于增强自身的技术储备,以满足互联网时代的市场竞争。因此,对于银行业来说,以分布式数据库解决方案来逐步替代现有关系型数 据库成为最佳选择。 2.分布式数据库的概念: 分布式数据库系统:分布式数据库由一组数据组成,这些数据物理上分布在 计算机网络的不同节点上(也称为站点),逻辑上属于同一个系统。 (1)分布性:数据库中的数据不是存储在同一个地方,更准确地说,它不是 存储在同一台计算机存储设备中,这可以与集中数据库区别开来。 (2)逻辑整体性:这些数据在逻辑上是相互连接和集成的(逻辑上就像一个 集中的数据库)。 分布式数据库的精确定义:分布式数据库由分布在计算机网络中不同计算机

分布式数据库技术在大数据中的应用复习过程

分布式数据库技术在大数据中的应用

分布式数据库技术在大数据中的应用 摘要随着当前运营商对数据管理和应用需求的不断增加,分布式数据库技术得到极大的发展。在本文中首先对当前大数据环境下的分布式数据库技术进行介绍,然后分析分布式数据库技术在大数据中的具体应用。 关键词分布式数据库;数据管理;数据处理 中图分类号 TP3 文献标识码 A 文章编号 1674-6708(2016)165-0108-01 随着当前移动互联网技术的迅猛发展,数据的种类和数量呈现快速的增长,传统的处理方式逐渐的不能够适应当前的发展需要,基于此种背景下,分布式数据库技术需要得到更快的发展,以达到对大数据的存储、管理以及分析等处理要求。 1 大数据中发展分布式数据库的意义 在面对当前的大数据时代,传统的集中式数据库已经逐渐的不能够满足人们的使用要求,需要找到新的处理方式来进行更新,分布式数据库就是在这样的背景下逐渐的被发展和应用。分布式数据库在使用中有着许多传统集中式数据库不具备的优点:第一,分布式数据库有着极为强大的扩展能力,这是传统数据库所不具备的,在数据的存储方面表现出巨大的优势;第二,来自于成本上的优势。

在大数据中,如果仍旧采用原有的数据库,在进行扩容的时候,会花费大量的资金,使得成本上花费巨大,而且所取得的效果也是有限的。分布式数据库则只需要较少的资金就能够完成扩容处理,占据着特别大的优势[1];第三,分布式数据库在用户上有着很大的优势,分布式数据库让人们对大数据的存储、分析和处理变得容易和快捷。 2 分布式数据库技术分析 在大数据中,分布式数据库技术得到极大的发展,也正是由于分布式数据库技术表现出来的先进性能,才使得分布式数据库得到广泛的使用。在分布式数据库中,其由很多个并行的处理单元组成,而且每个处理单元都是一个完整的系统,其中包括数据的存储,数据的分析等,对于每一个处理单元来说,其所处的位置和作用都是对等的,而且是相对独立的。混合存储技术:突破传统行存的限制,实现行列混合存储。该项技术对于分布式数据库的性能有着很大的提升,使得分布式数据库在运行速度和运行的灵活性上都有很大的提高。再就是智能索引技术,该种技术所占用的空间减少,并且能够很好的解决后面数据库慢的问题,不会对后面的索引数据造成影响[2]。除此之外,分布式数据库中还具有许多先进的技术,如并行处理技术、高效透明压缩技术等,都是传统数据库中所不具备

分布式数据库查询优化技术

分布式数据库查询优化技术 摘要在分布式数据库中,由于高可靠性和高速度性是其重要特点,所以对查询执行的要求也就更高。而查询执行中查询优化是执行的关键环节,查询优化在很大程度上决定查询的效率或快慢。本文讨论的重点是对分布式查询执行的全局处理策略进行优化,尽可能避免通信代价的开销,并着眼于查询执行的实际代价,从分布式系统中选出一个最优的执行节点。从查询执行的效果出发,通过统计的方式,不断从最近的查询执行代价学习纠正最近查询执行的统计代价,为查询的全局处理提供参考,以达到优化执行、提高执行效率和速度的目的。 1 分布式数据库概述 1.1 分布式数据库的定义 所谓分布式数据库系统就是由分布于多个计算机结点上的若干个数据库组成, 每个子数据库系统都是一个独立的数据库系统,它们都拥有各自的数据库、中央处理机、终端,以及各自的局部数据库管理系统,分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。简单的说,分布式数据库系统是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统,但在物理结构上是分布式的[1]。 1.2 分布式数据库系统的组成 如图1-1所示,分布式数据库系统由以下述成分组成: (1)多台计算机设备,并由计算机网络连接。 (2)计算机网络设备,网络通讯的一组软件。 (3)分布式数据库管理系统,它包括GDBMS、LDBMS、CM,除了具有全局用户接口由GDBMS连接外,还可以具有自治场地用户接口,由场地DBMS,并持有独立的场地目录。 (4)分布式数据库管理者(DDB),包括全局数据库(GDB)和局部数据库(LDB)以及自制场地的自治场地数据库。 (5)分布式数据库管理者(DDBA),它可分为二级,一级为全局数据库管理者(GDBA),另一级问局部或自治场地数据库管理者,统称为局部数据库管理者(LDBA)。 (6)分布式数据库系统软件文档,这是一组与软件相匹配的软件文档及系统各种使用说明和文件。 图1-1 分布式数据库系统的结构 1.3 分布式数据库系统的功能 通常的集中式数据库管理系统应具备以下几个基本的功能[2]: (1)数据库定义功能; (2)数据存取功能; (3)数据库运行管理; (4)数据库的建立和维护功能。 分布式数据库除了须具备以上集中式数据库的功能外,一般还须具有以下几个方面的功能: (1)分布在网络中的各节点的数据库,其物理位置对用户透明; 在用户眼里见到的只是整个系统中有哪些数据库,无论是本地还是远程数据库,用户操纵某一数据库就像操纵本地数据库一样。 (2)处于网络中的各数据库共享的数据应保证一致性:

分布式数据库系统(DDBS)概述.

分布式数据库系统(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适当增加数据冗余度

MySQL数据库查询优化技术

MySQL数据库查询优化技术 MySQL是高效能高稳定的开源数据库产品,由于其超低成本和操作简易便利,在互联网等行业被广泛使用,几乎99%以上的网站都乐于采用mysql作为后台数据库,自从被Oracle收购后,Mysql更是从站长们的宠儿一举成为企业级应用的红人。在当今灸手可热的BAT,Mysql被大量使用。对于想进入互联网行业发展的数据库工程师和DBA们,熟练的Mysql技术无疑是一块很好的敲门砖。炼数成金在过去已经成功举办多种数据库课程,覆盖Oracle,DB2和多种NoSQL数据库,现在再推出MySQL系列,更加丰富了课程线路,也希望可以为大家带来更多学习知识提升价值的机会。 公益性培训课程: 《MySQL数据库查询优化技术》课程概述: 该课程通过15次课程,系统地讲解MySQL数据库的查询优化技术 课程语言:SQL 课程大纲: 第1课数据库与关系代数 综述数据库、关系代数、查询优化技术 综述数据库调优技术 预计时间1小时 第2课数据库查询优化技术总揽 综述查询优化技术范围,包括查询重用、查询重写规则、查询算法优化、并行查询优化等 综述逻辑查询优化,包括子查询的优化、视图重写、等价谓词重写、条件化简、连接消除、非SPJ的优化等 综述逻辑物理优化,包括单表扫描算法、两表连接算法、多表连接算法、基于代价的算法等 初步理解MySQL的查询执行计划。 预计时间1小时

第3课查询优化技术理论与MySQL实践(一)------子查询的优化(一) 第4课查询优化技术理论与MySQL实践(二)------子查询的优化(二) 从理论看,子查询包括的内容和范围,建立清晰的概念 从实践看,MySQL的子查询优化技术的内容和范围,明确掌握子查询优化手段预计时间2小时,每小时一个课程段(子查询是SQL查询优化的重点内容,务必掌握好) 第5课查询优化技术理论与MySQL实践(三)------视图重写与等价谓词重写什么是视图重写?哪些类型的视图可以被优化?MySQL是怎么优化视图的?从而明白在MySQL中怎么写与视图相关的查询语句才能有好的效果? 什么是等价谓词重写?MySQL中怎么写WHERE子句有利于提高查询效率? 预计时间1小时 第6课查询优化技术理论与MySQL实践(四)------条件化简 什么是条件化简?MySQL中对什么样的条件自动进行优化?如何写出可利用索引的条件语句? 预计时间1小时 第7课查询优化技术理论与MySQL实践(五)------外连接消除、嵌套连接消除与连接消除 连接方式有些什么类型?不同类型的连接又是怎么优化的?外连接优化的条件是什么?MySQL中怎么写出可优化的连接语句?MySQL是否支持嵌套连接消除?MySQL是否支持连接消除?MySQL中书写SQL连接查询语句时的优化技巧。 预计时间1小时 第8课查询优化技术理论与MySQL实践(六)------数据库的约束规则与语义优化 数据库的参照完整性(CHECK t NULL等)。什么是语义优化?MySQL是否支持语义优化?怎么利用语义优化的思路人工进行SQL语句的优化? 预计时间1小时 第9课查询优化技术理论与MySQL实践(七)------非SPJ的优化

SQLServer数据查询的优化方法

SQLServer数据查询的优化方法聂文燕 摘要:SQLServer是一种功能强大的数据库管理系统,许多数据库应用系统都是以它作为后台数据库。本文在分析影响SQLSERVER数据查询效率的因素的基础上,提出了几种优化数据查询的方法。 关键词:SQLServer,数据,查询,优化 一、引言 SQLServer是是由微软公司开发的基于Windows操作系统的关系型数据库管理系统,它是一个全面的、集成的、端到端的数据解决方案,为企业中的用户提供了一个安全、可靠和高效的平台用于企业数据管理和商业智能应用。目前,许多中小型企业的数据库应用系统都是用SQLServer作为后台数据库管理系统设计开发的。设计一个应用系统并不难,但是要想使系统达到最优化的性能并不是一件容易的事。根据多年的实践,由于初期的数据库中表的记录数比较少,性能不会有太大问题,但数据积累到一定程度,达到数百万甚至上千万条,全面扫描一次往往需要数十分钟,甚至数小时。20%的代码用去了80%的时间,这是程序设计中的一个著名定律,在数据库应用程序中也同样如此。如果用比全表扫描更好的查询策略,往往可以使查询时间降为几分钟。而且我们知道,目前数据库系统应用中,查询操作占了绝大多数,查询优化成为数据库性能优化最为重要的手段之一。 二、影响查询效率的因素 SQLServer处理查询计划的过程是这样的:在做完查询语句的词法、语法检查之后,将语句提交给SQLServer的查询优化器,查询优化器通过检查索引的存在性、有效性和基于列的统计数据来决定如何处理扫描、检索和连接,并生成若干执行计划,然后通过分析执行开销来评估每个执行计划,从中选出开销最小的执行计划,由预编译模块对语句进行处理并生成查询规划,然后在合适的时间提交给系统处理执行,最后将执行结果返回给用户。所以,SQLServer中影响查询效率的因素主要有以下几种:1.没有索引或者没有用到索引。索引是数据库中重要的数据结构,使用索引的目的是避免全表扫描,减少磁盘I/O,以加快查询速度。 2.没有创建计算列导致查询不优化。 3.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)。 4.返回了不必要的行和列。 5.查询语句不好,没有优化。其中包括:查询条件中操作符使用是否得当;查询条件中的数据类型是否兼容;对多个表查询时,数据表的次序是否合理;多个选择条件查询时,选择条件的次序是否合理;是否合理安排联接选择运算等。 三、SQLServer数据查询优化方法 3.1建立合适的索引索引是数据库中重要的数据结构,它的根本目的就是为了提高查询效率。当根据索引码的值搜索数据时,索引提供了对数据的快速访问。事实上,没有索引,数据库也能根据SELECT语句成功地检索到结果,但随着表变得越来越大,使用“适当”的索引的效果就越来越明显。索引的使用要恰到好处,其使用原则有: (1)对于基本表,不宜建立过多的索引; (2)对于那些查询频度高,实时性要求高的数据一定要建立索引,而对于其他的数据不考虑建立索引; (3)在经常进行连接,但是没有指定为外键的列上建立索引; (4)在频繁进行排序或分组(即进行groupby或orderby操作)的列上建立索引;

分布式数据库系统知识点及习题

第9章分布式数据库系统 9.1 基本内容分析 9.1.1 本章重要概念 (1)分布计算的三种形式:处理分布,数据分布,功能分布。 (2)C/S系统,工作模式,技术特征,体系结构,两层、三层、多层C/S结构。 (3)DDBS的定义、特点、优点、缺点和分类;分布式数据存储的两种形式(分片和分配)。 (4)DDB的体系结构:六层模式,分布透明性的三个层次,DDBS的组成,DDBMS的功能和组成。 (5)分布式查询处理的查询代价,基于半联接的优化策略,基于联接的优化策略。 (6)分布式数据库的并发控制和恢复中出现的问题,以及处理机制。 9.1.2 本章的重点篇幅 (1)两层、三层、多层C/S结构。(教材P365-367) (2)分布式数据存储:分片和分配。(教材P375-377) (3)DDB的体系结构。(教材P378的图9.10,P381的图9.12) (4)基于半联接的执行示意图。(教材P389的图9.17) 9.2 教材中习题9的解答 9.1 名词解释 ·集中计算:单点数据和单点处理的方式称为集中计算。 ·分布计算:随着计算机网络技术的发展,突破集中计算框架,DBMS的运行环境逐渐从单机扩展到网络,对数据的处理从集中式走向分布式、从封闭式走向开放式。这种计算环境称为分布计算。 ·处理分布:指系统中处理是分布的,数据是集中的这种情况。 ·数据分布:指系统中数据是分布的,但逻辑上是一个整体这种情况。 ·功能分布:将计算机功能分布在不同计算机上执行,譬如把DBMS功能放在服务器上执行,把应用处理功能放在客户机上执行。 ·服务器位置透明性:指C/S系统向客户提供服务器位置透明性服务,用户

分布式数据库系统查询优化算法综述

网工102-韩伟彬-1006100162 分布式数据库系统查询优化算法综述 摘要:随着互联网和数据库技术的飞速发展,分布式数据库在计算机网络上的应用越来 越广泛,数据的查询也越叫复杂化,对查询的效率要求也越来越高。在分布式数据库中,查询处理方法的效率对系统的性能起着非常关键的作用,而在分布式数据库系统中,处理一个查询的代价主要是由进行通信的数据量来决定的,半连接是一种非常有效的工具(方法)来减少连接的代价,从而更好的减少通信的数据量。在这样一个分布式系统中,我们有能力分散那些数据(经常被不同的用户终端使用的)在不同的物理位置,同时可以通过查询的方式组合来自于不同站点的数据,假如在一个比较合适的系统中多个数据副本被使用,这样分散的数据将会产生一个比较合理的查询相应时间。 关键字:数据库技术,分布式,数据库系统,查询,优化算法。 一:分布式数据库的定义 分布式数据库是一个逻辑上完整而在物理上分散在若干台互相连接着的计算机上的数据库系统,各组件分布在网络的各个节点上,依靠特定的更新和检索机制进行数据库分布,数据库的所有性能都会显著增强。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来,共同组成一个统一的数据库系统。因此,分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。 分布式数据库系统有两个重要的组成部分:(1)分布式数据库和(2)分布式数据库管理系统。分布式数据库是计算机网络中各站点上数据库的逻辑集合。也就是分布式数据库是一组结构化的数据集合,在逻辑上属于同一个系统,在物理上分布在计算机网络的不同站点上,是集中与分布的统一。这个定义强调了分布式数据库的两种特性;(1)数据分布性。即这些数据库是分布在不同站点上的。这把分布式数据库与单一的集中式数据库别开来。(2)逻辑关联性。即这些数据库具有某些把它们联系在一起的性质。这把分布式数据库与驻留在计算机网络不同站点上的一组本地数据库区别开来。分布式数据库管理系统是分布式数据库中的一组软件,负责管理分布环境下逻辑集成数据的存取、一致性和完整性。同时,由于数据的分布性,在管理机制上还必须具有计算机网络通信协议的分布管理特性。 分布式数据库系统有两种: (1)在物理上分布的,但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。 (2)在物理上和逻辑上都是分布的,也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的,这种系统可以容纳多种不同用途的、差异较大的数据库,比较适宜于大范围内数据库的集成。

分布式数据库系统其应用(徐俊刚 第三版)重点课后习题

第一章 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分布式数据库系统的主要优点是什么?存在哪些技术问题? 分布式数据库系统优点:良好地可靠性和可用性;提高系统效率,降低通信成本;较大的灵活性和可伸缩性;经济型和保护投资;适应组织的分布式管理和控制;数据分布式具有透明性和站点具有较好的自治性;提高了资源利用率;实现了数据共享。

分布式数据库系统

分布式数据库系统 分布式数据库系统有两种:一种是物理上分布的,但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的,也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的,这种系统可以容纳多种不同用途的、差异较大的数据库,比较适宜于大范围内数据库的集成。 ----- ---- 分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。在分布式数据库系统中,一个应用程序可以对数据库进行透明操作,数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体,在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲,不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看,一个分布式数据库系统在逻辑上和集中式数据库系统一样,用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上,有单个数据库管理系统(DBMS)管理一样,用户并没有什么感觉不一样。 分布式数据库系统是在集中式数据库系统的基础上发展起来的,是计算机技术和网络技术结合的产物。分布式数据库系统适合于单位分散的部门,允许各个部门将其常用的数据存储在本地,实施就地存放本地使用,从而提高响应速度,降低通信费用。分布式数据库系统与集中式数据库系统相比具有可扩展性,通过增加适当的数据冗余,提高系统的可靠性。在集中式数据库中,尽量减少冗余度是系统目标之一.其原因是,冗余数据浪费存储空间,而且容易造成各副本之间的不一致性.而为了保证数据的一致性,系统要付出一定的维护代价.减少冗余度的目标是用数据共享来达到的。而在分布式数据库中却希望增加冗余数据,在不同的场地存储同一数据的多个副本,其原因是:①.提高系统的可靠性、可用性当某一场地出现故障时,系统可以对另一场地上的相同副本进行操作,不会因一处故障而造成整个系统的瘫痪。②.提高系统性能系统可以根据距离选择离用户最近的数据副本进行操作,减少通信代价,改善整个系统的性能。 分布式数据库具有以下几个特点: (1)、数据独立性与位置透明性。数据独立性是数据库方法追求的主要目标之一,分布透明性指用户不必关心数据的逻辑分区,不必关心数据物理位置分布的细节,也不必关心重复副本(冗余数据)的一致性问题,同时也不必关心局部场地上数据库支持哪种数据模型.分布透明性的优点是很明显的.有了分布透明性,用户的应用程序书写起来就如同数据没有分布一样.当数据从一个场地移到另一个场地时不必改写应用程序.当增加某些数据的重复副本时也不必改写应用程序.数据分布的信息由系统存储在数据字典中.用户对非本地数据的访问请求由系统根据数据字典予以解释、转换、传送. (2)、集中和节点自治相结合。数据库是用户共享的资源.在集中式数据库中,为了保证数据库的安全性和完整性,对共享数据库的控制是集中的,并设有DBA负责监督和维护系统的正常运行.在分布式数据库中,数据的共享有两个层次:一是局部共享,即在局部数据库中存储局部场地上各用户的共享数据.这些数据是本场地用户常用的.二是全局共享,即在分布式数据库的各个场地也存储可供网中其它场地的用户共享的数据,支持系统中的全局应用.因此,相应的控制结构也具有两个层次:集中和自治.分布式数据库系统常常采用集中和自治相结合的控制结构,各局部的DBMS可以独立地管理局部数据库,具有自治的功能.同时,系统又设有集中控制机制,协调各局部DBMS 的工作,执行全局应用。当然,不同的系统集中和自治的程度不尽相同.有些系统高度自治,连全局

分布式数据库的查询优化算法研究_

再执行局部数据的查询语句Q2,返回局部查询结果Q2’,最后对局部查询结果Q1’和Q2’根据公共连接属性no进行自然连接操作,连接结果就是最终的全局查询结果。 假设student_1表和student_2表分别有1000条记录,student_1表中满足age>25的记录有100条,则中间查询结果的数据记录有100+100=200条。由此可见,经过查询优化后,中间查询结果的数据记录大大减少了,下面就分布式数据库的查询优化技术进行详细的介绍。 3.3 查询优化算法 3.3.1 基于关系代数等价变换的优化算法 基于关系代数等价变换的优化算法使用启发式优化方法对关系代数表达式进行优化。 在关系代数表达式中,最花费时间和空间的运算是笛卡儿积和连接操作,为此,引出三条启发式规则,用于对表达式进行转换,以减少中间关系的大小[1]。 ①尽可能早地执行选择操作; ②尽可能早地执行投影操作; ③避免直接做笛卡儿积,把笛卡儿积操作之前和之后的一连串选择和投影合并起来一起做。 基于关系代数等价变换规则的优化算法的基本思想是: 把查询问题转变为关系代数表达式,分析得到的查询语法树,按等价变换规则优化(与集中式数据库的等价变换规则类似,这里不再详述)。算法首先利用关系代数等价变换规则,把查询树中的连接和合并操作尽可能上提,选择和投影操作尽可能下移到片段的定义处。然后判断是水平分片还是垂直分片,若为水平分片,则把分片条件与选择条件进行比较,去掉存在矛盾的片段,如果只剩下一个片段,就可以去掉一个并操作。若为垂直分片,则把片段的属性集与投影操作所涉及的属性集进行比较,去掉无关的所有片段。如果只剩下一个垂直片段,就可以去掉一个连接操作,从而达到优化查询的目的。 以全局数据模式中的学生表student(no,name,age,sex,class,grade)为例,先对学生表student进行垂直分片,使其分为student_1(no,name,age,sex)和

从GoogleSpanner漫谈分布式存储与数据库技术

从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),并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系,用户表中的一条记录(一

相关文档