实时数据库

实时数据库中的二级压缩技术

Linkman的学习记录 — Tue, 13 Nov 2007 04:35:00 GMT

今天心情不好，写写文章散散心。

我在文章《实时数据库领域中有关数据压缩的认识误区》中提到，在工业应用领域中，常用的压缩算法分为三类：无损压缩、有损压缩、二级压缩。二级压缩技术，同时利用了无损压缩、有损压缩这两种数据压缩技术。

liyaoer123同学很好学也很好问，他问到：“我有点疑问，通过旋转门压缩后的数据基本上是没有重复量了，二次压缩这个词应该不能准确表达意思。”

首先要提醒liyaoer123同学一下，旋转门压缩只是有损压缩的一种，osisoft公司似乎还拥有旋转门压缩的技术专利，我们还是少提它吧。

常用的几种的有损压缩的方法都类似，主要是抽取那些特征点，以特征点的连线来近似地表示原始数据曲线，如下两图所示。

图一压缩前，总共有52个采集点

图二压缩后，只有6个特征点

二级压缩的概念，是在已进行有损压缩的基础上，再次对数据进行压缩。

对于二级压缩，需要考虑如下如下两方面的问题：

1、为什么需要进行二级压缩？

在《实时数据库领域中有关数据压缩的认识误区》中，我已提到，对实时数据库而言，数据压缩可以带来两方面的好处：占用硬盘容量减小、系统整体处理速度提高。

随着计算机硬件水平的提高，硬件成本在整个系统投入的比重逐步下降，硬盘容量不再是实时数据库中最主要的矛盾，但对系统整体处理速度及性能的追求，还是非常重要的。

关于压缩性能和系统整体处理速度及性能的指标，我经常面对两类指责。

有一些人对我说，我们保必要追求那么高的压缩比，何必要追求那么快的处理速度，只要够用就行了，我们还是将精力放在系统的稳定性和可靠性方面吧，似乎对指标的追求导致了系统稳定性的下降。

而另外一些人则对我说，你们中国人只知道在低层次上的技术水平上竞争，现在PI的最新的版本已支持单服务器1000万点，而国内这些实时数据库厂家还在10万点这个层次上竞争。

对这两类指责，我不想评价是与非，只想说，不管我们做什么，都会有不同的意见，关键的问题是，我们自己想做出什么东西。

对于MES系统集成商，实时数据库只是其中一个子系统，只要够用就行，而作为实时数据库的提供商，我们希望我们的实时数据库系统在各个指标方面，包括稳定性和可靠性方面，也包括功能的完备性和需求的准确性，都能全面与国外产品抗衡，因此，对性能的追求是一直会坚持走下去的。

写到这里，跑一下题。这前段时间在全国几处地方跑了跑，与很多客户进行了技术和商务交流，当我们提到，我们的实时数据库的数据读写指标为每秒30万次，他们大部分表示了惊讶：不对呀，PI和IH都是每秒2万到10万呀，你们的实时数据库怎么比那些国外的品牌还要强呀。

再将马拉回来，我在《此实时数据库非彼实时数据库》中提到，压缩比例的提高，对实时数据库的整体性能的提高有很大的推动作用（但不一定成正比），因此，有必要分析一下，能否对已经进行有损压缩处理的数据进行二级压缩。

2、如何进行二级压缩？

从刚才分析的情况，大家很可能就得出结论，行呀，先通过有损压缩，将点数由52个变成6个，再对剩下的6个点进行编码，再进行哈佛曼压缩或别的什么压缩，不就行了？

没这么简单。

哈佛曼压缩的特点是，将那些经常使用的字母用较小长度的字节表示，这在文本和字符串压缩中会有比较大的效果，比如英文那个e就是用得很多的，而汉字中的五笔字型也有一级编码、二级编码等，也就是说，它们具有可压缩的余地。

如果大家对随机的数据点，比如刚才6个数据点，采用哈佛曼或其它无损压缩试验，会发现压缩率不会特别地高，也就是说，再次进行无损压缩的意义已经不是特别地大。

难度就没有别的办法了？办法还是有的，要完整地表达测点的一个数据，需要包括以下四个字段：

测点ID
时间戳
质量戳
值

其中，同一测点的多个数据可以保存在一起，因此，测点ID可以不考虑。还剩下三个字段，仔细分析一下这三个字段的特性，还是有很多文章可做的。

值

先考虑“值”字段，我们采用8字节的双精度数来表示一个模拟量，这里就存在一个由低精度值来表示高精度值的可能。如果一批数据中，全部（或大部分）数据都可以由4个字节（或2个字节）来表示精度误差范围内的8字节双精度数，便可以节省下很多空间了。

当然，如果我们能明确地知道某数据的精度范围，便可直接在配置环境下选择最合适的数据类型，而不必要一定要选择双精度数。

对于值，还有另一种压缩思路，在流程工业中，某值的绝对值可能非常大，但如果该值在某时间段时的变量范围在某个精度范围内，也可以采用基准值+变化值的方式保存值，其中基准值只保存一次，而变化值用低精度值表示。

质量戳

质量戳是慢变化量，如果不与值共同保存，则可以有很高的压缩比。但如果不共同保存，则需要考虑查找的索引方式，这是一笔额外的空间开销。

时间戳

对于时间戳，也可以按照值相类似的方式来考虑。

首先，那个毫秒字段，不一定是每个系统每个测点都需要的。再者，两个时间之间的相差值，在大部分情况下，不会超过1天的，这个就可以采用简化表示。还有，现在的系统，肯定不需要再处理时间为2000年以前的时间了。

以上只是分析，在实际系统中，还需要考虑这些因素的制约关系，解压的难度和时间度，索引建立的方便性，以及编程的复杂度。

关于实时数据库接口标准的讨论[中]

Linkman的学习记录 — Tue, 13 Nov 2007 04:35:00 GMT

上回说到，实时数据库的接口类型，包括以下三种，这三种接口类型功能不同，对标准化需求的迫切性不同，标准化所需要作的工作也不同相。

①、数据采集接口；
②、内部模块数据交换接口；
③、对外数据接口；

我本来拟就此三种接口的异同、对接口标准化的需求等，一一进行分析说明，但邹骁同学已明确表示，他拟推动的乃是数据采集接口的标准化，非其它两种接口，而且，从其文章《OPC——资本和崇洋豢养的病态协议》中可以得出结论，他拟推动的标准化工作，有相当一部分任务是为了解决OPC的弊端，也就是说，该数据采集接口在很大情况下可以替代OPC。那好，今天我也就只针对该接口进行分析。

先让我们猜想一下，邹骁同学心目中，理想的、标准化的数据采集接口，到底是一副什么样子吧：

