实时数据库中的二级压缩技术
今天心情不好，写写文章散散心。
我在文章《实时数据库领域中有关数据压缩的认识误区》中提到，在工业应用领域中，常用的压缩算法分为三类：无损压缩、有损压缩、二级压缩。二级压缩技术，同时利用了无损压缩、有损压缩这两种数据压缩技术。
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年以前的时间了。
以上只是分析，在实际系统中，还需要考虑这些因素的制约关系，解压的难度和时间度，索引建立的方便性，以及编程的复杂度。
