Linkman的学习记录

国产实时数据库真的比洋品牌差吗

Linkman的学习记录 — Fri, 28 Nov 2008 16:35:00 GMT

国产实时数据库真的比洋品牌差吗？我不信。

一个月之前，我们与某公司商谈合作，讨论将我们的实时数据库OEM到他们的MES系统中，这个公司的老总是我多年的老相识，也是多年的老朋友，他这么对我说：老Linkman呀，我们合作吧，在2万点以下这一档次，我们公司全面OEM你们的实时数据库，2万点以上，我们还是准备使用国外的实时数据库产品，毕竟，在2万点以上的系统中，国外的实时数据库产品的性能和稳定性要强于国产实时数据库产品。

听到这些话，我有点欣慰，也有点失落。欣慰的是，曾几何时，一提到实时数据库，大家都只能想到国外的实时数据库产品，铁定只选用国外的实时数据库产品，根本不会考虑国产实时数据库，现在，至少在2万点这一档次上，我们已能与国外的实时数据库产品正面抗衡，很多用户已经认为国产实时数据库是一种很好的选择；失落的是，我们要真正证明自己，还有很长的路要走，即便我们说自己行，那也不一定行。

我当时并没有说任何话，能争取到2万点系统的OEM，对我们来说，已经是一个很大的胜利，只要给我们机会，我们就能更好地证明自己，再多的空话也是多余，先将眼前的事情做好吧，但我有理由相信，最多再过一年，我的那位朋友的观点会改变，我们值得他选择。我有这个自信，因为我熟悉我们产品的每一处细节，知道她的真正情况，也知道他的真实能力，就象了解我的小孩的每一处细节一样。

这一次投标更有意思，国内国外多家实时数据库厂家在客户现场直接PK，由我们与客户一起来做各种功能和性能测试，当我们做完了实验，提交了测试报告之后，客户的一位主管要求我们重做某一项实验。我们很配合地重做了这项实验，最终实验效果比我们第一次做的实验的效果还要好。

下面是这次测试的服务器配置：

数据库服务器硬件配置
名称	型号及说明	配件数量	数量
CPU	四核 Intel xeon x5450 3Ghz	2	1
内存	8G DDR2	1
硬盘	146G 15krpm SAS	1
网卡	千兆	1
数据库服务器软件环境
名称	型号及说明
操作系统	Windows Server 2003中文版
C盘剩余空间	4.12G NTFS
D盘剩余空间	128G NTFS

重做的实验为“以1秒为单位采集及写入数据时，记录服务器的各种负荷”，具体要求为：由客户工程师监护，实时数据库厂家做将采集模拟器放在与服务器不同的客户机上，以1秒为单位模拟采集及写入试验，并记录不同实时数据库容量下，服务器的各种负荷。

操作步骤：

A、启动实时数据库，数据库中已保存需测试的工程测点，总容量为60万点；

B、启动模拟采集器，以1秒为单位产生模拟数据，分别产生30万点、60万点的测试数据；

C、连续运行30分钟；

D、观察数据是否能够在规定的时间内写入，记录每次测试的CPU负荷等；

下面是测试结果：

服务器容量	60万点
工程测点总容量	60万点
数据是否全部保存	是，40万个模拟量，12万个整型量，8万个开关量
失真率是否满足要求	是，模拟量失真度0.5%，其它不失真
数据波形是否符合要求	是，模拟量和整型量以幅度100，周期300秒的正弦，开关量周期60秒
模拟器数据产生频率	1秒
是否能够在规定的时间内写入数据库	能

实时数据库服务器运行状态记录

观察时间	点数 (万)	CPU使用	物理内存使用	最高单核CPU使用	虚拟内存	备注
13:05	30万	6%	446M	38.9%	283M	一个模拟器，同步送30万点
15:48	60万	9%	558M	22.2%	305M	两个模拟器，分别异步送30万点。

下图是以单模拟器1秒同步插入30万点时的CPU负荷图：

800)this.width=800" border=0>
下图是以两个模拟器以1秒为单位异步插入60万点时的CPU负荷图：

800)this.width=800" border=0>

这个实试说明以下几个问题：

A、我们的实时数据库可以轻松地实现单服务器60万点容量（后来我自己又做了单服务器90万点容量的插入实验，性能同样不错）；