该标准协议基于以太网，基于IP层，具有自定义的简单而高效的传输控制协议，具有高效、功能完备、可扩展性强、配置简单、维护方便等特性。其它协议，包括OPC、Modbus协议等，先转换为该标准协议，再接入实时数据库。实时数据库厂商按照标准协议采集其它系统的数据，如果其它系统不存在标准协议，则为其编写一个专用的协议转发程序。实时数据库厂商可以将针对其它系统开发的协议转发程序单独销售，卖给任何需要该协议转发程序的最终用户或实时数据库厂家。

为了满足标准化的要求，该协议不应该只传实时值，它应该包括以下完整的功能点：

可选的链路层传输控制协议
可选的传输安全控制方法
多机环境下的用户权限管理
数据类型自描述体系
测点属性自描述体系
测点类型自描述体系
测点方法自描述体系
测点层次结构自描述体系
复杂数据类型自描述体系
测点属性读写
实时数据读写
历史数据读写
统计方法定义及统计数据读写
测点报警逻辑自描述体系
测点事件逻辑自描述体系
以上各种功能的订阅发布逻辑
以上各种功能的批处理逻辑
以上各种功能的同步异步逻辑

同时，还可能会考虑以下扩充功能点：

时间及时区对应逻辑
客户端数据压缩逻辑
客户端数据缓存逻辑
冗余逻辑
基于复制的可靠性服务
多主控制逻辑
多级级连系统
跨平台的协议程序实现

相信邹骁同学及其开发团队，已经严密地分析了各种应用，已经对比了OPC、Mobus、IEC-61850等各种协议，并认真地分析了OPC的功能点，虽然OPC在邹骁同学眼中的形象不太好，但它确实可以提供很多可供参考的信息，另外，相信邹骁同学也正在参考分析OPC UA协议，因为OPC UA协议也在努力地对OPC的缺陷作出修订和改进，而这些修订和改进，对我们重新制定新的实时数据库数据采集协议标准，是有非常大的参考价值的。

从以上分析，可以得到可能的问题一：制定完整的、大家都能接受的实时数据库数据采集协议，需要考虑的内容很多很多。

邹骁同学也可能会对该通讯协议的很多设计方面进行简化，以便能够尽快地拿出协议标准草案，以供大家讨论。不过，这种简化的版本，在功能上与其它厂家要求的差别到底有多大呢？

比如说，XX系统定义了5种特定的点类型，包括其独特的虚位号，问题是，其它实时数据库厂家一定也要使用虚位号的概念吗？再比如，XX系统的测点系统没有层次的测点树结构，如果别的厂家支持测点树结构，该如何取舍？

以上这些功能点，与系统的对外接口的关系更密切一些，但是，与数据采集接口的关系也是比较密切的，数据采集接口是需要考虑这些功能点的。

每个实时数据库厂家都在设计实时数据库时，定义了一套完备的系统内部功能体系，并针对这套功能体系进行了接口标准化工作，只是，这些标准化的工作只是针对该系统。举例说明：PI定义了一套自定义的功能体系，也针对该体系提供了采集接口开发包，如果国内、国外所有的实时数据库厂家都遵守PI的采集接口开发包编写程序，该接口便可以认为是接口标准。只是，这样的接口标准，必须在功能逻辑上满足PI的逻辑，是其它厂家在功能上妥协的结果。

从以上分析，可以得到可能的问题二：接口是系统功能的体现，如果不能定义出权威的系统功能，便很难定义出标准的通讯接口，目前实时数据库的系统功能并没有权威和标准，便匆忙推动接口标准化，其它厂家不可能接受。

即便该接口得到了国内实时数据库厂家的认可，那么，推行该接口的受益者是谁呢？

下回再写......

此实时数据库非彼实时数据库

Linkman的学习记录 — Thu, 08 Nov 2007 12:24:00 GMT

至从写下《实时数据库领域中有关数据压缩的认识误区》之后，有一位名为nsis的前辈发表了一些评论，内容如下：

"用关系数据库保存10000个每秒钟变化一次的双精度数"这个命题就是可笑的!如果"用关系数据库保存10000个每毫秒钟变化一次的双精度数"不是更费盘了吗?奉劝作者将精力放在工程上吧,别搞这些毫无意义的"理论"了!我们的实时数据库运行十几年了，从来就不需要数据压缩。希望从洋人的理论怪圈走出来吧。实时数据库的工程问题要解决的问题多得很,比"数据压缩"难得多!

作者关于什么是"实时数据库"都没有搞懂,还在讨论什么数据压缩!实际上,如果不是为了存储历史数据，我们的实时数据库根本就不需要磁盘就能运行！请Linkman先生先搞请实时数据和历史数据的区别，实时数据库和历史数据库的区别，实时数据库和关系数据库的区别，再讨论问题吧！

又一个可笑的命题"数据的高压缩率意味着整个系统的数据处理速度更快"空间和时间是计算机技术的基本矛盾,一个算法不可能既减少计算又节省空间,数据压缩可能节省空间,但是数据压缩肯定要反压缩,怎么可能比不压缩还要"数据处理速度更快"呢?我们是买不到12922G的盘,但是我们没有数据压缩,600G的盘够我们存20年的历史数据.就算存在磁盘的数据是被压缩的,这种数据是不能直接给人看的，必须反压缩后给人看，反压缩后的数据仍然是大量的，多做了数据处理的工作,怎么会“系统的数据处理速度更快”呢？

这种文章不值得评论,这是本人最后一次"评论"!

为什么nsis前辈的评价与我的结论会有如此大的差别呢？我认真地查看了nsis发布的一些文章，终于明白了原因所在，大家如果对NSIS的文章感兴趣，可以在白度上以“nsis”和“实时信息系统”为关键字搜索一下。

最关键的原因是：nsis前辈所说的实时数据库与我所说的实时数据库，不是同一个概念。

我在《数据库、实时数据库的分类和厂家列表》一文中曾提到，实时数据库可以细分为以下几类：

l 实时数据库

n 硬实时数据库；

n 固实时数据库；

n 软实时数据库

u 处理型软实时数据库；产品特征：

l 需要及时处理采集输入数据，针对输入数据及时运算及输出；

l 对历史数据的使用，只限于报表、查询等简单应用；

l 实时数据的关系相对复杂；

l 数据库作为其它系统的一部分存在；

u 统计型软实时数据库；产品特征：

l 一般不参与控制输出；

l 对历史数据的应用是系统的主要功能；

l 实时数据的结构简单；

l 数据库系统具有较强的独立性；

同时也提到，目前在国内提到实时数据库，大都是特指统计型软实时数据库，这已是一个约定俗成的称呼，包括我们公司开发的实时数据库产品。这类实时数据库产品，对历史数据的处理与实时数据同等重要，或更加重要，而nsis前辈所说的实时数据库，则不包括历史数据处理部分。

