实时数据库范文

实时数据库范文（精选11篇）

实时数据库 第1篇

1 实时数据库及其特征

实时数据库系统 (RTDBS) 中事务和数据都可以具有显式的定时限制, 系统的正确性不仅依赖于事务执行的逻辑结果, 还依赖于逻辑结果产生的时间。它已经引起了数据库和实时系统两个领域里的研究工作者们的极大关注。数据库研究工作者旨在利用数据库技术来解决实时系统中的数据管理问题, 实时系统研究工作者则致力于为RTDBS提供时间驱动调度和资源分配算法。

下面分析传统数据库、实时系统 (RTS) 和实时数据库 (RTDB) 彼此间的联系与差别以说明什么是RTDB、为什么要研究RTDB。

1.1 数据库与实时系统

传统数据库系统组合了多种功能:数据描述 (模型、模式) ;数据正确性维护 (完整性、一致性控制) ;有效的数据库存取 (数据库组织、操作与存取方法) ;查询与事务的正确执行 (查询处理、事务管理、调度与并发控制) ;数据的安全与可靠性保护 (安全性检验、恢复) 。

随着当今实时系统处理的信息量越来越大, 对这些功能的要求也越来越迫切。但在传统的数据库系统中, 其设计与开发主要强调维护数据的正确性、保持系统代价低、提供友好用户接口等。这种数据库系统对传统的商务和事务型应用是有效的, 但它不适合于实时应用, 关键在于它不考虑数据、事务及其处理相关的定时限制 (timing constraint) 。系统的性能目标是吞吐量和平均响应时间, 而不是各个事务的定时限制。

相反, 实时系统 (RTS) 所支持的应用具有很强的时间性要求, 其处理活动与数据都具有定时性。然而传统的实时系统典型地处理具有简单和可预报数据 (或资源) 要求的简单任务, 不涉及维护共享数据的一致性问题。

数据库与实时系统的结合导致了实时数据库的产生, 它集成两者的概念与要求以同时处理实时性与一致性, 这使得事务的调度与处理等问题要复杂和困难得多。

1.2 传统数据库与RTDB

传统数据库与RTDB在许多方面都不同, 最重要的是RTDB有不同的性能目标、正确性标准和关于应用的假定。不像传统数据库系统以快的平均响应时间为主要目标, 评价一个RTDBS是以其事务超截止期的比率、平均延迟度和承受的代价、数据的时间一致性为指标。

对于传统数据库, 其事务具有ACID (Atomicity, Consistency, Isolation, Durability) 特性。在RTDBS中, 则有根本的不同, 其事务由下列特性 (概念) 确定:

(1) 可见性:事务执行时可查看另一事务的能力。

(2) 正确性:事务的时间正确性、事务本身的逻辑正确性及事务提交时数据库状态的一致性。

(3) 可恢复性:发生故障时使数据库成为某种被认为是正确状态的能力。

(4) 永久性:事务记录其结果到数据库及识别其中数据的有效期的能力。

(5) 可预报性:事先预测一个事务是否会满足其时限的能力。

(6) 不可逆性:有些事务的执行不能像传统意义上那样ABORT和RESTART, 事务执行的失败可能需要别的事务来“补偿”或“替代”。

因此, 在实时应用环境下, 数据库的处理必须支持:

(1) 传统的平坦原子事务模型已不适用, 要求“复杂事务”。

(2) 事务的合作、协调而并发地执行, 即要求事务间的直接交互作用和通讯。

(3) 及时性比正确性更重要的性能标准, 有时宁愿要及时而部分正确的信息, 而不愿得到完全正确但是过时 (无效) 的信息。

(4) “识时”协议和“时间正确”的调度与并发控制, 至于对传统数据库最重要的可串行化调度与并发控制倒不一定必需。

(5) 数据的时间相关性, 即数据存储、组织与存取都是“识时”的。并非所有数据都是永久的, 许多是短暂的, 甚至不一定要求所有结果都记录到永久数据库中。

(6) 恢复不一定就是数据库状态的完全复原, 要特殊的提交与恢复机制。

所以RTDB与传统数据库在概念、原理、结构、算法等方面都存在着很大的差别, 最根本的区别就在于数据与事务的定时限制。这里要指出的是, “实时”并非简单地意味着快, 快固然需要, 但对RTDBS而言, 实时指的是能施加和处理“显式”的定时限制, 即使用“识时协议” (time-cognizant protocol) 来处理有关的截止时间或定时限制。

2 RTDB中的时间

RTDB系统要使用有效时间和事务时间, 有效时间用于在现实世界中有直接匹配对象的数据, 对应于改变这些物理对象的外部事件需要严密监视, 一旦发生, “输入接受”事务 (只写) 立即记录其变更值到数据库。事务时间用于借助RTDB和专门的输出设备给实时系统设置参数的“控制”事务、事件和导出数据的值, 与导出值相联的一般是事务的提交时间。

实时数据库涉及的时间信息与时态数据库 (TDB, Temporal Database) 中的有联系又有区别。时态数据库旨在包含随时间变化的信息, 它维护数据库中数据对象经历的变化历史, 外部环境的一个对象在数据库中可能存在多个对应不同时刻的映像值, 现实世界对象状态的变化并不一定引起数据库中对应者的修改, 而是在数据库中增加一新项, 用户可以查询对象的历史。在TDB中存取数据的事务并没有“显式”的时间限制。

相反, RTDB提供维护数据有效性和事务及时性的设施, RTDB对象因现实世界中对应者的状态改变而适时地相应修改, 其历史状态依应用可以保留也可不保留, 而且一般只允许事务存取数据库中当前 (有效的) 信息。事务必须维护数据库对象的“时间一致性”, 同时事务本身还有来自应用语义的定时要求, 故事务有时间限制与之相联。这就是RTDB与TDB的最大区别之所在。

由于所存取的数据的时间一致性要求和物理世界施加于控制系统的反应时间要求, 实时数据库系统中事务存在各种各样的定时限制, 典型地表现为事务的截止期 (deadline) , 它定义为事务t在能给系统带来最大价值的前提下能最晚提交的时间, 记为dl (t) , 即

式中, V (t, τ) 表示事务t在时刻τ提交时给系统带来的价值, MAX_V (t) 表示事务t能带来的最大价值。

3 RTDB的数据、事件及活动的时间限制

RTDBS就是其事务与数据都可以具有定时特性和/或显式的定时限制的数据库系统。故首先讨论RTDBS的数据、事件及活动 (事务) 的时间特性。

3.1 数据的时间限制

在RTDBS中, 数据只在一定时间 (外部有效期) 内是当前有效的, 所以我们不能只考虑数据库内部状态的一致性, 还必须考虑外部世界与内部状态的一致性, 同时也必须考虑不同数据间的相互时间一致性。

在RTDBS中, 与每一数据相联的有一“外部有效期” (或简称有效期) 。按这种时间分类, 数据可以是非实时数据和实时数据。传统数据库中的数据即为非实时数据, 可认为它是“有效期”任意长的实时数据;实时数据的采样 (或计算) 值有效性在其“当前值”建立以后不应超过一指定的时间。RTDB中有两类实时数据, 一类是由传感器事务自外部环境直接写入数据库的, 我们称这类数据对象为“映像”对象;另一类是由映像对象推导出来的数据对象称为导出对象。

定义1.1一个RTDB的数据对象为一个三元组d:。其中分量dv、dtp、devi分别为d的当前状态或值;观测时标 (observation timestamp) , 即采样d对应的现实世界对象的值的时间;外部 (绝对) 有效期 (external validity interval) , 即自dtp算起dv具有外部或绝对有效性的时间长度。

定义1.2 (内部一致性) 当且仅当d满足所有预先定义的完整性和一致性限制时, 数据d是内部一致的。

