惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
博客园 - Franky
GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
爱范儿
爱范儿
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
博客园_首页
MongoDB | Blog
MongoDB | Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Recent Announcements
Recent Announcements
Scott Helme
Scott Helme
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
C
CERT Recently Published Vulnerability Notes
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Jina AI
Jina AI
F
Fortinet All Blogs
N
Netflix TechBlog - Medium
L
LangChain Blog
L
LINUX DO - 最新话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
H
Hacker News: Front Page
MyScale Blog
MyScale Blog
P
Palo Alto Networks Blog
G
Google Developers Blog
Google DeepMind News
Google DeepMind News
AI
AI
T
Troy Hunt's Blog
Microsoft Azure Blog
Microsoft Azure Blog
阮一峰的网络日志
阮一峰的网络日志
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Vercel News
Vercel News
Microsoft Security Blog
Microsoft Security Blog
罗磊的独立博客
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
博客园 - 叶小钗
人人都是产品经理
人人都是产品经理
Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 三生石上(FineUI控件)
S
Security @ Cisco Blogs
Cloudbric
Cloudbric
E
Exploit-DB.com RSS Feed
Attack and Defense Labs
Attack and Defense Labs

博客园 - linkman

实时数据库中的二级压缩技术 关于实时数据库接口标准的讨论[中] 今天,你2.0了吗? 此实时数据库非彼实时数据库 - linkman - 博客园 实时数据库领域中有关数据压缩的认识误区 发一个招聘软件开发人员的帖子 图记2007年北京国际马拉松比赛 悲观程序员的五件武器 关于变化压缩算法的展开讨论[下] 关于实时数据库接口标准的讨论[上] [导入]写给一位有程序员心结的朋友 续 写给一位有程序员心结的朋友 [导入]关于谭浩强[上] [导入]实时数据库的经典书 [导入]热烈祝贺实时数据库行业协会成立! [导入]某失败项目的项目总结报告 [导入]实时数据库理论与技术演讲PPT [导入][转摘]C++资源之不完全导引(完整版) [导入]走在理想与现实之间
关于变化压缩算法的展开讨论[上]
linkman · 2007-10-29 · via 博客园 - linkman

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

待续......