这也给我们在国内推广实时数据库应用的同仁们提了一个醒，即便专业得如nsis前辈的人，都会质疑实时数据库是否应该包括历史数据处理部分，何况普通的用户？我们该如何更准确地表达实时数据库概念？

与统计型软实时数据库概念相近的，还包括如下类型的数据库：

硬实时数据库；
固实时数据库；
处理型软实时数据库；
内存实时数据库；
嵌入式实时数据库；
内嵌式数据库；

我们是否应该明确地将这些数据库类型区别开来，为每种类型的数据库取一个与其它类型明显不同不会产生二义性的名称？请大家发布高见。

nsis前辈在电力行业工作多年，又在石化行业工作多年，希望他所主持开发的nsis实时信息系统能越做越好，也希望nsis前辈多发表意见，不要“这种文章不值得评论,这是本人最后一次"评论"”。

最后，我想就nsis前辈评论中特别指出的两个命题进行一些补充说明。

命题一：“用关系数据库保存10000个每秒钟变化一次的双精度数”。

nsis前辈开发的系统由于市场定位的关系，没有遇到需要考虑超过10000个每秒钟变化一次的测点的需求，而在很多流程行业的企业级实时数据库的应用中，这种需求是真实而普遍地存在的，如SIS系统等。

在流程行业，生产企业的基础控制领域的自动化程度已经得到极大的提高，在设备及车间一级，FCS、DCS、PLC、智能仪表、现场总线等已到普及，在全厂进行厂级生产数据的综合处理，在实时生产数据及历史分析数据的基础之上进行企业的经营管理和决策，已成为流程行业企业信息化的发展热点。

在企业经营管理活动中，从厂级到现场级，对生产数据的实时性要求是成反比关系的，越是到现场级，对生产数据的实时性要求越低，而越是到厂级，对实时数据的要求越低而对历史数据的要求越高。一个厂长，不会成天盯着每个设备的具体运行参数，他只关心一些关键的实时信息，以及关键的统计数据。

要提高企业的宏观经营决策能力，除了能够对实时数据产生统计报表之外，还需要对历史数据进行数据挖掘和分析手段，这正是流程行业统计型实时数据库的存在价值和意义。

刚才讲的都是理论，我就讲实时数据库的一个实际应用例子吧。在某火电厂，机组容量6*300MW，总点数8万点，厂家要求，能将将这些机组的运行数据，以最小为1秒，大为10秒的间隔，全部保存起来，要求最长保存时间为4年。

命题二：“数据的高压缩率意味着整个系统的数据处理速度更快”

如果所有的处理全部在内存中，这个命题确定不正确，但如果数据要存放于硬盘，或传输于网络，这个命题就是正确的。

在计算机中，CPU的速度最快，内存次之，硬盘再次之，网络最慢，它们速度的差别是以量级来论的。流程行业的统计型数据库，性能瓶颈主要在网络和硬盘，减少数据在网络和硬盘中的尺寸，便能提高读写时间，便能保证整个系统的处理速度更快。

实时数据库领域中有关数据压缩的认识误区

Linkman的学习记录 — Mon, 05 Nov 2007 14:45:00 GMT

2007年10月28日晚上，我挖了一个坑，那篇“关于实时数据库接口标准的讨论”，只写了第一部分，到现在还没有填上。工作忙是一个原因，我只能利用晚上22:00至23:00这一段时间写一些东西，另外一个更重要的原因是：我还在为该文章备课呢，请大家再等一段时间吧。

今天咱另换一个话题，谈谈在实时数据库领域中，有关数据压缩的一些认识误区。

我曾答应liyaoer123（实时数据库阵地的博主）同学，与他讨论一下数据压缩技术。另外，我经常收到一些朋友的来信，他们对实时数据库及数据压缩的认识有一些误区，今天，我便收到三封讨论实时数据库的邮件。

数据压缩是实时数据库中一个很重要的概念和技术，只要接触过实时数据库，都应该听说过数据压缩。同时，很多人对实时数据库中数据压缩存在误解，我们就一条一条地解说吧。

1.实时数据库中的数据压缩技术很高深很神秘。

现在的数据压缩理论和技术已经很成熟，大家可以看看我转摘的博文《数据压缩技术简史》，该文章浅显易懂，是一篇很好的关于数据压缩的科普文章。

在不同的应用领域，又可以针对不同的数据应用特征，引用不同的数据压缩技术，比如，图形处理领域的JEPG压缩技术，声音处理中的MP3压缩技术等。在流程工业行业中，工业实时数据也有一定的变化规律，可以针对这些规律，研究特定的数据压缩算法。

下面是工业实时数据的一些特征：

工业实时数据的数据变化具有一定波形规律；
工业实时数据中只有一小部分测点的值经常发生改变；
工业实时数据中很多测点的数值都具有慢变化的特征；
数值变化与时间变化具有共同变化特性；
用户在一定范围内，能够允许数据的精度损失；

在工业应用领域中，常用的压缩算法分为三类：

无损压缩；
有损压缩；
二级压缩；

其中，无损压缩一般以通用压缩理论为基础，采取哈佛曼算法等经典的压缩算法；而有损压缩而更多地考虑了工业实时数据的特征，而采取的一些特殊舍点算法；二级压缩技术，则是同时利用了这两种数据压缩技术。

实时数据库的无损压缩以通用压缩理论为基础，随便找一本大学教材就能看懂，在此不再多说。

目前比较著名的有损压缩算法,有PI中使用的旋转门压缩算法，IH中使用的死区压缩算法，以及一些变通压缩算法（如在旋转门算法基础上改用二次均方差作为偏差比较，以提高数据还原精度），这些算法原理都比较简单。网上有很多相关的文章，我在前几篇文章中提到的变化压缩算法，是死区压缩算法的简化变种，而liyaoer123同学在他的博客上帖出了osisoft关于旋转门压缩的技术文章，大家有兴趣可以去看看。

总而言之，实时数据库的压缩算法真的不难理解，只是实时数据库重多技术中的一种而已。

2.只要搞清楚数据压缩算法，就能编写好的实时数据库了。

这个问题要从两方面来分析。

首先要说明，数据压缩只是实时数据库中一个技术点，这个技术点相对于实时数据库其它技术点而言，难度和工作量是非常小的，我在《实时数据库的理论与技术》中，列出了实时数据库需关心的技术点，大家可以看看。只搞清数据压缩算法，是不能编写良好的实时数据库的。

另一个方面，只从数据压缩这个角度来看，只考虑算法也是不行的。