内部一致性概念相当于传统数据库的正确性或完整性概念。

数据库的变更都是以事务的形式进行的, 因而操作的完整性和可串行化能提供内部一致性保证。

在RTDBS中, 数据库依靠逻辑世界与外部环境频繁地交互作用来获取准确、及时的数据, 所以一个正确的数据库状态必须与外部环境当时的实际状态一致。

定义1.3 (外部一致性) 数据d是外部 (或绝对) 一致的, 当且仅当 (τc-dtp) τdevi (τc为当前或检测时间) 。

当一组相关数据对象被使用时, 它们之间存在着时间上的相互 (或相对) 一致性问题。如两个传感器分别独立地读取飞行器的x坐标与y坐标的信息, 这两个值往往不会在完全相同的时刻进入系统。使用它们的事务必须知道它们是否对应对象在同一时刻或彼此充分接近的时刻的采样值。

定义1.4 (相互一致集) 用来作决策或导出新数据的一组数据对象称为一个相互一致集, 记为R。每一这样的R都有一与之相联的有效期, 记为Rmvi。

定义1.5 (相互一致性) 设R是一个相互一致集, d∈R。d是相互 (或相对) 一致的, 当且仅当:

实时数据库事务的执行不仅要考虑事务的截止期, 同时还应考虑事务所用数据的有效性 (外部一致性) 及不同数据间的相互一致性, 它们都与时间相关, 统称为时间一致性。

定义1.6 (时间一致性) 若一个数据既是外部一致的又是相互一致的, 则说它是时间一致的。

定义1.7 (数据的正确状态) 当且仅当一个数据同时是内部一致和时间一致的, 才说它具有正确的状态。每一数据都具有正确的状态, 则说数据库有正确状态。

在RTDBS中, 不光是数据存在时间限制, 还存在与事件相联的时间限制及与活动 (事务) 相联的时间限制。

3.2 事件的时间限制

在实时应用中, 各种活动一般由相关事件的发生所触发, 即与每一活动相联的是一个事件的发生, 因此, 施加于活动上的某些类型的时间限制来自于触发这些活动的事件的定时限制, 故先要弄清有关事件的定时特性。基本上有3种这样的时间限制: (1) 最大:两事件之间的最大时差。例如一旦一目标进入雷达的视野, 目标识别的完成必须在τ1 s内。 (2) 最小:两事件间的最小时差。例如两个飞机的着陆必须至少隔τ2 s。 (3) 持续:一个事件经历的时间长度。例如在“请系好安全带”信号关停前飞机必须经历至少τ3 s无颠簸平稳飞行。

在上述讨论中, 事件可以视为一种行为的瞬时发生, 也可作为一种有限的短暂行为过程, 若是行为的瞬时发生, 则在上第3例中的事件持续经历可看作为以简单事件来标志它本身的开始和结束的复杂事件;若是行为过程, 则上述第1、2例中的瞬时事件可看作其行为过程极短的事件。

3.3 活动的时间限制

在讨论了关于事件和数据的时间限制以后, 现在不难明确关于活动的时间限制的语义, 因为事件发生要由与之相联的活动来处理, 故关于事件的时间限制将直接作用于这些活动, 如重复发生的事件的时间限制则转换成相应活动的周期性要求;输入或激发事件与其响应 (或输出) 事件之间的“最大”时间限制则决定相应活动的截止期等。换句话说, 关于事件的时间限制将转换成处理这些事件的活动的时间限制。关于活动的时间限制归纳有:

(1) 外部环境行为所决定的时间限制—限制输入的频率与到达系统的时间。例如, 在空中交通管制系统中, 飞行指挥员必须到距机场10 min的飞行距离时请求允许着陆。

(2) 系统性能规定的时间限制—决定系统对输入的响应。例如发出允许着陆请求后, 系统必须在30 s内作出响应。

(3) 数据的时间一致性所施加时间限制—限定感知外部环境并更新系统数据库的活动。例如更新飞机的各种动态参数的活动必须以指定的周期执行, 这种活动有截止期, 它依数据的外部有效期而定。

(4) 此外, 还有一种解决问题方法可行性所决定的时间限制, 它限定系统内部行为以使有关解决问题方法能成立。例如, 在分布式系统中, 各种结点状态的相互同步通信的及时性常常用来作系统故障的检测。若在给定的时间范围内, 一个结点未收到另一正常结点的“我是正常的”消息, 则可能出故障, 要调用代价高的故障诊断程序来进一步诊断。

基于上述原因, 实时事务也有外部一致性和相互一致性, 外部一致性指满足外部环境所施加的定时特性, 包括数据的外部一致性转换而来的限制。相互一致性就是涉及事务正确性的各事务有效时间之间的相关性, 包括数据的相互一致性。

3.4 RTDB的事务特征

传统的并发控制技术和事务处理方法能够保证数据库的内部一致性, 而为了保证数据库的时间一致性, 必须采用“识时” (time-cognizant) 事务处理技术, 对传统的并发控制技术和事务处理方法进行改造。为此, 必须明确RTDBS的事务特征。

传统事务具有ACID特性, 前三者分别为“故障原子性”、“并发原子性”和“执行原子性”, 统称原子性, 故原子性和可串行化是事务正确性的通用准则。而在RTDBS中, 有以下方面必须考虑:宁愿要部分正确而及时的数据而不愿要绝对正确但已过时 (无效) 的数据, 系统可以忍受短暂的数据库状态在一定范围内的不一致性以提高并发度, 满足事务的截止期;事务之间有联系, 事务执行过程中的结果对某些其它事务是可见的;并非所有数据都具有永久性。

在RTDBS中, 事务最重要的特性是定时性, 它包含两方面的含义:定时限制—事务的执行具有显式的定时限制, 典型为截止期。事务 (或系统) 的正确性不仅依赖于其逻辑结果的正确性, 还依赖于逻辑结果产生的时间。这是由于系统需要随时跟踪外部环境而引起的。定时正确性—事务能按合适的时间要求正确执行。这是由于要求数据对于系统的各种决策活动随时有效所引起的, 它要求权衡定时限制与数据一致性等多方面因素, 提供合适的调度算法。

由此可见, 事务的时间限制来自于数据的时间一致性要求和/或施加于系统反应时间的要求。

4 结语

实时数据库系统 (RTDBS) 与传统关系数据库相比, 其事务和数据都可以具有显式的定时限制, 系统的正确性不仅依赖于事务执行的逻辑结果, 还依赖于逻辑结果产生的时间。因此它更适应于目前高速发展的移动计算技术和移动通信需求。

参考文献

[1]刘云生.现代数据库技术.第1版.北京国防工业出版社, 2001

[2]U.Dayal, B.T.Blaustein, A.P.Buchmann, et al.The HiPAC project:combining active database and timing constraints.ACM SIGMOD Record, 1988, 17 (1) :51～70

[3]N.W.Paton, O.Díaz.Active database systems.ACM Computing Surveys, 1999, 31 (1) :63～103

[4]R.Rifaat, S.L.Argue.Developing an engineering database for rural underground distribution projects.in:P.Kindred, D.Harley, eds.IEEE Western Canada Conference on Computer, Power and Communications Systems in a Rural Environment Regina, Sask, Canada.1991.New York:IEEE Computer Society Press, 1991.171～178

天猫双十一销售额实时数据 第2篇

为了全面直观展现当天消费者购物场景和节日气氛，水立方会议报告厅搭建起了实时直播数字大屏，相比去年的13米长、6米高，今年的显示屏升级到了20米长、10米高。

直播大屏将提供实时信号，包括数据大盘、全球交易图、热卖品牌榜、菜鸟物流雷达预警等。

1分12秒交易额过10亿元

现场大屏幕提供的实时数据：

开场18秒，天猫交易额超过1亿元。

