Linkman的学习记录

1.       实时数据库的基本概念

解说：

虽然演讲的主题及标题找在十多天以前便定下来了，但到底该在“2008远程自动化高峰论坛”演讲些什么内容，这是一件令人难以决策的事情。既然是论坛，就应该淡化商业色彩，不要将演讲变成对公司实时数据库产品的发布宣传；既然是高峰论坛，所演讲的内容就应该有点高度和深度，不要将演讲变成对实时数据库的科普介绍和扫盲培训。

如果要演讲组态软件或采集板卡，我不需要从最基本的概念说起，因为在工控行业这些产品应用得非常广泛，已达到耳熟能详的程度。但是，实时数据库在国内的工控行业被知晓和认可的程度还很不够。这次高峰论坛，虽然参加的人员是来自各行各业的专家，我还是想先介绍一些基本概念。

PPT：

1.1. 实时数据库的功能

可以对海量数据进行：

l  采集

n  滤波

l  处理

n  量程变换

n  报警处理

n  事件通知

l  压缩

l  存贮

l  计算

l  查询

l  统计

解说：

因为面对的是非实时数据库专业的人员，而且，面对的受众大多是各行各业对监控软件熟悉的专家，我没有讲太多关于实时数据库理论方面的内容，只描述了实时数据库核心模块的所应该具备的基本功能。

这个功能描述，可以对比一下组态软件能完成的功能，可以看到，实时数据库核心模块所能完成的功能，比组态软件多一个“压缩”；比组态软件小一个“界面展现”；另外，它们之间处理数据量有区别，实时数据库能处理“海量”数据。

“海量”数据具体是一个什么概念呢？可以参考我的博文“实时数据库与组态软件市场定位之异同”，那里面提到了两者之间点数的大致区别。

从上面的描述可以看到，实时数据库的功能其实很简单，就是完成对工业数据的采集、实时处理、存贮。实时数据库能与其它产品有区别且能有自己的市场定位在于，实时数据库能高性能地完成这几项简单的工作。实时数据库的核心价值在于它的性能，一个性能平庸而功能完备的实时数据库没有任何市场生存空间。

PPT：

1.2. 与关系数据库的区别

强化和弱化，通用和专用：

l  表关系的复杂度

l  测点数量

l  数据插入速度

l  数据查询速度

l  保存的历史数据容量

l  工业业务逻辑

解说：

几乎所有人都了解关系数据库，因此，如果能够以关系数据库的概念去理解实时数据库，并搞清他们之间的区别，即能对实时数据库有一个基本而大概的了解。

关系数据库的发展历史非常长，它能以事务处理作为理论基础，以三范式作为构建基础，由小至大，以简单地逻辑能描述复杂的世界，因此，它具有通用而广泛的应用空间。但是，当由于性能等原因而不能使用关系数据库时，就需要使用其它存贮解决方案，实时数据库因此而产生。

关系数据库的定位在于通用商业应用，如果我们将这个范围减少，针对某具体应用领域的应用特征对关系数据库作限定和优化，就可以形成各种不同的类数据库系统。实时数据库就是这样的类数据库系统。

在工业相关的行业，生产过程数据是一种结构简单、关系简单的数据，它具有随时间而变化的简单特性，同时，它所产生的历史数据量非常大，针对这种应用，我们可以设计出非常简单的表结构，设计非常简单的表关系，并针对实时和历史数据的特点，设计出特定的处理功能，设计出特定的数据压缩算法以及存贮逻辑，就形成了实时数据库。

上面解释了实时数据库所具有的“专用”的特性，也解释了实时数据库的强化和弱化的特性，同时解释了实时数据库的工业业务逻辑。

这些弱化和专用的目的，就是为了针对工业过程数据的应用，达到如下几个目标：

l  能处理尽可能多的测点数量；

l  能以尽可能快的速度插入和查询数据；

l  能尽可能多尽可能快地保存历史数据。

PPT：

1.1. 对实时数据库的四个误解

l  误解1：实时数据库与关系数据库的功能类似，只是处理速度更快；

l  误解2：实时数据库只处理实时数据，不处理历史数据；

l  误解3：实时数据库就是内存数据库；

l  误解4：实时数据库只能应用在厂一级的管控一体化系统中；