B、将模拟器的数据由1个改为两个，通讯方式由同步改为异步时，性能大大提高，终于利用了客户那么高档的多CPU多核计算机的优势，而且，随着模拟器数量的增加和通讯客户端的增加，利用多核的优势越明显；

C、我们的实时数据库性能还有很大提升空间，如果在程序设计中充分考虑多核的并发处理，性能至少可以提高3-4倍。或者，直接运行3-4个实例，那样，我们的单台实时数据库服务器可以轻松地支持200万-300万点。

我能想象得到，这位主管为什么要让我们重做这项实验，因为在这一证明实时数据库性能的实验中，我们的试验数据甚至比国外的实时数据库的性能指标还要高得多，他有理由怀疑，我们是不是在作假，而我们毫不犹豫地配合重新做了这个实验，并愿意在不同环境下重做（不同的计算机、更长的实验时间，不同的网络环境等），更说明我们的自信，只有这样，我们才能得到用户的认可和尊重。

都说国外的实时数据库要比国内的实时数据库强，我一直不服气，相信国产实时数据库能超越那些国外的品牌，不仅仅是某一项指标，而是全面超越，不仅仅是内核，而是整体，不仅仅是性能，而是包括性能、功能和稳定性，我已为这个信念投入了三年的时间，而且以后愿意投入更长更多的时间，相信在不久的将来，我们可以真正得到用户的认可，可以在高端实时数据库市场与国外实时数据库产品全面抗衡，乃至超越，乃至战胜！

危机

Linkman的学习记录 — Tue, 18 Nov 2008 16:03:00 GMT

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

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

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

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

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

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

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

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

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

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

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

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

实时数据库在大型远程移动监控系统中的应用要点（三）

Linkman的学习记录 — Tue, 18 Nov 2008 16:01:00 GMT

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

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

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

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万数据点的大型实时数据库。

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

实时数据库的压缩率是怎么算出来的？

Linkman的学习记录 — Tue, 18 Nov 2008 15:59:00 GMT

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

有实验报告吗？没有！

在“2008远程自动化高峰论坛”演讲PPT之解说版（三）

Linkman的学习记录 — Tue, 18 Nov 2008 15:59:00 GMT

PPT：

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

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

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

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

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

解说：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在“2008远程自动化高峰论坛”演讲PPT之解说版（二）

Linkman的学习记录 — Tue, 18 Nov 2008 15:59:00 GMT

PPT：

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

关系数据库、内存数据库、实时数据库的简单比较

Linkman的学习记录 — Tue, 04 Nov 2008 03:38:00 GMT

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

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

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

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

比较项目	关系数据库	内存数据库	实时数据库	说明
表结构	完整	完整	简化	实时数据库不能处理复杂的表关系，但在特定行业的应用中，比如工控监控软件中，不需要复杂的表关系
每秒读写速度	3000	50000	500000	内存实时数据库比关系数据库快10倍左右，实时数据库比内存数据库快10倍左右
历史数据压缩	无	无	有	实时数据库比内存数据库的压缩率能达到20~40倍
4G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）	5小时	5小时	8.5天	在4G内存的情况下，在单服务器处理30万点的情况下，内存数据库只能存贮5小时以内的历史数据，在带索引时，只能保存3小时以内的历史数据。(详见我的博文《实时数据库存贮容量计算方法》)
128G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）	7天	7天	269天	内存数据库有般用在电信行业，国内电信行业应用的最大项目也就使用了90G内存，在128G内存下，内存数据库也只能保存7天的历史数据
是否需要历史数据库	不需要	需要	不需要	内存数据库还需要配套使用历史数据库，且历史数据库同样存在不能压缩、不能保存长时间海量历史数据的问题

从以上的表格可以看出，内存数据库与关系数据库相比，速度快10-20倍左右，且具有与关系数据库类似的完整表结构，因此在电信业处理大量实时事务业务时经常用到，它也可以应用在工控行业，比如，在很多电力行业SCADA软件中，都包含了一个小型的内存数据库系统（但不是真正意义上的内存数据库），但是，在超大型SCADA软件中，它仍不能满足需求，因为它性能比实时数据库慢10倍，且不能解决历史数据存贮的问题，还存在因为掉电导致大量数据丢失的风险。

以上的比较，指标并不全面，也并不是说，实时数据库一定比关系数据库和内存数据库好，只能说，需要针对不同应用的不同需求，做出综合决策，选择最适合自己需要的数据库产品。