1分12秒，交易额就突破10亿，去年这个时间，交易额刚突破1亿元，今年第一分钟的交易额度增长了10倍。

1分45秒，数据显示天猫跨境贸易的交易额超过去年双11全天的数据。

5分钟，交易超过43亿元，是去年同期交易额的一倍多。

12分28秒，天猫交易额就超过了100亿元，而去年这个数字用了38分钟28秒。

31分钟，达到191亿元，是双11全天的交易额。

33分53秒，交易额超过200亿元。

1小时13分59秒，交易额突破300亿元。

环境信息化中的实时数据库应用 第3篇

实时数据库的优势

大多数环境信息化系统的数据量都较为庞大，以环境监测和污染源监控管理系统为例，系统需要接入大量实时的污染源自动监控数据和环境质量自动监测数据，而常规数据处理方式会带来数据存储时间不长、精度不高、存取效率低下等诸多问题，而与此同时，数据量的增长与系统运行效率成反比，大幅增长的数据会逐步影响平台的正常运行。

为解决上述矛盾，人们在技术层面上一般采取构建分布式关系数据库集群的方案，这无疑会增加硬件构架的复杂性，并增加维护管理和设备投资成本。

针对以上问题，系统构架者可选择采用成熟的实时数据库产品及相关技术解决方案。实时数据库构建树状数据模型，能够提供大量、不间断的存储，支持多种压缩，存储容量大，提供大量数据挖掘分析功能，在高速、大量的存储时能够提供多并发的高速查询，弥补关系数据库在实时数据存储、分析、查询方面的不足，改善关系数据库应用过程中系统响应速度下降、系统崩溃等问题，大幅提高系统安全性和运行效能。

污染源在线监测与分析系统

“污染物治理设施过程（工况）在线监测及分析系统”（简称“污染源在线监测与分析系统”）是污染源自动监控系统的进一步深化，其从原有的“末端监测”基础，深入到污染治理设施的运行，通过抽取出代表设施运行的模型和工况参数，精确描述设施运行的状态，为提高自动监控数据有效性、优化治污设施运行，及环境监察执法、总量减排、排污收费等各种管理应用提供可靠的数据支撑，该系统采用的正是实时数据库产品及解决方案。

工况在线监测及分析系统是对污染治理设施运行全过程进行实时监控、分析、预警、核查和管理的一体化环保信息化管理平台。系统结构分为四层：采集层、网络层、数据层和应用层，数据直接来源于生产控制系统、治污设施控制系统和自动监控系统。

工况在线监测及分析系统主要满足了环境监管部门日常监管工作需要，可以实现重点污染企业污水、废气过程参数的实时查看、分析、报警和辅助决策，过程参数与污染源自动监控数据可进行一致性校验分析，支持环境执法、总量核定和排污统计等环保业务。

污染物治理设施过程（工况）在线监测及分析系统以实时数据库为基础，在工况验证分析、工况数据统计两个基础平台的支撑下，实现对工况数据的分析和应用，主要包括系统管理、实时监视、趋势分析、报警、工况统计、工况核定、总量核定、企业交互及报表分析等功能。

数据库结构设计

工况在线监测与分析系统数据库结构

工况在线监测及分析系统数据库按照分布式多级数据库方式进行设计，主要分为三个层次：前端工况过程数据库层、中心工况过程数据库层、中心工况应用数据库层。

前端工况过程数据库和中心工况过程数据（原始库与分析库）采用实时数据库，由于工况系统需要存储大量的数据，因此需在存储前进行数据压缩。实时数据库具有数据压缩功能，可以用非常小的空间来存储大量的数据，而且还能保持相当不错的数据精度。

前端工况数据库层由布置企业前端的工况现场前端工况数据库组成，它是分布式过程数据库的基础层。前端工况数据库的作用是在企业前端将全厂的工况数据做汇总，由于其布置在前端现场，存储数据只受现场采集设备、采集网络及现场供电情况的影响，故其完整性在整个系统中是最高的。

前端工况过程数据库还有一个重要的功能是通过数据转发模块向中心工况过程数据转发实时工况数据，转发模块在网络出现异常时会记录最后发送的记录情况，在网络恢复时会将网络中断时间内的历史工况数据回补到中心工况过程数据库中，从而保证中心工况过程数据库中工况数据的完整性。

中心工况过程数据库层由原始库和分析库两个工况过程数据库组成。原始库主要是存储、汇总与前端工况数据库一致的工况过程数据，同时采集参数名称也与工况现场完全一致。分析库主要是将原始库中的数据依据一定的标准化规则转换成工况分析所需要的数据，包括采集测点的标准化、采集参数的实时计算（换算）、实时分析结果的存储等。

实时数据库应用情况

实时数据库在数据采集、存储、显示、分析方面拥有显著优势，所以在工况在线监测与分析系统中得到了广泛应用。

数据处理能力：工况在线监测与分析系统数据庞大，要求数据库读取数据和存储数据的能力能跟上节奏，实时数据库具有海量数据处理能力，读取实时数据库的时间是毫秒级，同时支持百万级单数据库的容量。

实时工况监控：工况监测的一个重要功能就是实时监测，即将工况的实时数据真实准确地反映在工况实时图形界面上。工况实时图形界面不但要具备实时显示模拟量的数值变化，还要能显示开关量的变化情况，系统通过红、绿、黄颜色分别代表运行、停运、故障。

火电厂工况实时图形界面

趋势分析：实时数据库能准确记录数据的变化趋势，方便监测人员查询调阅历史数据变化趋势。实时数据库提供实时数据对比分析、历史数据对比分析、自定义趋势组、表格显示数据、数据导出、前进、后退、放大、缩小和打印等功能。

数据查询：主要针对采集的排污数据、状态数据、过程数据进行综合查询。

报表系统：报表工具基于J2EE的B/S报表平台，能够实现统计参数的在线配置、数据自动统计、报表模板定制及发布等功能。

工况报警：实时及历史报警可视化工具可以显示当前或过去某段时间内的报警详细信息，提供报警过滤、报警数据导出、报警鸣笛等功能。在火电厂工况系统中，报警主要分为网络报警、机组停运报警、脱硫设施停运报警、污染物偷排报警、超标报警报警、脱硫设施低负荷运行报警、脱硫系统参数异常报警。

工况数据关联性分析：主要依据实现定义的分析模型对工况进行综合分析，以电厂为例，可以判断发电机组、治污设施的运行情况是否正常、污染源监测数据是否可靠，及时发现发电机组生产过程、治污设施、监测系统中可能存在的异常情况，如偷排、治污设施虚假运行等。

关系数据库与实时数据库结合

当前，很多项目的数据层设计都采用关系数据库与实时数据库相结合，工况在线监测与分析系统中，前端工况过程数据库和中心工况过程数据（原始库与分析库）采用的是实时数据库，中心工况应用数据库层由通用关系型数据库来承担。

对于实时采集的数据需要能够进行数据分析，并与关系数据库进行数据交换，能够根据业务需求配置相关数据统计规则，定期统计、抽取实时数据库数据至关系数据库中，实时数据库的测点能够与关系数据库进行映射，构建实时数据库的横向业务关系模型，能够根据业务需求，实时地组织实时数据，构建关系模型，并提供给业务系统。

实时数据库是采用实时数据模型建立起来的数据库，用于处理不断更新、快速变化的数据，以及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的产物，利用数据库技术来解决实时系统中的数据管理问题，同时利用实时技术为实时数据库提供时间驱动调度和资源分配算法，其主要应用于自动连续数据的监控，如电力、环保、石化、化工、钢铁、冶金、造纸、交通控制和证券金融等领域。

实时数据库与关系数据库的结合解决了连续自动数据采集所带来的并发性、高速存取、数据存储、系统性能等问题，同时也能利用关系数据中的对象关系、事务处理、自定义结构等来优化系统数据的利用。

