分布式数据库解决方案

分布式数据库解决方案（共8篇）

1.分布式数据库解决方案 篇一

分布式|事务处理

分布式事务处理

张健姿 01-6-22 下午 04:48:27

美 国Sybase 公 司 于 今 年 七 月 发 布 了PowerBuilder 6.0 的Beta 版， 正 式 的 版 本也 将 于 不 久 的 将 来 推 出， 其 中 对 分 布 式 事 务 处 理 的 支持 是 新 版 本 中 增 强 得 最 多 的 功 能， 早 在1995 年，PowerSoft 公司 就 提 出 了 在“ 分 布 式 事 务” 方 面 的 发 展 战 略， 并 在1996 年 发 布 的PowerBuilder 5.0 中 支 持 了 分 布 式 事 务 处 理 的 功 能，笔 者 在 以 前 的 讲 座 中 也 曾 经 讨 论 过 有 关 如 何 创 建 分布 式PowerBuilder 应 用 的 问 题， 但 是 得 到 读 者 反 馈 意 见 却 很少。 以 往， 一 个 使 用PowerBuilder 开 发 客 户/ 服 务 器 应 用 软 件的 程 序 员 是 较 少 会 想 到 使 用 分 布 式 事 务 来 分 割 应 用的， 因 此 一 般 的 用 户 对 分 布 式 事 务 的 概 念 和 意 义 也 不甚 了 解， 这 里 我 们 来 进 一 步 讨 论 一 下 分 布 式 事 务 处 理及 其 应 用。 三 级 体 系 结 构 首 先我 们 介 绍 三 级 体 系 结 构 这 一 概 念。 所 谓 级 是 指 一 种 功能 划 分， 我 们 以 往 所 开 发 的 数 据 库 应 用 软 件 一 般 是 基于 客 户/ 服 务 器 结 构 的， 我 们 称 之 为 两 级 体 系 结 构。 也就 是 说 整 个 系 统 可 以 分 成 两 个 功 能 块， 第 一 级 包 括 了软 件 的 应 用 层 和 表 现 层， 驻 留 于 客 户 端。 我 们 使 用PowerBuilder 开 发 出 的 应 用 主 要 用 于 第 一 级， 运 行 于 客 户 端。 第 二级 包 含 数 据 库 和 服 务 器 的 组 件。 一 个 基 于SQL 的 数 据 库管 理 系 统 一 般 安 装 在 服 务 器 端， 应 用 软 件 在 服 务 器 端进 行 的 操 作 主 要 是 数 据 存 储 和 检 索。 在 两 级 模 式 中 会有 一 些 应 用 逻 辑 以 存 储 过 程 和 触 发 器 的 形 式 存 储 在服 务 器 端， 以 优 化 服 务 器 的 性 能， 但 绝 大 多 数 的 应 用逻 辑 是 放 在 客 户 端 的。 三 级模 式 是 将 系 统 分 为 有 三 个 不 同 的“ 级”： 表 现 级， 商业 逻 辑 级 和 数 据 访 问 级。 表 现 级 是 处 理 用 户 界 面 的 功能； 数 据 访 问 级 是 数 据 源， 在 通 常 状 况 下 指 数 据 库；商 业 逻 辑 级 是 新 增 加 的 一 级， 指 程 序 中 作 出 智 能 决 策的 那 一 部 分 功 能。 在 早 期 的 应 用 中， 这 一 部 分 的 功 能并 不 十 分 复 杂， 一 般 将 其 放 在 表 现 级 即 可， 另 有 少 量以 存 储 过 程 或 触 发 器 的 形 式 放 在 数 据 访 问 一 级， 而 随着 软 件 工 程 的 发 展， 软 件 的 日 益 复 杂， 软 件 中 功 能 增加 最 多 的 就 是 在 这 一 级。 一 个MIS 系 统 的 功 能 由 早 先 的对 某 一 个 表 的 简 单 查 询， 发 展 到 涉 及 多 个 表 的 分 类 统计 求 和， 根 据 复 杂 的 公 式 分 析 计 算， 进 行 决 策 支 持等， 如 将 这 些 增 强 的 功 能 仍 全 部 放 置 在 表 现 级， 会 使得 客 户 机 越 来 越 不 堪 重 负， 因 此 就 有 人 提 出 在 系 统 中将 商 业 逻 辑 分 离 出 来， 单 独 形 成 了 一 级， 这 就 形 成 了三 级 结 构。 随 着 三 级 结 构 的 进 一 步 发 展， 一 般 总 是 把运 行 在 商 业 逻 辑 级 的 软 件 编 写 成 为 了 一 个 为 客 户 机所 调 用， 能 够 完 成 一 定 的 逻 辑 功 能 的 专 用 软 件， 同 数据 库 服 务 器 相 区 别， 我 们 称 之 为 应 用 服 务 器。 在 一 个网 络 中， 可 以 有 着 多 个 不 同 功 能 的 应 用 服 务 器， 为 客户 机 或 其 它 的 应 用 服 务 器 提 供 专 业 服 务， 这 样， 三 级结 构 就 发 展 成 为 了N 级， 这 就 是 所 谓 的 分 布 式 计 算 方式。 分 布式 计 算 的 优 势： 采 用 分 布 式 计 算 有 着 多方 面 的 技 术 优 势， 包 括： 逻 辑封 装 性： 这 是 分 布 式 模 式 中 最 具 诱 惑 力 的 特 征， 这 种模 式 的 根 基 在 于 将 以 往 全 部 由 客 户 机 完 成 的 事 务 逻辑 中 的 一 部 分 从 客 户 端 分 开。 当 使 公 司 需 要 动 态 改 变一 个 应 用 软 件 的 商 业 逻 辑 规 则 时， 只 要 改 变 一 个 应 用服 务 器 的 程 序 即 可， 而 不 需 要 更 改 客 户 端 用 户 界 面，这 样 就 无 需 中 断 用 户， 为 最 终 用 户 重 新 发 放 新 的 界 面软 件 或 亲 自 上 门 为 其 安 装 调 试 并 重 新 培 训 用 户， 提 高了 工 作 效 率。 这 种 多 级 模 式 对 于 需 经 常、 快 速 改 变 应用 程 序 的 行 业 很 有 帮 助。 瘦 客 户 机： 这 种 类 型 的 应 用在 运 行 时 最 显 著 的 特 点 就 是 减 少 甚 至 消 除 了 传 统 的两 级 体 系 结 构 中， 以 客 户 机 为 中 心 或 称 为“ 肥 客 户” 的 模 式， 减 轻 了 客 户 机 的 功 能 负 担， 使 其 消 肿 成 为了“ 瘦 客 户”，