在实时数据库的数据压缩模块中，除了要考虑压缩算法之外，还要考虑以下内容：

变量ID、时间戳、质量戳、值四个字段在压缩算法中的数据组织，包括逻辑组织和空间组织；
压缩算法与内存缓冲区的配合；
压缩算法与磁盘文件的配合；
特殊情况的数据处理，如，启动、停止、备份、恢复等时的数据压缩状态。

3.实时数据库中，数据压缩的压缩率越高越好。

刚才提到，实时数据库中的数据压缩算法都是非常简单，这是由实时数据库的应用特点决定的。

要考虑一个实时数据库的数据压缩技术技术，需要从以下几方面考虑：

数据压缩率；
压缩数据的检索和定位速度；
数据压缩时间；
数据解压时间；
压缩数据在内存和磁盘的组织结构，以便更方便地利用内存和磁盘的特性；
数据解压后的还原精度；

数据压缩率只是其中一个指标，实时数据库追求的是综合性能指标，不能只看某一项指标。

从某个角度而言，在实时数据库的应用中，数据的压缩和解压时间的指标，要优先于数据压缩率指标。但是，在设计良好的系统中，这两个指标之间并不矛盾。

4.无损压缩比有损压缩要好

在两个洋品牌PI和eDNA之间，经常会就无损压缩和有损压缩哪个更好这个问题产生争执。

基本上，在此争执中，eDNA的无损压缩处于攻势，而PI则见招折招处处守势。总的来说，eDNA的市场宣传做得很不错，很多用户都是这样评价：eDNA比PI相比有很多优点，它采用了无损压缩技术，还有......，而且，它的价格比PI便宜多了。

客观地讲，无损压缩有其好处，它在某些方面保证了数据的精度，但是，这并不能说，无损压缩一定比有损压缩好。

采用无损压缩算法的实时数据库厂家，不能回避以下两个问题：

采用无损压缩算法的压缩率比采用有损压缩算法要低得多，针对工业实时数据的特征信息提取的无损压缩，是不可能达到10:1的。

采用无损压缩算法的实时数据库，单机总处理点数会存在性能瓶颈，以目前主流的计算机而言，采用无损压缩算法的实时数据库，平均只能处理2万左右的历史点。

另外，无损压缩所宣称的100%保持数据不丢失，只是一句话宣传词，在计算机上处理工业实时数据，本身就存在大量的数据信息丢失：

数据采集传感器存在采集误差；
数据采集是实时数据趋势变化的采样和数字化的过程，采集周期之间的特征波型已经丢失；
计算机处理和网络传输造成的延时和不确定，也会造成采集波型的失真；
传感器和计算机的数据类型字节限制，也会造成数据的失真。

在存在多处无法控制的失真环节的情况下，只强调保存数据的完全不失真，是没有意义的，只是商务宣传的需要，只要是数字化和计算机化处理，所有的数据就是近似的处理过程。

有人会说，这也失真、那也失真，还处理个屁呀。这其实是一种处女情结，是在无意义地追求某个特定的指标而不考虑系统整体性能。如果实时数据库在采用无损压缩的同时，还能保证很快的解压缩速度和较高的压缩率，当然无可厚非，但目前的理论和技术条件下，这些指标是矛盾的。而采取有损压缩技术，是在不影响整体精度情况下的性能指标的综合平衡。

5.实时数据库中，数据压缩不重要，要不要数据压缩没关系。

关于这一论点，有两种不同的观点。

第一种观点认为，现在的计算机硬盘很便宜了，磁盘容量不够，大不了多买几块磁盘。

第二种观点认为，实时数据库的重点是上层功能和应用，在工业应用中，数据压缩费力又不讨好，还不如将精力放在其它功能上。

这两种观点都不正确，实时数据库的市场存在意义，是因为现在的其它数据库产品，不能地处理大量工业实时和历史数据。这里说不能处理，包括处理速度和磁盘容量。

在我的文章《实时数据库历史数据容量的计算方法》中计算得出，用关系数据库保存10000个每秒钟变化一次的双精度数，同时建立一个索引，保存一年需要磁盘空间为：12922G，而用实时数据库保存，则只需103G，大家可以换算一下，12922G，需要多少块磁盘？

磁盘容量只是问题的一个方面，另一方面，数据的高压缩率意味着整个系统的数据处理速度更快，这体现在三个方面：高压缩率的数据，占用磁盘空间小，将数据从磁盘读入内存的速度快，网络传输的速度快，数据在内存中占用的空间小。而这三个因素，是实时数据库提高系统整体运行速度很重要的几个因素。

一个良好的实时数据库，必须要处理好实时压缩问题，只有处理好数据压缩问题，才能使系统的整体性能达到某个可用性指标。

以下有一个对是否选用实时数据库和数据压缩技术的简单判断：

关系数据库只能处理5000点每秒变化的工业实时数据，在此范围内，可以不考虑选用实时数据库。
在5000点至10000点的系统内，需要抛开关系数据库，重新设计自己的数据存贮系统，但是，在这个领域，是不太需要考虑数据压缩技术的。
当系统的历史点数在10000点以上时，必须要考虑数据压缩技术和专门的实时数据库了。

很多朋友告诉我，他们的系统不采用数据压缩技术，他们也不关心数据压缩技术，他们认为，良好的上层应用软件比数据压缩更重要。我要对他们说：不同的行业，不同的系统规模，对实时数据库的性能指标要求是不一样的。实时数据库系统是一个综合性的应用系统，设计良好的底层模块是其它模块良好运行的基础，数据压缩技术与其它数据库技术一起，对整个系统的运行提供了很底层但很重要的环境，大型实时数据库系统中，数据压缩技术是必须考虑的，另一方面，实时数据库中，数据压缩技术只是实时数据库系统中一个重要的技术点，但不是全部。

linkman 2007-11-05 22:44 发表评论

发一个招聘软件开发人员的帖子

Linkman的学习记录 — Sat, 03 Nov 2007 02:58:00 GMT

又到年底了，员工和学生忙找工作，发一个招聘帖，以求志同道合者。

我们需要三类人：

1、系统架构师；

要求：

A、3年以上工作经验；

B、熟悉C\C++\VC语言；

C、熟悉软件架构、设计模式、重构理论；

D、熟悉数据结构；

扩展知识点（不一定要掌握，列出来，只是让有兴趣者参考）：

A、ACE及网络编程；

B、LIUNX及跨平台软件开发；

C、数据库理论；

D、流程工业信息化；

E、实时数据库及应用；

F、项目管理理论；

2、编程人员；

A、熟悉C\C++\VC语言；

B、熟悉数据结构；

3、实习学生；

A、大四学生，或研三学生；

B、有C\C++\VC语言等基础；

