Linkman的学习记录

爱好和平的人士，总希望自己生活在一个没有战争没有竞争没有危机的社会，美其名曰和平主义者，这类人士，总生活在理想中，而在现实中痛苦。如果某一天上帝突然出现了，实现了这些和平主义者的梦想，这世界会不会就真的美好了呢？

我们可以想象一下，人们肯定会兴高彩烈一番，然后呢？

有一部科幻小说，描述的就是这样一个社会，未来的某一天，聪明的人们发明了全虚拟现实软件，只要将插头插在身上，就可以一直享受和平美好幸福快感的生活，于是，人们象迷恋鸦片一样迷恋上这个没有战争没有竞争没有危机的世界，他们变成了一具具行尸走肉。

这些一动不动的人们，他们选择了快乐选择了安宁选择了享受，同时也选择了逃避选择了麻目选择了脆弱。这种快乐，从旁观者的角度看，是那么的可笑，就好象我们从旁观者的角度，看待一个个呆坐在网吧中快乐地上网的人。

如果世界一直美好下去，我们不能指责他们的选择，但是，如果世界突然又改变了，他们怎么办？他们还能改变回去吗？

陶渊明描述了一个美好的世外桃园，那里的世界，一切都是美丽的，时间都是缓慢的，不知有汉，无论魏晋，问题是，汉魏晋不会因为他们的无知而消息，外面的世界终究有一天会将他们改变。而他们需要改变时，他们还有没有改变的勇气和能力？我们可以想象一下，在桃园中生活了100代之后的后人们，他们还想不想走出桃园？还敢不敢走出桃园？还能不能起出桃园？

达尔文提出，物竞天择，适者生存，这个观点不只是适用于生物界，同样适应于整个人类；不只是适用于宏观的大社会，同样适用于每个个体。只有那些勇于面对危机敢于克服困难的人，才能生存下去。

危机有大有小，大到战争，小到自己遇到的挫折，很多危机和困难降临在我们头上时，我们无法幸免，对于这些无法避免的危机，我们想了也白想，人力不能胜天。但是，谁能告诉我，什么叫不能避免，什么又叫能够避免呢？在事情真正发生之前，谁能知道它的危害到底有多大？谁又能知道时间有多长？谁又能告诉我们，这次能不能挺得过去？

想那么多有什么用？当原子弹正打中你的脑门，你只能哀叹自己的幸运指数太低，当原子弹在你十公里之外炸开时，你还活着，就必须要应对危机，否则，你会失去活下去的希望。

世界不总是美好的，经济发展是有周期性的，人们总会遇到不顺心的事情，我们不要责骂老天，我们也逃避不了，只有面对，只有解决，才能继续前行。对危机的惧怕是每个人的天性，能否应对危机则是个体的磨砺和自信。面对可能的危机，我们准备好了吗？

经济危机要来了，聪明者如马云要去冬眠了，豪放者如陈志列要去冬泳了，渺小的我们该怎么办呢？想起小时侯的一篇课文，寒号鸟说：多咯咯，多咯咯，寒风冻死我，明天就垒窝。我们该不会是那只唱歌的鸟吧。

后记：这次经济危机，现在北京还感受不明显，虽然2008年的中国多灾多难，但总能给人们希望。对我个人而言，2008年也是多经磨难的一年，现在最困难的时间已过去了，但还是需要应对很多困难和危机，但是，我相信能面对能处理能挺过去。世界局势我控制不了，国家大事我监管不了，尽量做好自己的事情，应对好日常生活和工作中的小危机，保护好自己以及家人和朋友，独立寒秋，笑对寒冬，尽人事而听天命，该来的都来吧，我不怕！

本章讨论“使用分布式实时数据库服务器解决超大容量实时和历史数据访问”的问题。

在开发远程移动监控系统时，一般有两种技术路线，一种是直接开发针对特定行业特定应用的系统，另一种是选用组态软件进行二次开发，这两种技术路线各有优缺点。当管理功能是远程移动监控系统的主要功能点，或者监控对象具有非常独特的行业特性，直接开发应用系统是一种合理的选择。而当监控功能是远程移动监控系统的主要功能点时，选用合适的组态软件，可以减少投入成本，缩短项目周期、提高系统稳定性，减少失败风险。