解说：

这里专门用一章的篇幅来澄清对业内对实时数据库的几点误解，是因为平常在与客户的交流过程中，发现很多客户都会有类似的误解。

误解1：实时数据库与关系数据库的功能类似，只是处理速度更快；

上一节中，专门将实时数据库与关系数据库进行了对比，这种对比的目的，是为了让大家能够更好地理解实时数据库，而不是说，实时数据库就是速度更快的关系数据库，事实上，实时数据库与关系数据库之间并没有必然的联系，两者的发展历程也各不相同。

经常有客户在使用我们的实时数据库之后，很自然地提出这个问题：如果你们的实时数据库也有关系数据库那种复杂而灵活的表结构和表关系，能支持用户按照与关系数据库类似的方法进行操作，那该多好呀。

我们不能责难用户的无知，他们只是想要得到一个满意的产品，但是，要能达到这个目标，还是比较困难，我们可以反向思维，如果真有一种方法，即能与常规关系数据库一样使用，速度又快，那ORACLE、SQL SERVER等产品早就将自己的运行速度提得更快而不需要使用实时数据库了。

事实上，在很多大型实时数据库的应用中，都是将实时数据库与关系数据库混合使用的，以便发挥各自的优势而避免各自的不足。有关这方面的内容，详见我的博文《实时数据库与关系数据库的混合使用》。而且，现在越来越多的实时数据库（包括我们），也在考虑在实时数据库中加入有限的关系数据库的特性，只是，不管如何改进，实时数据库就是实时数据库，很可能一个实时数据库加入了复杂的关系数据库之后，就便成了一个性能平庸的关系数据库，而失去了它本来的存在意义了。

相对于关系数据库，实时数据库只有简单的表结构，且不能加入用户自定义的表结构（新一代的实时数据库有限地支持此功能）如下图所示：

误解2：实时数据库只处理实时数据，不处理历史数据；

实时数据库这个名称，本来就具有某种让用户误会的可能，用户一听说实时数据库，很自然地会认为，实时数据库就应该只处理实时数据，不处理历史数据，如果命名为“实时历史数据库”或“工业库”，效果都比实时数据库这个名称更加好，意义更加准确，只是这个行业的标杆产品PI，以及其它国外产品都是这么命名的，经过十几年的流传，也就约定俗成了，关于这个误解的详细说明，请见我的博文《数据库分类》和《此实时数据库非彼实时数据库》，在此不再多说。

误解3：实时数据库就是内存数据库；

实时数据库是实时数据库，内存数据库是内存数据库，这两者是完全不一样的产品，详见我的博文《关系数据库、内存数据库、实时数据库的简单比较》，只是某些内存数据库产品，例如eXtremeDB号称自己是实时数据库，还有某些电力行业的专用内存数据库也号称自己是实时数据库，于是，很多不太明白具体情况的客户被误导了。

误解4：实时数据库只能应用在厂一级的管控一体化系统中；

教科书或许多产品的宣传手册中，都宣称实时数据库是MES的基石，是专门应用在厂一级的管控一体化系统中，作为厂级生产过程数据的中心，于是，很多用户都认为，实时数据库只能应用在这个范围，其实，很多行业，生产和管理的界线并不是特别分明，另外，实时数据库也应用到很多非厂级监控领域，比如，此次演讲，我准备演讲的关于实时数据库在远程自动化领域的应用，包括远程监控，远程调度、远程设备维护、移动设备监控等，并不属于厂级管控一体化系统，而更多地属于SCADA范围。

有关这方面的内容，详见我的博文《实时数据库与组态软件的市场定位之异同》。

用户对实时数据库的这些误解，很可能会让客户对实时数据库到底是什么，到底能干什么，到底能为他们解决什么问题，到底如何为他们解决问题等，会产生或多或少的疑惑，这对我们做实时数据库的厂家来说，不是一件好事，需要我们经常宣传实时数据库，多推广实时数据库。

各个实时数据库厂家，都会在自己产品的宣传手册或说明书中，标明自己的压缩率能达到多少多少，或是“10:1”或是“20:1”，这些数字是怎么算出来的呢？

标准答案是：没法算出来。

压缩率的表示方法“N:1”，隐含了两个概念：参照物和测试环境。也就是说，在某种测试环境下，保存同样的数据，实时数据库可以达到参照产品的1/N。

