深入浅出实时数据库
实时系统中的实时数据库技术与应用(九)

实时系统中的实时数据库技术与应用一、引言随着科技的不断发展,实时系统在我们的日常生活中扮演着越来越重要的角色。
实时数据库作为实时系统的核心组成部分之一,为实时数据的存储、查询和处理提供了关键的技术支持。
二、实时数据库技术的基本原理实时数据库技术是指一种能够在指定时间范围内对实时数据进行高效存储、查询和处理的技术。
它通过采用特殊的数据结构和算法,实现对实时数据的快速读写和实时更新。
实时数据库技术的基本原理包括以下几个方面:1. 数据存储:实时数据库采用了高效的数据存储结构,如索引、哈希表等,以提高数据的读写效率。
同时,为了保证数据的实时性,实时数据库还采用了一些数据压缩和压缩算法,以减少数据在存储和传输过程中的时间和空间开销。
2. 数据查询:实时数据库通过引入查询优化器和查询执行引擎等技术,对用户的查询请求进行高效处理。
它利用索引和预先计算的统计信息,选择最优的查询计划,并通过并行处理和分布式计算等技术,提高查询的响应速度和并发处理能力。
3. 数据处理:实时数据库为实时数据的处理提供了高效的机制。
它支持实时数据的实时更新和实时计算,将数据的更新和计算结果即时地反映到数据库中。
实时数据库还支持各种复杂的数据操作,如聚合查询、事务处理等,以满足不同应用场景下的需求。
三、实时数据库的应用领域实时数据库技术在许多领域都得到了广泛的应用,下面将介绍其中一些典型的应用场景。
1. 工业自动化:在工业生产过程中,实时数据库可以用于实时监控和控制。
它可以实时地收集和分析生产数据,及时调整生产参数,并通过实时报警和异常处理等手段,提高生产过程的稳定性和可靠性。
2. 交通管理:实时数据库在交通管理系统中起到重要作用。
它可以实时地采集和处理交通数据,如车辆位置、道路状况等,实时监控交通流量,为驾驶员提供实时导航和路况信息,减少交通拥堵和事故发生的概率。
3. 金融服务:实时数据库在金融服务领域中应用广泛。
它可以实时地处理交易数据,如股票成交、资金流动等,以满足交易系统对低延迟和高吞吐量的需求。
实时数据库系统

实时数据库系统在当今数字化的时代,数据的产生和处理速度日益加快,对于企业和各种应用场景来说,能够实时获取、处理和分析数据变得至关重要。
实时数据库系统应运而生,成为了满足这一需求的关键技术。
什么是实时数据库系统呢?简单来说,它是一种能够实时处理和存储数据的数据库系统。
与传统的数据库系统相比,其最大的特点就是能够在极短的时间内响应数据的变化,并保证数据的准确性和完整性。
实时数据库系统在许多领域都发挥着重要作用。
比如在工业控制领域,工厂中的各种设备会不断产生大量的数据,包括温度、压力、流量等参数。
这些数据需要被实时采集、处理和分析,以便及时发现生产过程中的异常情况,进行调整和优化,从而提高生产效率和产品质量。
实时数据库系统能够快速地存储和处理这些海量的实时数据,为工厂的智能化管理提供支持。
在电力系统中,实时数据库系统也有着广泛的应用。
电力的生产、传输和分配需要精确的监控和调度。
系统中的电压、电流、功率等数据必须实时获取和处理,以确保电网的安全稳定运行。
实时数据库系统可以帮助电力部门实现对电力系统的实时监测和控制,快速响应各种突发情况,保障电力的可靠供应。
在金融交易领域,每一笔交易都需要在瞬间完成处理,对数据的实时性要求极高。
实时数据库系统能够快速存储和更新交易数据,支持风险评估和决策制定,确保金融交易的顺利进行。
实时数据库系统之所以能够实现实时处理数据,依赖于一系列关键技术。
首先是高效的数据采集技术。
它能够快速从各种数据源获取数据,并将其传输到数据库中。
其次是优化的数据存储结构。
通过合理设计数据的存储方式,提高数据的读写速度。
再者是强大的索引和查询优化算法,能够在海量数据中迅速找到所需信息。
此外,还有高效的并发控制和事务处理机制,确保在多用户并发操作时数据的一致性和准确性。
为了保证实时数据库系统的性能和可靠性,系统的架构设计至关重要。
常见的架构包括集中式架构和分布式架构。
集中式架构将所有的数据处理和存储集中在一个中心节点上,管理相对简单,但存在单点故障的风险。
实时数据库介绍