“ 肥 客 户” 是 用 户 感 到 十 分 苦 恼 的 事情， 用 户 为 使 用 更 强 功 能 的 软 件， 就 必 须 付 出 高 昂 的维 护 费 用， 不 断 地 为 个 人 电 脑 的 软 硬 件 设 备 升 级。近日 流 行 的NC 也 正 是 看 到 一 般 用 户 在 维 护PC 机 运 行 时 负担 过 重， 而 提 出 通 过 网 络 将 一 部 分 的 任 务 交 给 了 服 务器 完 成。 这 两 种 方 法 有 着 相 通 之 处。 性能： 性 能 的 提 高 是 三 级 模 式 最 终 被 用 户 采 用 的 主 要 原因。 将 复 杂 的 应 用 和 商 业 逻 辑 分 离 出 来 由 专 门 的 一 台应 用 服 务 器 来 处 理， 既 可 以 提 高 应 用 的 执 行 速 度， 也可 以 减 少 网 络 调 用 的 通 讯 量。 不 过 这 种 性 能 提 高 是 有一 定 代 价 的。 这 就 是 开 发 时 要 将 应 用 逻 辑 分 割 为 客 户端 逻 辑 和 服 务 器 端 逻 辑， 这 就 增 加 了 设 计 的 复 杂 性。 安 全性 管 理： 在 分 布 式 计 算 模 式 中， 由 于 所 有 的 商 业 逻 辑都 驻 留 在 服 务 器 端， 信 息 管 理 部 门 就 可 以 十 分 方 便 地监 控 服 务 器 的 运 行 情 况， 很 容 易 地 控 制 访 问 服 务 器 以及 与 服 务 器 应 用 打 交 道 人 员 的 数 量。 这 可 以 大 大 简 化管 理 员 对 系 统 的 管 理， 减 轻 系 统 维 护 的 工 作 量， 并 确保 系 统 的 可 靠 运 行。 分 布式 事 务 处 理 最 广 泛 和 最 成 功 的 应 用 当 数Internet/Intranet 技术 了， 尽 管 许 多 人 并 不 意 识 到Internet 就 是 一 个 三 级 体 系结 构 的 代 表。 随 着Internet/Intranet 使 用 的 不 断 深 化， 用 户 对Web 服 务 器 所 查 询 的 信 息 就 不 只 局 限 于 以 文 件 方 式 存 放在 服 务 器 端 的 静 态 的 超 文 本 文 件 了。 这 时 我 们 需 要 借助 关 系 型 数 据 库 来 存 放 变 化 的 数 据， 并 在Web 服 务 器 与数 据 库 服 务 器 之 间 以JDBC、CGI 等 协 议 建 立 起 两 者 的 连接， 使Web 服 务 器 能 够 实 现 对 数 据 库 的 即 席 查 询， 并 将结 果 返 回 浏 览 器。 我 们 可 以 发 现， 在 这 样 一 个Intranet 结构 中， 浏 览 器--Web 服 务 器-- 数 据 库 服 务 器 就 分 别 对 应 于客 户 端-- 应 用 服 务 器-- 数 据 库 服 务 器 三 级 体 系 结 构 中的 三 个 环 节，Intranet 就 是 一 个 典 型 的 三 级 体 系 结 构 的 应用。 因 此， 我 们 可 以 认 为，Internet 模 式 的 技 术 优 势 如 用户 界 面 简 单， 管 理 人 员 易 于 维 护 等 也 正 是 多 级 计 算 方式 的 优 势 所 在。 此 外， 由 于PowerBuilder 支 持 分 布 式 事 务 处理， 这 就 使 得PowerBuilder 很 容 易 地 支 持 了 作 为 分 布 式 事 务的 特 例---Internet 的 开 发 了。 分 布 式 应 用 的 开 发 尽 管分 布 式 计 算 是 一 个 较 新 的 概 念， 但 是 使 用PowerBuilder 开 发分 布 式 应 用 却 十 分 简 单， 只 要 您 会 使 用PowerBuilder 中 的 用户 自 定 义 的 不 可 视 对 象， 您 就 会 很 快 地 掌 握 分 布 式PowerBuilder 的 开 发。 在PowerBuilder 中， 应 用 服 务 器 一 端 的 功 能 都 是 通过 不 可 视 用 户 对 象 实 现 的， 开 发 人 员 可 以 将PowerBuilder 的自 定 义 用 户 的 对 象 放 于 应 用 服 务 器 一 侧， 被 称 作 远 端对 象， 在 客 户 端 放 置 该 用 户 对 象 的 代 理 对 象。 此 外，在 服 务 器 一 侧 有 一 个 新 的transport 对 象 用 于 监 听 任 何 一个 用 户 或 其 它 应 用 服 务 器 的 请 求， 在 客 户 端 有 一 个connection 对 象 用 以 建 立 同 远 端 对 象 的 连 接。 客 户 端 的 应 用 程 序通 过connection 对 象 连 接 应 用 服 务 器， 连 接 建 立 后， 客 户端 的 应 用 就 可 以 象 调 用 本 地 对 象 一 样 调 用 应 用 服 务器 上 的 对 象 函 数 了。 当 然， 我 们 这 里 指 的 用 户 可 以 是一 般 意 义 上 的 客 户， 也 可 以 指 应 用 服 务 器 以 一 个 客 户的 身 份 调 用 其 它 应 用 服 务 器。 远 端的 用 户 对 象 中 的 商 业 逻 辑 可 以 是 采 用PowerScript. 编 写 的，作 为 一 个 不 可 视 用 户 对 象 的 特 例， 这 个 对 象 可 以 调 用任 何 函 数 或 使 用 数 据 库 命 令， 它 也 可 以 使 用 不 可 视 的DataStore 来 封 装 数 据 库 访 问，PowerBuilder 5.0 可 以 支 持 除 可 视 对 象 以外 的 所 有 的 数 据 类 型。 在 客 户 端 使 用 这 种 形 式 调 用 就象 在 使 用 存 储 过 程 一 样 将 参 数 通 过 网 络 传 递 给 服 务器， 服 务 器 的 运 行 结 果 返 回 客 户 端。

