分布式数据流系统分析（精选10篇）
分布式数据流系统分析 篇1
1 系统设计
从对LDAP目录服务的分析可知, 它具有开放性、分布性、可伸缩性和跨平台等特性。LDAP目录的分布性使得它易于组织、存储分布式环境中的信息, 其复制特性使得LDAP服务在分布式环境中具有很强的容错性和抗毁能力;同时, 用目录服务器存储异构信息环境中的信息相比于关系数据库的查询, 速度要快很多, 用户的大量查询需求, 依靠LDAP目录服务的查询速度和良好性能, 会大大增强异构信息环境中的信息检索能力。
2 系统模型
信息资源的检索定位是在信息组织与索引的基础上完成信息的查询处理, 它向上接收用户以高级语言形式提交的复杂查询, 向下根据数据模型选择并定位到具体信息源形成查询规划, 然后从各个信息源提取信息经转换、合并等处理后形成查询结果返回给用户。本文采用LDAP目录技术组织和管理全局索引信息, 设计出了基于LDAP的分布式异构数据查询模型。模型分为3层:用户界面层、中间层和数据层。
(1) 用户界面层。即信息查询的目标信息输入层和查询结果的输出层。它可以采用网络浏览器作为用户的交互界面。该层负责与用户的交互, 用来接收来自用户的信息请求或向用户返回请求的响应结果, 该层实现了信息资源的异构性分布性对用户的透明。
(2) 中间层。这层是系统的核心部分, 主要包括查询分解与查询结果整合、LDAP目录服务、资源中心信息管理与服务。用户输入的查询信息经过Web服务器转化为标准的请求, 接着再传给LDAP目录服务器, 接到目录服务查询请求后, LDAP服务器首先确定信息所在的资源中心位置, 然后将请求转发到资源中心执行, 如果能在资源中心的本地信息仓储中查找到所需信息, 就将查询结果返回给用户;否则根据资源中心提供的有关具体信息源的位置, 将查询请求分解至各信息源执行。LDAP目录服务用来对全局索引信息进行组织和管理, 它能够对物理上分布的索引信息通过LDAP的数据同步功能来进行统一管理, 同时保持这些索引信息在逻辑上的一致性和完整性。LDAP目录服务器之间采用层次式的组织方式。在此过程中涉及到各个LDAP目录服务器的数据同步问题, 由于各LDAP服务器在地理上呈分布性放置, 并且所在环境和系统结构不尽相同, 这给数据的查询检索带来了一定的复杂度, 数据同步很好地解决了这个问题, 数据同步将各个分散性地LDAP服务器的数据同步统一, 数据检索查询变相性地将分布式数据查询转化为集中式查询, 并且很好地解决了几个层次的异构性问题。
(3) 数据层。该层由分布在整个信息空间中的各种分布性信息资源组成, 包括文本信息、超文本信息、音/视频信息、空间信息等。各种信息资源写入其所在地的LDAP服务器进行存储。这些信息资源是以数据库管理系统作为存储媒介进行组织和管理, 当前普遍用来进行数据存储的数据库包括SQL Server、ORACLE、MYSQL等关系型数据库和BDB等层次型数据库。各数据库中的信息由于结构不同, 因此需要通过LDAP与各数据库的集成整合来实现信息的写入。
2.1 系统查询模块的实现细节
基于LDAP的目录访问模块主要对目录系统进行浏览、搜索、添加和删除等操作。查询模块通过HTTP协议把用户所需要的目录服务请求, 通过参数传递给Java Servlet程序, 将请求页面信息转化为相应文件, 然后解释程序通过JNDI对LDAP目录服务器发出请求, 接着LDAP服务器将请求信息提取出来通过DAP送到DSA。DSA根据请求对目录库进行操作, 并把结果返回给LDAP服务器, 返回结果经过转化后, 最终返回到界面层供用户浏览。因此, 系统的查询模块由客户端、转换器、适配器和LDAP服务器5个部分组成。
2.2 LDAP目录服务器的组织设计
LDAP目录服务器所维护的全局索引信息按照信息条目DN构成一个目录信息树, 在异构信息空间环境中, 分布式目录服务由多台LDAP服务器组成, 每个LDAP服务器负责维护目录信息树中一颗子树信息。每棵目录信息子树的信息都由一台LDAP目录服务器来维护。目录服务器之间的连接就是要将各个分散的子树合成一个统一的树型结构。由于目录服务器也采用了层次式的组织方式, 因此上一级目录服务器除了含有自身的资源属性信息外, 还有两种特殊类型的信息:上级引荐和下级引荐。上级引荐是用来指向父亲服务器的指针, 它指向该LDAP服务器所维护的子树的父亲节点所在的LDAP服务器;下级引荐是用来指向孩子服务器的指针, 它指向该服务器所维护的子树中更小的某棵子树所在的LDAP服务器。LDAP服务器之间的互连就是通过两种引荐实现的。另外, 任何一个目录服务器都可以通过LDAP的复制功能将自身的部分或全部信息进行备份, 并且通过备份信息实现容错、负载平衡等功能, 提高目录访问的效率和性能。当一台服务器接收到一个用户查询请求时, 首先查找本地的信息, 如果没有, 则根据用户的查询条件向父LDAP服务器或子LDAP服务器转发请求;各LDAP服务器都按照这个协议进行请求处理, 直到该请求得到满足。
2.3 异构分布式数据查询的工作流程
异构分布式数据查询的工作流程为: (1) 界面层接收用户查询请求, 将JSP页面请求传给Web服务器, 经过转化后通过JNDI来操作LDAP服务器中的数据; (2) LDAP目录服务器收到查询请求后进行查询, 返回所需信息所在的资源中心位置。此查询过程是一个分布式的查询过程, 查询首先向本地服务器发出查询请求, 本地服务器视情况进行本地查询或将查询重定向到其他目录服务器, 查询结果为资源中心的位置及描述信息等; (3) 根据目录服务器返回的结果向资源中心发出查询请求。在查询过程中, 如果发现本地信息中有满足用户需求的信息, 则将此信息直接返回给用户;否则, 返回所需信息所在的具体信息源的位置及有关的访问信息。依据所返回的信息源的位置及相关信息, 将查询分解至各有关信息源; (4) 各信息源返回查询结果进行整合处理, 经Web服务器对文档进行转化, 最终以JSP页面的形式返回到界面层呈现给用户。
3 LDAP与异构数据库的集成
异构数据库的集成就是要将不同数据库系统、不同操作系统、不同计算机平台或者不同的底层网络进行屏蔽, 使得用户通过一个检索平台可以同时对多个数据库进行检索, 用户访问异构数据库集成系统如同访问一个数据库系统一样。
目前, 对于异构数据库集成, 主要有以下4种方法: (1) 利用中间数据库的转换; (2) 分布式计算技术; (3) 使用中间件; (4) 多数据库系统。
对于分布式存储的异构数据源来说, 通过LDAP与各数据库的集成能够更好地提高系统的效率, 而且能够很好地解决数据源的异构性问题。然而, 由于LDAP本身提供数据库的支持, 因此需要通过不同的配置转换来完成与各种数据库进行集成。LDAP通常带有固定的后台数据库, 例如Openldap通常采用Berkeley DB (BDB) 为后台数据库, 数据普遍存储在SQL、Oracle、My SQL等数据库当中, 因此, 我们以ORACLE数据库为例讲述与Openldap的集成方法。
3.1 openldap与oracle数据库
将Oracle数据库作为Openldap的后台数据库进行访问需要通过oracle ODBC驱动桥。Oracle ODBC让ODBC嵌入式应用访问Oracle数据库, Openldap通过Oracle ODBC来访问Oracle数据库中的数据并将其作为后台数据库和采用SQL作后台数据库的步骤相似。
3.2 关系型数据表映射实现树型结构信息存储
Openldap通常访问树型结构数据, 那么对于象Oracle中的关系型数据就要经过转化才能让Openldap访问, 通常我们可以借鉴数据结构中树结点存储的有关知识, 利用关系表之间的数据映射来实现关系表对树型结构信息的存储。
参考文献
[1]甄玉刚, 刘璐莹, 康建初.基于XML的异构数据库集成系统构架与开发[J].计算机工程, 2006 (2) .
[2]孙青, 邓苏, 黄宏斌, 等.基于LDAP的分布式异构信息检索模型研究[J].计算机应用研究, 2007 (21) .
分布式数据流系统分析 篇2
分布式网络系统中的数据访问设计与优化*
张均东，任 光，陈 健
(大连海事大学 轮机工程学院，辽宁大连 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来执行。
分布式数据流系统分析 篇3
关键词：分布式；数据库；医院信息管理
中图分类号：TP315 文献标识码：A文章编号：1007-9599 (2011) 03-0000-01
The Research of Distributed Database in Hospital Information Management System
Sun Xiyi
(Kunshan City,Jiangsu Province, the First People's Hospital Information Branch,Kunshan215300,China)
Abstract:Hospital information management systems are distributed and complicated. The data cannot be dealt with and analyzed synthetically after it is gathered. The coordination and cooperation among every node is quite difficult; and therefore influences efficiency.This paper combines the characteristic of the distributed multi-database system, designs the database systematic model, develops the hospital system based on the distributed multi-database systems.
Keywords:Distributed;Database;Hospital Management
一、分布式数据库
分布式数据库系统是计算机网络系统与数据库系统与协作与融合的产物，具有数据独立性、事务管理的分布性、集中与自治相结合的系统控制方法、存在适当的数据冗余等主要特点。在分布式数据库系统的运行过程中，数据独立性除了数据的物理独立性与逻辑独立性以外，还有关于数据的分布透明性，即用户不必去关注数据是如何被逻辑分片的；不必关注数据及其分片是否被复制，若被复制的话，副本的个数是多少；也不必去关注数据及其分片的物理位置分布的细节问题；最后，也不必关注某个局部的数据库系统究竟支持哪种数据模型。所以，我们可以把分布式数据库系统看成是数据库系统和计算机网络的有机结合。在分布式数据库系统中，被计算机网络连接的逻辑单位称为站点或节点。
（一）分布式数据库系统的实现方案
1.使用分布式数据库系统，将物理上分布在各地，但是在逻辑上相关联的数据库进行统一管理。分布式数据库系统具有透明性和独立性等特点，如前所述，用户对数据库的任何操作都形同在本地进行，不必关注其数据模型、物理位置等细节问题。2.建立用户交互接口来联合分布在各个节点上的数据库，而数据库之间则不进行任何模式的集成。各个成员数据库采用区域分段管理策略，对本区域以外的数据操作，全部通过远程登录的方式来进行，从而隔离了区域间的影响。3.采用联邦数据库系统模型，在维持局部成员数据库自治管理的前提下，对其他异构的成员数据库进行部分的集成，提供数据的共享，并且采用数据转储技术来解决多节点的分布数据处理及数据一致性维护等问题。
（二）分布式数据库体系结构
分布式数据库体系结构由下述几部分组成：1.多台计算机及其配套设备，并由计算机网络进行连接。2.计算机网络设备及其相关的软硬件和配套通信协议。3.分布式数据库管理系统，它包括全局数据库管理系统、局部数据库管理系统、通讯管理程序，除了具有由GDBMS链接的全局用户接口外，还具有由节点LDBMS链接的自治节点用户接口。4.分布式数据库包括全局数据库和局部数据库。5.分布式数据库管理者可分为二级，一级为全局数据库管理者，另一级为局部或自治节点数据库管理者，称为局部数据库管理者。
二、系统总体设计方案
（一）医院分布式数据库系统的设计目标：1.实现跨地域型企业的资源共享、统一管理和局部控制。2.满足具有分布式存取需求的企事业机构并且为其提供一种经济、可靠、实用的分布式数据管理系统。3.充分利用先进成熟的计算机网络、通信技术和原有的设备，确保医院收费系统的网络先进性，实现医院管理规范化、网络化、智能化。
（二）总体结构本系统设计时使用C/S和B/S混合模式，实现了医院系统的综合管理。
1.门诊挂号：分配门诊号记录病人的自然情况。2.药库管理：登记进库药品，根据药房的提药申请向药房发药。3.药房管理：领药等级，并按领药单划价发药。
4.住院管理：（1）入院登记：记录患者详细情况，并为其分配住院号和病区。（2）病区管理：在病区内分配患者病室以及床位，录入相关医嘱和医嘱确认，生成请药单，以及办理同意出院。（3）取药管理：根据请药单取药、收费。（4）出院管理：显示出院病人的相关信息和各项费用，核对并结清费用，打印出单据。
5.院长查询：医院领导有权随时对医院的财务收支、药品库存及病人的入住院情况等信息进行查询，这可以帮助领导层及时地了解医院的整体情况，从而做出准确的判断。
三、数据库设计
（一）医院系统功能非常繁多，由于篇幅所限，这里仅列举出最为复杂的收费系统功能框架。医院计费系统的主要功能如下：
1.信息显示、查询、检索；2.输出各种收费、管理报表；3.系统智能识别功能；4.身份识别
（二）数据库系统事件或用户事件：系统事件包括系统启动或退出、异常错误等，用户事件包括用户登录或注销。触发约束为一布尔表达式，只有当该表达式的值为TRUE时，触发事件才能够激活触发器使其执行触发动作；否则，当触发事件发生时，触发器并不执行其动作。触发器动作作为触发器要执行的程序块，其中包含SQL语句和其他代码。
创建表触发器的语法格式为：
CREATE [OR REPLACE]TRIGGER trigger_name
{BEFORE|AFTER}tirgger_event ON table_reference
[FOR EACH ROW [WHEN trigger_condition]]
trigger body ；
其中BEFORE和AFTER指出触发器的触发时序分别为前触发和后触发方式，前触发是在执行触发事件之前触发当前所创建的触发器，而后触发则是在执行触发事件之后触发触发器。FOR EACH ROW选项说明触发器为行触发器，行触发器要求当一个DML语句操作影响数据库表中的多行数据时，对于其中符合触发约束条件的每个数据行均激活一次触发器；而语句触发器将整个语句操作作为触发时间，当它符合触发约束时，激活一次触发器。
四、结束语
本文以分布式数据库技术为基础，开发了一套具有使用价值的医院信息管理系统，可较为有效的提高医院业务的处理速度，对促进医疗机构的自动化、信息化具有一定的参考价值。
参考文献
[1]张震.异构数据库同步系统的研究与实现[J].计算机应用,2002,10
[2]邵佩英.分布式數据库系统及其应用[M].北京：科学出版社,2005.
对分布式数据库系统的安全分析 篇4
关键词：分布式,数据库系统,安全分析
分布式数据库作为一种计算机数据库系统, 对计算机数据储存于共享尤为重要。在计算机飞速发展的时代, 分布式数据库系统的应用在带来方便的同时, 也面临着巨大挑战, 必须尽快找出处在不安全因素, 并采取相应的安全措施进行处理, 从而为用户使用提供安全性保障。
1 分布式数据系统的不安全因素
1.1 黑客攻击
黑客攻击的方法是各种各样的, 不仅能够利用网络信息上的“监听客户—数据库服务器—服务器的报文”的方式来窃取数据信息, 还可利用用户的口令实施身份攻击。此外, 为了达到攻击的目的性, 黑客还可通过破译攻击方式, 使用密码分析来获取加密文件, 再解密或者是篡改数据信息。一般情况下, 黑客攻击的目的主要是为了扰乱系统的稳定运行与窃取数据信息, 其中黑客攻击的方式包括3种类型:假装攻击、迂回攻击及窃取攻击。
1.2 内部威胁
由于分布式数据库系统终端位置的物理特性分布具有分散性的特点, 威胁到系统运用内部本身的安全性, 加上它的每一个分站点都会存在薄弱环节, 会直接给整个系统运行的安全带来威胁。因此, 对于每一个分站点的潜在安全风险引起的问题, 都会发出警报, 这时必须充分利用网络安全性为系统提供安全防护措施。
1.3 计算机病毒
计算机病毒的发展与网络、自身因素有关, 对计算机网络来说, 网络环境的开发性加快了计算机病毒传播的速度, 难以根除计算机病毒。对计算机病毒本身而言, 计算机病毒本身具有传染性较强、隐蔽性良好和传播速度快的特点, 在发现病毒的时候通常已经被感染计算机病毒。
2 分布式数据库系统安全防护措施
2.1 建立安全审核系统
在运用分布式数据库系统过程中, 应建立安全审核系统, 对获得任何时间、用户访问数据库系统具有举足轻重的作用, 能够提升数据库系统使用的安全性。并且还应建立相应的用户权限安全性审核体系, 用来找出威胁系统安全性的来源, 以此建立有针对性的数据库安全防护系统。例如某省公安厅交通警察总队的某个项目中, 运用了数据库系统安全审计系统, 通过部署数据库审核系统, 在不更改业务网络结构基础上, 采用旁路镜像方法, 实时采集服务器和数据库网络数据流, 协议分析和识别信息数据, 最终将全部网络操作进行还原, 然后记录储存于取证分析操作痕迹, 以此提出相应的设定安全策略, 审核多个不同的分站点, 防止违规操作同时, 向管理员报警, 从而实现分布式部署。
2.2 净化网络环境
针对上述复杂、开放性网络环境条件下, 分布式数据库系统运用中存在的不安全因素, 为了降低网络环境的影响力, 真正做到安全防范, 必须净化网络环境, 加强网络管理力度, 为系统使用的安全性提供保障。例如某市为了净化网络环境, 确保计算机信息系统安全, 促进计算机应用与发展, 按照《中华人民共和国计算机信息系统安全保护条例》相关规定, 结合当地计算机应用情况, 明确相关部门工作职责, 加强网络管理, 收集和通报计算机病毒, 对计算机病毒来源进行追查, 定期检测计算机病毒, 及时消除计算机病毒传播与扩散。
2.3 病毒防控措施
分布式数据库系统内部储存与管理着海量数据信息, 都是为了防止黑客利用各种非法手段篡改、破坏和窃取数据库中的文件, 为了保护数据库系统中全部文件的安全性与完整性, 必须对分布式数据库系统中的数据库文件进行病毒防控, 做好相应的病毒预防与控制措施, 从而有效降低黑客攻击的威胁性。例如某校为了预防与控制本校计算机感染病毒, 维护用户利益, 按照国家与公安部门相关规定, 结合本校的实情, 制定相应的病毒防控措施, 要求学校信息化建设和管理领导小组负责病毒预防与控制工作, 并成立病毒防控小组, 负责监督与指导病毒防控工作, 根据有关规定检测计算机系统和软件的病毒, 对产生病毒计算机进行清除, 并更新防病毒软件, 新接入的软件必须经过检测, 确定没有病毒后才能使用。
2.4 保密安全措施
用户访问权限在通过一系列身份验证后, 分站点和分站点之间才可以进行数据互动。为了确保数据信息的保密性, 在数据信息传递的整个过程中, 一般会对需要传输的数据信息设置密码, 在通信双方建立一条保密通道, 对数据信息访问与传输进行加密处理, 以此避免数据被窃取、反复发送及遭到黑客攻击。另外, 应使用实时入侵检测方式, 加大分站点之间的安全监测力度, 在通信双方建立一条安全通道, 加强数据信息传输的保密性。例如某公司为了确保整个分布式数据系统信息系统中数据信息的保密性, 在发送信息数据过程中, 使用端对端加密方式对数据信息进行加密, 然后进入TCP/IP数据包封装, 将其设置成不可识别或者是不可阅读的信息数据, 最后通过网络方式传送到另一个用户系统中 (目的地) , 再对信息数据进行解密重组, 变成可读数据信息。
3 结束语
在开放式和复杂的网络环境中运用分布式数据库系统时, 应充分分析了解不安全因素, 通过建立访问控制和审计体系和安全审核系统方式, 净化网络环境, 实时预防和控制病毒传播, 从而做好分布式数据库系统保密安全措施, 确保分布式数据库系统安全使用。
参考文献
[1]邹平吉.对分布式数据库系统的安全分析与探讨[J].林区教学, 2013 (12) :98-100.
分布式数据流系统分析 篇5
分布嵌入式大气数据系统算法的初步研究
针对某型飞机给出了DFADS系统的构型描述,进行了DFADS的算法设计,算法采用了一种非物理映射的方法来建立各测压点压力和基本大气参数之间的关系.先是利用制定的多传感器数据表决规则表决出2～3对相关的`测压点,然后通过建立相关测压点压力和其压力系数值之间的关系,利用这几对测压点的压力对事先建立的Cpi(α,β,Ma)映射关系表格数据库进行查表计算,从而得到当前的飞行状态.本文利用计算流体动力学(CFD)计算手段获得了332个飞行状态下飞机前机身14个测压点的表面压力系数数据,并以此为基础对DFADS的算法进行了仿真验证.结果表明,该DFADS的算法可以根据14个点的压力输入,正确地解算当前的大气参数.
作 者：王岩 郑伟 WANG Yan ZHENG Wei 作者单位：沈阳飞机设计研究所,辽宁,沈阳,110035刊 名：飞机设计英文刊名：AIRCRAFT DESIGN年，卷(期)：28(6)分类号：V241.7关键词：嵌入式大气数据系统 多传感器 数据表决 映射嵌入式
分布式数据流系统分析 篇6
关键词：网络数据库分布,协作业务处理系统,计算机网络系统
1. 相关的基本词语的含义
要了解到如何在网络数据库的下设计操作分布写作业务处理系统, 首先我们要弄清楚词语要表达的含义。
首先是网络数据库的含义, 它是由两个部分构成的, 是以后台的数据库为基, 再通过前台计算机某种特定程序的, 由一个页面显示和存储出所需要的文字、图象、音频、视频等数据。如今被广泛的应用于各个领域。因为可以通过不同的端口直达后台的数据库, 不受时间地域等等条件的限制, 在大的数据库里搜寻所需的信息, 同时又能对用户终端进行识别, 这样将用户的使用网络地址聚集成另外一个数据库。不仅仅是存储功能, 同时兼具着对数据的整理、识别、划分、后期加工、再工前台不同的需求进行筛选。网络数据库是打破传统模式只在前台单机的存储, 数据不能够进行共享, 只能在指定的某一台电脑上进行独立操作, 而是覆盖了很多电脑, 进行相互的联系起来, 可以相互贯通也能从总后台提取资料。双向的存储提取工作为更多用户提供便捷, 同时又丰富了数据库的保有量, 可以进行不同前台计算机信息的传递。
其次是协作业务处理。它是目前被深入研究的一个课题。由于他就像是一个科层制系统机构, 自上而下的分布, 彼此之间相互串联且并联的结构, 密密的织成一个组织间互相联系的关系网络, 任何网络之中的部件都讲是牵一发而动全身。主要涵盖了各个部门之间相互交换所需信息, 以维持各部门的职责工作, 又经过不同的部门对信息的使用而反馈回来的不同对原有信息的更新加工整理筛选构成最后的信息储存到源信息所属部门, 经过这样的流程, 信息在不同部门之间的流通和使用到反馈结果都是属于写作业务处理的一部分。而这种模式更广泛的应用于生产链条彼此紧密相连的各个部门, 在这些部门可同时对同一条信息加以整理和反馈, 彼此之间可以互通信息以完善最初的信息, 这叫做不同终端操作, 并且这种信息的交流时错综复杂但是是有秩序有章节的进行, 基于计算机的操作, 充分利用了计算机网络数据库的特点。更高级的是, 在这个协作系统中, 可以根据不同终端的存储量和对信息整理、筛选、使用的程度进行合理化分配, 将现有资源进行整合在通过分配给每个终端继续完成操作, 充分行使链条的联系作用。
最后是分布式系统。有字面我们可以看出是由至少两步以上的操作前台, 才可能进行分布工作。他是一种多处理器的计算机系统, 包括硬件和其他功能的特殊配置。而具体分布的是中央处理器的任务, 通过计算筛选整合检测的过程, 对不同的操作特点的处理器进行合理化分配, 使拥有不同功能的处理器根据个体的优势来进行优势的任务处理, 这样任务的执行能够简单化, 速度化, 协调化。最主要的是, 分布式依旧需要以网络的后台作为操作的依托, 彼此之间也是互相联系的。各个系统是通力合作、各司其职、主次有序的。
2. 系统的设计分析
我将以最为体现最为明显的链条上最关键的并且表面化显露特性的销售部分为例来进行系统设计。在销售员处理销售业务中包括需要将公司仓库中现存的调货清单输入到电脑中, 这将直接发送到相关管理部门仓储部进行数量的统计和货物的对比分析, 再将整理结果录入到电脑中, 再由供货商对清单的查看做出对产品生产或引进的货品订单, 最后由公司采购进行对货物的补充, 就完成了整个流程。在此期间, 各个部门都在执行各自的职能, 对信息的录入、审查、传达、互换工作都在相应的职位权限中。于此同时, 如果有一个部门的临时变动, 会在电脑中输入相关信息, 其他的连接上的各个部门会在第一时间内收到信息并进行更正和校对, 最后进行相互的整合, 保证在每个连接上都依旧是正确的信息。这种就充分体现了反馈在整个系统中的具体表现形式。所以, 有以上案例我们可以知道, 在利用网络数据库实现分布协作系统的设计操作的每一步, 最关键的地方就是要在准确全面的分解廓清系统业务过程及交叉关联的前提下, 标清出每个部分每个操作阶段的名称进行具体测量值的变换, 据此实现实时检测不同场合数据检索范围控制、分级权限控制与状态信息传递等目标任务。
3. 总结
无论在什么样的系统装置下, 本文最终强调的核心思想是合作, 就是通过不同的手段达到各部门能够紧密联系, 发挥各有所长, 将共有的问题进行机械化合理化, 根据不同功能, 不同的优势进行分工处理, 最后在整合数据信息, 将信息资源最终汇总处理, 使问题得以顺利的最短时间内的解决。这套科学的系统已经被广泛运用到商业运行企业管理的系统中, 我们也十分的肯定这种先进技术会给企业降低成本, 减少工作量, 使整个流程跟专业化更具技术性的特点, 这也将是现代化企业能够适应市场变化解决错综复杂问题的一条捷径。
参考文献
[1]李立新, 陈伟民, 黄尚廉.强制访问控制在基于角色的安全系统中的实现[J].软件学报, 2000, 11 (10) :1320-1325.
[3]李国徽, 王洪亚, 一种新的实时数据库乐观并发控制方法, 计算机应用软件, 2004 (5) .
[2]吴洁明编著, PowerBuiIder应用与开发[m], 北京:清华大学出版社, 1998.
分布式数据流系统分析 篇7
关键词：数据同步通信,分布式,实时数据库
1 前言
随着信息技术的发展以及国家对企业安全生产信息化要求的提高, 我国大多数企业生产过程中基本都采用了各种各样的监测监控系统, 由于管理和技术的原因, 这些系统分散在各个相关职能部门, 形成了多个“信息孤岛”, 严重影响了企业安全生产管理水平的提高, 阻碍企业信息化进程。
分布式实时数据库系统DRTDBS (Distributed Realtime Database System) 的出现为各种监测监控系统提供了统一的数据平台, 以便数据的查看和使用不受监测监控系统专有技术、网络、协议的制约, 达到实时数据真正共享的目的。并确保所传输数据的实时性、准确性、有效性, 为企业上层应用提供可靠的支持。
DRTDBS按照各监控设备区域分布情况, 将整个企业的实时数据进行区域划分, 由若干实时数据库服务器 (以下简称数据服务器) 加以管理。DRTDBS的网络分布结构如图1所示。
在每个数据服务器管辖区域内, 数据采集工作站将现场设备的物理信息和实时数据上传到数据服务器, 由数据服务器统一管理。区域内的监控站点如监控开发工作站, 监控应用运行服务器、现场监控工作站点等与数据服务器通信, 从中读取所需实时数据。若监控站点想跨区域访问实时数据, 例如, 区域1的监控开发工作站想访问区域2的实时数据, 则通过两区域内数据服务器的数据同步
通信来完成实时数据的访问操作。
由于在DRTDBS中数据不仅具备分布性, 同时还具备实时性, 因此, 如何在有效的时限范围内, 使各分布站点能进行准确无误的数据通信是实现DRTDBS的关键技术之一。但由于DRTDBS数据的双重特性, 迄今为止在这方面的研究还比较薄弱, 所以数据同步通信成为了DRTDBS的一大研究难点。在此背景下, 本文对已有的分布式数据库数据同步技术进行研究, 提出了适用于DRTDBS的数据同步方案, 并给出了较详细的设计步骤。
2 影响数据同步性能的因素
由于DRTDBS中数据具有实时性, 因此衡量数据同步性能的一个重要指标就是系统中所有参与数据同步的服务器完成一次数据同步所需最大时间tmax。又由于DRTDBS处于企业局域网中, 因此本节着重讨论在局域网内影响tmax的因素, 并定性分析这些因素对tmax的影响程度, 以此作为选用数据同步策略的参考。
图2, 给出了参与数据同步的服务器 (以下简称数据服务器或服务器) 的网络链路图。在图中S1、S2、S3……Sn为数据同步服务器。为简化分析, 在此我们仅考虑极端状态即每个服务器都与其它所有服务器进行数据同步的情况。Si代表服务器Sj到服务器Wij的链路带宽。Kij代表每个服务器的数据同步率 (服务器i每次向服务器j提供的同步数据量, 单位bit) 。根据图2可以得出各服务器链路带宽矩阵 (图3) 和各服务器的数据同步率矩阵 (图4) 。
根据服务器Si到Sj的一次数据同步时间, 可得整个局域网内数据同步时间矩阵:
根据图5得整个局域网中所有数据同步服务器一次数据同步后, 所需最大时间为:
即tmax为tij中最大值。可根据tij, 做适当的假设, 分析影响tmax的各大因素, 并定性分析各大因素对tmax的影响程度。假设如下:
(1) 网络稳定, 且每条链路所占带宽相等为2B/n (n-1) , 其中为网络总带宽, n (n-1) /2为网络总链路数。
(2) 在理想情况下, 不考虑网络传输延迟问题, 不考虑主机处理同步数据耗时。则Si到Sj的一次数据同步时间为:
一次数据同步中, Si向其它所有服务器提供同步数据总量为, 那么所有服务器提供同步数据总量为:
由公式 (2) 可得出以下结论:
(1) 当n恒定且K
(2) 当K
从tmax角度分析, 影响数据同步性能主要有3大因素, 数据同步率Kij, 数据同步服务器数目n和网络带宽B。选定局域网后, 在理想状态, 即网络带宽B不变的情况下, 提高数据同步性能集中在数据同步率Kij和数据同步服务器数目n两大因素上。由结论 (1) 可以总结出, 在设计数据同步方案时, 要尽量减少数据同步率, 但前提是不
会造成主机处理时间延长, 以至成为影响数据同步性能的主要因素之一。由结论 (2) 可以总结出, 在设计同步方案时, 应根据公式 (2) 估计在一次数据同步过程中能允许的数据同步服务器数目, 然后根据实际情况对服务器数进行适当控制调整。
3 数据的同步策略
(1) 为方便起见, 定义如下概念:
(1) 主服务器:是指那些提供同步数据的服务器, 如图8所示。
(2) 从服务器:指引进同步数据的服务器, 如图4-11中的服务器A, B, C和D。
(2) 主服务器和从服务器之间具有如下关系:
(1) 主服务器和从服务器都是数据同步服务器;
(2) 一个主服务器可以拥有多个从服务器, 因为它可以向多个从服务器提供同步数据;
(3) 一个从服务器可以有多个主服务器, 因为它可能拥有来自不同服务器的数据备份;
(4) 一个主服务器即可以是某些数据的主服务器, 也可以是另一些数据的从服务器, 即它可以向其它数据同步服务器提供同步数据, 也引进其它数据同步服务器提供的同步数据。
(3) 完全同步法 (Completion Synchronization, C_Syn)
完全同步法是指每次进行同步操作的时候, 主服务器都将生成完整的同步数据集合MD={MR1, MR2……, MR3, }, 并用M D完全刷新从服务器上的同步数据集合SD={SR1, j, SR2, j, ……, SR3, j}, 使主服务器与从服务器的数据同步起来。其优点是实现简单;缺点是数据同步率Kij增大时, 同步时间正比增加, 当存在大量同步数据时, 采用完全同步法效率低下, 对数据同步性能影响较大。若数据同步服务器数量n也增加时, 完全同步法将严重影响数据同步性能。
因此, 该方法仅适用于主从服务器之间需同步的数据量较少的情况。
(4) 差异同步法 (Difference Synchronization, DS)
为了克服完全同步法每次同步操作都完全刷新同步数据集的缺陷, 差异同步法并不将整个同步数据集应用于从服务器, 而是不停地监视自上一次同步操作以后主服务器同步数据集的变化, 在下一次同步操作的时候, 将这些变化应用到从服务器。
与完全同步法相比, 差异同步法最大的好处在于只需要同步变化了的数据即可, 从而大大减少了数据同步率Kij, 提高了数据同步的效率。
为实现差异同步法, 本文为每个需要同步的实时数据添加了跟踪因子, 每个负责监视一个同步数据的的更新情况。=实时数据索引号nm+更新标志。每经历一次实时数据更新, 每个实时数据值都要和上一次更新时的值进行比较, 若有更改则跟踪因子的更新标志置1, 若无更改, 则置0。之后把凡是置1的实时数据发送给相应的从服务器。
4 数据同步实现
每个服务器既可是主服务器又可是从服务器, 因此, 每个服务器数据同步模块功能相同, 由两大模块组成:通信处理模块、通信接收模块。
(1) 通信处理模块
主要负责命令、配置数据、实时数据的传输与相关处理。
(2) 通信接收模块
主要负责对命令、配置数据、实时数据的接收工作。该模块采用DCOM Server形式, 可被远程调用。
4.1 协议说明
要完成整个数据的访问通信需要以下几条最基本的命令:
(1) 请求命令:有关远程实时数据访问的请求命令。
(2) 回复命令:对远程实时数据访问的有关回复命令。
(3) 数据传输命令:实时数据、配置数据及配置数据修改信息的发送。
(4) 数据传输应答命令:数据接收方的应答命令, 表明是否接收到数据。
协议制定时应考虑到协议要包含必要信息, 简洁、清晰、易于处理。协议定义如下:
Cmd ID;Local ID, Cmd, Time;
Cmd ID:命令的标识, “Request”表示请求命令;“Response”表示回复命令;“Req Data”表示数据发送;“Res Data”表示数据接收应答。
Local ID:命令发送方标识。
Cmd:具体命令内容, 可以带参数, 详细Cmd命令如下:
Time:命令发送的系统时间。
4.2 通信连接建立
用户只需选择主服务器和具体请求命令, 按发送键即可, 剩下的工作都由通信处理模块和通信接收模块完成。在数据同步之前, 因各服务器处于非连接状态, 这就需要建立通信连接。通信建立过程如图9所示。
这里服务器A为主服务器, 服务器B为从服务器。因各从服务器与主服务器通信连接建立过程相同, 故仅讨论一个从服务器与主服务器通信连接建立过程。
1.首先从服务器B向主服务器A发出“请求查看配置表”RT命令;
完整的命令为:Request;2, RT, 2008-1-23 14:3:0 (其中2为服务器B标识) 。其命令解读为在2008-1-23 14:3:0, 服务器B向A发送了“请求查看配置表”命令。
2.服务器A通信接收模块接收到请求命令后, 由通信处理模块识别发送方, 并对其命令作出回应:
(1) 若服务器A允许服务器B查看配置表 (YRT命令) , 则服务器A与服务器B间通信连接建立成功。完整命令为:
Response;1, YRT, 2008-1-231 4:4:10 (其中1为服务器A标识) 。解读为在2008-1-2 314:4:10, A向B作出回应, 允许B查看配置表。
(2) 若服务器A不允许服务器B查看配置表 (NRT命令) , 则通信连接建立失败。完整命令为:Response;1, NRT, 2008-1-2314:4:10。
4.3 配置数据的选取
当通信连接建立后, 从服务器即可访问主服务器A的配置数据库。因各从服务器的访问过程相同, 故也仅讨论从服务器B对主服务器A配置数据库选取过程。服务器B从主服务器A的配置数据库中选择感兴趣的数据, 在内存中建立临时配置信息库, 暂存相关同步配置信息, 并在本服务器配置数据库中做好备份, 然后把指定的配置信息自动发送给服务器A。A收到后, 也在内存中建立临时配置信息库, 暂存B选定的配置数据, 并在自己的配置数据库中做好指定配置数据备份工作。最后A向B发送“YSTD”选定配置信息已收到命令。实现过程如图10所示。
具体命令为:
ReqData;2;SSTD, 1, a, 2, b 3, c…….;20 0 8-1-2314:5:12 (其中1, a, 2, b 3, c……为选定的配置信息) 。在2008-1-2314:5:1 2, B向A发送选定配置信息1, a, 2, b, 3, c……。
Res Data;1;YSTD;2006-5-20 15:31:24, 解读为在2008-1-23 14:5:20, A向B发送配置信息已收到命令。
4.4 多服务器实时数据同步更新
在此, 所谓多服务器实时数据同步更新是指以服务器数据更新周期为期限, 当主服务器数据更新后, 在不超过主服务器数据更新周期的时间内, 对从服务器上的引进实时数据进行更新。
首先, 服务器间要进行时钟同步操作, 统一各服务器时钟, 然后按照图11进行多服务器实时数据同步更新操作。
(1) 主服务器A实时数据库通知通信处理模块实时数据已更新 (1) 。
(2) 根据同步数据量多少分两种情况讨论:
(1) 若同步数据量较少时, 采用完全同步法。通信处理模块读取临时配置信息库中的配置数据 (2) ;接着根据配置数据, 读取相应实时数据 (3) ;然后发送各从服务器指定的实时数据 (4) ;
(2) 若同步数据量较大时, 采用差异同步法。通信处理模块读取临时配置信息库中的配置数据 (2) , 根据配置数据, 仅读取数值有更新的实时数据并发送给相应的从服务器。
(3) 各从服务器定时判断是否收到实时数据, 分别向主服务器A发送“YRTD/NRTD收到/未收到实时数据”命令, 由服务器A通信接收模块接收命令 (5) 。
(4) 通信处理模块定时从通信接收模块读取命令, 若有从服务器未收到实时数据, 并且服务器A实时数据库未进行下一次更新, 则重新发送指定的实时数据到相应从服务器。
以上整个过程应在主服务器下一个数据更新周期前完成。若某从服务器数据更新超时, 则舍弃接收到的实时数据。
5 结论与展望
本文从分析影响DRTDBS数据同步通信的因素入手, 根据DRTDBS的实际情况采取了两种数据同步策略, 并给出了差异同步法的实现方法。最后提出了设计实现DRTDBS数据同步的详细方案。实践证明该方案已取得了初步的成效。
今后应在DRTDBS的时钟同步、实时事务的并发控制等方面进行深入研究, 逐步完善DRTDBS数据同步功能。
参考文献
[1]闫晓多.非连接分布式数据库环境下的数据同步策略[D].青岛海洋大学硕士学位论文, 青岛海洋大学图书馆, 2002.
[2]王岳斌, 潘久辉.分布式环境下数据同步技术的设计与实现[J].南京大学学报 (自然科学) , 2001年10月, 37卷:276-279
[3]丁鲲, 严浩, 刁兴春.分布式数据库数据同步技术研究[J].海军工程大学学报, 2004年9月, 1卷5期:100-104
[4]谢坤武.基于组件技术的数据同步分析[J].武汉科技学院学报, 2004年6月, 3期:46-48
分布式数据流系统分析 篇8
数据库就是存储在计算机上的数据集合, 分布式数据库是部署在多台计算机上的数据的集合, 他们为了执行某任务需要进行协作。
实际上, 在分布式数据库系统的设计中, 大部分的问题来自数据的分布性问题, 所以如何进行数据分配, 对整个分布式数据库系统的可靠性、可用性、数据的存取效率和存取代价都有很大的影响。本文结合传统的算法, 进行了一些改进, 从两个维度分别考虑, 对数据分片进行分配, 提高了数据分配的效率。
代价公式的选择就是衡量系统中数据分配算法好坏的重要标准。这个表明, 在进行系统设计时看重系统的哪方面功能。本文选择的是以通信代价的好坏来衡量算法的效率, 并假设场地间的距离是理想的, 我们计算的场地间距离为归一化的值。
查询事务的代价公式为
其中, D_S为两场地之间的距离, 该距离为归一化后的距离
Q_E为查询事物t对场地i上的执行次数
Q_T为查询事务t对数据片段f的查询次数
S (Ff) 为分片f的大小
相应地, 更新事务的代价公式为
其中, U_E为更新事务t在场地i上的执行次数
U_T为更新事务t对数据片段f的查询次数
2 常用的片段分配算法
2.1 最佳适应分配法
该算法的大致思想:把所有的数据片段分为若干组, 初始时分配到各场地中去, 此时的数据分配方案为D0, 计算初始代价C0。然后按照顺序相对最优的分配每一数据分片分组, 分配一个分组时, 要固定其他已分配或未分配的分组, 使得要分配的分组在该条件下是最优分配。分配完所有的分组一遍后, 计算此时的总代价C1, 此时的数据分配方案为D1。若符合一定条件的约束, 则按以上的方法分配所有的数据分片, 否则让D0=D1, C0=C1, 再重复如上操作, 直到Ci与Ci-1满足约束条件的约束, 算法结束。
步骤
(1) 设系统中共有n个片段, 将其分为K组, 每组g个数据片段 (最后一组有可能不足g个片段) 。
(2) 将此事数据分配方案命为D0, 计算该分配的总代价为初始代价C0。
(3) 固定第2组到第k组数据分配方案, 进行第1组的数据片段的分配。对第1组的数据的各种分配进行代价计算, 选出最优的分配方案来, 按此方案分配第1组的g个数据片段。
(4) 依次固定第2组, ……第k组数据片段, 找出所有组的最优数据分配方案, 此时的数据分配方案成为D1, 此时对于这a个片段求总的代价为C1。
(5) 比较C1与C2, 如果两个代价的误差控制在一定的范围内, 则选定D1的分配方案, 否则继续执行以上的过程, 知道算法结束。
该算法的算法流程比较复杂, 用该算法计算一遍系统代价就已经有很大的工作量, 而且该算法有可能产生迭代求解过程, 这样系统的代价求解运算会更多。
2.2 启发式添加副本法
该算法的大致思想是:首先, 可以用最佳适应法等非冗余的分片分配方案, 把所有的分片分配到场地中去, 这样我们得到一个相对最优的非冗余的数据分配。接着, 分别尝试在场地Sj上添加部分Fi, 计算添加副本Fi后的系统的总代价。若整个系统的总代价减少, 则说明该分片的的分配有利于减少系统运行的总代价消耗, 就给Sj场地上分配副本Fi, 否则, 不分配。就这样, 依次把数据分片分配完毕。
步骤:
(1) 首先将所有数据分片非冗余的分配到场地中, 得到一个相对最优的数据分配策略。
(2) 将数据分片Fi冗余地分配到场地Sj上, 计算分配之前和分配之后该系统对于分片Fi的操作的总代价。
(3) 若分配数据片段Fi之后系统的总代价减少, 则把数据分片Fi分配到该场地Sj上, 否则, 不分配。
(4) 按照 (2) 、 (3) 的方法, 一直把所有分片都分配完毕。
启发式添加副本法, 在一开始添加副本时, 系统的代价计算所需要的时间和代价较小, 随着副本分配的增加, 因为每次计算的代价都不能迭代利用之前计算的结果, 而且计算条目越来越多, 这样计算量就会越来越大, 所以这并不是一个最好的数据分配算法。但是它考虑了前面的数据副本分配对后面的数据分配的影响, 并且实时地考虑了数据副本的分配对系统代价的影响。
启发式删除副本法, 与启发式添加副本算法类似, 但该算法是从冗余度最大的情况开始, 通过一步一步的衡量系统总代价的方式, 逐渐删除系统中的不利于减少系统总代价的冗余副本的算法。
2.3 得益代价法
该算法是在分别计算系统的得益与代价的基础上, 结合事务操作类型, 来对数据片段进行不同种操作。它是在启发式添加和删除副本算法上优化改进得到的。
基本思想:首先用非冗余的方式将数据分配到系统中, 使之代价较小。再将其中的事务分为只读事务和更新事务。按照只读事务进行数据片段副本的冗余分配, 再按更新事务对数据分片进行冗余副本的删除, 以减少维持系统一致性的开销。
步骤:
(1) 按非冗余算法, 在系统内分配好数据片段。
(2) 根据只读事务所涉及到的分片进行冗余地分配。若一个场地上的只读事务对某分片进行了查询操作, 那么将该分片复制到本场地上。该事务对此分片查询的网络通信代价为零, 该分片冗余分配结果是该分片及对应的场地和数据片段的分配矩阵。
(3) 根据更新事务进行冗余副本的删减。若一个更新事务涉及到对某分片的操作, 那么先计算删除该分片前后系统的代价, 若代价减少, 则删除该冗余分片。该算法在计算代价时, 只计算与该分片相关的代价, 不必计算系统总代价。
(4) 再找出查询事务中不涉及, 但更新事务中涉及的分片。按照更新矩阵和更新事务场地执行频率矩阵来分配这样的分片。
该算法按只读事务分配冗余数据, 又按更新事务对冗余的数据进行精简删除。这使得数据副本一方面按需分配, 另一方面又合理地降低了系统的副本冗余度, 减少了冗余数据维护费用。但是该算法也未能严格的保证数据副本冗余度的范围。在使用算法时, 可以根据具体场景外加条件, 限定副本冗余度的范围。
3 基于二维度的数据分配策略
该策略的基本策略是把场地上的数据片段的访问分为两种, 查询事务访问和更新事务访问。按照查询事务和更新事务对数据片段的访问量多少, 将数据片段分为查询类片段和更新类片段。然后从两个角度把数据分配问题分为四种情况, 并分情况讨论数据分配问题。首先, 我们将数据片段分为查询类片段和更新类片段, 再把场地内的事务分为查询事务和更新事务。从自定义的数据片段属性和场地事务属性把数据分配问题要讨论的情况分开讨论。
步骤:
(1) 首先, 进行数据统计。统计出每个场地发出的事务对各个数据片段的更新访问量和查询访问量。再统计出每个数据片段的更新访问量和查询访问量, 并求出每个数据片段的更新访问量和查询访问量的比值。根据这个比值的大小, 确定数据片段是查询类片段还是更新类片段。
对于该步骤中的比值, 它的大小一般来说是1, 但是在具体的场景下, 可以改变。比如在一个偏重查询的系统中, 可以把更新访问量与查询访问量的比值一定程度缩小, 以满足需要;在一个经常需要更新数据的系统中, 可以把该比值设置的大一些。通过控制这个比值的大小, 可以改变下一步中更新片段在系统当中的冗余程度。
(2) 按事务访问量大小进行分配。按照统计出的每个片段的访问量和每场地发出的事务对数据片段的访问量, 给该片段分配场地。分别选择查询类片段中查询访问量最大的和更新类数据中更新访问量最小的两个场地进行分配。根据该表可以找到查询类 (更新类) 数据片段Fi在场地Sj、Sk上的查询类 (更新类) 事务访问量最大 (最小) , 就将数据片段分配给它们。
在这里我们选择把查询类片段和更新类片段都同样按照访问量的多少进行冗余度为2的分配。在这一步中, 数据片段分配给两个场地上, 确保系统中的数据冗余度至少为2, 以确保系统的可靠性。
(3) 进行冗余分配。当场地上的查询事务对查询类片段进行查询时, 系统将分配一个冗余数据副本到该场地上;当对一个更新片段进行查询时, 系统统一不分配数据。当场地上的更新事务要涉及对查询片段进行访问时, 以冗余度为2为标准删除多余片段, 然后统一更新剩余查询片段;当涉及更新片段的操作时, 不分配数据, 不涉及分配操作。
这样, 查询类片段按需分配, 增加了片段冗余度, 减小了由于通过网络查询数据产生的开销, 在进行更新的时候缩减副本数, 降低了该片段的冗余度, 减少了维护数据一致性产生的开销, 该过程是一个动态的过程;对于更新类片段来说, 一直维持冗余度为2的标准, 因为更新类数据片段的性质, 我们采用通过增加网络查询的通信代价, 来缩小维护数据一致性的开销。
该算法仅通过添加了选择分类这样一个步骤, 在两个维度上对数据进行详细梳理, 再对数据进行不同的操作。在没有提高算法复杂度的基础上, 细化了算法的选择类别, 效率有所提高。
与传统的基于数据片段访问特性的算法比, 该算法在算法步骤上简化了不少。基于数据片段访问特性的分配法是首先按需分配查询类片段再用启发式删除副本法进行数据删减, 非冗余分配了更新类片段后再进行启发式副本添加。我们知道启发式添加副本法和启发式删除副本法在算法的复杂度上偏大, 所以导致该算法在复杂度方面并不突出。
本文提出的算法, 同样需要对数据和事务做出统计, 但是无需对数据的分配做太多处理, 根据数据及事务的分类标准, 就完成数据分片的分流处理, 更加简便。
4 实验结果
假设第一组实验的数据分片数为10, 节点数为5, 查询事务数是90, 更新事务数是100。各个分片容量分别为200, 300, 100, 200, 400, 100, 300, 200, 300, 100, 单位为KB。数据节点的容量均为100000KB。
节点间的通信代价和查询事务对分片的使用百分比情况, 如表1、2、3所示。
可以看出在数据片段比较少的情况下, 本文提出的分配策略表现情况一般。
第二组数据, 将分片扩展到50个, 节点扩展到10个, 查询和更新类事务都扩展为100个的情况下, 进行对比, 结果如表4所示。
在这组实验中, 基于二维度的分配策略所需的时间和代价明显比其他的算法要好。在实际的数据库系统中, 事务与分片的个数要远大于实验给出的个数, 用传统的分配策略, 时间和代价消耗较大。因此, 本文的算法具有一定的参考性。
5 结论
这种策略比基于数据片段访问特性的算法简单很多, 在算法的初始就分类好不同数据的走向, 简化了算法的流程, 从而缩短算法的求解时间;在数据量大的情况下, 可以明显改善算法的执行的代价。
参考文献
[1]Bhattacherjee S, Narang A, Garg V K.High throughput data redundancy removal algorithm with scalable performance[C].Proceedings of the 6th International Conference on High Performance and Embedded Architectures and Compilers.ACM, 2011:87-96.
[2]周波.分布式内存数据库数据冗余分配研究与应用[D].西南交通大学, 2013.
[3]杨洲.分布式数据库中数据分配策略的研究[D].哈尔滨工程大学, 2007.
[4]Lina S.Research on Query Optimization Algorithmin Distributed Database[J].International Journal of Digital Content Technology&its Applications, 2013, 7 (6) .
[5]南菊松.分布式数据库系统中数据分配算法研究[D].华中科技大学, 2013.
分布式数据流系统分析 篇9
Google公司因其强大的互联网搜索能力而闻名全球, 它并没有使用数据库存储网络数据, 而是采用运行在分布式文件系统GFS上的Bigtable系统管理PB级的数据。Bigtable系统是一个大规模的结构化数据分布式存储系统, 它运行在数十万台商用计算机组成的集群上, 提供了强大的数据存储和检索能力。由于此系统采用了一种新的数据模型, 它为客户提供了动态管理数据布局和格式的方法, 具有广泛的应用领域。
本文分析了Bigtable的体系结构, 重新设计系统的数据服务器。首先进行总体设计, 明确数据服务器的主要功能, 然后设计数据服务器的读写原理和数据块加载操作, 最后对设计情况进行总结。
1 体系结构
Bigtable的实现包括三个主要组件 (图1) 和每个客户端相连的库 (Client Lib) , 一个主服务器 (Master) , 多个数据服务器。数据服务器可以从集群中动态地添加 (或移除) 以适应负载的变化。除此之外, Bigtable使用分布式文件系统GFS存储Bigtable的海量数据, 使用Chubby提供锁服务和对表结构数据的存储。
客户端Lib是运行在客户端上的库, 它向客户机提供操作Bigtable的统一接口, 并且对客户端读到的部分数据进行缓存。每个数据服务器管理着一组数据块。数据服务器负责处理客户端对数据块的读写请求, 并对数据块进行分割操作。主服务器实现了对Bigtable元数据的管理, 同时它负责跟踪数据服务器的变化, 均衡数据服务器的负载, 对GFS文件进行垃圾回收。
2 数据服务器的设计
2.1 总体设计
数据服务器主要包括三大功能:管理一组子表数据块;加载子表数据块;数据整理。
(1) 每台数据服务器管理着一组数据块, 数据服务器负责处理对所属数据块的读写请求。客户端通过查找元数据表, 确定数据所在的数据块并对数据服务器进行定位。客户端直接向数据服务器发送读写请求, 而不通过主服务器进行信息传输, 这样大大减轻了主服务器的负载。数据服务器响应读写请求, 并通过和Chubby进行通信完成对读写用户权限的检查。由于数据块中的数据最终存储在GFS文件系统上, 所以数据块需要调用GFS的接口最终完成数据的读写, 并将读取的数据和写成功信息返回给客户端。
(2) 每个数据块在某一时刻只能被指派给一台数据服务器, 在主服务器向数据服务器发送数据块加载请求后, 数据服务器完成整个加载过程, 它建立本地的数据块数据结构, 创建内存缓冲区Mem Table, 并将存储文件SSTable和日志文件Commit-Log的索引信息读到数据结构中。随着数据的写入, 数据块越来越大, 当数据块的大小超过上限 (Max Size) 时, 数据块需要分裂成两块。数据服务器负责检测所属的数据块的大小, 并发起数据块分裂的操作, 当数据服务器完成数据块分裂后, 向主服务器发送数据块分裂的通知。
(3) 数据服务器负责数据的整理。数据整理分为三种:小型整理、合并整理和大型整理。
2.2 读操作原理
Big Table能够实现在某一行中查找所需要的值, 循环读取Big Table的一个数据子集等功能。这些功能的基础是读操作, 数据服务器负责响应用户的读操作。如图2, 在客户端读取数据块数据之前, 它首先和主服务器进行通信以获取到需要读取的列家族以及版本控制信息。之后客户端直接从元数据表上查找所要读的数据块的位置, 即提供服务的数据服务器。客户端向此数据服务器发送读操作请求。数据服务器响应此请求, 并对读用户的权限进行验证。数据服务器根据需要读出物理文件SSTable中的数据, 并将其和Mem Table中的数据进行合并, 重新按序排列后, 将客户端所需数据返回。
2.3 写操作原理
除了对Big Table结构信息的修改, 用户还需要将数据写入到数据块中。写操作包括两种:将数据添加到数据块中, 将数据进行删除。Big Table提供了时间戳机制, 不同时间写入的版本会被保留下来。所以数据的写入是添加式和覆盖式写入, 一般不会涉及到数据修改和更新的情况。我们使用的是标识性删除, 在对数据删除时, 并不真正将数据从磁盘上删除, 只是在相应的位置进行标识, 在数据整理或GFS文件垃圾回收时对数据进行彻底的删除。
图3描述了数据服务器写操作流程, 客户端在进行写操作之前打开表, 以获取表结构数据。和读操作一样, 客户端从元数据表中查找要写入的数据块位置, 客户端向数据服务器发送写操作的请求。数据服务器对请求进行响应:首先, 数据服务器将写操作写入到存储在GFS的Commit-Log中, 此时数据服务器就可以向客户端返回写操作成功。但是写操作没有真正结束, 数据服务器将写入Commit-Log的操作成组的提交给内存中M e m T a b l e, 随着M e m T a b l e的不断增大, Mem Table中的数据最终将转换成SSTable。也就是下面讲到的数据整理。
2.4 数据块加载
数据服务器管理一组数据块, 它是建立在完成对数据块加载的基础之上的。数据块加载功能的使用是比较频繁的。数据块加载的发生时机:主服务器重启时, 新的数据服务器加入时, 进行负载平衡和数据块转移时。数据块加载发生的条件是存在未指派的数据块并且服务器有空闲资源。此时主服务器向空闲资源最多的数据服务器发送数据块加载请求。
数据服务器对数据块加载的请求进行响应。如图4所示, 数据服务器首先在元数据表上查找待加载的数据块信息, 和主服务器发送的信息进行核对。如果两者不一致, 则表示待加载的数据块发生了分裂, 这是由于在数据块分裂后分裂信息没有及时通知给主服务器造成的。如果数据块发生分裂, 数据服务器再次在元数据表中查找另一半的数据块信息, 通知主服务器发生了数据块分裂。数据服务器发起新的线程完成对另一半数据块的加载。
具体的加载过程是:数据服务器在本地的数据块链表中添加数据块的数据结构。数据服务器根据从元数据表中读取的数据块相关联的日志文件Commit-Log和存储文件SSTable的索引, 读取GFS上存储的Commit-Log和SSTable的数据, 重建内存中的Mem Table。数据服务器根据返回的Mem Table指针更新本地的数据块数据结构。数据服务器向元数据表发出更新请求, 将元数据表上的数据块的记录标识为已指派给此服务器。最后数据服务器向主服务器返回加载成功的消息, 主服务器将此数据块转移到已指派的集合中。
3 总结
本文设计了数据服务器的主要功能。数据服务器的主要功能包括:数据块的读写操作, 数据块的加载和数据整理。本文着重设计了前两种基本功能, 数据整理是一种辅助功能, 本文没有详细设计。
至今, Bigtable的主要功能已经实现, 数据服务器相关的技术包括:数据存储结构, 数据读写机制和服务器的负载计算。系统经测试证明, 具有较高的读写效率, 较低的磁盘使用率和较强的负载平衡能力。
参考文献
[1]Google’s BigTable[EB/OL].2005.http://andrewhitchcock.org/?post=214.
分布式实时数据库系统技术研究 篇10
1.1分布式数据库系统的特点。
分布式数据库由一组数据组成, 从物理层面看这些数据分布在计算机网络的不同结点上, 从逻辑层面看这些数据属于同一系统。网络中每个结点都具有独立执行局部应用程序的功能, 也能通过网络通信子系统在全局范围内执行应用程序。也就是说, 分布式数据库系统的数据库、终端、中央处理器、局部DBMS运行、局部应用程序执行等都是独立的, 但又可相互协作形成整体, 其用户可以实现在任何场地执行全局应用程序[1]。
1.2实时数据库的特点。
实时数据库系统是管理有时间限制的数据和事务, 强调调度机制和事务管理上对传统数据库的优化, 可设定事务的截止时间特征, 最大限度地满足事务起讫时间限制, 保证数据库内数据在逻辑和时序上完整一致。
1.3分布式实时数据库的优势。
现代数据库需求要求实时数据库与分布式数据库在功能特性上实现有效集成, 由分布式实时数据库管理系统统一调度管理, 其方法是在实时数据库的事务处理层基础上实现分布式事务处理, 即将具有执行期限的数据和事务分布在不同结点上。
二、分布式实时数据库的事务管理机制
2.1分布式高优先级两阶段锁定并发控制协议。
数据库系统的事务管理机制包括分布式事务并发控制机制、提交机制、避免或解决死锁及日志管理机制等, 分布式实时数据库是在分布式高优先级两阶段锁定协议基础上加入优先级因素考虑。在这一新型协议中, 优先级将由事务最后期限和紧迫性的初始状态调整为将事务进入系统的时间追加到初始状态的实时状态。以此实现每个站点上的锁管理器为站点上各个事务的子事务要访问的数据对象进行枷锁。其中, 当事务之间按照优先级的高低对占锁产生申请冲突时, 低优先级事务将被重启, 重启范围和事务自身全局或局部性质保持一致, 以此保持分布式实时数据库的优先级次序与加锁、解锁实现优化。
2.2附带终结协议的两阶段提交协议。
分布式数据库系统在出现协调站故障或通信链路问题时, 可能导致个体参与者不能及时收到协调者的提交决定, 导致参与者在结束投票阶段发生延迟, 子事务因此错过截止期, 附带影响其下关联事务执行。分布式实时数据库系统对此加入了终结协议, 以提高两阶段协议发生故障时的应急处理能力, 实现实时事务管理。
所谓终结协议即协调站在向若干参与者发送投票信息时同时附带提供所有参与站地址, 当出现上述异常情况时, 问题参与站可利用附带地址沟通信息。其实施办法是, 在参与站与恢复站的信息设计上分三种情况考虑:一是参与站有明确提交命令时则发送给恢复站相同信息, 恢复站执行协调者决策, 并发送信息至不确定站点;二是提交了信息却未收到命令则发送给恢复站不确定信息, 则恢复站继续询问;三是提交信息夭折则发送恢复站夭折信息, 恢复站自行回滚并将发送回滚命令至所有参与站。
2.3减少协议依赖性。
分布式数据库的协议模式虽实现了冲突模式下的数据共享, 却导致冲突事务之间相互依赖, 限制了提交顺序, 一旦协议出现故障且无法迅速恢复, 则其下依赖事务都将错过截止期。数据库通常依据事务在投票子阶段的时间长度是否超出无故障事务时限来断定该事务是否正常执行。因此分布式实时数据库对此协议形式改为弱依赖协议类型, 即维持执行冲突的协议解决方式不变, 而将既有的依赖性用依赖集实现其可串行性, 保证并发数据方位的数据库一致。当事务在提交后严重超出无故障事务时限则作回滚处理, 并顺次执行到该事务其下的连带事务上。由此只要有需要, 前期其提交事务都能被立即产生依赖性, 在依赖过程中可依据具体状态随时决定是否取消其被依赖资格。
总结
长久以来, 国内众多计算机应用行业文献都致力于对传统协议进行改进, 但多停留在或改善并发控制协议的并发度、或改良提交协议来提高食物管理的实时水平等单向度改进层次上, 分布式实时数据库在此问题改进上集成了二者优势, 令使协议适用于分布式实时系统环境, 设计了基于分布式实时数据库系统环境下, 并行交融并发控制和提交处理两个工作阶段的新协议方案, 解决了单向度改进协议无法全面解决的截止期问题。
参考文献
[1]庞惠, 翟正利.论分布式数据库[J].电脑知识与技术, 2011, 02:271-273.