C、熟悉数据结构；

D、毕业后有兴趣留在我公司发展；

有意者请与我联系。

主力博客：http://linkman.gkbk.com可以了解更多行业相关信息
MSN：LiaoChangBin@hotmail.com
E-Mail：Linkman2002@sina.com.cn

关于实时数据库接口标准的讨论[上]

Linkman的学习记录 — Mon, 29 Oct 2007 12:34:00 GMT

邹骁同学是实时数据库行业的大名人，策划成立实时数据库行业协会，便是该同学的大手笔，他告诉我，实时数据库行业协会成立后的第一年，将主抓以下四件事：

1、建立协会网站，统一宣传；
2、共同参加展会及合动；
3、共享行业信息；
4、建立接口标准；

2007年6月24日协会筹备会召开之后，邹骁同学一直特别地忙，我与他沟通的次数也只有不多的几次，作为将推进国产实时数据库发展为己任的我，每次与他沟通时，都不忘提到：接口标准的工作进展如何？能不能将接口标准的初稿让我看看？要不要我帮你参谋参谋？

我这样直接地提出这些问题，一方面，是真心地希望能为国产实时数据库的发展尽自己一份微薄之力，另一方面，是我暗暗地为邹骁同学的工作表示担心，却又怀疑自己杞人忧天，便希望在看到一些实在的东西后，再下结论。

到目前为止，我尚未得到这些接口标准的相关文档，也未能了解这些接口的具体细节，却希望自己能做一些有意义的事情，对邹骁同学在推进相关工作时提供一些参考，也期望对那些愿意了解实时数据库的同学们提供帮助。因此，我还是早一点将自己对实时数据库接口标准的想法写出来，抛砖以引玉。

到目前为止，邹骁同学在实时数据库接口标准方面的观点不是很明确，我能够得到的文章主要有以下几篇：

《OPC——资本和崇洋豢养的病态协议》
《工业以太网技术有望统一现场总线》
《深入浅出实时数据库》

他对实时数据库接口标准的观点，归纳起来有以下几条：

1、由于历史遗留或人为垄断等原因，目前在实时数据库接口及通讯协议方面，种类繁多，没有统一的标准；
2、目前的接口及通讯协议具有上层开放、下层封闭的特点；
3、OPC具有许多缺点，不适合作为实时数据库的接口和通讯协议标准；
4、如果底层协议不统一，实时数据库的市场将继续存在混乱和低速发展；

由以上观点，可以很自然地引申出如下结论：目前，在实时数据库行业，国内的实时数据库厂家，应该联合起来，一起来制定接口标准。

这确实大快人心，令人鼓舞。如果我是实时数据库的使用者，我会高兴地说：好，很好，非常好，你们快行动吧！

当第一次看到《OPC——资本和崇洋豢养的病态协议》时，我也是兴奋异常、浑身舒畅，当晚连喝了两大瓶啤酒。但是，当第二天酒醒后，我冷静了，仔细思考后，我便认定，这只是邹骁同学的一时兴起，即兴之言。

从一个命题的完整性而言，需要考虑如下因素：

1、实时数据库接口的封闭性和不统一的现状如何？
2、这种封闭性和不统一对实时数据库发展有哪些影响？
3、实现实时数据库的接口标准化，技术上有哪些难点和重点？
4、实现实时数据库的接口标准化，市场上有哪些难点和重点？
5、目前实现实时数据库的接口标准化的时机是否成熟？
6、国内实时数据库厂家，目前是否有能力推动实时数据库接口的标准化？

我们接下来，就这几方面的内容，一一讨论。

1、实时数据库接口的封闭性和不统一的现状如何？

实时数据库的典型结构如上图所示，实时数据库的接口类型，包括以下三种，这三种接口类型功能不同，对标准化需求的迫切性不同，标准化所需要作的工作也不同相。

①、数据采集接口；
②、内部模块数据交换接口；
③、对外数据接口；

那么，邹骁同学提到的接口，具体是指哪一种呢？我个人的理解，他提到的接口，应该是对外数据接口，但是，他在某些描述语言中，也包含了数据采集接口。我们就将这三种接口的现状都讨论一下。

又到了23:30，下次再写吧，待续......

关于变化压缩算法的展开讨论[下]

Linkman的学习记录 — Mon, 29 Oct 2007 12:34:00 GMT

首先，让我们热烈祝贺嫦娥一号卫星发射成功！它标志着一个新时代的开始。

上篇文章中提到的“变化压缩算法”是一种非常简单的算法，但其中隐含了实时数据库理论中的数据采集、分析、处理的完整内容，通过对该算法的理论分析，有助于大家更好地理解实时数据库。因此，我便将对实时数据库科普之旅的起点，设定在对“变化压缩算法”的理论分析。

针对上篇文章中留下的课外作业，peter wu同学提交了他的答案，让我们对peter wu同学勤学好问的精神表示鼓励。

他的答案是：

“第一种只记录了数据变化的时间点，对只关心数据发生变化的应用有用，例如客户端要对某个数字量变化采取一定措施。优点是数据量小，缺点是用这种数据画出来的历史曲线不符合真实情况。”

对该答案，我要说的是：基本正确，不太准确。

该答案中提到，用第一种方案中的数据画出来的曲线不符合真实情况。我们要特别问一句：什么叫真实情况？

让我们再看一下原始数据的那个图，上面有几个点，还有由这些点连接起来的几条折线。问题是，这几条折线是真实情况吗？

(此类情况适合第二种方案)

比如，下面这个图，是不是一种可能的真实情况？

(此类情况适合第一种方案，世纪应用中，有此种曲线吗？)

再比如，下面这个图呢？

(此类也情况适合第一种方案，用于说明采集精度)

这些，说明了什么呢？

这需要讨论一下数据采集及数据拟合的理论，邹骁同学在他的文章《深入浅出实时数据库》对数据采集有较准确地描述，我就不再多费口舌，直接摘抄过来：

“......大家都知道采样定理，根据拉普拉斯变换，任何信号都可以被分解为频率不同、幅值不同的正弦波叠加，而如果要让采到的数据中包含一个频率的信息，则采样频率至少为此频率的2倍。......实时数据库中存储的数据永远是滤波后数据，实时数据库就像一个低通滤波器......”

上面这段话比较专业，如果转换为大白话，意思就是：

1、采集后的数据，只是对原始数据的近似表示；
2、为了提高采集精确度，需要提高采集频率；

还是回到两种“变化压缩算法”取点方案的异同这个问题上来。

上面的第一张图和第二图已经对此问题作了提示。这两种方案分别对应两种不同的原始数据曲线，应用在不同的领域。

第一种方案，主要应用在以下两种场合：