2.分布式数据库解决方案 篇二

数据中心是企业对价值信息进行收集、存储、处理有机组合。数据中心电能巨大, 对供能可靠性要求高, 同时冷负荷需求大, 数据中心这些特点适合配套建设天然气分布式能源站。本文详细介绍了上海某数据中心建设天然气分布式能源系统的必要性及经济性。

2 数据中心负荷需求

上海某数据中心建筑面积10500m2, 其中主机房7000m2, 辅助区大约3500m2。

2.1 电负荷

数据中心电负荷需求主要包括:制冷系统主机房设备耗电、冷却塔水泵耗电、风机耗电、辅助设备耗电、建筑照明等常规设备耗电。根据数据中心提供资材料及参考国内类似已建数据中心相关负荷统计信息, 数据中心电负荷大约10000kW (扣除制冷负荷) [1]。

2.2 冷负荷

数据中心机房电子信息设备等工艺设备散热量很大且散热集中, 空调负荷主要为机房设备散出的显热, 即使在冬季也由于机房向室外散热量小于设备发热量而仍需供冷, 因而冷负荷随季节变化波动不大, 全年均需供冷[2]。数据中心冷负荷需求主要包括:机房主要工艺设备散热形成的冷负荷、新风引起的冷负荷、围护结构形成的冷负荷、照明散热和人体散热形成的冷负荷。根据数据中心资料分析、《电子信息机房设计规范》中负荷设计方法、参考国内类似已建数据中心相关负荷统计信息, 数据中心夏季冷负荷需求为8400kW, 冬季冷负荷需求为7700kW[2]。

2.3 热负荷

数据中心服务的供热范围包括辅助区和公摊区, 由于辅助区及公摊区大部分房间属于内区, 故夏季数据中心整体建筑对热负荷的需求很少, 根据项目提资材料分析及参考国内类似已建数据中心相关负荷资料, 数据中心冬季热负荷需求为120kW。数据中心负荷需求见表1。

kW

3 建设方案

分布式能源是以“效益规模”为法则的第二代能源系统, 它是“规模效益”为法则的第一代能源系统的发展与补充, 特别是以天然气为燃料的能源利用系统, 实行热电冷联产, 可以大幅度提高能源转换效率和减少能源输送损失[3]。天然气分布式能源是以燃机或者内燃机作为原动机, 设备 (余热锅炉或者溴化锂机组) 利用烟气余热向用户提供冷负荷与热负荷。

3.1 方案1

2台由A公司生产的单机容量为5.75MW内燃机配2台单机制冷量为4.87MW的烟气热水型溴化锂热组 (其中2台机组为补燃型) , 方案1装机示意图见图1。方案1系统性能参数分析见表2。方案1经济性分析见表3。

3.2 装机方案2

3台的单机容量为3.3MW内燃机配3台单机制冷量为3.3MW的烟气热水型溴化锂热组 (其中2台机组为补燃型) 。方案2装机示意图见图2。

数据中心分布式能源站系统性能参数分析见表4。方案二经济性分析见表5。

4 方案对比分析

4.1 技术方案比较

方案1采用2台由A公司生产的单机容量为5.75MW内燃机配2台单机制冷量为4.87MW的烟气热水型溴化锂热组 (其中2台机组为补燃型) , 整套系统发电气耗为0.152m3/kWh, 供冷气耗为28.06m3/GJ。

方案2采用3台由B生产的单机容量为3.349MW内燃机配3台单机制冷量为3.3MW的烟气热水型溴化锂热组 (其中2台机组为补燃型) , 整套系统发电气耗为0.161m3/kWh, 供冷气耗为25.7m3/GJ。

方案2整个系统采用3台机组, 对于数据中心处于不同阶段、不同时间段不同负荷时具有更加灵活的调节方式, 同时供冷气耗比方案1低, 对于冷负荷需求大的数据中心来说, 方案2更加适合。

4.2 经济性比较

从以上技术经济分析表格可以看出方案2的初投资比方案1小, 机组单位造价比方案1机组单位kW造价低 (总投资同时考虑上海市关于冷热电联供工程的补贴政策) ;方案2项目资本金财务内部收益率比方案1高, 投资回收期比方案1短, 综合技经分析方案2优于方案1。

4.3 效益分析

在数据中心建设冷热电联供系统有利于解决数据中心的能源供应紧张等问题, 保证数据中心供能安全, 降低用户用能成本, 数据中心冷热电联供能源站节能减排效益分析见表6。

天然气分布式能源站向数据中心供电电价比电网电价低0.2元/kW·h, 仅此一项, 数据中心年运行成本降低约1000万元。

5 结语

数据中心是高科技、高耗能单位, 不断增长的能耗问题制约着数据中心在经济发达地区的发展。天然气分布式能源系统具有清洁、高效特点, 系统提供电能的同时还向用户提供冷 (热) 能。上海某数据中心采用天然气分布式能源供能, 减少企业建设成本 (备用电源) , 降低企业运营成本。项目将设为上海乃至全国数据中心采用先进供能模式提供示范作用。