实时数据库介绍在当今数字化的时代,数据的处理和管理成为了企业和组织运营的关键环节。
其中,实时数据库作为一种特殊类型的数据库,在众多领域发挥着重要作用。
什么是实时数据库呢?简单来说,实时数据库就是能够实时处理和存储数据的数据库系统。
与传统的数据库相比,它最突出的特点就是对数据的实时性要求极高。
在很多场景中,数据的价值往往会随着时间的流逝而迅速降低,比如在工业控制、金融交易、电力系统等领域,每一秒钟的数据都可能对决策和操作产生关键影响。
实时数据库的工作原理可以这样理解。
它通过高效的数据采集机制,能够快速获取来自各种数据源的实时数据。
这些数据源可以是传感器、监测设备、交易系统等等。
采集到的数据会被立即存储到数据库中,并进行快速的处理和分析。
为了实现这种高效的处理,实时数据库通常采用了一系列优化的技术和算法,比如内存数据库技术、数据压缩算法、索引结构优化等。
在实际应用中,实时数据库有着广泛的用途。
在工业生产领域,它可以用于监控生产线的运行状态,实时获取设备的温度、压力、转速等参数,及时发现异常情况并进行预警,从而避免生产事故的发生,提高生产效率和产品质量。
在电力系统中,实时数据库能够实时采集电网的电压、电流、功率等数据,为电力调度和稳定运行提供支持。
在金融交易领域,它可以快速处理大量的交易数据,确保交易的实时性和准确性,防范金融风险。
实时数据库的优点是显而易见的。
首先,它能够提供实时的数据支持,让决策者能够在第一时间获取最新的信息,做出及时准确的决策。
其次,由于其高效的数据处理能力,可以处理海量的实时数据,满足大规模应用的需求。
再者,它具有良好的稳定性和可靠性,能够在复杂的环境中持续运行,保证数据的安全和完整。
然而,实时数据库也面临着一些挑战。
一方面,由于对实时性的要求极高,其系统的复杂性也相应增加,开发和维护的成本较高。
另一方面,数据的准确性和一致性也是需要重点关注的问题,因为实时数据的快速处理可能会导致数据的错误或不一致。
实时数据库和传统数据库的区别与应用场景分析

实时数据库和传统数据库的区别与应用场景分析随着信息技术的不断发展,数据库在各行各业中的应用越来越广泛。
在数据库的应用领域中,实时数据库和传统数据库是两种常见的类型。
本文将对实时数据库和传统数据库的区别进行分析,并探讨它们在不同应用场景中的应用情况。
一、实时数据库和传统数据库的区别实时数据库是一种专门用于处理实时数据的数据库系统。
实时数据是指那些要求在严格的时间要求下进行处理和响应的数据。
相比之下,传统数据库则更适用于处理非实时数据,如批处理和离线数据处理。
1. 数据处理方式不同实时数据库采用了一系列优化策略来保证数据的实时性和响应性能。
它使用了高效的数据存储和索引结构,能够在较短的时间内对数据进行读写操作。
而传统数据库则更注重数据的一致性和持久性,对于实时性要求不高的应用场景更为适用。
2. 数据处理速度不同实时数据库能够以毫秒级的速度对数据进行读写操作,能够满足对数据实时性要求较高的应用场景。
而传统数据库则需要更长的时间来处理数据,适用于对实时性要求不高的场景。
3. 数据规模不同实时数据库通常用于处理大规模的实时数据,如传感器数据、监控数据等。
它能够高效地处理大量的数据并保证数据的实时性。
传统数据库则更适用于处理较小规模的数据,如企业的业务数据、客户数据等。
二、实时数据库的应用场景1. 物联网领域随着物联网技术的不断发展,各种传感器设备产生的实时数据需要被高效地处理和分析。
实时数据库能够满足对实时性要求较高的物联网应用场景,如智能家居、智能交通等。
2. 金融领域在金融交易中,实时性是非常重要的。
实时数据库能够高效地处理金融交易数据,保证交易的实时性和准确性。
例如,证券交易系统、支付系统等都需要使用实时数据库来处理交易数据。
3. 游戏领域实时数据库在游戏领域中也有广泛的应用。
游戏中需要实时地处理玩家的操作和交互,实时数据库能够满足对游戏数据实时性和响应性能的要求。
三、传统数据库的应用场景1. 企业应用传统数据库在企业应用中有广泛的应用。
实时系统中的实时数据库设计与实时数据管理方法(七)