1、数据一变化即需通知客户端处理的数据服务器，如OPC Server、历史数据库的实时数据发布等。大家注意该图中几个直角，那便是变化的时间，也是需通知客户端处理的时间，在此方案中，隐含了数据的订阅和通知机制。
2、数据是跳变的，不是连续变化的，如开关量、整型数等；

第二种方案，则应用于数据采集程序向主程序传送数据的应用场合，这个大家都应该能理解。

当然，上面第一种方案中的第二种情况，也可以以第二种方案近似处理。

我就“变化压缩算法”罗嗦了这么多，是因为某些软件中，在数据采集程序中用错了方案，这一般在那些支持客户端数据压缩的监控系统或实时数据库系统中存在。

那么，如果选择第二种方案，如何实时地、正确地处理拐点呢？

大家不要想当然，仔细想一下，作为采集程序，如何才知道某时间是最后未变化的呢？

有五种解决方案：

1、客户端（数据采集端）不考虑压缩，将所有采集到的数据传送到服务器端（主程序端）。
2、客户端提供带时间戳的数据传送机制，当检测到数据已变化，则需要先将上一次采集数据加上时标传送到主程序，再传送新数据；
3、客户端采用变化才传送的逻辑（第一种方案），在服务器端进行周期处理逻辑（即在服务器端又增加一次虚拟的数据采集）；
4、客户端采用变化才传送的逻辑（第一种方案），在服务器端设置一个最大采集周期时间，对超过最大采集周期时间的数据自动增加拐点。
5、客户端采用变化才传送的逻辑（第一种方案），服务器端也不作任何特殊处理，容许此种丢失拐点问题的存在；

这五种方案各有优缺点，具体选用哪一种方案，需要综合决定。对这五种方案的取舍，涉及到实时数据库内核模块的IO框架的设计，不知有没有人感兴趣，先不展开吧，如果有人感兴趣，我再展开讲讲。

关于“变化压缩算法”的一些知识，就介绍到这里，如果各位同学有什么不同的意见，欢迎提问。在下一篇文章中，我想与邹骁同学就实时数据库中统一数据接口的问题进行一些探讨，敬请期待。

关于变化压缩算法的展开讨论[上]

Linkman的学习记录 — Mon, 29 Oct 2007 12:34:00 GMT

我在文章《关于实时数据库开发人员的面试题》提到，死区压缩的算法原理是：一段按时间顺序从小到大排列的数据，只有前后数据变化的绝对值超过常量COMPRESS_RATE才被保存，这个死区压缩的算法原理应该非常简单，我们就从这里开始，展开一些纯理论的讨论吧。

如果常量COMPRESS_RATE非常小，比如，COMPRESS_RATE是0.000001，则形成了新的压缩算法：变化压缩算法，变化压缩算法的基本思想是，数据只在变化时才被处理，这个处理的范围非常广，可以是压缩、传输、条件触发等等。

变化压缩算法更加简单，但在工业现场经常用到，它的存在价值是基于流程行业的以下三个方面的特点：

1、在工业现场，有相关一部分数据，在一定时间范围之内数据值不会发生变化；
2、在一定周期内，不是所有的数据都会产生变化；
3、在工业现场，有相关一部分数据，如开关量，或整型变量（如有载调压装置的档位等），它们的值变化是跳变，而不是连续变化的；

一般情况下，可以在以下几个地方采用变化压缩算法：

1、数据采集程序，只在数据变化时，才将数据传往主程序（比如传入实时数据库）；
2、网络通讯程序，只在数据变化时，才将数据发送给网络通讯部分；
3、实时数据库内核，只在数据变化时，才通知客户端进行处理；
4、......

这些地方采用变化压缩算法，都是基于这种思路：采用一种简单的算法，以便获得以下效果：

1、减少数据处理量；
2、减少网络传输量；
3、提高数据访问速度（客户端不需要循环处理所有的变化，只需要处理变化的数据，以事件处理的逻辑替代循环处理逻辑）；
4、......

因此，变化压缩算法在工业监控软件中，是一项应用得非常广泛的技术，当然，平常的软件中，没有专门提出这一概念，而且，变化压缩算法通常是与其它概念一并出现的：

1、事件订阅和事件通知：只要数据变化时，才向关心此变化的客户端发布变化通知；
2、本地缓存或本地映射：数据表在本地有一个完整的映射，平常用户访问该映射表，变化通知后更改部分数据；
3、网络发布机制：与事件通知的逻辑差不多，只是需要跨网络，有时还需要跨操作系统；

我们今天不讨论变化压缩算法的更复杂的内容，只讨论一个在变化压缩算法中容易忽视的一个细节。

让我们以一些实际数据为例来进行说明，假设有一段数据（以下说明中，都省略了时间项）：0，10，10，10，10，20，如果采用变化压缩算法处理，该处理哪几点数据？

有两个方案：

第一种方案：0，10，20；

第二种方案：0，10，10，20；（我们就将第二个10称为拐点吧）

大家都会认为，第二种方案是合理的，它真实地纪录了数据变化的特征值，但是，我们会问如下一些问题：

1、我们在实际处理过程中，有没有选用第一种方案的？
2、第一种方案在哪些情况下使用？
3、第一种方案会带来什么好处，会带来什么副作用？
4、如果解决这些副作用？
5、如果选择第二种方案，如何实时地、正确地处理拐点？

一晃又到晚上23:00了，先写到这儿吧，希望明天有时间将后续的内容写完。我已有好几篇文章写了待续却没有继续下去，总而言之，还是人懒呀。

待续......

实时数据库与关系数据库的混合使用

Linkman的学习记录 — Wed, 29 Aug 2007 00:35:00 GMT

在向客户解释什么是实时数据库时，我喜欢以这句话开头：实时数据库也是一种特殊的数据库，但它与关系数据库相比，有什么什么不同，所以在工业企业中，很多场合只能选用实时数据库......

这么说有其道理，一般的用户都熟悉关系数据库，对关系数据库的特性也非常清楚，知道了哪些事情关系数据库干不了，就明确了实时数据库能干什么事情。但这样一来，将实时数据库与关系数据库对立了起来，似乎两者是非A即B的关系。

实际上，实时数据库与关系数据库并不是对立的关系，在很多场合，他们是可以混合使用的。

上一周，遇见一个客户，他们是做充电实验系统的，需要对300个充电机、1000个电池箱进行监控和管理，每个电池箱有50个需要监控的变量，系统所要监控的总变量有50000个。

该项目使用实时数据库是非常合适的，理由不再多说，请参见我的文章《实时数据库简介》、《实时数据库历史数据容量的计算方法》以及《实时数据库与组态软件的市场定位之异同》。

