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

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

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

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

他的答案是：

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

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

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

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

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

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

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

再比如，下面这个图呢？

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

这些，说明了什么呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

有五种解决方案：

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

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

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