实时系统中的实时数据库设计与实时数据管理方法引言:实时系统是一种对时间敏感的计算机系统,它要求系统能够实时地响应外部事件,并在规定的时间范围内完成任务。
在实时系统中,实时数据库的设计和数据管理方法是至关重要的。
本文将深入探讨实时系统中的实时数据库设计与实时数据管理方法。
一、实时数据库的设计原则实时数据库的设计需要考虑以下几个原则:1. 高可靠性:实时系统中的数据往往是关键数据,一旦丢失或错误将导致系统故障。
因此,实时数据库的设计必须具备高可靠性,采用冗余机制来保证数据的安全性。
2. 快速响应:实时系统对外部事件的响应时间要求严格,因此实时数据库的设计需要具备快速读写能力。
可以采用索引结构、缓存机制等方式来提高数据库的读写效率。
3. 高并发性:实时系统中需要处理大量的并发请求,因此实时数据库的设计需要具备高并发性。
可以采用分布式数据库、负载均衡等方式来提高数据库的并发处理能力。
4. 数据一致性:实时系统中的数据一致性是非常重要的,任何一次读写操作都必须保持数据的一致性。
可以采用事务管理、锁机制等方式来保证数据的一致性。
二、实时数据库的数据管理方法实时数据库的数据管理方法涉及到数据的存储、查询、更新等方面。
下面将介绍几种常用的实时数据库的数据管理方法:1. 数据存储:在实时系统中,数据的存储方式需要满足快速读写的需求。
可以采用内存数据库、闪存数据库等方式来提高数据的访问速度。
同时,为了保证数据的可靠性,可以采用数据冗余、备份等方式来进行数据存储。
2. 数据查询:实时系统中的数据查询需要快速响应,因此查询的效率是关键。
可以采用索引机制来提高查询的速度,同时可以采用数据划分、分片等方式来降低查询的负载。
3. 数据更新:实时系统中的数据更新需要及时生效,并保证数据的一致性。
可以采用事务管理机制来保证数据的一致性,同时可以采用缓存机制来提高数据更新的效率。
4. 数据同步:实时系统中的分布式环境下,数据同步是一个重要的问题。
实时数据库与时序数据库功能架构对比

引言实时数据库和时序数据库是两种广泛应用于数据存储和处理的技术,它们在功能架构上有一些共同点,同时也存在一些差异。
本文将对实时数据库和时序数据库的功能架构进行对比,探讨它们各自的特点和适用场景。
概述实时数据库和时序数据库都是为了满足特定应用领域的数据存储和处理需求而设计的。
实时数据库主要用于管理实时数据,并提供实时数据分析和处理的功能;时序数据库则专注于处理和分析时间序列数据,以支持对时间序列数据的高效查询和分析。
正文一、实时数据库功能架构1.实时数据管理:实时数据库负责管理实时数据的插入、更新和删除操作。
它提供高效的数据存储和检索机制,以满足实时数据的快速响应和高效查询。
2.实时数据分析:实时数据库提供实时数据分析功能,可以对实时数据进行实时统计、聚合和计算,以支持实时的数据分析和决策。
3.实时数据处理:实时数据库能够对实时数据进行实时处理,可以对数据进行过滤、转换和计算,以满足实时业务应用对数据的处理需求。
4.实时数据同步:实时数据库支持实时数据的同步和复制,在分布式系统中能够实现数据的一致性和可用性。
5.安全和可靠性:实时数据库提供数据安全和可靠性保障,包括数据的备份和恢复机制、数据的访问控制和权限管理,以及故障和异常处理。
二、时序数据库功能架构1.时间序列数据管理:时序数据库负责管理时间序列数据的插入、更新和删除操作。
它提供高效的数据存储和检索机制,以支持对时间序列数据的快速查询和分析。
2.时间序列数据分析:时序数据库提供时间序列数据分析功能,可以对时间序列数据进行统计、聚合和计算,以支持对时间序列数据的深入分析和挖掘。
3.时间序列数据处理:时序数据库能够对时间序列数据进行处理,包括数据的过滤、插值、模型拟合等操作,以满足时间序列数据的处理需求。
4.时间序列数据存储和索引:时序数据库采用特定的数据存储和索引结构,以支持对时间序列数据的高效存储和快速检索。
5.安全和可靠性:时序数据库提供数据安全和可靠性保障,包括数据的备份和恢复机制、数据的访问控制和权限管理,以及故障和异常处理。
实时数据库与关系数据库的性能比较分析