最后，列举一些典型的内存数据库产品：

■ Oracle TimesTen

Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。

■ Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适合于有高时效要求的实时系统。

■ eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。

关于单元测试的10点总结

Linkman的学习记录 — Tue, 28 Oct 2008 08:55:00 GMT

在两年以前，我写了一系列关于单元测试的文章，希望在公司内部的产品开发过程中，引进完整的单元测试，当单元测试工作推动起来后，我便停止了这方面的写作。前几天，与公司不同部门的同事谈起单元测试，很有一些感触，因此，又动了写单元测试文章的想法。

话题的起因是这样的，这位同事以及其他几位同位，正在全力开发一个全新的产品，团队人数不多，项目周期也不长，想在内部引入单元测试，因为觉得我部门单元测试的工作推动得不错，这位同事向我搬救兵，希望我部门给他支援一两个单元测试人员。问他打算如何推动单元测试工作，他的想法是，他和另一个核心开发人员全力编写系统，我支援的测试人员全力给他们做单元测试。

我当时问了他几个问题：

1、你们两个核心人员准备参与单元测试吗？

回答：不准备参与。

2、如果两个测试人员的测试速度跟不上两个核心人员的开发速度，怎么办？

回答：只测主流程和基础模块，不测分支流程和上层模块（也是非界面）。

3、测试人员如何理解拟测试的程序及模块？

回答：核心开发人员给测试人员讲解模块的功能，由测试人员自我阅读理解。

我当时这样回答那位同事：如果是这样，我建议你还是不要引入单元测试。

这样回答，不是给那位同事拨冷水，也不是不愿意支援两个单元测试人员，这两年，我们团队在单元测试的过程中，尝到了太多酸甜苦辣。回想这两年以来的产品开发工作，在我的强力推动下，单元测试工作推动得不错，取得了一些成绩，也发现了很多以前没有发现的问题。在这里将一些感受写出来，算是两年单元测试的总结吧。

总结1：如果项目团队的主要领导对单元测试的理论和技术不熟悉，一定不要引入单元测试。

总结2：当项目的开发周期紧，开发人员的投入不多，一定不要引入单元测试。

总结3：在项目的开发过程中，要只少有一位核心开发人员投入到单元测试，或者，每位核心开发人员至少要投入1/3的时间到自己所编程的单元测试中。

总结4：单元测试是一项长期的系统性的工程，启动容易，长期坚持难，对单元测试如何能够长期适应项目的变动，是单元测试中最难处理的事情。

总结5：当项目需求经常变化，或内核模块未达到一定的功能稳定期，不要贸然投入单元测试，否则，大量的单元测试工作会全部白做。

总结6：如果单元测试对被测试代码不能够达到一定程度的测试覆盖度，不如不做单元测试。

总结7：当代码的文档不全时，对单元测试人员的水平要求非常高，如果单元测试人员的水平不够，会编出很多无意义的单元测试用例。

总结8：同水平的单元测试人员与开发人员的数量如果不能达到1:1，不要引入单元测试，要使单元测试发挥效果，单元测试人员与开发人员的数量最好达到或超过2:1。

总结9：不要试图对第三方库、或历史遗留模块做单元测试；

总结10：不要迷信单元测试所得出的系统稳定性指标，再严格单元测试也不能完全保证系统质量，需要与模块测试、接口测试、集成测试等一并保证系统质量。

写了以上这些内容，并不是反对在项目中引入单元测试，只是希望那些对单元测试不太了解的团队，在是否要引入单元测试时，一定要慎重，否则，会发现投入了很多，产出却少得可怜。

事实上，我们团队已经在项目中尝到了单元测试的甜头，我们也希望在单元测试方面做得更好，我相信，经历过这两年的酸甜苦辣，我们有信心在单元测试这条路上走得更远。

实时数据库在大型远程移动监控系统中的应用要点（二）

Linkman的学习记录 — Mon, 13 Oct 2008 12:26:00 GMT

这一章重点讨论在大型远程移动监控系统中网络方面需要处理的问题。

随着移动设备数量的增加，需传输的数据量、对网络带宽的占用、单台服务器的负载等都会随之增长，在设计大型远程移动监控系统时，需要考虑增长的趋势以及增长对系统的影响，做出定量分析和定性判断，在必要时做出增加服务器、改造网络等系统重构决策，并要确保系统重构不对现有系统结构、软件架构产生冲击。