实时数据库设计的关键技术 第4篇

关键词：实时数据库,事务模型,事务规划,并发控制,I/O规划

1引言

和传统的数据系统一样, 实时数据系统的功能是数据的知识库, 提供高效率的数据存储, 完成信息的查询和操作。实时事务是实时数据库的基本单元，按照完成点的不同，事务可以分成硬、软和严格实时事务。硬完成点的事务必须满足它们的完成点，否则系统不能满足性能指标。软实时事务有时间约束，但是当一个事务通过它的完成点而没有执行时，可以有一些时间余量来完成这个事务。和前两类事务相比，严格实时事务一旦通过它的完成点，则这个事务不再被考虑。因而，作为实时系统的一部分，实时数据库的各项任务是和时间约束密切相关的。用当前的技术很难提供一个满足事务完成点的绝对可靠的方法。因此实时数据库被大部分限制在软实时系统。有几个因素使得实时数据库很难满足所有时间约束。首先，数据库事务的执行通常是数据和资源相关。为了满足事务完成点需要大量的额外资源去适应最高的系统负载。再者，完全的事务支持包括许多数据库协议，而这些协议的执行时间很大程度上是不可预测的。最后，基于磁盘的数据库系统和I/O子系统频繁相互作用。如磁盘寻找时间变化、缓存管理和导入导出页失败等问题，引起平均和最差的执行时间变化很大。所有这些增加了事务的不可预测性。

2实时数据库设计的主要问题

事务模型：

在一个实时事务的属性中，完成点是最重要的一个属性。其被应用于实时数据库系统的许多方面，如并发控制、规划、不精确的计算等。通常一个事务的完成点被设计人员指定。但是，如果事务模型支持嵌套或子事务，有一个问题是在父事务的完成点要求下约束如何被赋给单个的子事务。

到目前为止，我们假定实时约束专用于事务。Korth等人提出了一个不同的模型完成点和一致性约束相关。在他们的模型中除了维持系统正常状态的事务以外，事务可以被激活以记录产生在系统外部的一些外部时间的影响。在数据库状态的真实改变可以产生一个一致性约束无效。这个一致性约束可以需要在一个特定的完成点被恢复。但是不一致性被检测到，一个补丁事务被激活试图纠正这个错误。但是这个补丁事务可能违背其它的一致性约束。这可能导致一个事务触发链。

一致性恢复的方法如下：首先分析实时系统，构建一个预测优先级图（PPG）。当一个约束被违背时，通过分析预测优先级图，一个补丁计划被构建。这个计划可用PPG的一个不一致性的解子图（IRS）所表示。直观上讲，一个不一致解子图给出事务执行的部分序列, 使得一致性约束被恢复。

事务规划：

实时系统研究的一个主要工作是多用户程序环境下工作的规划。事务规划的工作, 包括CPU、数据、I/O、内存等。在这里主要讨论事务的优先级如何分配及CPU调度。

实时规划算法优先处理关键的任务。一个通常的做法是根据任务的紧急程度赋给不同的优先等级。如下列公式所示：

其中γ是事务的重要度，w i是加权值，a是事务的优先级，d是事务完成点，c是已经完成的工作数量，l是未完成的工作数量。优先级计算的实时规划算法是基于未完成工作的数量和延迟，要求有一个好的事务时间预测。

并发控制：

并发控制是指并发事务中的一种交互控制方式，使得保持数据库的一致性。两个碰到的主要问题是优先级转换的可能性和死锁。解决优先级转换的方法之一是有条件启动重新算法。

其中：EH:=估计剩余运行时间TH

SR:=估计延迟时间TR pr (TR) >pr (TH)

如果TR的延迟时间更长超过TH的运行时间, TH允许被完成不损失TR的完成点。

死锁是可能碰到的第二个问题。当一个事务的集合在一个环路等待，一个死锁发生。这种情况下，在死锁中的一个事务被选择终止，选择终止事务的策略包括：