但是，该项目是一个典型的间歇过程控制系统，如何记录每次充电实验的开始时间和结束时间，并方便地查询每次实验的开始时间和结束时间，采用实时数据库表处理不是非常方便。最后我们建议用户选用实时数据库和关系数据库混合使用的方案。

我们提出此方案的过程是几经反复的：最开始，我们使用用组态软件方案，但发现需保存的历史点数量太多；后来，又使用实时数据库方案，但发现不能很好地记录每次充电实验的开始时间和结束时间；再后来，又使用纯关系数据库方案，但又发现保存一年的历史数据需要的磁盘空间根本不够；最后选用了实时数据库和关系数据库的混合方案，当选择了实时数据库和关系数据库的混合方案后，才发现，这个方案是多么的简洁和美妙。

当天晚上，便有想将这个决策过程中的一些心得写下来的冲动。当冷处理了几天之后，想法更多了。

实时数据库在国内的应用，是在工业企业信息化过程中，随着关系数据库应用的局限性不断被发现的过程中，逐步使用和被用户认可的。与关系数据库相比，在工业企业中，生产数据的描述相对简单，但其点数非常多，对实时和历史数据的处理远远超过了关系数据库的处理能力。而实时数据库在快速处理简单生产数据及其产生的海量历史数据等方面，具有极大的优势。

实时数据库为什么能实现关系数据库不能实现的功能和性能呢？主要原因是，实时数据库将数据库的应用领域缩少了，针对这个缩少的应用领域，它可以将数据库理论中的部分功能弱化而将部分功能强化。例如，它弱化了表之间的关系描述；弱化了ACID原则，ACID是 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）和 Durability（持久性）的简称；弱化了数据库理论中的事务处理逻辑；它可以允许在一定精度范围内的数据失真。等等。实时数据库弱化这些功能，用以实现高效的数据插入和查询功能，以及较高的压缩比。

实时数据库弱化了数据库的某些功能，带来了很多好处，所以能够形成新的市场，但是，在很多应用领域中，用户发现，某项目单独使用实数据库不行，单独使用关系数据库也不行。针对这个问题，我们可以引伸思考以下四个问题：

1、能不能对项目的功能进行取舍，某些指标进行降低，而实现一个不能达到完美效果但能解决用户问题的方案？
2、能不能还是只选用其中一个产品，而采取一些变通办法来完成整个项目？
3、能不能将两者混合，发挥两者的优势，共同完成项目？
4、能不能扩展关系数据库和实时数据库的某些功能？形成针对该项目该应用该行业的新的数据库系统？

以上四个问题很是有趣，我这几天一直在考虑这几个问题，最后发现，这些问题可以上升到逻辑高度呢。

前三个问题，主要是项目经理该考虑的；后两个问题，则是产品开发商该认真考虑的。作为以实时数据库事业为已任的开发者，我的思考重点是后两个问题。

关于第3个问题，我有这样一些想法：

实时数据库的产生，其目标是为了解决关系数据库不能解决的问题，但是，实际的应用，并不那么单纯。比如，企业信息化领域中，需要打通现场生产数据与企业经营管理之间的鸿沟，现在管控一体化的思想和MES（制造执行系统）大行其道，其目的即是如此。但是，不管是管控一体化，还是MES，都在监控和数据平台这些基本功能之上，增加了管理相关的功能，这些需求是真实存在的，也是实时数据库产品开发商不能回避的问题。最终的权衡的结果，是关系数据库和实时数据库并存，各自完成自身特定的功能，并且彼此进行数据交换，这是关系数据库与实时数据库混合使用存在的原因。

作为实时数据库产品开发者，需要考虑：能不能提供一种与关系数据库并存的解决方案，将实时数据库集成到整个企业信息化领域中；能不能提供一个能很方便地共同使用关系数据库和实时数据库的应用软件；能不能提供一个提供整体数据的数据平台。

数据平台是一个很重要的概念，对于用户而言，他为什么要关心不同数据库之间的异同，为什么要看到两套不同的数据呢？数据就是数据，仅此而已。

这是问题的所在，也是商机的所在！可以给用户提供一个工业企业的数据平台，不管这些数据是从关系数据库中来，还是从实时数据库中来。这个工作，实时数据库提供商可以做，有一定开发经验的系统集成商也可以做（想好了，明天给我原来呆的湖南那家公司打电话，建议他们考虑在他们的电厂信息化产品套件中使用我们的实时数据库，他们可以向用户提供电厂生产数据平台，这是一个新的可以卖钱的产品呀。）

关于第4个问题，我有这样一些想法：

实时数据库不能满足用户项目的需求，这本身说明，我们所设计的实时数据库在功能上有可能进行某些扩展，如果扩展后，我们即能保持实时数据库的特点，又能满足某具体行业的需求，这不就是行业实时数据库吗？如果我们再扩展一点，可不可以发展一个新的数据库系统呢？

关系数据库是经典的数据库，现在，新的数据库越来越多，详见《实时数据库理论与技术演讲PPT》，如果某些行业的应用具有通用性，为什么不能设计一个新的数据库系统呢？

当然，新的数据库系统的应用领域肯定比标准实时数据库的应用领域要小，但是，随便哪个一个行业，不足够我们发展好一阵了？电力、交通、仿真、优化控制......呵呵，越想口水越多。

这些想法有点远了，但有一个现实的问题：现在的实时数据库，一般都是指流程行业历史型实时数据库，这是由于流程行业历史型实时数据库有其具体特点，也见《实时数据库理论与技术演讲PPT》，但是，我想到了一个新的应用领域，它所使用的实时数据库与我们的实时数据库有功能上有区别，有其特定的问题域和功能域，是一个非常大的市场，我们完全可以做这样的产品，先不说，卖个关子，聪明的你，知道我想说什么吗？

国产实时数据库的发展前途

Linkman的学习记录 — Wed, 29 Aug 2007 00:35:00 GMT

很多关心实时数据库发展的朋友都会问：实时数据库市场到底如何？国产实时数据库有没有发展前途？

我的一个高中老师教导我们：历史的经验值得总结。

在回答这个问题之前，如果分析一下相关产业的发展道路，并从中归纳出放之四海皆真理的方法论，用它来分析国产实时数据库的发展，应该有很好的参考作用。

改革初期，在全国形成这样一个局面：全国人民学广东，广东人员学深圳，深圳人民学香港。很多新的潮流，都是从香港到广东，再流行至全国。要判断国内未来一年会流行什么东西，只需要看看现在广东流行什么，就很清楚了。

要分析国产实时数据库的发展方向，可以将实时数据库相关的几个产业进行分析，可选择的产业有：关系数据库、工控组态软件、厂级监控系统（SIS）。这三个产业的发展道路有类似之处，也有不同之处，正需要我们对之进行分析、归纳和总结。