摘要：对上海某数据中心运行的能源需求进行了预测, 根据预测结果, 制定了天然气分布式能源站装机方案。

关键词：数据中心,分布式能源,经济效益,环境效益

参考文献

[1]谷立静, 周伏秋, 孟辉.我国数据中心能耗及能效水平研究[J].中国能源, 2010 (11) :42~45.

[2]黄森.数据中心空调系统节能研究[D].上海:同济大学, 2011.

3.分布式数据库技术应用研究 篇三

关键词：分布式；数据库；管理；数据

中图分类号：TP315 文献标识码：A文章编号：1007-9599 (2011) 07-0000-02

Application Research of Distributed Database Technology

Chen Xiangping

(Shengli Oilfield Company Dongxin Oil Production Plant,Dongying257000,China)

Abstract:With the development of computer network technology,distributed database technology is more widely used.This paper discusses the design is based on B/S structure of the integrated management information system the application of distributed database technology,and in the application process the principles of database design,structure and mechanism.

Keywords:Distributed;Database;Management;Data

分布式数据库技术是过去十几年中最重要的计算机发展成果之一。到八十年代中期，已出现了不少商品化的分布式数据库系统，如计算机公司等。尽管这些系统还不算完全成熟，但由于它们至少已经实现了分布和重复数据的透明管理、依靠分布式事务处理提高系统可靠性、依靠交叉查询和内部查询并行机制改善系统性能以及更容易和廉价的系统扩展，因而可以断定今后大多数组织将转向分布式数据库管理，集中式数据库系统将成为历史的过客。

一、分布式数据库结构模型

通常情况下，分布式数据库结构模型如图1所示。具体特征是：分布式数据库由分散在不同地域上的局部数据库和全局调度数据库两个强力自治的数据库功能实体有机合成。其中，局部数据库的设计实现多要配置集中式数据库管理系统（DBMS）和数据库（DB）。使用局部数据库主要完成用户专用数据存取的控制与更新，因此，各个局部数据库的有较强独立性；另外，局部数据库能够至少分享和执行一个全局调度数据库（节点中心库）所提供的全局应用功能，这种全局应用功能主要包括：远程信息检索调阅、公用信息随机存贮等[1]。

作为全局调度数据库多要配置分布式数据库管理系统（DDBMS）和数据库（DB）。该数据库部分主要完成数据库信才良的全局调度，并具体执行全局查询检索策略和并发应用管理策略。这里，全局查询检索策略主要完成用户查询语句转换和将其转变为一系列的可行数据库操作；并发应用管理策略主要完成数据库并发操作环境下的数据库操作管理与控制，并主要包括并发事务的排队处理与封锁管理等技术设计实现。

图1分布式数据库结构模型

从图1中可以看出：DDBMS主要包括网络数据字典、网络数据库管理、全局逻辑映射等功能实体；DBMS主要包括本地数据库管理、局部逻辑映射、存贮模式等功能实体。DBMS和DDBMS均应通过操作系统（OS）完成数据库的存贮访问与透明操作。

在分布式数据库开发设计过程中，网络数据字典至关重要，它不仅存有系统所需有关对象的描述信息和控制信息，以使系统能把用户对数据的高级查询转换成对相应存贮对象的低级操作，而且还应完成维护与管理功能，诸如数据分布、结构、使用和访问控制等维护和管理功能等。

关于分布式数据库中全局调度数据库与局部数据库的信息交互主要依靠两个条件支撑：1.利用全局逻辑映射与局部逻辑映射相接口，具体解决数据库结构转换和地域分片定位处理。2.数据库分布式功能实现与计算机网络环境设置密切相关，因此，作为分布式数据库的网络环境必须具有下述功能特性针对全局查询检索策略的优化设计，应对信息传输路径的优化选择提出可靠服务。针对网络数据管理，应在网络通信软件和数据库管理软件之问备有网络存取进程的必要接口服务。

二、分布式数据库技术在系统体系结构中的应用

（一）数据管理现状

由于生产管理需要，公司总部与各分公司之间经常要进行数据传递，公司总部需要动态掌握各分公司的日常生产数据。由于公司总部与各分公司处于不同城市，在业务上它们处理和存储各自的数据，如何处理分散的数据，实现公司总部与分公司数据更新同步，确保数据一致性、避免数据存储冲突是目前亟待解决的问题。

（二）数据库设计的基本原则

从全局应用的角度出发，将这些数据库自下而上构成分布式数据库系统，实现全局数据的完整性和一致性，各分公司仍然存放本公司的数据，总公司的数据库则存放所有业务数据，并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。该分布式数据库系统可以在对当前机构影响最小的情况下进行扩充，增加新的分公司时只需增加一个节点就可以了，同时也使得各处理机之间的相互干扰降到最低。

（三）数据存储

分布式数据库系统可以通过复制、分片和复制加分片三种方式存储数据，因为各数据库之间存在一定的数据冗余，又存在着差异，我们使用了复制+分片的方式进行数据存储。

1.数据分片

在分布式数据库系统中，将关系分片，有利于按用户需求组织数据的分布，目前的分片方式有水平分片、垂直分片、导出分片、混合分片等四种。我们根据不同的数据关系采用了不同的分片方式：（1）在总公司与分公司的数据关系中，由于分公司的数据是总公司业务数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。（2）在总公司数据库服务器与Web数据库服务器的数据关系中，数据是按照其应用功能来划分的，所以我们采用了垂直分片的方式。

2.数据同步

数据同步方式则根据系统需求使用事务复制和合并复制两种，由于分公司只存放本部门数据，数据管理和分析功能是由总公司的数据库服务器来实现，分公司只需将更新的数据发送到总公司的数据库即可，我们使用事务复制进行业务数据的同步，把分公司的数据库作为出版者和分发者，总公司的数据库作为订阅者，对分公司的数据建立快照代理，并在分发数据库中记录同步状态的信息。每一个使用事务复制的分公司数据库均有自己的日志读取代理，运行在分发者上并连接出版者[2]。分发代理的任务是将分发数据库中保持的事务任务直接推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布代理运行在分发者上并与订阅者相连。