(1）、终止一个已经通过它的完成点的事务。

(2）、终止一个最长完成点的事务。

(3）、终止一个最次要性的事务。

实验证明，当死锁发生时，通常死锁内仅包含两个事务。因此使用复杂但是昂贵的解决死锁冲突算法是不明智的。

I/O规划

在基于磁盘的数据库系统中，磁盘I/O占据了事务执行时间的大部分。考虑时间的磁盘规划算法极大地改进了实时系统性能。常用的算法如电梯算法和先执行最高优先级组的算法。

先执行最高优先级组算法是模糊了优先级的边界，磁盘请求被分成几组小的优先级，磁盘被规划首先去服务最高优先级的组，如果最高优先级的组中超过一个请求，电梯算法被用于内部组。

实验表明先执行最高优先级组算法（HPGF）在满足完成点方面的性能超过电梯算法，但这是以加长平均反应时间为代价。研究显示反应时间主要对低优先级请求方面的影响较差，而对高优先级的反应时间非常接近电梯算法。

缓存管理和缓存驻留数据库

缓存影响事务反应时间存在两种方式。首先，在一个事务开始它的执行以前，缓存必须被分配到事务，这些缓存被用于存储磁盘上的执行代码，文件拷贝和数据页以及一些临时文件，一定数量的缓存必须被分配以防止事务花费大量的时间从磁盘交换数据。当缓存容量低时，一个事务可以分块执行。一个系统中可得到的内存数量因此限制了并发执行的事务数量。再者，一些高容量的缓存应用中，如果缓存数量有限，经常的内存交换引起事务执行速度的大幅度下降。

缓存管理的工作是去分配内存缓冲区给所要执行的事务，使得高优先级的事务享有更短的反应时间，一个缓冲管理器的工作通常按照它的允许和缓冲替换的时间决定。当一个事务T被发布的时候，缓冲管理器将决定是否允许去执行事务，这个决策被称为事务允许策略。常用的事务允许策略是挂起最低优先级事务直到：（1）.足够容量的缓存被释放给T去执行。（2）.没有更多挂起的事务，其优先级小于事务T。第一种情况，释放的内存被分配给T, T执行。第二种情况，由于缺乏内存T被锁。

替换缓冲的选择被称为缓冲替换策略，传统的替换策略包括最近最少使用策略（LRU）, 最少经常使用策略以及带优先级的最近最少使用策略。

内存驻留数据库

跟磁盘比较而言，主存访问时间更快也更具有预测性，这些特点对于严格规定事务完成时间的实时数据库系统而言是非常必要的。但是，放所有数据到内存也有它的不利之处。其一，价格比基于磁盘的系统更昂贵。其二，主存的易失性问题。存储在主存中的数据当停电或CPU出现故障时会丢失。其三，驻留内存的设计目标和传统的基于磁盘的系统不同，传统数据库系统的数据结构和查询处理算法是减少访问磁盘的次数，而驻留内存的系统而言，当数据被驻留内存时查询优化和数据结构设计以最小化CPU处理时间和使用的内存容量。传统的访问方法和数据结构被修改。最后，小的数据访问时间也影响一个并发控制机制的选择。没有I/O延迟，事务执行时间将是很小的。由于数据锁的块延迟也将减少，我们因此有一个更粗糙的粒度为了数据锁以减少内存和处理器负载。

结束语

本文讨论了实时数据库和事务处理设计的相关问题。实时数据库区别于数据库系统和实时系统是它的更多需求目标限制在时间约束内。因此，子事务的合适完成点赋值对许多实时数据库协议而言是至关重要的。当实时数据库不断发展时，这方面的工作将有很大的空间。

参考文献

[1]D.Hong, S.Chalravarthy, T.johnson.AlternativeVersionConcurrencyControlforfirm real-timedatabasesystems.Tech.report UF-CIS-TR-95-031, 1995

[2]BenKao, HectorGarcia-Molina.An OverviewofReal-TimeDataBaseSystems.NJ, USA:Prentice-Hall.Inc, UpperSaddleRiver, 1995.463-486.

飞机实时监控数据挖掘方法研究 第5篇

飞机实时监控数据挖掘方法研究

通过数据挖掘技术分析与飞机运行和维护相关的.数据资源来研究一套能及时察觉、分类并预报故障的飞机实时监控系统(Aircraft Real-Time Monitoring & Troubleshooting System,AMTS),使其能够在优化飞机关键部件寿命的同时减少飞机运行和维护的费用.分析着手于历史维护经验库,结合飞机维护技术文档和相关数据挖掘算法,介绍了构建该系统的原理和方法,并初步实现利用飞机实时故障报文对飞行状态进行实时监控及故障诊断.

作 者：朱睿 郭隐彪 ZHU Rui GUO Yin-biao 作者单位：厦门大学机电工程系,福建,厦门,361005刊 名：厦门大学学报(自然科学版) ISTIC PKU英文刊名：JOURNAL OF XIAMEN UNIVERSITY(NATURAL SCIENCE)年，卷(期)：46(5)分类号：V267 V247.5关键词：数据挖掘 实时监控 技术文档 历史经验

甲骨文 实时数据提升企业创新能力 第6篇

“为什么我无法访问决策所需的数据”; “为什么我的应用系统引用的是上周的数据”; “为什么系统内有这么多数据副本,而且其中大部分并不准确?”随着企业规模的迅猛扩张,企业的信息量、数据量呈爆炸式增长,企业的决策者会发现很多诸如此类的问题。

“传统的数据处理方式由于技术限制已无法满足企业需求,只有实时的数据采集方式,才能为企业正确的决策提供精准的数据分析、降低信息延迟、保证快速的业务响应。” 甲骨文公司大中华区产品战略部首席产品战略/解决方案专家萧百龄解释道。

然而当企业决定要实现实时数据时,却发现面临着开发成本难以评估、基础架构可靠性和数据质量无法保证等诸多挑战。针对市场和企业的发展需求,近日,甲骨文公司提供了一个统一的企业级实时数据解决方案——Oracle数据集成解决方案。

据介绍,Oracle数据集成解决方案用于在SOA、BI和数据仓库环境中构建、部署和管理以实时数据为中心的架构,包含了数据集成的所有要素—实时数据移动、转换、同步、数据质量、数据管理和数据服务,能确保各个复杂系统的信息及时、准确、一致。

萧百龄表示,通过使用Oracle数据集成,企业可以将其开发成本降低30%,数据处理速度提高50%,业务流程执行时间减少至少70%。这些成本节省和效率提升对企业适应当今极具挑战性的全球经济环境至关重要。

实时数据库数据压缩算法探讨与改进 第7篇

实时数据库 (RTDB) 作为组态软件的核心, 保存着系统运行时产生的各种数据和信息。这些信息对管理层及时了解生产现场的实时情况、实现上层信息系统与底层控制系统的集成都具有重要意义。随着RTDB应用领域的不断扩展, 对它的研究也越来越深入, 其中如何存储与管理实时数据库中大量历史数据的问题也受到了更多的关注。

参考文献

[1]方来华, 吴爱国, 何熠.组态软件核心技术研究[J].化工自动化及仪表, 2004, 31 (1) :33-35.

[2]王伟, 刘文怡, 秦丽, 等.遥测数据实时压缩技术的设计与实现[J].仪器仪表学报, 2006, 27 (6) :2467-2469.

[3]张景涛, 王华, 王宏安.实时数据的存取与压缩[J].化工自动化及仪表, 2003, 30 (3) :47-50.

[4]徐新.增强型矢量数据压缩算法的设计与实现[J].计算机应用研究, 2007, 24 (12) :393-395.

[5]WELCH T A.A Technique for High Performance Data Com-pression[J].IEEE Computer, 1984, 17 (6) :8-18.

[6]黄豪佑, 董辉, 卢建刚.历史数据压缩算法在DSP上的实现[J].计算机测量与控制, 2006, 14 (12) :1686-1688.

QCS实时数据库系统的研发 第8篇

工业自动控制的飞速发展, 呼吁与之配套的数据库技术的发展。传统数据库在非传统的工程和时间关键型应用方面显得力不从心, 而实时数据库在这里显示了它蓬勃的生命力。下文将结合一个开发的定量水分控制系统 (QCS) 实时数据库的实例对它进行研究。

2、实时数据库简介

2.1 实时数据库的发展与特征

数据库的应用正向新的领域扩展, 如过程控制、数据通信、电子银行事务、电子商务等。这些应用与传统应用有着不同的特征: (1) 要维护大量共享数据和控制数据; (2) 其应用活动有很强的时间性, 要求在规定的时刻或时间内完成;同时, 所处理的数据有一定的时效性。

实时数据库的基本特征恰好能满足这些应用特征, 这就是就它的时间相关性。实时数据库在如下两方面与时间相关: (1) 数据与时间相关; (2) 实时事务有定时限制。

2.2 实时数据库的应用领域

实时数据库有以下几个方面的应用:记录实时过程的历史数据;连接各类自控设备, 实现自动监控;通过数据库网络通信功能构建分布式应用系统;运行在控制系统的位机中, 实现可扩展的先进控制或优化控制目标。“定量水分控制系统数据库”主要是前两应用的体现。

3、实时数据库的结构

3.1 实时数据库的体系结构和系统结构

从系统的体系结构来看, 实时数据库与传统数据库区别不大。同样把数据库分成3个级别:内部级、概念级和外部级。数据库的3级结构是数据的3个抽象级别。

下表1以“定量水分控制系统数据库”为例, 描述了一个典型实时数据库系统结构。

“定量水分控制系统实时数据库”结构实现的部分代码如下:

3.2 实时数据库的数据结构

实时数据库与其它一般数据库一样, 包含一组对象及其结构。但目前对它还没有提出统一的数据模型。“定量水分控制系统数据库”采用了Access关系数据库的数据结构。以定量水分测量值数据表为例, 其数据结构 (即逻辑结构) 如下:

4、实时数据库系统的功能

实时数据库除具有一般DBMS的基本功能, 还具有以下三个功能特性:

(1) 数据库状态的最新性;

(2) 数据值的时间一致性;

(3) 事务处理的“识时”性。

“定量水分控制系统实时数据库”的功能有: (1) 定量水分实时数据采集、统计、显示、绘图、存储等; (2) 定量水分历史数据查询、绘图、打印; (3) 浓度、流量、压力、车速实时数据的采集、显示、存储等; (4) 浓度、流量、压力、车速历史数据的查询、绘图、打印。

下面结合“定量水分控制系统数据库”, 对实时数据库系统的主要功能进行介绍。

4.1 I/O设备的数据采集与回送

它是实时数据库的一个最基本的功能。本实例支持的I/O设备有DCS、PLC。用户可以任意指定各种数据的采样周期。本实例中浓度、流量、压力、车速数据的采样周期为2秒, 定量、水分的采样周期由扫描架运动周期决定。

4.2 输入输出处理

任何数据在进入数据库前, 均可先进行来源检查, 上下限检查, 并进行量程转换、简单滤波、开方等处理后再进入数据库。输出处理用于在数据库向外部设备进行数据回送前, 对发往现场的数据进行输出上限、下限检查和限值变化率检查, 并进行输出记录。

本实例在输出历史记录时用到曲线图的方法, 下面举出部分定量、水分历史曲线制作部分代码 (注:RS为记录指针) :

4.3 统计

设置了自动统计功能时, 数据库自动对PV值 (过程值) 的变化进行累计运算, 可提供小时、班、日、月、年的累计值。自动计算时间段内的平均值、最大/小值, 形成统计历史数据。

“定量水分控制系统实时数据库”中对定量、水分的采样值进行了统计, 下面仅举出部分求横向定量值的平均值、偏差、最大值的算法 (注:arr1 (i) 为动态存储定量采样值的数组) 。

4.4 在线组态与查询

以上各种内置的数据处理功能, 均是由组态数据进行管理的。用户可以用任何一个访问数据库的应用程序在线修改这些参数, 当然也可以在数据库上直接修改或查询。

下面列出了“定量水分控制系统数据库”中对浓度、流量、压力测量值查询的部分算法。

4.5 保存历史数据

各实时数据库均可保存历史数据, 且可任意指定保存时间, 中间可随时停止和恢复。“定量水分控制系统数据库”保存历史数据用到几个自定义函数, 下面给出保存定量水分的函数。

4.6 其它功能

实时数据库系统的其它功能有:数据累计处理、运算和控制、事件管理、网络通信及并发处理等。

5、结语

实时数据库能同时处理大批实时的数据和库存的静态数据, 使得它同时具有传统数据库和实时数据库的双重功效, 这种特性必然使它将成为数据库的主流。随着自动控制的深入发展, 必将促进实时数据库的研究和发展。

参考文献

[1]马国华.监控组态软件及其应用.北京:清华大学出版社, 2001.

[2]刘焕彬.制浆造纸过程自动测量与控制.北京:中国轻工业出版社, 2003.

[3]清宏计算机工作室.Visual Basic编程技巧—网络与数据库篇.北京:机械工业出版社, 2001.

[4]温贤发.Visual Basic数据库程序设计高手.北京:科学出版社, 2001.

实时数据库 第9篇

荆门石化实时数据库系统简介

荆门分公司实时数据库系统采用Honeywell公司的Uniformance PHD202版本实时数据库系统软件,网页发布是WPKS 2.11版本。本系统由四台服务器组成,分别是域名服务器JMPHD、数据库服务器PHDORACLE、主服务器PHDMAIN和网页发布服务器PHDWPKS。

荆门分公司的DCS系统主要由Honeywell、Foxboro、横河、和利时、浙大中控等厂商提供。Honeywell采用APP节点,此APP为缓存服务器与Uniformance连接;Foxboro采用OPC DA Server作为数据采集通道,OPC RDI与PHD Server软件安装在PC上作为Uniformance缓存服务器,与Uniformance连接;横河、和利时、浙大中控采用标准OPC Server接口与Uniformance连接。

实时数据库系统在生产管理上的应用

通过实时数据库系统的网页发布,可对生产进行实时监管。网页发布服务器能够形象描绘出生产装置的流程图,实时显示流程控制点的温度、压力、流量等生产工艺参数,还能掌握各控制点某一时间段的数据趋势图。这有利于生产调度部门实时了解生产动态,指挥生产;便于车间技术人员实时掌控装置生产情况,对装置操作的稳定性进行分析评价,及时发现、分析和处理装置生产过程出现的异常,预防事故的发生。

另外,车间对班组、职能处室对车间的生产指标考核,可方便地通过实时数据库的数据提取来实现。通过提取需考核时间段数据,计算出工艺参数上下限范围内符合要求的数据,得到该时间段达到控制要求的数据比例,从而科学定量地反映出该装置生产的稳定状态。这种情况下数据的查看和读取方式往往采用Microsoft Excel,其优点是能够对生产数据进行分析处理,还可以直接形成生产报表。

实时数据库系统维护管理中几点经验

1.加强部门间沟通

由于实时数据库系统涉及到的部门比较多,信息管理中心、仪表车间、计量中心与生产车间等部门要经常沟通协调,以确保实时数据库系统的取数准确性。如在装置检修或改造时,仪表人员有可能改变DCS组态,就会改变实时数据库系统与DCS系统同步,一旦两个系统之间出现不同步,就可能出现实时采集的数据不可靠。有时仪表、计量人员校表时,也会改变DCS组态文件。车间生产工艺人员发现实时数据库系统数据有误差时,要马上与信息管理中心联系,中心与仪表部门沟通,及时更新与DCS相连的OPC(buffer机)组态文件。因此,多方要保持沟通渠道的畅通才能保证系统数据的真实可靠。

2.保证数据的连续性

为确保生产管理,必须保证数据的连续性。实时数据库系统的主服务器PHDMAIN是影响历史数据的重要原因,此服务器一旦出现故障,可能会中断部分历史数据,修复后也可能存在历史数据断点。所以此服务器必须保持冗余,即备份服务器,一旦出现故障就立即启动;同时对正在运行的服务器做好数据备份,以确保数据的连续;另外,经常对所有装置上传数据进行检查,一旦某套装置的DCS与OPC中断,要及时启动该套装置的OPC,保持与DCS的连接。

3.保障生产管理人员的PC机正常使用

对生产管理人员的PC机安装实时数据库系统Microsoft Excel取数客户端时,软件安装较多,影响因素也较多,用户在使用时稍不注意就有可能不能正常读取系统数据,诸如以下几种情况:

取数客户端系统安装完成后,进入域JMPHD用户TEST,能够正常读取系统数据。但操作人员以后在PC机使用过程中把IP地址改变,就有可能不能再次进入域用户,导致读不了实时数据。这种情况下需要重新注册域用户。

计算机安装Oracle数据库客户端,必须选择Oracle客户端其中六个功能:Oracle Network Utilies 9.2.0.1.0、SQL*Plus 9.2.0.1.0、Oracle Windows Interfaces 9.2.0.1.0、Oracle Call Interfaces 9.2.0.1.0、Oracle9i Windows Documentation 9.2.0.1.0、Oracle Universal Intaller 2.2.0.12.0,安装完成后,用户在使用过程中若有更改,就可能造成用户PC客户端读取数据不正常。

安装Excel取数客户端,需安装补丁程序Unf_202.1.2_Desktop.msp。进入Excel后,还要添加Uniformance宏。如果用户丢掉Uniformance宏,客户端就不能正常读取系统数据。

还要注意的是,有的用户重装Office系统后,必须再重新安装Unf_202.1.2_Desktop.msp补丁程序,否则此PC客户端就不能读取系统数据。另外,用户PC客户端系统必须是2003版Office系统,2007版的也取不出数据,许多用户因为Office系统升级而不能读取数据。

4.实时数据库系统中的时钟错乱问题

该版本Honeywell实时数据库系统的每一个数据都有一个时间戳,精确度达到秒级。实时数据库系统在采集DCS系统数据时,采用了DCS系统的时钟,如果DCS系统的时钟不校准的话,与北京时间不相符。实时数据库系统服务器时钟不校准,也可能与北京时间不同步。如果不注意,在服务器发布流程图时,实时数据的时间戳就会出现不同生产装置的流程图时间戳不同,有的相差几分钟,有的甚至超过半个小时。实时数据库时间戳应以北京时间为准,对DCS系统、实时数据库系统服务器时钟均要进行时钟校对。

5.实时数据库系统中用户计算机重名问题

近年来荆门分公司不断更新用户PC机,安装过程中遇到一些新问题,如计算机重名问题。分配新PC机后,在为生产管理人员安装实时数据库Excel取数客户端时,有些用户开始使用正常,过了一段时间后,却不能正常读取系统数据。

经过原因查找和分析,发现影响用户PC机正常读取数据的原因是重名问题。新PC机是用GHOST安装操作系统,有些用户拿到后更改了计算机名,使用正常;而有些用户没有更改,随着更新的PC机数量增多,导致PC机重名现象出现,影响了用户正常读取数据。解决的办法是注销原用户域名,更改计算机用户名后,再重新注册计算机域名。

6.利用补丁软件提高系统网页发布的兼容性

随着操作系统的发展,IE不断更新,实时数据库网页发布客户端只能在IE6.0、IE7.0这两个版本下运行。通过实践探索,可安装办公自动化系统的两个软件IEcfg.exe和Indi Doc X.exe打补丁,以提高其兼容性。

实时数据库系统方案的设计与实现 第10篇

1 实时数据库系统关键技术

实时数据库系统是在数据库技术和实时技术基础上产生的研究领域, 与传统的数据库系统有着本质差别, 实时数据库系统主要是利用数据库技术来解决实时系统中的数据管理问题, 并不是在概念、结构和方法上的简单集成, 设计实时数据库系统主要涉及如下关键技术:

1.1 实时数据模型

实时数据库领域首先要研究解决的主要问题, 具体包括:开发实时数据模型, 设计允许用户说明实时数据模型中所含的语义知识的和使用户能以各种方式使用的实时数据定义和查询语言、说明“复杂事务”的结构及相互作用的实时事务执行说明语言。通常的层次、网状和关系模型都不能描述有关时间的信息, 当前有两种修改关系模型以进行实时查询处理的方法: (1) 使用“近似关系”集。为了查询的及时评价, 需要为各种关系定义其近似关系, 再反复地修改近似关系以获得更接近的结果和更好的查询响应。 (2) 使用关系的“片段网格”以改善查询处理。

1.2 实时事务模型

在实时数据库系统中由于实时事务结构更加复杂、事务之间有多种交互, 实时事务模型主要为满足更加复杂的实时事务处理而设计, 主要包括嵌套、分裂/合并、合作、通信等事务模型。在实时查询/事务的接纳管理方面, 查询/事务的性能依赖于可以使用的内存量。当有足够的内存时, 绝大多数查询/事务就可简单地一次性读取它们操作的数据, 且直接产生所需结果。若给定较少的内存, 只要给定的量超过查询/事务的最小内存需求, 大多数事务可以通过一定的数据I/O仍然可以运行。为了帮助事务获得期望的性能级别与定时限制的满足, 实时数据库系统需要通过接纳比其最少的内存容纳事务数更多的事务来提高并发度。

1.3 实时事务处理

主要是针对实时数据库系统中事务的定时限制, 按照事务截止期控制实时数据库系统中事务的执行顺序, 确定实时事务的优先级, 并按照优先级实现实时事务调度。在实时数据库系统中, 实时事务处理降低了传统可串行化并发控制的严格程度, 更加关注数据的实时性, 因此, 实时事务处理在并发控制方面“放松的可串行化”或“暂缓的可串行化”。

2 面向铁路信号监控的实时数据库系统总体方案

本论文结合实际应用需求提出面向铁路信号监控的实时数据库系统方案框架, 它是适应高技术条件下管理要求, 设计实现集成、开放、模块化的人机界面, 与其它商用实时数据库系统相比, 系统在设计过程中忽略了一些不常用的次要功能, 注重各功能的模块化、标准化和开放性, 突出了数据采集的实时性、显示的直观性、增强了数据分析能力和事务的处理能力, 主要包括系统实现方案框架和实时数据模型总体设计思路。

2.1 实时数据库系统方案框架

面向铁路信号监控的实时数据库系统的方案框架主要包括如下三部分, 具体如下:

1) 实时数据管理系统:运行于实时数据库服务器, 主要功能是系统进程管理、数据存储和数据服务。这是整个系统的核心, 要求它运行稳定、功能强大、可处理不同类型的数据点, 并能对历史数据进行压缩进而长久保存。

2) 设备数据接口:用于实时数据库系统和指挥中心等数据源之间的数据交换。这个设备数据接口要求是多功能、多层次、多服务对象的标准设备数据接口。它不但能和实时数据库进行数据交换, 还要能给关系数据库提供数据。

3) 实时数据上层应用工具包用于实时数据及历史数据查询和分析应用程序。