先分析一下关系数据库的发展道路。关系数据库的理论从1960年代便建立了，在1980年代开始出现商业化的产品，1990年代有超过10几家的国外数据库厂家互相竞争，进入2000之后，便形成SqlServer和Oracle的垄断地位，其它数据库的市场份额开始下降，但是，由关系数据库延伸的行业和产品越来越广，每个厂家又在这些延伸的行业内寻找新的金矿。而在这个过程中，国产关系数据库一直未能发展起来，只有几家科研单位开发出几套实验性的产品。

再分析一下工控组态软件的发展道路。工控组态软件最早在1980年代由Intouch推出，在1990年初，国内基本由两三家国外产品垄断，从1995年开始，国产工控组态软件开始产生，在2000年左右，国产工控组态软件开始与国外产品抗衡，到现在，国产组态软件在装机容量上已远远超过国外品牌的装机量，但在高端市场上，国外品牌仍牢牢地控制着局面，而在中低端市场上，国内前四名的产品已形成垄断之势。

最后分析一下厂级监控系统（SIS）的发展道路。SIS的概念是一个国产的概念，最早由侯子良教授在1997年提出，至今已有10年历史，在这10年内，一直由国产SIS产品高举大旗，而国外产品在经过将近5年的观望之后，于2003年左右也开始推出SIS系统。现在的市场，基本由国内产品把执，并已进入残酷地优胜劣汰和趋近垄断阶段，但在这场大战中，国外的实时数据库产品一直控制着SIS的核心价值点。

可进行类似分析的行业还有很多，如：DCS、PLC、SCADA、ERP、MES等。

通过以上分析，能得出什么结论呢？这是仁者见仁智者见智的问题，我个人的结论是：

1、每个行业的发展，都会经历从理论到产品再到竞争最后到垄断这四个发展阶段，随着计算机技术的发展和普及，这四个发展阶段有越来越短的趋势。

2、某个行业在国内发展，都有一个市场培育和进入时机的问题，当市场和产品发展到一定阶段，便会出现发展的井喷期。

3、技术含量越高、应用通用性越大的行业，国外品牌垄断的可能性越大，留给国内品牌发挥的空间越小，在定制化、本地化要求多的行业，则国内品牌完全可以与国外品牌竞争，甚至超越。换句话来说，就是国内品牌拼方案，国外品牌拼技术。

4、先行者未必能笑到最后，但先行者很可能是最后垄断者之一，不管是国内品牌，还是国外品牌，都是如此。

基于以上分析，我们可以比较清晰地分析出国产实时数据库的发展前途。

实时数据库的理论在1980年代便已出现，并在1980年代未开始出现初期产品，该行业的发展到目前已有30多年的历史。现在在中国已形成影响的国外产品有7、8家，形成影响的国内品牌也有7、8家。从整个行业的阶段分析，实时数据库行业已进入竞争期。

实时数据库主要应用于工控行业，也有应用在其它行业的。从目前的市场发展情况分析，已到了市场发展井喷的前期。原因如下：
1、设备自动化的成熟度已得到广泛认可，设备自动化的应用已深入各行各业，已完全取代常规控制市场；
2、企业信息化从1990年代在国内普及，ERP、CMIS等概念已有广泛影响，并有许多成功样例；
3、从设备自动化到企业信息化两方面的双重需求，当两者应用重叠度达到一定程度，必然迫使厂家和用户寻找新的信息化建设方案；
4、企业对厂级到车间级的生产信息管理有了比较明确的市场需求；
5、用户对实时数据库的概念的了解已比较详细，对实时数据库的功能和作用的知识也慢慢普及；

实时数据库在技术上有较大的门槛和壁垒，使得国外实时数据库进入国内之后，在长时间之内没有竞争对手。但由于互联网的发展、国内开发实时数据库的起点相比国外产品已无很大差距。即国产实时数据库在很大程度上可以与国外品牌拼技术。

实时数据库本身应用的特点决定了实时数据库的通用性被控制在某个范围之内：实时数据库的对外接口很难在短时间之内标准化和统一；行业应用过程中的需求的极大不同，导致每家产品都可以作出非常独特的功能；实时数据库本身不能单独使用，必须与方案和应用捆绑切售。

能在实时数据库行业分一杯羹的厂家，应该会从以下可能的厂家产生：DCS厂家、工控组态软件厂家、工业企业信息化厂家。其中，工业企业信息化厂家很难形成通用的实时数据库产品，他们的发展方向不同，即便有实时数据库产品，也只会将实时数据库产品定位为系统的一部分。而DCS厂家和工控组态软件厂家中却极有可能出现几个挑战国外品牌的英雄，这两类厂家各有所长也各有所短。也就是说，国产实时数据库厂家的发展道路是从下往上走的可能性大，而从上往下走的可能性小。

其它厂家，由于对应用需求把握能力的不足，或者对实时数据库行业判断的不准确，很难产生能很好发展的实时数据库厂家。

在发展过程中，一部分国产实时数据库厂家会将自己的产品定位为自身系统的一部分，如DCS厂家，这类厂家在实时数据库的通用性应用方面的作为不大；另一类厂家极有可能发展出通用实时数据库厂家，如工控组态软件厂家和行业SCADA厂家，但这些厂家自身能力的不足以及后期推广领域的受限，他们会自然地与企业信息化厂家结盟，以OEM或者集成的方式向这些厂家提供产品；还有一类厂家，做到一定程度后，会在某些行业深入，形成专做某些行业应用的整体方案提供商。

国内实时数据库行业的市场比DCS市场的规模要小，比组态软件的市场则要大得多，初步估计，应该在50亿至100亿之间，不管怎么说，这都是一个非常大的市场，未来几年，转身到该行业一试牛刀的厂家不会少于50家。由于现在该市场远未达到饱和的阶段，三年之内各厂家仍会相安无事。真正的竞争残酷期在三年之后，即2010-2012年，经过几年残酷的争夺和淘汰，在2012年左右，国内实时数据库将会形成垄断的局面。

总而言之，实时数据库在未来五年将有非常大的发展，整个产业的发展在5年后会形成垄断局面。同时，实时数据库的价格会降至30万至50万左右。那时，两三家国外品牌占有着20%左右的高端市场，四五家国内品牌占有着50%左右的中低端市场，剩下30%的市场则由一大批二、三流产品把执，但他们也未闲着，他们在努力地往上冲刺，同时又在寻找新的市场突破点。在2011年左右，实时数据库接口的标准化和功能的标准化将会由国外某非赢利组织制定，新标准又会导致新的竞争和厂家重排位，但那时，国产实时数据库已站得很稳了。

注：一家之言，不要拍我。