Linkman的学习记录

今天，你2.0了吗？

Linkman的学习记录 — Sat, 17 Nov 2007 05:10:00 GMT

2.0是个时髦的词，2.0是个火爆的词，2.0是一个普受关注而又备受争议的词。

WEB 2.0、.NET框架 2.0、ASP.NET 2.0、C# 2.0、企业开发库 2.0、通讯服务 2.0，......，各种2.0的专有名词层出不穷，令人目不暇接，在CSDN网站上就有一个专题：让我们一起来参加“2007年软件开发2.0大会”，讨论如何深入理解“软件2.0”的思想，熟悉“开发工具2.0”，进行“企业开发2.0”吧。

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

2.0本来只是一个普通的版本号，但现在，它已超越版本号的概念，与超女一样，成为流行、跟风、模仿、艳俗与浮燥的代名词。

国内厂商被国外的大公司诱奸，并成为他们强奸普通观众眼睛的帮凶，早已是司空见惯的事情。这一回，2.0来势凶凶，铺天盖地，本也是无可耐何的事情，毕竟，普通观众的眼睛在忍受被强奸的痛苦的同时，还可以痛并快乐着。

可恶的是，还有一批流氓，他们冒称自己是2.0，也有2.0的各种好处，跟在洋大人的后面，混淆视听，浑水摸鱼，顺手牵羊，强奸民意。

2.0是什么？不同的人有不同的解释，但从目前它被热炒的态势来看，它应该是指那些：与第一代产品（工具、方案、工程、思路、功能、概念等）相比，有明显的区别、突出的优点、全新的诠释、崭新的角度等特性的新一代产品。

在CSDN的网站上，对“软件2.0”这样评价：“软件2.0”是正在发生的技术革命，其意义远远大于任何一个单项的新技术和新方法。从长远来看，“软件2.0”将把人类的信息化带上一个全新的境界，从而强烈地塑造人类的文明进程。

不信？自己去看吧：http://www.sd2china.cn/

2.0是一场革命！会塑造人类的文明进程！这个牛皮吹得挺大的，但也说明一点，2.0这个专有名词隐含了如下的观点：2.0与1.0相比，那跨出的不只是一小步，那可是相~~当~~的大。

“WEB2.0”算不算2.0？“软件2.0”算不算2.0？这个只能靠每个人自己去判断它的正确性，但是不管怎么样，它们至少在概念、特性上有一些与第一代很不相同的东西，就算他是2.0吧，谁让它们本身就是这个版本号呢。

还有其它一些产品，版本已到了6.0、7.0，也在装嫩，也要号称自己是2.0，拜托，大家都是神仙，不要对我的眼睛进行性骚扰行吗？

更有甚者，看到2.0时髦了，便翻开自己的宣传手册，边看边在心里YY：我这个功能点，算不算2.0？

我说这些，有些人不爱听了：为什么和尚能2.0，我就2.0不得？

你当然可以，你在你家里2.0自己，没人能管你。你苦练了宝典，已经有了神功，再去2.0别人，更没人敢说你。但是现在，还是先去苦练自己的葵花宝典2.0吧。

一本热门书《谁动了我的奶酪》，引出了一个新的时髦语句，类似的“谁动了我的XX”，或者“我能动谁的XX”，或者“动的就是XX”，再或者“动什么也不能动XX”，还有那些“将XX进行到底”、“拿什么拯救你，我的XX”、“都是XX惹的祸”之类的语句。现在2.0这么时髦了，这些时髦语句都可以套用上去啊：“谁动了我的2.0?”、“将2.0进行到底”、“拿什么拯救你，我的2.0？”、“都是2.0惹的祸。”。

所以我也庸俗一次：今天，你2.0了吗？

（请不要对号入座，这只是一篇游戏之作）

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

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的学习记录 — 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的学习记录 — 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的学习记录 — Sat, 03 Nov 2007 02:58:00 GMT

只要有机会，我就会去游览天安门，夜幕下的天安门，更是别有一番风味。

1.天安门

2.人民英雄纪念碑

3.毛主席纪念堂

4.华灯

5.正阳门

6.毛主席纪念堂前的雕像

7.孙中山像

8.广场的喷泉

9.　街景1

10.街景2

11.人海

12.夜景

13.异彩

14.人民大会堂前的美景

15.夜狮

16.天安门近景

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

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了，先写到这儿吧，希望明天有时间将后续的内容写完。我已有好几篇文章写了待续却没有继续下去，总而言之，还是人懒呀。

待续......