2.2 实时数据模型总体设计框架

本论文的实时数据模型方案设计主要以刘云生等提出的实时数据模型方案为基础, 结合本系统结构及其功能需求, 在传统数据模型的基础之上, 把时间概念扩展进去, 以满足实时应用的定时限制的要求。本系统实时数据模型总体设计思路如下。

3 实时数据库系统数据模型方案

针对实时数据库系统的数据采集、存贮、管理、查询、分析、处理等关键功能, 系统对“实时性”和“准确性”的要求非常严格, 为此实时数据模型的操作应该包括时间关系代数操作、数据的时间一致性限制、事件及事务的时间限制等关键因素。实时数据模型主要包括如下三个部分:一组对象及其结构、一组操作和一组 (关于对象与操作的) 约束, 其中的约束与传统数据模型相比更突出地包括时间限制, 即: (1) 定义实时数据对象及其结构集合 (RTDO) ; (2) 定义施加于RTDO的一般数据操作和时间关系代数操作 (RTOP) ; (3) 定义对于RTDO和RTOP的完整性与一致性限制及实时限制 (RTC) 。

3.1 RTDO实时数据对象

实时数据对象包含如下三种类型:映像对象 (IMO) 、导出对象 (DEO) 和常量对象 (COO) 。映像对象是被实时写入实时数据库的RWO (现实世界中的对象) 值的数据对象, 即一个IMO就是一个RWO在特定时刻的映像。导出对象 (DEO) 是经过事务的执行, 通过一组IMO和/或其他数据对象计算得到。常量对象 (COO) 可以看作实时数据库的对象, 也可以不是实时数据库对象。如果是实时数据库对象, COO可当作实时数据的特例, 不随时间而改变, 时标为系统初建时刻 (设为t0) , 有效期的上限为“当前” (tc) 。