不管采取以上哪种技术路线，都不可避免地要对一个问题进行决策：如何保存采集到的数据。保存的概念包括三个方面：内存中保存的实时数据，磁盘上保存的历史数据，针对实时数据和历史数据的访问接口。可以选择的方案有五种：

1、组态软件本身的内存和历史数据库（或模块）；
2、自定义的内存和文件格式；
3、关系数据库；
4、实时数据库；
5、关系数据库+实时数据库；

针对以上两种不同的技术路线，可以选择不同的数据保存方案，当需要采集和保存的数据点达到一定的规模时，就需要采用方案4或方案5，在我的上一篇文章《实时数据库与组态软件的市场定位之异同》中，提到了依据工程总点数和需保存的总点数来决定是使用实时数据库还是组态软件，在远程移动监控系统中，当系统的点数规模超出了组态软件能处理的范围时，关系数据库也同样不能处理。

还是以那个重型机械厂的项目为例说明，如果按照每台车辆每10秒向上传送一次数据，每次传送100个数据，车辆总数按50000台计算。
如果采用Oracle关系数据库来存贮实时和历史数据。对数据的保存有两种方式，这两种方式也决定了上层Oracle数据库的数据表设计方案。

第一种方案是每个车辆设备的数据用一条记录来表示，每条记录有100个字段，这样设计的好处是采集服务器操作ORACLE服务器的事务数比较小，平均每秒钟的插入事务数为50000*5/60=4167条。该方式的缺点是，对不同的DTU需要设计不同的数据表；数据不能被压缩，磁盘空间占用非常大，如果每条记录按1K来计算，则一年需占用的磁盘空间为：356*24*60*60/5*50000*1024=293335G，再加上索引等辅助内容，整个系统一年所占用的磁盘空间约为400000G。

第二种方案是每个车辆设备的数据用多条记录来表示，每条记录只记录该DTU中某一个具体的数据点，这样处理，Oracle服务器的事务数达到每秒钟50000*100*5/60=416667次，在这种情况下，对数据可以采取一些压缩处理，系统一年所占用的磁盘空间与第一种方案相比，可以减少到1/10左右，约为40000G。

不管是采用以上的哪一种方案，都存在单位时间的读写次数达到系统处理上限，系统容量超出系统上限等困难，导致系统无法使用。可以通过引入网格数据库，或重新规划需保存的历史数据等方式解决这些难点问题，但都存在缺点，不是价格高，就是不得不损失相应功能。

引入实时数据库，只能部分解决此问题，举例说明，如果使用我们的实时数据库，单台服务器只能处理5000台左右车辆设备的数据采集和保存问题（经过定制改造，如果不改造，单服务器只能处理1000台车辆设备，该问题的瓶颈不在于性能，而在于点数限制，目前我们的标准实时数据库单台服务器只支持126000个数据点），仍不能处理高达50000台车辆设备。

这时，需要使用分布式实时数据库服务器来解决超大容量实时和历史数据访问，如下图所示（图略）。

可以看到，单台服务器处理5千台设备，处理的数据点为50万个，10台实时服务器能处理5万台设备，处理的总数据点为500万个，调度服务器对这10台服务器进行调度，使得10台服务器对外部而言（包括采集服务器和客户端）是透明的，外部只看到一台能处理500万数据点的大型实时数据库。

要实现一个分布式分布式实时数据库服务器，可能做得非常复杂，但对于大型远程移动监控系统中，可以简化处理，当然，这需要实时数据库支持层次点系统、设备模块、在线修改等功能的辅助支持，关于这方面的内容，在下一章中加以说明。

各个实时数据库厂家，都会在自己产品的宣传手册或说明书中，标明自己的压缩率能达到多少多少，或是“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是这么回答的）。

有实验报告吗？没有！

PPT：

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

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

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

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

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

解说：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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  能尽可能多尽可能快地保存历史数据。

　很多情况下，用户会将实时数据库与关系数据库混为一谈，实际上，这两类产品的设计理念及应用场合是完全不同的。

内存数据库就是将数据放在内存中直接操作的数据库，它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。

而实时数据库不但利用了内存的特性，而且考虑到工控行业的应用特性，将关系数据库的表结构和表关系简化，以进行性能的优化，并针对工控行业的数据特性，对数据进行压缩处理。

关系数据库、实时数据库与内存数据库相比，有如下差别：