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

我在文章《关于实时数据库开发人员的面试题》提到，死区压缩的算法原理是：一段按时间顺序从小到大排列的数据，只有前后数据变化的绝对值超过常量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了，先写到这儿吧，希望明天有时间将后续的内容写完。我已有好几篇文章写了待续却没有继续下去，总而言之，还是人懒呀。

待续......