基于以上分析, 从实时数据对象的角度设计实时数据库Trss:设CYO (VO, ti) 表示在时刻ti对现实世界中可变对象集合VO的采样操作;F (CO) 表示对现实世界中常量对象CO的一次性取值, VO和CO都是RWO的子集。DO表示一个数据对象的集合, 它是实时数据库Trss的子集;JSC (DO) 表示对DO的计算操作;IMOn表示当前映像对象集, IMO1, IM02……IMOn-1表示数据库的存储映像对象集。

其中COO表示对时间不变的对象的集合, IMO表示映像对象的集合, DEO表示导出对象的集合。

3.2 RTOP时间关系代数操作

关系代数是关系数据操纵语言的一种传统表达方式, 它是由关系的运算来表达查询的。基于Trss系统的需求设定了选取、投影、差、并四种时间关系代数操作。

时间选取:为选取针对属性和/或有效期指定的满足条件F的数据对象。F可以是关于属性值的传统表达式, 也可以是关于有效期VI的时间条件表达式, 或两者都包括。被选取的数据对象的值和有效期均不变。

时间投影:为选取由A指定的属性值和/或有效期VI, 构成一个新的关系。若A中未指定VI则其结果对象均为常量对象, 否则结果对象中具有相同值的对象可进行时间归并。对有效期VI的投影等价于返回各对象O的有效期的函数VI (0) 。

时间差:具有相同值但有效期不一定相同的对象。设R, S为两个数据对象集, 其时间差P=R-S定义为:对于R中的任一Xi, 仅当S中有Xj使得xi=xj, 且VI (xi) 属于VI (xj) 时, xj不属于P;否则xj属于P, 此时VI (xi) =VI (xi) -VI (xj) 。

时间并:两个具有相同值和不同有效期的数据对, 还需要维护有不同有效期而有同样值的IMO对象的完整性, 在实际应用过程中, 主要通过引入“时间归并”操作来实现。

3.3 RTC时间限制

数据的时间一致性:实时数据库Trss是相应现实世界的直接映像, Trss实时反映现实世界状态的任何变化, 并实现对现实世界的实时表示。数据对象的时标足够接近真实时间, 使数据库的状态能反应现实世界的“当前”状态。如果数据对象的时间在当前时间的某个指定阈值范围内, 实时数据库Trss中该对象与外部一致。