（四）利用分布式技术实现事务处理

我们使用MS DTC作为事务管理器来协调各个服务器对事务的处理操作，为了减少网络故障对事务处理的影响，避免分布式事务造成不同服务器间数据的不一致，将分布式事务的处理过程规定为两个阶段，即准备阶段和提交阶段，就是常说的两阶段提交。在进行分布式事务处理时，我们首先在服务器端用Transact SQL脚本程序BEGIN DIS－TRIBUTED TRANSACTION语句启动一个分布式事务，将该服务器作为分布式事务管理服务器，然后脚本程序对连接服务器执行分布式查询或远程服务器上的存储过程，分布式事务管理服务器会自动调用MS DTC，使远程服务器参加分布式事务处理。当脚本程序执行COMMIT TRANSAC－TION、COMMIT WORK、ROLLBACK TRANSAC－TION或ROLLBACK WORK语句时，分布式事务管理服务器将再次调用MS DTC，用它来管理两阶段提交进程，使连接服务器和远程服务器提交或回滚事务。例如在业务系统中，如果主体数据库管理系统发现该数据在有重复录入，则需将该信息插入数据重复记录表中，同时在对应的局部的数据库中将该条记录的状态设为无效。我们在局部的数据库（DBServer1）中建立存储过程update-policy更新数据状态，在主体数据库服务器（DBServer）上执行以下脚本程序，启动一个分布式事务insert-reject系统执行insert-reject事务向DBServer中的reject表插入一条记录，同时更新对应的局部数据库中的对应数据表status字段，该事务使系统数据的完整性得到了保证。

三、结束语

分布式数据库技术引入系统体系结构中的应用后，有效的解决了总体和部分之间数据分散和集中管理的矛盾，实现了数据的共享和交换，有关分布式特性设计与分布式计算机网络环境的强力支撑能力密切相关。分布式数据库技术决非独立存在，它的应用与网络环境密切相关，或说两者正在融于一体。事实证明，分布式技术在远程数据管理中具有不可替代的作用。

参考文献：

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

[2]刘志敏.Oracle数据库应用管理解决方案[M].北京:电子工业出版社,2002

4.分布式数据库解决方案 篇四

一、背景概述

随着政府上网、电子政务的不断普及和深入，IBM公司的Lotus Domino系统在国内得到广泛的应用。其中不乏大型的、跨地域的企事业单位或集团公司应用案例。这些案例一般采用分布式系统结构，即分布在全国各地的分支机构分别设有独立的数据库服务器，各地数据库服务器采用数据库同步复制的方式更新本地数据库复本内容。从而使得各地终端用户及时、快捷、可靠地访问到最新公告、新闻等。

本文结合呼和浩特铁路局客运公司办公自动化系统案例讨论基于IBM公司的Lotus Domino技术构建的分布式OA系统中数据库之间的同步复制技术。

二、几个概念

IBM公司的Lotus产品包含Lotus Domino Server，Lotus Notes，Lotus Domino Administrator和Lotus Domino Designer。Lotus Domino Server为后台数据库平台，Lotus Notes为客户端，Lotus Domino Administrator为系统管理平台，Lotus Domino Designer设计开发工具。先介绍几个Domino中和同步复制有关的概念。

1、复制

Notes允许在多个服务器或工作站上保存数据库的多个拷贝，这些拷贝称做“复本”。它们使各个地方的不同网络上的用户共享相同的信息。复本与文件的拷贝不同之处在于在复制时源文件与其复本具有相同的复本标识符。

复制是在复本之间共享更改信息的过程。复制时，Notes通过把更改信息从一个复本拷贝到另一个复本来更新复本。最终，Notes 使所有复本保持一致。可以选择在复本拷贝之间进行复制，这时两个复本都发送并接收更新信息，或者选择仅从一个复本复制到另一个复本。

也可以定期安排复制，或者根据需要手动进行复制。复制可以在两台服务器之间或者在服务器和工作站之间进行。如果设定为定期进行完整复制，那么 Notes会根据时间使所有复本保持同步。

2、复本标识符

复本与源文件或数据库有相同的复本标识符。这是数据库的复本与拷贝的区别所在，因为有共同的标识符才能使复本与源数据库之间可以复制更改信息。如果数据库的两个拷贝具有不同的复本标识符，则不能在它们之间进行复制。

3、复制冲突和保存冲突

在复制之间，如果有两个或多个用户对相同文档的不同复本进行了编辑，就会导致复制冲突。而保存冲突则是在两个或多个用户同时编辑服务器上同一个数据库的同一个文档时发生。当发生复制冲突或保存冲突时，Notes 将在视图页面左边把发生冲突的文档标注出来。

Notes对复制冲突的处理是这样的，在两个或多个用户编辑并保存同一个文档之后，下次进行复制时，Notes 将编辑和保存最频繁的文档指定为主文档，而将其他文档显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。如果用户在一个复本中编辑并保存了某文档，然后另一个用户将该文档删除，则认为该文档是被删除的。然而，如果文档被编辑和保存了多次，或者在该文档被删除之后又被另一个用户编辑和保存过，则把编辑过的文档作为主文档。

Note对保存冲突的处理如下，当多个用户同时打开相同的文档进行编辑时，Notes指定最先保存的文档为主文档。当另一个用户试图保存同一文档时，Notes 就会提示该用户把它作为“保存冲突”文档来保存。如果用户这样做了，那么 Notes 将它显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。

根据笔者的经验，在实际开发过程中，我们应该通过设计控制保存冲突，避免文档产生“保存冲突”的答复文档。对于复制冲突可以设置数据库合并复制冲突，这样如果产生增量改动，服务器在复制过程中会自动合并冲突。需要说明的是，Notes在进行复制时，并不是传统意义上的完全拷贝，而是一系列的规则进行增量的合并。