对网络带宽的影响有如下因素：

单台移动设备单位时间内的数据上传量

假定每台移动设备需要传送的总量为100个，这些变量中，开关量和模拟量是各占一半，再考虑到大部分变量都是慢速变化量的特性，并在移动设备本地采用一些简单的数据压缩算法，每次需上传的数据量还可以更低。可以将每台移动设备每一分钟上传的数据量，控制在平均500-1K字节之间。

数据中心与电信之间的网络带宽

GPRS理论带宽可达171.2Kbps，实际应用带宽大约在40~100Kbps；CDMA 1x理论带宽可达300Kb/s，目前的实际应用带宽大约在100Kb/s左右。在TCP/IP协议上，每一秒钟能够传输的数据量为3K-9K左右，移动设备端不会出会通讯带宽瓶颈。但随着移动设备数量的增加，数据中心与电信之间则有可能出现带宽瓶颈。

按照10000台移动设备计算，如果每台移动设备每一分钟传送的数据量为1K字节，则数据中心与电信之间的理论带宽为10000*1024*2*8/60=2.5Mbps，再考虑到GPRS网络的不稳定性，数据传输的时间不均匀性，可以将该带宽值*4倍，即在10000台移动设备的情况下，数据中心与电信之间的网络带宽应设计为10Mbps左右。

单台服务器的处理性能

对于单台服务器的处理性能，需要考虑在操作系统下，单台服务器能够处理的最大连接数。单台服务器能够处理的最大连接数由以下几个因素决定（以linux为例）：

A、Linux内核支持的最大socket连接数，现有linux默认支持的最大socket连接数为2048，但可以通过修改内核的方法调整该值；

B、服务器支持的最大内核信号量，该内核信号量用于网络连接处理、数据库访问等一系列多进程或多线程处理的数据同步。linux服务器版本设置的全系统支持的信号量虽然有上万个，但是分配给每个用户的数目一般为200-500之间，对于通讯服务器往往是不够的。可以通过修改内核信号量参数来适度增大该值；

C、服务器内存及在合理的CPU负荷率情况下，能支持的最大连接数。

以上对性能参数的分析，只有定性分析，没有定量分析，只能通过经验值进行调整。目前，一般的单台linux服务器能够支持的连接数为2000-4000个，业界也有通过调整内核、程序优化等手段，将单台linux服务器支持的连接数指标提高到20000个，但那样花费在linux内核调整、linux的TCP协议栈的程序修攺等方面所作的工作非常之大，在很多时侯是得不偿失的。

为了使得大型远程移动监控系统能够在移动设备数量扩展的过程中，能够达到只增加服务器（最好能实现动态在线增加服务器）、不需要重构软件系统的目标，必要要在系统中引入支持负载均衡的多采集服务器群集。

目前，业内通用的负载均衡方法有两类，一类是硬件解决方案，一类是软件解决方案。

硬件解决方案主要是引入支持负载均衡的路由器或防火墙来实现，是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

目前，许多厂商推出了专用于平衡服务器负载的负载均衡器。目前负载均衡器生产商有：Intel、Alteon Web、Arrow Point(已被思科并购)、Coyote Point、F5 Networks、Foundry Networks、HydraWeb以及 RADWare等。负载均衡器的形式多种多样，作为启动器，它以各种形式和大小出现。一些厂商，如Alteon、ArrowPoint，将负载均衡器集成到交换设备中，置于服务器与Internet链接之间；而另外一些厂商，如Coyote Point、 F5 Networks 以及HydraWeb，则运用两块网络适配器将这一功能集成到PC中，其中一块连接到前端止于Web服务器的Hub上，另一块通过路由器或其他设备连接到Internet上。一旦负载均衡设备检测到所管理的每台服务器承载的负荷量，它会按照一定的算法来分配通信。

而软件方案则有如下选择：
动态DNS方法；
反向Proxy方法；
NAT（网络地圵转换方法）；
IP隧道方法；
直接IP路由方法；

这些方法各有其优缺点，在大型远程移动监控系统中，我们选用NAT方法来实现分布式数据采集及负载均衡。

NAT（Network Address Translation网络地址转换）的工作原理修攺IP包的报文头，报文头（目标地址、源地址和端口等）被改写后，客户相信它们连接一个 IP 地址，而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由此，可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址上的一个虚拟服务。