实时数据库与关系数据库的性能比较分析在当今信息时代,数据的处理变得越来越重要。
随着技术的不断发展,数据库的种类也越来越多。
其中,实时数据库和关系数据库是两种常见的数据库类型。
本文将对这两种数据库的性能进行比较分析。
一、概述实时数据库是一种专门用于处理实时数据的数据库系统。
它具有高速读写的特点,能够实时地接收和处理大量的数据。
而关系数据库是一种基于关系模型的数据库系统,它通过建立表格之间的关系来组织和管理数据。
二、性能比较1. 数据处理速度实时数据库在数据处理速度方面具有明显的优势。
它采用了高速缓存技术和并发控制机制,能够快速地读写数据。
而关系数据库在处理大量数据时,由于需要进行复杂的查询和关联操作,处理速度相对较慢。
2. 数据一致性关系数据库在数据一致性方面表现出色。
它通过事务机制来保证数据的一致性,能够确保数据的完整性和可靠性。
而实时数据库在处理实时数据时,为了追求速度,可能会牺牲一定的数据一致性。
3. 数据存储结构关系数据库采用表格的方式来存储数据,每个表格包含多个字段和记录。
这种结构使得数据的存储和查询相对简单。
而实时数据库采用了更加灵活的数据存储结构,可以根据实际需求进行优化,提高数据的读写效率。
4. 数据可扩展性实时数据库在数据可扩展性方面具有一定的优势。
由于实时数据库的数据存储结构更加灵活,可以根据需求进行扩展和优化。
而关系数据库在数据量增大时,可能需要对表格结构进行调整,增加了数据扩展的难度。
5. 应用场景实时数据库适用于对实时性要求较高的应用场景,如金融交易、物联网等。
它能够快速地接收和处理大量的实时数据。
而关系数据库适用于对数据一致性要求较高的应用场景,如企业管理系统、客户关系管理等。
它能够确保数据的完整性和可靠性。
三、结论综上所述,实时数据库和关系数据库在性能方面各有优劣。
实时数据库在数据处理速度和数据存储结构方面具有优势,适用于对实时性要求较高的应用场景。
而关系数据库在数据一致性和数据可扩展性方面表现出色,适用于对数据一致性要求较高的应用场景。
实时数据库