4、复制类型

Domino中支持四种不同的复制方式

拉入推出：是一个双向过程。此过程进行时，呼叫服务器从响应服务器拉入更新，然后向响应服务器推出自己的更新。使用“拉入推出”时，呼叫服务器上的 Replicator 任务执行所有的工作。拉入推出是系统缺省的复制方式。

分别拉入：是两个服务器交换更新的双向过程。使用“分别拉入”时，两个复制器（一个在呼叫服务器上，另一个在响应服务器上）共同进行复制工作。

只推出：是呼叫服务器向响应服务器推出更新的单向过程。单向复制总是比双向复制耗时少。只拉入：是呼叫服务器从响应服务器拉入更新的单向过程。单向复制总是比双向复制耗时少。

三、案例

笔者曾经参与呼和浩特铁路局客运公司办公自动化系统的设计、开发和实施工作。呼和浩特铁路局客运公司包括三个信息中心，分别在呼和浩特市、包头市和东河区三个地方，三地之间通过64K的DDN专线连接。因为带宽的限制，用户远程访问速度成为本系统的瓶颈，经过再三论证，我们决定构建分布式数据库存储架构，采用后台数据库实时同步复制技术使三个异地服务器内容一致，将远程访问转化为本地访问，从而提高终端用户访问速度。

详细步骤如下。

1、安装服务器

在三地信息中心分别安装Domino服务器，服务器的详细配置并不复杂，读者可以参阅相关资料，一般情况下按照安装配置向导四步就可以快捷配置完毕。注意三台Domino服务器不要同名，其简单拓扑结构如下：

图中呼市处于相对中心的位置，所以呼市和包头之间，呼市和东河之间分别建立了互推复制机制，为了降低网络负担和流通环节，没有建立包头和东河之间的复制，各地直接通过与呼市同步来保持三地数据的一致。一般而言，如果各分支机构处于平等位置，互相之间的数据流量相当，也可以两两之间建立复制机制。

2、建立服务器之间的连接

对于两个服务器之间进行的复制，应创建一个“连接”文档来指定进行信息交换的方式和时间。“连接”文档存储在“Domino 目录”中。一次仅使用一个“连接”文档来处理每对服务器之间的所有复制。创建不必要的“连接”文档会增加网络传输量和阻塞。

缺省情况下，邮件路由和复制都已被启用，但是可以更改此设置并使用单独的“连接”文档来安排每项任务。这样，就可以分别控制复制和邮件路由的特定时间、时间范围或重复间隔，并根据需要增加或减小这些设置。

怎么保证服务器之间的连接能顺利的连通？实际上对于物理连接形式Domino并不关心，也就是说物理上无论通过什么连接方式，专线、光纤、X.25、电话拨号等，只要TCP/IP通，简单说只要能Ping通，就能够保证服务器之间顺利连接。

下面给出了建立服务器之间连接的操作步骤和主要参数的设置说明：

A）在 Domino Administrator 中单击“配置”附签。

B）在“使用目录”域中选择连接服务器的“Domino 目录”。

C）单击“服务器”，然后单击“连接”。

D）单击“添加连接”。

F）关键域配置描述：

域输入

源服务器连接服务器的名称

使用以下端口连接服务器或源服务器使用的网络端口（或协议）名称

使用优先级选择一个：“一般”（缺省）“低”

目标服务器响应服务器的名称

可选网络地址与所选协议相适应的目标服务器的地址。对于 TCP/IP，应使用完全有效的网络域名称（首选）或 IP 地址（例如：HR-E.Acme.com 或者 192.22.256.36）。

对 TCP/IP 或其他需要特定网络地址的协议，建议填写此域。

复制类型缺省情况下，Domino 的复制方向为“拉入推出”。但根据实际情况，为了平衡服务器之间的负载，充分发挥每个服务器的性能，我们可以设定双方互推或者互拉，本例中我们采用服务器双方互推的方式，即每个服务器上的连接复制类型都是由源服务器向目标服务器推出。

复制文件/目录如果为空，则服务器将DATA目录下的所有存在复本的数据库全部进行复制，否则填写哪个库系统就复制哪个库。

安排在安排中可以设置连接时间、重复间隔、每周复制日期等参数。可根据实际情况设定，本例设置为每日8：00到晚上10：00连接，连接期间每一小时进行同步复制或服务器依据增量自动复制，非连接时间服务器处理其他性能调优动作，如更新数据库索引等。

H）保存文档。

3、建立数据库复本

连接建立成功以后，保证服务器之间可以进行通讯了，下一步就是对要进行同步的数据库建立复本，当建立了复本以后，通过连接设定就能保证异地各个复本之间的数据完全一致。

这里需要说明的是，我们在第一台服务器上建立了一套数据库系统，对于需要同步复制的所有数据库，在其他服务器上只需要产生他们的复本，而不能再在每台服务器上分别创建相同的数据库。在本例中我们在呼市客运公司信息中心安装配置好第一台服务器后，在包头信息中心和东河信息中心的Domino服务器上则通过呼市信息中心服务器建立各自本地所有需要的数据库复本。

如果要在本地Domino服务器上创建源Domino服务器的复本数据库，需要本地服务器的系统管理员具有对源服务器访问和创建复本的权限，因为Domino对权限控制很严格，尤其是多域用户之间的访问，其目的就是为了充分保证系统的安全性。那么怎样才能具有这样的创建复本的权限呢？需要具有两个基本的存取权限就可以在本服务器上创建源服务器的数据库复本，一是源服务器配置中允许本地服务器的系统管理员访问，二是允许本地服务器的系统管理员创建数据库复本，这两个权限由源数据库的系统管理员设置给目标数据库的系统管理员。结合本例，需要在包头信息中心的服务器上建立呼市信息中心的数据库复本，则首先在呼市信息中心的服务器上配置“当前服务器”文档。