这里的参照物有两种可能性，可以是压缩之前的原始数据，也可以是另一种典型的存贮系统，比如关系数据库。这里的测试环境，应该是某种人为约定的标准输入。关键的问题是，我们能找到一种能近似模拟工控设备数据源的标准输入吗？如果不能找到合适的测试数据，那些测试结果又有多大的价值呢？

实时数据库应用在过程控制及相关行业，在这个领域中，数据具有如下特征：

• 最常见的数据是模拟量，也有一部分开关量；
• 数据中只有一小部分值经常发生改变，很多开关量常期不变化；
• 数据的变化具有一定波形规律；
• 很多数值都具有慢变化的特征； 
• 数值变化与时间变化具有共同变化特性； 
• 用户在一定范围内，能够允许数据的精度损失；

我们能找到一组模拟以上特性的测试数据吗？聪明的观众肯定会自然地想到，可以用正弦曲线来模拟。只要测得针对正弦曲线的数据压缩率，就能定性（但不能定量）地判断出某实时数据库的大体数据压缩性能。

可是，即便采用正弦曲线来模拟，还需要考虑很多其它因素。

A、取样密度
对于同一条正弦曲线，比如1分钟变化一个周波，如果取样密度不一样，所得到的取样点数是不一样的。如果每秒钟取一个点，可以取得60个点，如果每0.1秒取一个点，可以取得600个点，再极端一点，如果1毫秒取一个点，可以取得60000个点。我们假定可以用一些特征点来描述该曲线，则取样密度越大，数据冗余度越高，数据压缩率就越高。如果某实时数据库产品宣称自己的数据压缩率为1000:1，你也不要认为他在吹牛，他也许就是对以毫秒为单位取样的1分钟变化一个周波的数据进行压缩呢。

B、数据精度
保存一个双精度数比保存一个单精度数所需要的空间肯定要大。但在很多过程控制应用中，单精度数完全足够了。

C、数据范围
数据范围可能影响数据精度。

C、数据失真率
如果用户不允许任何失真，那就是无损压缩。但事实上，工控行业就是一个不可能完全不失真的行业（详见我的博文《关于变位压缩的讨论》）。

聪明的观众看到这儿，肯定就会说，那好办，制定一个统一的标准，以1秒钟作为取样密度，取单精度数，以1分钟变化一个周波，数据范围为-100至100，失真率设为0.5%，将各个实时数据库产品都运行起来，看看各个实时数据库厂家的数据压缩率到底是一个什么样的值。

这个方法确实可行，可是，会有一些实时数据库厂家站出来说，只有这些还不够，还要考虑以下因素：

A、时间精度
大家部实时数据库支持精确到毫秒，但部分厂家在这上面打起了节省空间的算盘，只精确到5毫秒，或只精确到100毫秒，并很严正地宣告，在常规实时数据库应用中，精确到毫秒完全没有意义。

B、测点数
有一些实时数据库对多个测点的数据压缩与对单个测点的数据压缩，效果是有区别的（这个地方我卖个关子，有谁能猜得出来吗？）

C、测试时间
大部分实时数据库为了减少磁盘读写时间，对磁盘空间都是预分配的，系统初始化后，就预先申请了一大块磁盘空间，你怎么测试它保存数据花了多少空间呢？

聪明的观众会继续聪明地说，再加约束条件，所有的时间精确到1毫秒，统一测试1万点，统一运行一个月，现在总可以了吧。

差不多了（还有一些其它因素，就不再罗列，否则有人会说我是唐僧），如果按照这个标准来测，呵呵，大家会发现，每一家实时数据库的测试结果都比他们的宣传要低几倍。

但这些实时数据库厂家也有理由，这种测试本来就不能完全模拟工控现实情况呀，工控现场有开关量，有整型量，还有个别字符串量，还存在很多大部分时间不变化的量，这些因素，是要考虑进去呀。

OK，这么多理由，那你告诉我你的数字怎么来的吧。他们会这么答复：我们是从多个典型工程的多年对比数据中统计而来的，这些数据，如果用关系数据库来存贮，需要比实时数据库30倍的空间（PI是这么回答的）。

有实验报告吗？没有！