事件的时间限制:对于Trss系统中的各种实时应用活动总是由一事件来触发和标志, 即每一活动有一与之相联的事件, 因此, 施加于活动 (事务) 的某些实时限制来自于事件的限制。实时事务由事件驱动, 事务的定时限制有的则表现为相联事件的限制。

4 结束语

论文提出了铁路信号监控的实时数据库的体系结构, 基于实时数据库的功能需求提出了实时数据模型的设计思想, 根据设计思想, 对实时数据模型进行设计, 体现出了实时数据模型不同于传统数据模型的突出特点, 在模型上加上了时间概念, 包括数据的时标、事件的时间限制。

摘要：论文在分析实时数据库系统关键技术基础上, 提出针对铁路信号监控的实时数据库系统方案框架以及实时数据模型总体设计思路, 并根据总体设计思路提出了实时数据库系统数据模型方案。

关键词：实时数据库,体系结构,实时数据模型

参考文献

[1]刘云生, 易岚, 余利平.一个实时数据模型[J].小型微型计算机系统, 2000 (5) .

[2]刘英, 王志坚, 尹燕敏.实时数据库的事务处理[J].科技与经济, 2002 (2) .

[3]陈祥.基于OPC技术的实时数据库研究与实现[D].河海大学硕士学位论文, 2003.

[4]徐洁磐.面向对象数据库系统及其应用[M].北京:科学出版社, 2003.

数据库中小文件的实时存储与优化 第11篇

1 现有的小文件处理方法

1.1 结构化存储

结构化存储是在数据库中将小文件整合成一个大文件一次性写入, 将小文件的内容作为二进制字符串的大字段存入数据库中, 由于每个字段都是固定的, 而小文件则是在一定范围内变化的, 为了保证数据不因字段长度不够而丢失, 故在设计数据库时会将字段设计得相对比较大, 这样就使小文件内容的存储占据了大量的空白数据, 造成磁盘资源的浪费, 也会使数据库在进行I/O操作时操作时间变长[1]。

1.2 归档文件

归档文件是将文件合并后放入文件存档设备, 在文件系统上创建一个文件系统进行工作, 虽然采用创建归档文件来处理小文件能够降低内存的使用效率, 但创建归档文件的同时会创建一个副本, 需要同样大小的磁盘空间, 而且一旦创建后, 归档文件就不能再改变, 所以要增加或删除文件时必须重新创建文件。

1.3 文件优化器技术

在分布式文件系统上设计一个小文件优化器, 将小文件在优化器中进行合并, 并且建立索引, 这样所有操作都在优化器中完成, 而大文件直接存储在文件系统, 虽然避免了海量小文件存储的麻烦, 但如果小文件索引多到无法估计, 就对优化器磁盘的容量提出挑战。

1.4 构建结构体

构建结构体是将相同扩展名的小文件进行合并, 元数据存储于结构体的成员中, 通过建立结构体中各文件间的存储索引[2]。访问时只需读取要查找文件的扩展名, 然后访问名称节点, 名称节点根据该扩展名返回一个索引块列表;最后用户根据这个块列表访问相应的数据结构体, 在数据结构体中根据元数据进行截取, 查找到原先的小文件进行截取并返回。虽然将多个小文件合并成一个大文件的方案能使原先小文件占用的名称节点服务器的内存成倍数地降低, 但是由于结构体在定义时已经设定了成员的大小, 所以对于同类型但大小不一的小文件, 传统的合并方法会浪费大量的存储空间。

2 基于数据库处理小文件的方案

在归档文件方法和文件优化器处理思想的基础上进行改进, 能够使文件优化器的功能由传统的结构化数据库来实现。数据库能存储海量块小的元数据, 能快速建立索引, 检索速度比较快;而分布式文件系统可以多个存储磁头并行读写, 文件的存储和读取带宽较大, 能够突破数据库存取的I/O瓶颈问题。文件系统与数据库系统各尽其能, 弥补了对方的不足[3,4]。由于实时存储系统在这一时刻和下一时刻传入的文件类型可能不同, 不属于同一个业务, 可以根据他们不同的访问字段来对部分常用字段建立非聚集索引, 在不过分影响插入效率的前提下提高用户查找文件的速度。

2.1 文件的合并机制

在合并文件时需要创建文件头, 记录大文件中包含的小文件个数以及每个小文件的大小, 并且与小文件放置在同一块大缓存内, 在数据库中记录文件的元数据信息及相应的大文件和在大文件中的具体位置, 与构建结构体进行文件合并的方法相比, 创建文件头的合并机制更适合于文件大小有变动的海量小文件的合并, 在进行文件读取时通过查询数据库来获取文件的逻辑地址并且对文件进行访问。

2.2 优化思想

首先, 创建一个Ping File的类, 其中包括:Name:大文件的文件名称;size[count]:用于记录每个小文件的大小;*addr[count]:用于记录每个小文件的内存地址;timecount:用于记录当前Ping File存在的时间;current:用于记录当前状态传入的参数, 要求存入Ping File的相对位置。count表示大文件中小文件数量的上限, timelimit表示等待时间的上限, 当等待时间或数量达到上限时, 开启线程将Ping File中小文件的缓存按照表1的结构形式合并为一个大缓存并存入到文件系统中, 提交本次数据库的事务, 完成一次小文件的合并及其元数据的入库。程序接收到传入的小文件, 根据传入的相关参数将文件块存入大的缓存区内, 并将小文件在大文件中的相对位置和大文件的命名作为元数据, 放在数据库事务中, 以便保持数据库和文件系统的一致性, 然后继续等待下一文件的传入。当缓存区的文件达到合成条件时, 将缓存块生成数据文件存放在文件系统中, 数据库再次提交事务 (见表1) 。

2.3 文件的读取过程

在读取文件时, 首先根据查找信息在数据库中查找相应的数据条目, 如果找不到就直接返回, 如果找到就遍历所有的结果集, 找到大文件的地址以及小文件在大文件中的相对位置, 然后对大文件进行解析, 根据小文件的存储位置在缓存中取出小文件并返回给用户, 完成文件的读取操作。

3 实验测试及结果

使用本地文件系统将300个不同的图形文件 (32KB至512KB不等) 进行合并, 之后对其进行逐一读取, 最后得到的图形文件与原文件完全相同, 其可行性得到了验证。表2为512KB大小不同数目的小文件合并读取的时间对比 (时间为十次测试的平均值, 每次读取的是第30个小文件) 。从图1可以看出, 合并与读取所用时间基本和合并个数呈线性关系。

4 结论

针对文件系统实时存储海量小文件不方便, 提出了基于数据库的小文件合并方法, 即对大量小文件的数据进行批量处理, 在保证存取前后系统的稳定性和文件正确性的前提下, 大幅度提高了文件系统对小文件存储效率。通过文件系统与数据库的结合, 解决了文件系统的检索瓶颈和数据库I/O瓶颈问题, 减少了存储时间。但是需要指出的是, 由于进行了文件合并, 如果要对单个小文件进行修改操作, 则需要对大文件中的片段进行解析、扩展或者缩减, 会造成单个小文件更新操作的不方便。所以, 该方法适用于量多块小、时间分布均匀且更新频度较小的数据仓库类的工作业务流程。

参考文献

[1]江柳.HDFS下小文件存储优化相关技术研究[D], 北京邮电大学, 2010.

[2]http://hadoop.apache.org/mapreduce/docs/r0.21.0/hadoopp_archives.html.

[3]刘小俊, 徐正全, 潘少明.一种结合RDBMS和Hadoop的海量小文件存储方法[J].武汉大学学报, 2013 (1) :27-31.