A）在 Domino Administrator 中单击“当前服务器”文档。

B）单击“编辑服务器”

C）选择“安全”标签页，填写以下两项：

域输入

访问服务器本例为包头信息中心系统服务器名称及管理员的用户名称

创建数据库复本同样是包头信息中心系统管理员的用户名称

D保存后退出。

接下来就可以在包头信息中心的服务器上创建源数据库的复本了，这步动作比较简单，选择源数据库，从菜单中执行创建复本功能即可，这里不在详细描述。

同样的处理在东河的服务器上如法炮制一遍，则所有数据库复本成功建立完毕。

4、复制测试

完成以上三步，配置就全部完成，接下来就要测试一下配置是否完全成功以及配置是否生效。我们测试主要包括两个内容：一是测试连接是否成功，能否进行复制动作。二是测试设置的复制安排是否按照预定生效。

A）进行第一项测试的办法是在Domino的控制台上，使用Domino的系统命令，进行数据库的推、拉测试，检查复制是否能成功进行，命令格式如下：

拉入复制

语法：Pull servername [databasename]

描述：强制从指定服务器到本地服务器进行单向复制。通过在命令行中包括单个数据库名称，将其从特定服务器单向复制到本地服务器。发起复制的服务器从指定的服务器接受数据，但不能申请将自己的数据复制到其他服务器上。该命令重设在“Domino 目录”中预定的任何复制，而强制一台服务器与发起复制的服务器立即进行复制。如果可能，请输入服务器完整的层次结构名称。

推出复制

语法：Push servername [databasename]

描述：强制进行从本地服务器到指定服务器的单向复制。也可以通过在命令行中包括要复制的单个数据库名称，来将其从本地服务器单向复制到特定服务器。发起复制的服务器将数据发送到指定的服务器，但不申请获得数据。该命令可以重设在“Domino 目录”中预定的任何复制，而强制一台服务器立即与发起复制的服务器进行复制。如果可能的话，请指定服务器完整的层次结构名称。

B）第二项测试通过将连接文档的安排时间设置为两分钟进行一次，同时观察Domino的系统控制台，查看服务器的动作，以确保安排设定生效。正确的结果是从控制台上能看到系统报告复制过程。

按照以上实例说明进行，没有任何问题。

四、结束语

5.分布式数据库解决方案 篇五

1 分布式数据库系统概述

1.1 分布式系统

分布式系统主要是将各自独立运行的计算机进行分组，并保证计算机之间能够实现对数据方面的资源共享，促进协同合作发展。这就需要在每一台计算机上安装分布式系统软件，保证上述内容得以实现。其中，关于分布式软件系统，是在通信网络环境下能够互联的多处理体系接口之上进行任务执行，其包含的内容主要为分布式操作系统、分布式程序设计语言、编译系统、分布式文件系统以及分布式数据库系统等内容[1]。

其中，关于分布式数据库的内容，主要是位于各个计算机节点之上的各数据库内容所构成，通过有效的控制措施实现对子数据库系统的控制。但分布式数据库在使用的过程中又可以将其看为一个整体，保证各节点之间互联。

1.2 模型结构分析

6.分布式数据库解决方案 篇六

分布式网络系统中的数据访问设计与优化*

张均东，任 光，陈 健

(大连海事大学 轮机工程学院，辽宁大连 116026)

摘 要：

在基于局域网的大型分布式仿真和控制系统中，包括数据库服务器在内的各计算机之间的信息交互方案的设计是系统性能优异的关键，尤其是在计算机数量较多或待交互的单位时间信息量较大时更为重要。计算机间的信息交互涉及各机间的共享数据的读取、存贮和更新等方面的内容，需采取有效的系统规划、实时通讯和快速数据库访问等手段解决。本文全面论述了有关内容，给出了有效的解决方案。

关键词：网络系统、信息交互、优化设计

1 前言

随着计算机和网络技术的不断提高，使用基于局域网的，分布式的计算机系统对大型、综合或复杂的工业过程和运行环境进行系统仿真与运行模拟以及控制已越来越普遍。由于这样的仿真与控制系统一般规模庞大或过程复杂，单独一台计算机无法完成整个系统任务，需要多机参与，构成计算机网络，通过网上信息交互共同协调完成整个仿真与控制任务。各机之间信息交互的方式、频率和数量决定了整个网络系统的综合性能。由于在这样的系统中，机间的信息交互一般都非常频繁，各机都要面临数据更新、系统运行、结果存贮等过程的快速性问题，因此有关的设计是非常重要和关键的。

2 系统规划与设计

无论是仿真还是控制系统，合理的系统和数据规划至关重要。通过系统和数据规划可以优化系统设计，解决各机任务均衡，资源充分利用等问题，在兼顾可靠性、安全性和故障可诊断性的同时充分发挥系统的整体效率和性能，并容许具有一定的可扩展性。

目前有许多分布式仿真和控制系统采用以数据库为中心的设计方案。在这种设计方案中，网上的交互信息通过数据库来进行，首先由产生交互信息的机器存入数据库，然后由需要该交互信息的机器从数据库中读出来完成一个信息交互或更新过程。由于该信息交互通过一个中间环节即数据库来进行，因此在网上的计算机数量较多或程序要求的数据更新较多较快时，易造成数据冲突和网络堵塞，极易导致系统运行迟缓或死机，成为整个系统性能的瓶颈。