在一组采集服务器前有一个调度服务器，移动设备连接数据中心时，请求报文到达调度服务器，调度服务器根据连接调度算法从真实的采集服务器中选出一台服务器，将报文的目标地址改写为选定服务器的地址，报文的目标端口改写为选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度服务器在连接表中记录这个连接，当这个连接的下一个报文到达时，从连接表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自采集服务器的响应报文经过调度服务器时，调度服务器将报文的源地址和源端口改为对应的IP地圵和相应的端口，再把报文发给移动设备。当连接终止或超时，调度服务器将这个连接从连接表中删除。这样，移动设备所看到的只是一个固定的IP上提供的服务，而采集服务器的集群的结构对用户是透明的。

这种负载均衡方案存在两个缺点：

1、调度服务器存在单点故障，即调度服务器出故障后整个系统会出会故障，这个问题可以通过双机冗余方案来解决。

2、调度服务器可能存在性能瓶颈，从目前已运行系统的经验数据来看，调度服务器在连接20台以上的采集服务器时，将会出现性能瓶颈，但这已足够大多数应用的需求了。

这是什么概念呢？简单总结一下：通过负载均衡技术，单采集服务器可以支持3000个移动设备，最大可以支持20台服务器，最大可以支持60000个移动设备。

实时数据库在大型远程移动监控系统中的应用要点（一）

Linkman的学习记录 — Sun, 12 Oct 2008 14:38:00 GMT

刚出差回来，在整理邮件时，收到一封控制工程中文网发来的“邀您参加2008远程自动化高峰论坛”的邮件，打开一看，呵呵，我们公司是赞助商之一。有兴趣者可以点击以下网址查看详情：（http://www.cechinamag.com/event/SCADA2008/eletter.htm）。

既然我们公司也是赞助商之一，肯定要写写文章捧捧场。刚好，这次出差，与一家重型机械厂家谈项目合作时，就大型远程移动监控系统中的技术要点进行了深入的讨论，在此，将一些想法写出平，权当抛砖引玉。

远程移动监控系统的概念是，通过安装在移动设备（如车辆、船舶、仪器等）上的现地数据采集设备，以无线通讯技术将移动设备的信息传送到中心站点，在中心站点实现远程监控、维护、管理及其它扩展应用。而当系统需要管理的移动设备达到一个非常大的数字时，便可称之为大型远程移动监控系统。

大型远程移动监控系统到底是一个什么样的系统呢，还是以这个重型机械厂家的项目为例进行说明：该厂家生产重型机械车辆，在每台出厂的车辆上都安装了现地监控设备和GPS定位系统，通过GPRS网络向厂家实时发送车况信息，发送频率为1-10秒钟一次，需要发送的数据量为100-200个，现在安装车载设备的车辆达到了3000台，系统最终的规模会达到50000台车辆，在厂家需要对所有安装了车载设备的车辆进行远程监控，实现对车辆的地理定位、实时车况监控、远程维护、客户服务等功能。

可称之为大型远程移动监控系统的项目比较多，我就不一一例举了。这类应用，应该是未来几年远程监控系统的新应用热点，瞄向这类应用的不单单有厂家、集成商，还包括移动公司，移动公司专业就此成立了M2M部门。

部分常规远程SCADA技术仍可以应用在大型远程移动监控系统中，但是，由于系统的规模的扩大，许多常规远程SCADA技术已无能为力，需要应用新的解决技术。归纳起来，在大型远程移动监控系统中需要处理如何几个要点：

1.使用负载均衡技术和多采集服务器解决超大容量网络传输及网络数据接入问题。

2.使用分布式实时数据库服务器解决超大容量实时和历史数据访问问题；

3.通过设备模板、功能模板、画面模板、脚本语言、在线数据修改功能，实现移动设备的动态管理，包括移动设备的动态加入、在线、停运等自动维护功能；

4.现地引入GPS模块，后台的SCADA软件与GIS软件的溶合，实现对移动设备的工况和地理位置的统一处理；

5.实时数据库与关系数据库的配合使用，提供易用接口和二次开发接口，实现扩展管理应用；

后续文章，将就以上问题一一展开讨论，敬请期待。

文章来源:http://blog.gkong.com/more.asp?name=linkman&id=64113