实时数据库一.实时数据库概述实时数据库可用于工厂过程的自动采集、存储和监视,可在线存储每个工艺过程点的多年数据,可以提供清晰、精确的操作情况画面,用户既可浏览工厂当前的生产情况,也可回顾过去的生产情况,可以说,实时数据库对于流程工厂来说就如同飞机上的“黑匣子”。
实时数据库RTDB(Real-Time Data Base)是数据和事务都有定时特性或显示的定时限制的数据库。
系统的正确性不仅依赖于逻辑结果,而且还依赖于逻辑结果产生的时间。
RTDB的本质特征就是定时限制,定时限制可以归纳为两类:一类是与事务相联的定时限制,典型的就是“截止时间”;另一类为与数据相联的“时间一致性”。
时间一致性则是作为过去的限制的一个时间窗口,它是由于要求数据库中数据的状态与外部环境中对应实体的实际状态要随时一致,以及由事务存取的各数据状态在时间上要一致而引起的。
实时数据库是一个新的数据库研究领域,它在概念、方法和技术上都与传统的数据库有很大的不同,其核心问题是事物处理既要确保数据的一致性,又要保证事物的正确性,而它们都与定时限制相关联。
实时数据库系统中最为典型的问题是利用数据库技术的特点和优点解决实时系统中的数据管理问题,为数据库系统提供时间调度和资源分配的算法,以及实时数据处理的各种方法。
时间特性是实时数据库系统不同于其它关系数据库的特点之一。
数据、事件、活动都有与之相联系的时间限制。
设计实时数据库系统时一定要充分考虑时问特性,考虑外部环境所施加的时间限制、系统性能所决定的时间限制、数据的时间一致性所要求的时间限制以及其它的时间限制。
另外,由于时间限制的存在,实时数据库中的数据还存在除数据逻辑一致性和事务逻辑一致性外的两种一致性约束条件:数据时态一致性、事务时态一致性。
实时数据库系统可以看作是常规数据库管理系统与实时系统的结合体,像DBMS一样,它必须处理事务并保证ACID数据特性。
此外还必须在实时环境下满足事务提交的时间约束。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
深入浅出实时数据库12.8日版主要介绍如下主题:谈到实时数据库,暂时大家还颇感神秘,后面我们将逐渐解开面纱,给大家展示一个真实的实时数据库世界。
先了解概念,再深入原理。
说道实时数据库,当时诞生于美国,随着流程工业和航天工业的发展,大量的测量数据需要集成和存储,采用关系数据库难以满足速度和容量的要求,而且接口访问复杂,不适合科研和监控的需要,因此80年代中期,开始诞生了以工业监控为目的的实时数据库。
今天大家看到的一些实时数据库,如PI、Uniformance、Infoplus、InSql等工业监控类实时数据库均先后诞生于此阶段。
而当时还有另外一个分支,即所谓硬实时数据库,它的采集速度和响应速度均是毫秒级的,而大家知道,今天大量应用实时数据库,主动采集速度均是秒级的,响应速度也不严格,在Windows平台下,小于40ms的响应均不准确,但当时却有这类产品,目前多用于军事和科研了。
到了上世纪90年代,实时数据库在流程工业全世界范围内大行其道,源于以太网的逐步普及;主要应用于工业监控、控制和公用工程。
国内的实时数据库发展较为缓慢,这和技术封锁和政治风气都有关系,到了2000年之后,国内的实时数据库逐渐展露头角,如ESP-iSYS、Agilor等与国外的PI、InfoPlus均属于大型分布式网络实时数据库。
规模相对较小的,如PHD、ConRTDB、SuperInfo,在国内开始应用。
由于应用场景的不同,好多企业开始还只是解决现场监控的问题,分不清RTDB与SCADA的概念,结果InSql获得了一个发展的机会。
那么,什么是实时数据库呢,过去国人老将其与SCADA搞混,倒也给SCADA 一个发展的机会。
实际上实时数据库是“对实时性要求高的时标型信息的数据库管理系统”,在这里特别提醒,是管理系统,而非单独一个数据库。
实时数据库虽是系统软件,但更多是一个应用平台软件,原因是实时数据库还没有一个像SQL一样的标准,而且其功能太过综合,各厂商推出的产品功能各有侧重。
但以上的膜片中至少总结了实时数据库的主要功能。
目前实时数据库已经应用到众多领域,它的应用范围还在不断扩展,业界的工程师在不断创造出实时数据库的应用模式。
只要有时标型数据(时标表示每隔几个记录间隔显示一点),实时数据库就可以在一定程度上发挥威力。
说到这里,渐渐要讲原理了。
与一般认识不同,时标型数据并非仅仅指时间戳、值和质量码,还有一个很重要的属性,那就是及时性,及时性有两重含义,采样间隔和数据的新鲜度。
时标型数据的价值随新鲜度降低而递减。
1秒钟内的数据可以用来流程工业中的控制,5秒钟之内可以用来监视,半小时内的数据可以用来分析和优化,一天内的数据可以用来日报表,如果是半年前的数据,则只能做对比和追溯了。
而得到数据的新鲜程度往往取决于采样频率,这就是为什么如此重视实时数据库的采样快速性。
同时采样的频率还进一步决定了实时数据库保存信息的丰富程度。
请看下一张膜片:大家都知道采样定理,根据拉普拉斯变换,任何信号都可以被分解为频率不同、幅值不同的正弦波叠加,而如果要让采到的数据中包含一个频率的信息,则采样频率至少为此频率的2倍。
所以大家不要过分关心实时数据库宣称的无损压缩,更重要的是要明白,信息的最大损失就在于采样。
更简单的例子,当你以10秒钟的周期去采样,可能装置运行过程中出现了异常的超调,在5秒内又恢复了,而你的实时数据库中却根本不存在这些信息。
从另一个方面讲,实时数据库中存储的数据永远是滤波后数据,实时数据库就像一个低通滤波器。
接下去,要讲到实时数据库的核心技术原理了,理解了这些原理,在设定实时数据库运行参数的时候,才能得到更好的效果。
也就会明白,一个RTDBA(RTDB Administrator 实时数据库管理)的存在价值。
看看这些标题,就知道,下面将会讲很多关键的东西。
首先看看,任何复杂的大型实时数据库,其基本体系架构,也不外乎如图所示,通过现场适配层适配现场的各种接口,在工业控制中这是一个复杂的工作。
然后通过实时核心,完成数据的采集、实时计算、报警计算、其它处理,实时数据被不断泵入磁盘历时存储,形成可追溯的历时信息,同时通过向应用层提供各种适配接口,支持各种开发语言和各种应用需求的访问。
认识好这个基础架构,下面看核心原理,就思路清晰了。
总的来说,目前工业通讯、传输的协议种类繁多,主要有两方面原因:1、历史遗留;2、人为垄断;二者的合力就是上边这张膜片的内容,很多时候,为了不付出厂商提出的巨额接口或接口板卡费用,广大的业界工程师采取编程口、打印口等极端方式,以获得可以接受的性价比。
在协议载体上,主要是串行和以太两种,当然在串行通讯中又有很多专用总线分支,例如Profibus等。
未来在载体上是相当的清晰,以太网通讯技术已经势如破竹,所以,前途光明,但另一个困扰更大,就是封闭的协议,目前大部分厂商都宣称自己开放了,但开放的是上层,而非底层。
虽然,至少可以做到采用OPC访问实时数据库,但要想简单地将For InSql的接口用于Agilor,则很难,这就是底层没有协议的问题。
有些工程师提出,如果底层协议不统一,实时数据库的市场将继续存在混乱和低速发展。
谈到接口,小型实时数据库(许多是号称自己是实时数据库的组态软件)均采用了以上的架构,即将核心和接口做在一起,用户使用起来较为简单,但如果出现任何一个不稳定的接口或局部异常,那整个实时数据库就崩溃了。
另外对于大型应用,这种结构也较难扩展。
对于大型分布式实时数据库,基本按照如下的配置:接口软件被独立出来,即可以与实时数据库核心集中部署在1台计算机上,也可以与部署在接口机上,在大规模应用的时候,接口的负载不会影响核心的稳定,同时任意一个接口出现Crash,都不会导致实时数据库整体宕机。
从而提供了更好的可扩展性和稳定性。
谈到影响接口效率的因素,主要如下:首先协议如果慢,那没什么好的方法,这主要可以看看DDE协议,在OPC出现前,也曾经红火了一段时间,DDE使计算机上跨进程数据可以方便通讯,但这种通讯协议本身效率很低。
计算机再快,容量不能大幅度上升,几百个位号就很不错了。
就这一点,就决定了其退出了历史舞台。
第二在于网络状况。
没有有效地组网,以太网也会十分缓慢。
有效的带宽变低,使得快速协议也变得缓慢而不稳定。
网络状况有两方面:1、物理结构合理性,多少次经验告诉我们,没有合理组织的以太网,往往导致数据的阻塞,梳理以太网就像控制交通流量,任何地方出现瓶颈,都会导致数据缓慢;2、病毒,尤其是占用大量带宽的蠕虫,一旦感染了这个,接口中断就很有可能了。
设备效率也一样关键,经常出现DCS 工作压力很大了,这时再看其通讯,就很难了。
针对这种情况往往应该增加通讯卡件来提高效率;工作站负载也是影响大型系统接口效率的关键,很多大型系统的OPC都在工作站上,这时,如果工作站负载很重,OPC能分到的运行时间不足,又会影响效率,最终数据传输还是很缓慢,而且不稳定。
OPC并非什么好协议,只不过因为是中立国出的协议而如此广泛被使用。
如果这些都没有问题,那么最终协议总归协议,实现协议交互的软件质量还十分关键,在实施中,我们也经常会碰到因为质量不好的OPC,效率低、稳定性差导致整个系统不稳定的。
知道了以上内容,现场遇到问题,应逐个排除,不要一开始就责怪实时数据库不好,只有对症下药地解决问题,才能获得高效的系统。
接下去将探寻接口内部的奥秘,先给大家一张预览图:谈到这里,就要谈到实时数据库为做到实时的考虑了。
为了做到实时,实时数据库采取了“实时”的反面-》“缓存”,缓存是为了提高交互效率,从而使整体更加实时,这点后面将详细介绍。
那么一个接口程序内部有什么呢?主要有两部分:现场接口协议栈和位号分组。
当然,对于小型的接口,位号分组被省略了。
位号分组是按照实时数据库组态的要求,按不同的频率采集实时数据。
分组的优势在于降低了位号采集的工作量。
要知道很多协议是慢速的(如串口协议)。
如果实时数据库中仅要求5秒钟的采样频率,而下端却不作区分,按最快的频率采集,则往往效率就会降低,甚至影响到配置为高速采集的其它位号。
因此,分组往往是必须的。
协议栈则不用解释,大家都知道必须实现的。
实现的好,则效率高、稳定性好。
实时数据库接口中有定时器,在Windows平台上能获得的最高定时精度为40ms,因此采样周期高于40ms,没有意义。
一般主动采集的频率都是1赫兹以下的(也就是慢于1秒/次),更加快速的时候,均采用主动通知的方法,即当数据变化的时候,主动向实时数据库内核发送变化的数据,以达到更高效率。
接口就简单介绍到这里,要明确的是,对于主动采集方式下,接口相当于多了一层缓存,在今后的讲解中,大家会发现,实时数据库的效率和缓存的层次多少很有关系。
简单谈谈分布式技术,大型分布式实时数据库都采用了一定的分布式技术,采用的技术不同,局限性也不同。
COM/DCOM被熟知,被业界认同,是微软主要分布式技术,因此被广泛应用。
但逃不出DCOM安全性的魔障,与Windows权限捆绑紧密。
而且对于连接效率低的时候容易出错。
跨平台能力则更是彻底不具备了。
J2EE很好,但效率有些低,最近JAVA6出现后,效率已经有了显著提升。
甚至比.Net快,但作为底层研发来说,采用J2EE很不合适,原因是其对硬件的访问能力较弱。
随着以太网和工业通讯标准的提升,J2EE平台也许在工业应用上有后劲。
目前多数实时数据库厂商采用了专用TCP/IP协议,优势是易跨平台,部署方便,稳定性容易掌控。
但增加了掌控能力的同时也降低了对已有框架的集成,开发工作量大。
从实时数据库所面向的应用场景来说,专用TCP/IP 协议更加适合一些。
下面给出实时数据库的简化模型,后面的原理将结合这张图来讲解。
实时数据库被简化成由多个接口、一个接口管理模块、一个组态模块、一个实时模块、一个高速缓存和一个历史模块组成,上面覆以应用接口。
这个结构基本适合大部分实时数据库,各模块运行需要的组态信息往往从组态模块中获取,高速缓存往往和历史模块、实时模块都发生关系。
接下去将讲解实时数据库的核心IO策略。
前面已经讲过了,实时数据库一般采用缓存来增加读实时数据的及时性,因此实时数据库核心中都有高速缓存,如上图所示,通过接口的采集,高速缓存的数据得到不断的更新,而当上层读位号的时候,实时数据库通过返回缓存的值来快速响应。
因此,读一般是异步的。
但写则一般是同步的,写意味着控制,控制意味着严格的时序性,同时,写也可能失败的,如果写是异步的,则可能以为成功了,但实际失败了,后果不堪设想。
写的效率严重依赖于接口通讯效率和执行机构。
如果只是修改设定值,则可以较快返回,如果直接写阀位等需要机械执行的值,那就慢了。
由于缓存,则必然会产生时滞。