当然以数据库为中心的分布式仿真和控制系统也有其优点，其编程思路比较简单清晰，容易被人理解和掌握。对于网上信息交互量不多的系统，可以采用以数据库为中心的`系统，同时可以通过数据规划合理地分配各计算机的任务，使用一些编程技术来降低网上的信息流量，提高系统的性能。例如在程序中应尽量使用全局变量创建公用数据库连接，避免每次不必要的数据连接重建时间。

如果系统较大、网上信息交互量较多或对系统实时性和可扩展性要求较高时，应采用实时网络数据通讯的设计方案。在以数据库为中心的系统设计方案中，由于数据的变化首先要存入数据库，然后被其它程序访问才能刷新，经历了数据库存取这一中间环节。如果网上有多个应用程序都需要知道该数据的变化，则都必须通过数据库访问才能更新。这样就浪费了许多网络资源，容量造成瓶颈。在采用实时网络数据通讯的设计方案中，通过网络实时通讯来解决网上各机器间的数据交互与刷新问题，其中对于多台机器都需要的数据变化通过网络广播的方式，以定时和数据变化实时触发传送的机制向所需机器通知该数据已发生变化和具体的数值;对于只存在两台机器之间的信息交互可采用点对点的方式进行通讯。通讯的数据格式和组织可以自行定义。因此，与以数据库为中心的方案相比，该设计方案减少了因数据刷新所需的多次访问问题，大大减少了数据流量，同时网络传输还可以增加数据正确性和合法性校验，为操作者或系统管理员及时提供系统信息和出错信息，便于系统故障诊断和系统调试。

如果把各子系统初始化数据都保存在服务器的数据库中，则各机一起启动时，由于都需要建立数据库链接，读取其中的初始化数据，容易造成起动时间过长的现象。为此，对于不必要存于服务器的数据可存于本地数据库中，本地数据库可采用ACCESS数据库。对于一般不变的系统初始化数据也可以备存到本地数据库中，供日常程序起动时使用。如果系统的初始化数据进行了更新，可以编制一段程序，根据数据库服务器的数据库版本号来更新本地数据库。无论何种方案，数据库的访问总是不能避免的，如何提高数据库的访问速度非常值得研究。

3 提高数据库访问速度(以SQL数据库为例)

客户机程序一般采用VC++，VB

，PowerBuilder，Delphi等支持访问数据库的集成开发环境进行开发。在编写客户端程序时，一般通过ODBC(Open Database Connectibvity) API，RDO(Remote Data Objects) [5]，ADO(ActiveX Data Objects) [5]访问数据库，查询或修改数据库中的数据。其中ODBC API是被人们广泛接受的用于数据库访问的应用程序编程接口。具有访问数据库速度快效率高，但编程复杂的特点;远程数据对象(RDO)对ODBC API函数进行了封装，为编程人员提供了一个访问远程数据库的高级接口，在程序中通过该对象可轻松对数据库进行远程访问。组件对象(ADO)不仅继承而且发展了RDO，它不但具有访问远程数据库的能力，而且还具有访问其它数据提供者(不一定是数据库，可能是其他文件或其他应用程序所提供的数据)的能力。在VB中可很方便的使用RDO和

ADO来访问数据库，但访问数据库效率不高，速度较慢，灵活性也差。为了满足系统的要求经常需要提高访问数据库的速度，具体方法有：

3.1 使用ODBC API函数

由于ODBC API函数的入口参数表中有些参数需要传递指针，而VB不支持指针，因此在VB中调用ODBC API函数会有一定的限制。另外，VB的字符串内存存储格式与C语言不同，而ODBC API函数是用C语言开发的，这也限制了VB和ODBC API

函数之间的数据交换。为此需要开发一个动态链接库(Dynamic Link Library - DLL)，编制二个API函数分别以获取参数指针和支持数据交换，从而实现在该动态链接库的支持下，在VB中直接调用ODBC API函数的目的。

可以使用VC++6.0开发动态链接库。VC++6.0可开发三种类型的动态链接库：Win32 DLL、常规 MFC DLL、扩展 MFC DLL。其中Win32 DLL、常规 MFC DLL可被任意Win32编程环境(包括Visual Basic 6.0

版)加载使用。常规 MFC DLL在发行时必须附带MFC42.DLL库，而Win32 DLL可单独发行[3]。如果只提供给VB编程环境使用，可建立Win32 DLL即可。

具体的开发步骤为：利用VC++6.0编程环境的AppWizard创建一个简单Win32 DLL工程，工程名为SQLAPI，在此基础上加入自己的代码。代码如下：

#include “stdafx.h”

#define DLLEXPORT

extern “C” __declspec( dllexport) //定义导出宏

BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved)

{ return TRUE; }

DLLEXPORT long __stdcall GetAddress(void * Address) //按地址传送

{ return (long) Address; }//将地址强制转换为长整形

DLLEXPORT long __stdcall strCopyToByte (char * BytesAddress,char * strAddress)

{ return (long) strcpy(BytesAddress, strAddress); }//

将字符串传送到指定地址

经编译链接生成SQLAPI.DLL动态链接库，将其拷贝到C:WINDOWSSYSTEM(对于Windows) 或C:WINNTSYSTEM32(对于Windows NT 或)目录下，这样就可在VB中调用这两个API函数实现对ODBC API的调用。ODBC调用的一般流程为：

1连接至数据源：分配环境句柄、设置环境属性、分配联接句柄、联接数据源和设置联接属性。

2初始化应用程序：分配语句句柄、设置语句属性，必要时进行数据绑定。

3建立和执行SQL语句：a) 建立SQL语句，或使用硬编码的SQL语句。b) 如果SQL语句含有参数，将每个参数绑定至应用程序变量。c) 用SQLExecDirect执行该语句。如果语句要多次执行，则进行语句准备，并用SQLExecute来执行。

7.分布式数据库查询优化方法 篇七

近年来, 随着计算机网络和数据库技术的发展, 对分布式数据库的应用越来越广泛;随着应用不断扩大, 数据的查询也越来越复杂, 对查询的效率要求也越来越高, 因此查询处理成为分布式数据库系统中的一个关键性的问题[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.

8.分布式数据库解决方案 篇八

关键词：分布式数据库；数据分片；数据分配；分布透明性

中图分类号：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）（））orσ（A）（Π（U）（））

U为属性表；A为条件集合；R为关系名；U={U1，U2，⋯，Un}；A ={A1andA2and ⋯andAn}。

2.关联分片。Ri=Π（U）（σ（A）（）∞σ（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