CN109086380B - 对历史数据进行压缩存储的方法及*** - Google Patents
对历史数据进行压缩存储的方法及*** Download PDFInfo
- Publication number
- CN109086380B CN109086380B CN201810825552.4A CN201810825552A CN109086380B CN 109086380 B CN109086380 B CN 109086380B CN 201810825552 A CN201810825552 A CN 201810825552A CN 109086380 B CN109086380 B CN 109086380B
- Authority
- CN
- China
- Prior art keywords
- data
- client
- file
- tag
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种对历史数据进行压缩存储的方法及***。所述方法包括:服务端读取标签文件和配置文件,并完成初始化;在所述初始化之后,创建命名管道并完成与客户端的连接;经由所述命名管道从所述客户端读取数据;启动保存线程,并按照数据类型将所述数据进行分类保存。由此可见,本发明实施例通过在服务端与客户端直接创建命名管道,从而将客户端获取的数据在服务端以***的方式进行分类保存,如此能够充分地利用有限的磁盘空间存储数据。
Description
技术领域
本发明涉及数据处理领域,更具体地涉及一种对历史数据进行压缩存储的方法及***。
背景技术
随着环保业务的飞速发展,大量的现场运行数据需要被收集并存储。一种常用的方式是增加存储器的容量和提高计算机的处理速度等,然而这种方式不仅会使体积增大而且还极大地硬件成本,因此如何让有限的磁盘空间容纳更多的数据成为亟需解决的问题。
发明内容
本发明提供了一种对历史数据进行压缩存储的方法及***,能够充分利用磁盘空间,实现数据存储。
根据本发明的一方面,提供了一种对历史数据进行压缩存储的方法,所述方法包括:
服务端读取标签文件和配置文件,并完成初始化;
在所述初始化之后,创建命名管道并完成与客户端的连接;
经由所述命名管道从所述客户端读取数据;
启动保存线程,并按照数据类型将所述数据进行分类保存。
在本发明的一种实现方式中,在所述初始化之后,创建命名管道并完成与客户端的连接,包括:
初始化重叠结构体后,设置打开模式为文件重叠以创建所述命名管道;
所述命名管道创建后,接收所述客户端的连接请求;
根据所述连接请求完成与所述客户端的连接。
在本发明的一种实现方式中,经由所述命名管道从所述客户端读取数据,包括:
创建并进入实例线程,并读取所述客户端发送的数据;
将所述数据放入缓存数组中。
在本发明的一种实现方式中,所述启动保存线程,包括:
在确定所述缓存数组中的实际字节长度大于或等于管道头中记录的发送字节长度时,启动所述保存线程。
在本发明的一种实现方式中,按照数据类型将所述数据进行分类保存,包括:
创建和初始化历史文件;
获取关于位号数据、数值刷新时刻及在所述历史文件中的存储位置的缓存记录;
根据所述缓存记录,在所述历史文件中对应的所述存储位置处写入所述位号数据和所述数值刷新时刻。
在本发明的一种实现方式中,所述位号数据是根据所述数值刷新时刻以***的形式存储在所述历史文件中的。
在本发明的一种实现方式中,所述数据的格式是由所述客户端定义的,包括:
管道头结构体,用于记录发送缓存区中数据结构的个数、数据结构的长度以及管道发送字节的总长度;
数据结构,用于存放变量的信息,所述变量的信息包括以下至少一项:标识ID、质量码、数值、数值刷新时刻;
管道返回结构体,用于表示从所述服务端返回至所述客户端的反馈,所述反馈包括通讯是否成功和/或数据是否保存。
在本发明的一种实现方式中,在服务端读取标签文件和配置文件之前,还包括:
所述客户端中的核心软件对数据库进行配置;
在所述配置之后,根据所述数据库生成所述标签文件。
在本发明的一种实现方式中,对数据库进行配置,包括:
获取管理员输入的服务器参数以及标签信息;
其中,所述服务器参数包括以下至少一项:服务器的名称,用户名、登录密码和互联网协议IP地址;
其中,所述标签信息包括以下至少一项:数据类型、是否需要记录、误差及记录间隔。
根据本发明的另一方面,提供了一种对历史数据进行压缩存储的***,用于实现前述方面或任一实现方式所述方法的步骤,所述***包括服务端,所述服务端包括:
初始化模块,用于读取标签文件和配置文件,并完成初始化;
连接模块,用于在所述初始化之后,创建命名管道并完成与客户端的连接;
数据读取模块,用于经由所述命名管道从所述客户端读取数据;
存储模块,用于启动保存线程,并按照数据类型将所述数据进行分类保存。
在本发明的一种实现方式中,所述***还包括客户端,所述客户端包括:
配置模块,用于对数据库进行配置;
生成模块,用于根据所述数据库生成所述标签文件。
根据本发明的又一方面,提供了一种对历史数据进行压缩存储的***,包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现前述方面或任一实现方式所述的对历史数据进行压缩存储的方法的步骤。
根据本发明的再一方面,提供了一种计算机存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现前述方面或任一实现方式所述的对历史数据进行压缩存储的方法的步骤。
由此可见,本发明实施例通过在服务端与客户端直接创建命名管道,从而将客户端获取的数据在服务端以***的方式进行分类保存,如此能够充分地利用有限的磁盘空间存储数据。
附图说明
通过结合附图对本发明实施例进行更详细的描述,本发明的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本发明实施例的进一步理解,并且构成说明书的一部分,与本发明实施例一起用于解释本发明,并不构成对本发明的限制。在附图中,相同的参考标号通常代表相同部件或步骤。
图1是本发明实施例的对历史数据压缩存储的***的一个示意图;
图2是本发明实施例的对历史数据压缩存储的***的另一个示意图;
图3是本发明实施例的对历史数据压缩存储的方法的一个示意性流程图;
图4是本发明实施例的确认服务主程序启动的界面的一个示意图;
图5是本发明实施例的OPC界面的一个示意图;
图6是本发明实施例的TAG界面的一个示意图;
图7是本发明实施例的客户端核心软件所执行的过程的一个流程示意图;
图8是本发明实施例的服务端所执行的过程的一个流程示意图;
图9是本发明实施例的历史文件的存储结构的一个示意图;
图10是本发明实施例的对历史数据压缩存储的***的一个示意性框图。
具体实施方式
为了使得本发明的目的、技术方案和优点更为明显,下面将参照附图详细描述根据本发明的示例实施例。显然,所描述的实施例仅仅是本发明的一部分实施例,而不是本发明的全部实施例,应理解,本发明不受这里描述的示例实施例的限制。基于本发明中描述的本发明实施例,本领域技术人员在没有付出创造性劳动的情况下所得到的所有其它实施例都应落入本发明的保护范围之内。
本发明实施例提供了一种对历史数据压缩存储的***,如图1所示,该***10可以包括服务端110和客户端120。示例性地,服务端也可以被称为服务器。
示例性地,客户端120存储有核心软件,例如可以为EBHKCore软件。另外还存储有数据库和标签文件,其中标签文件可以为Tag.cnt。其中,核心软件也可以称为核心程序、核心进程等,本发明对此不限定。
示例性地,服务端110存储有历史数据压缩软件,例如可以为EBHKHIS软件。其包括服务主程序、配置文件和标签文件,其中标签文件可以为Tag.cnt。
示例性地,服务端110与客户端120可以经由命名管道文件***(Named PipeFiles System,NPFS)接口进行C/S通讯,如图1中示出为命名管道。
另外,图1所示的***10还可以与外部的设备或***等进行通讯,例如,可以与以太网20进行通信。如图1所示,可以由客户端120经由以太网通讯实现与外部的以太网20之间的通信。具体地,客户端120的EBHKCore软件可以按时间间隔和误差超限方式采集OPCServer的数据。
本发明实施例中的***10,其开发的条件可以是普通的个人计算机(PC)及相对应的操作***,例如可以是WINDOWS 7 32位操作***。
应理解,图1示出的***10的结构仅是示意性的,该***10可以包括更多或更少的模块/软件等,本发明对此不限定。
作为另一例,如图2所示,该***10中的服务端110还包括Win32动态库。服务主程序包括主逻辑控制和支撑库调用控制。
其中,Win32动态库用于辅助实现服务主程序。示例性地,服务主程序可以采用VC++6.0Win32Console Application开发。
其中,主逻辑控制用于对服务主程序、数据库、配置文件和标签文件进行控制。服务主程序可以后台运行历史数据压缩存储线程,关于该服务主程序将在下文进行详细阐述。数据库中存储有存储Tag类型、记录方式及记录间隔,命名管道根据这些配置发送相应数据给后台存储服务。配置文件可以用于记录保存路径以及保存方式。标签文件(如tag.cnt)存有从数据库中读取的所有Tag信息,并按标识(ID)排序。
其中,支撑库调用控制用于对接口等进行控制。示例性地,本发明实施例中的C/S通讯可以调用现有的Windows命名管道文件***(Named Pipe Files System,NPFS)接口。服务主程序可以调用现有的服务控制管理器(Service Control Manager,SCM)编程接口。也就是说,支撑库调用控制用于对NPFS接口和SCM接口进行控制。NPFS接口用于实现C/S进程间稳定可靠的数据传输。当EBHKHIS在后台启动后,SCM接口可以负责把程序主线程连接到服务控制管理器(SCM)。
另外,以太网20可以为工业以太网,其包括可编程逻辑控制器(ProgrammableLogic Controller,PLC)和分布式控制***(Distributed Control System,DCS)控制器,且该工业以太网经由以太网接口与OPCServe服务器进行通信。
本发明实施例还提供了一种对历史数据压缩存储的方法,该方法可以由前述的***10执行,如图3所示,该方法可以包括:
S110,服务端读取标签文件和配置文件,并完成初始化。
S120,在所述初始化之后,创建命名管道并完成与客户端的连接。
S130,经由所述命名管道从所述客户端读取数据。
S140,启动保存线程,并按照数据类型将所述数据进行分类保存。
示例性地,在S110之前,可以首先获取管理员的指令,以在后台启动服务主程序。也就是说,该服务主程序为后台服务,例如为EBHKHIS服务。
具体地,管理员可以打开命令提示符窗口,输入脚本。作为一例,输入的脚本可以为:
在管理员添加完成后cmd退出,随后可以打开控制面板→管理工具→服务就会发现服务主程序(即EBHKHIS Service)已经在后台启动,该画面如图4所示。这样通过上述管理员的指令,在每次PC开机后EBHKHIS服务就会自启动,而不需要人工手动干预。
示例性地,在S110之前,还可以包括:客户端中的核心软件对数据库进行配置;并在配置之后,根据数据库生成标签文件。
在后台服务(即EBHKHIS Service)正常启动之后,EBHKcore软件在运行之前对数据库实现按需求配置。
具体地,管理员可以打开EBHKCore.mdb文件,并实现该配置过程。可选地,可以在用于过程控制的OLE(OLE(Object Linking and Embedding,对象连接与嵌入)for ProcessControl,OPC)界面获取管理员输入的服务器参数,从而实现对服务器参数的设置,其中服务器参数可以包括以下至少一项:服务器的名称,用户名、登录密码和IP地址等。可选地,可以在标签(TAG)界面获取管理员输入的TAG信息,从而实现对TAG信息的设置,其中TAG信息可以包括以下至少一项:数据类型、是否需要记录、误差及记录间隔等。
管理员可以点击OPC表从而呈现OPC界面,作为一例,该OPC界面可以如图5所示。进而在该OPC界面,管理员可以设置连接服务器的名称,用户名、登录密码及IP地址等等。
管理员可以点击TAG表从而呈现TAG界面,作为一例,该TAG界面可以如图6所示。进而在该TAG界面,管理员可以配置OPC标签点,主要添加数据类型、是否需要记录、误差及记录间隔等等。
示例性地,在对数据库进行配置之后,还可以包括:启动核心软件,根据数据库的配置,生成标签文件。
具体地,在数据库配置完成后,可以启动客户端的EBHKcore软件,根据数据库文件TAG表中的信息,按ID排序生成标签文件(例如可以为Tag.cnt)。可选地,该标签文件可以在后台服务中用于历史数据的压缩存储。
本发明实施例中,数据可以经由命名管道从客户端发送至服务端。示例性地,客户端可以在每隔一段时长后将数据放入命名管道,并发送至服务端。或者,客户端可以在待发送数据的变化量(如图6所示的误差)达到预定值之后将其放入命名管道(即误差超限的方式),并在命名管道中的数据累计达到一定的量之后发送至服务端。
数据的格式可以由客户端定义,其包括管道头结构体、数据结构和管道返回结构体。如此,客户端和服务端都可以引用该定义好的数据的格式进行数据收发。其中,管道头结构体,用于记录发送缓存区中数据结构的个数、数据结构的长度以及管道发送字节的总长度。数据结构,用于存放变量的信息,所述变量的信息包括以下至少一项:标识ID、质量码、数值、数值刷新时刻。管道返回结构体,用于表示从所述服务端返回至所述客户端的反馈,所述反馈包括通讯是否成功和/或数据是否保存。
具体地,可以首先声明三个结构体,例如在Structs.h头文件中声明三个结构体:管道头结构体(PIPEHEADER)、数据结构(LOGRECORD)和管道返回结构体(PIPERET)。以下将对这三个结构体进行简要阐述。
1.管道头结构体(PIPEHEADER),其被放置在发送管道的首端,用于记录发送缓存区中数据结构的个数、数据结构的长度以及管道发送字节的总长度。可以通过如下程序实现:
2.数据结构(LOGRECORD),其用于存放变量的各种重要信息,例如ID、质量码、数值以及数值刷新时刻等。可以通过如下程序实现:
3.管道返回结构体(PIPERET),结构与管道头类似,其为C/S通讯从服务端返回的校验结构体。管道返回结构体功能为:客户端把数据发送给服务端,并从服务端返回通讯是否成功,能否进行保存。可以通过如下程序实现:
另外,在此处也同时介绍命名管道客户端部分的程序:
可见,在对数据库完成配置,并启动核心软件之后,可以生成标签文件,具体地根据TAG表中的信息按照ID排序生成标签文件。另外,还可以经由命名管道向服务端发送客户端连接请求(如通过指令CallNamedPipe),若连接成功,则经由命名管道发送数据,否则不发送数据。该过程可以如图7所示。
下面将结合服务端的功能对图3所示的方法流程进行较为详细的阐述,具体地可以参见图8所示。
由于服务端的服务主程序属于windows后台服务程序,无需显示交互界面。因此,可以通过建立win32控制台应用程序以满足要求。
该服务主程序的服务控制管理部分可以包含三个函数:服务程序主函数(main)、服务入口点函数(service_main)和控制服务处理程序函数(Service Control handle)。其中,服务程序主函数(main)初始化一个服务表入口(SERVICE_TABLE_ENTRY)结构体数组(提供一个service_main函数),然后调用启动服务控制分派(StartServiceCtrlDispatcher)函数连接程序主线程到服务控制管理程序。其中,服务入口点函数(service_main)执行服务初始化任务,此处只需要一个服务进程完成历史数据压缩存储,所以对应一个服务入口函数。其中,控制服务处理程序函数(Service Control handle)调用注册服务控制处理(RegisterServiceCtrlHandler)函数来注册它的控制处理器(Control Handler)函数。
服务启动(ServiceStart)成功后,可以执行S110,即进行保存前的初始化工作,读取配置文件和标签文件。具体地,可以读取ini配置文件以获取his文件的保存路径,读取Tag.cnt文件以初始化m_mapIDToType集合(键:ID值:Type)。随后便可以在S120中由服务端循环创建非阻塞模式命名管道并在S130中不停地接收客户端的数据。
示例性地,S120可以包括:初始化重叠结构体后,设置打开模式为文件重叠以创建所述命名管道;所述命名管道创建后,接收所述客户端的连接请求(ConnectNamedPipe);根据所述连接请求完成与所述客户端的连接。
具体地,命名管道服务端主要包含两个重要函数,分别为创建命名管道(CreateNamedPipe)和连接命名管道(ConnectNamedPipe)。
首先定义并初始化安全属性(SECURITY_ATTRIBUTES)结构体,作为创建命名管道(CreateNamedPipe)的实参。随后在创建命名管道之后连接。
由于创建管道时的打开模式为文件重叠(FILE_FLAG_OVERLAPPED),所以必须初始化重叠(OVERLAPPE)结构体:
示例性地,S130可以包括:创建并进入实例线程,并读取所述客户端发送的数据;将所述数据放入缓存数组中。
具体地,如果命名管道连接成功,创建并进入实例线程(InstanceThread),读取管道中客户端发送的数据流(ReadFile),并把数据放入缓存数组(byBuf)中。
应注意,本发明实施例对数据的来源、含义等不作限定。例如,数据可以包括环境污染物的名称、种类、数量等。数据流中的数据可以被称为标签(tag)数据或标签点数据或位号数据,或者也可以简称为tag,本发明对此不限定。
具体地,S130中,服务端可以根据客户端预先定义的格式,从命名管道中获取数据,具体地可以根据数据结构获取数据的位号ID、质量码、保存类型、数值以及数值刷新时刻。其中,位号ID可以作为后续存储时的TagID,保存类型可以作为后续存储时的TagType。
示例性地,S140可以包括:在确定所述缓存数组中的实际字节长度大于或等于管道头中记录的发送字节长度时,启动所述保存线程。
具体地,如果实际读取得字节长度(即缓存的字节数)大于或等于管道头中记录的发送字节总长度,则把管道校验结构体pr的wCode成员变量置位并发送给客户端释放连接,同时服务端可以进行保存,随即启动保存线程(SaveThread),按管道头中的数据类型(wID)进行分类保存。例如,不同的数据类型在存储时所占用的字节数不同。
示例性地,S140还可以包括:创建和初始化历史文件;获取关于位号数据、数值刷新时刻及在所述历史文件中的存储位置的缓存记录;根据所述缓存记录,在所述历史文件中对应的所述存储位置处写入所述位号数据和所述数值刷新时刻。
具体地,保存的过程中,首先创建和初始化历史文件(his),紧接着通过缓存记录位号数据、位号刷新时刻及其在文件中的存储位置,最后根据记录的信息在文件中对应的位置处写入位号数据和刷新时刻,如此反复把管道中发送过来的每一个位号的信息都写入历史文件(his)中按顺序存储。
具体地,位号数据可以按照数值刷新时刻以***的形式存储在历史文件中。如下述结合图9所介绍的。
历史文件可以按照日期进行创建,例如可以在每日的零点创建一个当日的历史文件,每个历史文件表示某一天所存储的历史数据。举例来说,历史文件1表示在2018年4月12日的历史数据,可以将其命名为20180412.his。历史文件2表示在2018年4月13日的历史数据,可以将其命名为20180413.his。等等。下面以一个历史文件为例进行介绍。
示例性地,历史文件(his)中的存储结构可以如图9所示,包括文件头和数据块信息。其中,文件头可以占用1024字节,数据库信息可以包括多个标签(tag),每个tag占用594字节。如此可以按需地对历史文件进行自增长,当需要存储下一个tag时,可以将其存储在已有tag之后。作为一例,图9中示出了两个tag:tag1和tag2。
文件头可以包括多个变量,包括但不限于:1、dwLastPos变量4字节,用于存储his文件中最后一个Tag数据结构的位置;2、lTags变量4字节,用于统计Tag标签总数;3、wVersion变量2字节,用于存储版本号;4、dwCreateTags变量4字节,用于统计创建的Tag标签数;5、dwAddTags变量4字节,用于统计增加的Tag标签数;等等。
每个tag可以包括多个字段,包括但不限于:1、TagID,占4字节;2、TagType,占2字节;3、dwLastTagPos,占4字节,记录前一次Tag在文件中的位置;4、dwLastSec,占4字节,记录前一次Tag数值刷新时刻(s);等等。作为一个示例,图9中还示出了tag1和tag2的部分字段结构,其中,数值刷新时刻(经过编码)占用8字节,tag数值占用4字节。可理解,此处假设tag1与tag2具有相同的数据类型,存储时均占用12字节。
如此,便可以根据数据块信息在dwLastTagPos处存储具有TagID和TagType的数据,具体地将数值刷新时刻进行编码后与对应的数值(value)一起存储,如在图9的下方的tag1和tag2。可选地,图9的下方所示的数值刷新时刻(经过编码)可以表示将TagID、质量码叠加到数值刷新时刻后再进行编码。
举例来说,图9的下方的tag1可以存储编码后的数值刷新时刻t11以及对应的tag数值(记为v1)。也就是说,历史文件中存储的是经过处理的数据,而非文本形式的原始数据。这样,能够防止历史文件中的数据被泄露,保证其安全性。
示例性地,图9所示的Tag数据块信息中tag1处的dwLastTagPos为0,即在历史文件的位置0处存储如图9下方所示的tag1,包括编码后的数值刷新时刻以及tag数值。图9所示的Tag数据块信息中tag2处的dwLastTagPos为12,即在历史文件的位置12处存储如图9下方所示的tag2,包括编码后的数值刷新时刻以及tag数值。这样,能够充分地利用存储空间,避免存储空间浪费。
针对某特定的TagID,可以经由命名管道获取多个数据,多个数据可以是一次接收到的或者也可以是多次接收到的,不同的数据可以具有相同或不同的数值刷新时刻和/或数值(value)。
举例来说,假设tag1的TagID=ID1,TagType=Type1。若接收到一个新的数据,其TagID为ID1,其TagType为Type1,即其属于tag1,则可以将其按照数值刷新时刻进行***。若新收到的数据的数值刷新时刻(记为dwNewSec)>已存储的数值刷新时刻(即dwLastSec),则将tag数据库信息部分tag1的已存储的数值刷新时刻(即dwLastSec)更新为新收到的数据的数值刷新时刻,将tag数据库信息部分tag1的已存储的数值存储位置(即dwLastTagPos)更新为新收到的数据的数值存储位置。也就是说,tag数据库信息部分各个tag的dwLastTagPos和dwLastSec是根据最后接收到的数据而不断更新的。并且,可以在图9的下方所示的tag1之后存储新收到的数据的数值刷新时刻及数值。举例来说,可以存储编码后的数值刷新时刻t12以及对应的tag数值(记为v2)。示例性地,可以将图9所示的Tag数据块信息中tag1处的dwLastTagPos更新为24,将图9所示的Tag数据块信息中tag1处的dwLastSec更新为t12,并在历史文件的位置24处(即图9下方所示的tag2之后)存储与图9下方所示的tag1相类似的编码后的数值刷新时刻t12以及对应的tag数值。
如此便可以将tag1的所有历史数据进行存储,并且这种***的存储方式能够节省存储空间,使得存储空间的利用率更高。
若新收到的数据的数值刷新时刻(记为dwNewSec)=已存储的数值刷新时刻(即dwLastSec),则将对应位置处的数值进行更新。具体地,将如图9的下方所示的tag1中的tag数值(假设为v1)更新为新收到的数据的数值(假设为v2)。
另外,可以为历史文件设定预留空间,假设为1024。可理解,如果dwLastPos+1024(即预留空间)大于文件长度(字节),说明预留空间不足,此时需要额外增加空间,例如可以增加512KB或1024KB等等。
再者,还可以根据需求设定时间跨度,定时删除部分历史文件,减少磁盘的占用空间。
由此可见,本发明实施例通过在服务端与客户端直接创建命名管道,从而将客户端获取的数据在服务端以***的方式进行分类保存,如此能够充分地利用有限的磁盘空间存储数据。
图10是本发明实施例的对历史数据进行压缩存储的***的一个示意性框图。图10所示的***10包括服务端110和客户端120。
其中,服务端110包括初始化模块1101、连接模块1102、数据读取模块1103和存储模块1104。
初始化模块1101,用于读取标签文件和配置文件,并完成初始化;连接模块1102,用于在所述初始化之后,创建命名管道并完成与客户端的连接;数据读取模块1103,用于经由所述命名管道从所述客户端读取数据;存储模块1104,用于启动保存线程,并按照数据类型将所述数据进行分类保存。
本发明实施例的服务端110能够用于实现前述方法实施例中由服务端110(具体地由服务主程序)实现的方法过程,为避免重复,这里不再赘述。
其中,客户端120可以包括配置模块1201和生成模块1202。配置模块1201,用于对数据库进行配置;生成模块1202,用于根据所述数据库生成所述标签文件。
示例性地,配置模块1201可以具体用于:获取管理员输入的服务器参数以及标签信息。其中,所述服务器参数包括以下至少一项:服务器的名称,用户名、登录密码和互联网协议IP地址。其中,所述标签信息包括以下至少一项:数据类型、是否需要记录、误差及记录间隔。
本发明实施例的客户端120能够用于实现前述方法实施例中由客户端120(具体地由核心程序)实现的方法过程,为避免重复,这里不再赘述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
另外,本发明实施例还提供了另一种对历史数据进行压缩存储的***,包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序,处理器执行所述程序时实现前述结合图3至图9所示的对历史数据进行压缩存储的方法的步骤。
另外,本发明实施例还提供了一种计算机存储介质,其上存储有计算机程序。当所述计算机程序由处理器执行时,可以实现前述结合图3至图9所示的对历史数据进行压缩存储的方法的步骤。例如,该计算机存储介质为计算机可读存储介质。
由此可见,本发明实施例通过在服务端与客户端直接创建命名管道,从而将客户端获取的数据在服务端进行分类保存,如此能够充分地利用有限的磁盘空间存储数据。
本发明实施例中能够按照时间间隔和误差超限方式采集数据,且服务主程序能够与现有的核心软件进行通讯,具体地通过创建命名管道实现稳定可靠的进程间通讯。在数据存储时,可以创建历史文件进行写入操作。通过服务控制管理器(SCM)提供的接口创建后台服务,完成历史数据压缩存储。另外,存储的标签点数不受限制,且能够按照不同的数据类型进程存储。如此能够实现对数据的压缩存储,充分利用磁盘空间。
尽管这里已经参考附图描述了示例实施例,应理解上述示例实施例仅仅是示例性的,并且不意图将本发明的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改,而不偏离本发明的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本发明的范围之内。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。例如,以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个设备,或一些特征可以忽略,或不执行。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本发明并帮助理解各个发明方面中的一个或多个,在对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该本发明的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如相应的权利要求书所反映的那样,其发明点在于可以用少于某个公开的单个实施例的所有特征的特征来解决相应的技术问题。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域的技术人员可以理解,除了特征之间相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(Digital Signal Processing,DSP)来实现根据本发明实施例的物品分析设备中的一些模块的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
以上所述,仅为本发明的具体实施方式或对具体实施方式的说明,本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。本发明的保护范围应以权利要求的保护范围为准。
Claims (12)
1.一种对历史数据进行压缩存储的方法,其特征在于,所述方法包括:
服务端读取标签文件和配置文件,并完成初始化;
在所述初始化之后,创建命名管道并完成与客户端的连接;
经由所述命名管道从所述客户端读取数据;
启动保存线程,并按照数据类型将所述数据进行分类保存;
其中,按照数据类型将所述数据进行分类保存,包括:
创建和初始化历史文件;
获取关于位号数据、数值刷新时刻及在所述历史文件中的存储位置的缓存记录;
根据所述缓存记录,在所述历史文件中对应的所述存储位置处写入所述位号数据和所述数值刷新时刻;
其中,所述历史文件包括文件头和数据块信息,所述数据块信息包括多个标签;所述位号数据包括标签数值。
2.根据权利要求1所述的方法,其特征在于,在所述初始化之后,创建命名管道并完成与客户端的连接,包括:
初始化重叠结构体后,设置打开模式为文件重叠以创建所述命名管道;
所述命名管道创建后,接收所述客户端的连接请求;
根据所述连接请求完成与所述客户端的连接。
3.根据权利要求1所述的方法,其特征在于,经由所述命名管道从所述客户端读取数据,包括:
创建并进入实例线程,并读取所述客户端发送的数据;
将所述数据放入缓存数组中。
4.根据权利要求3所述的方法,其特征在于,所述启动保存线程,包括:
在确定所述缓存数组中的实际字节长度大于或等于管道头中记录的发送字节长度时,启动所述保存线程。
5.根据权利要求1所述的方法,其特征在于,所述位号数据是根据所述数值刷新时刻以***的形式存储在所述历史文件中的。
6.根据权利要求1所述的方法,其特征在于,所述数据的格式是由所述客户端定义的,包括:
管道头结构体,用于记录发送缓存区中数据结构的个数、数据结构的长度以及管道发送字节的总长度;
数据结构,用于存放变量的信息,所述变量的信息包括以下至少一项:标识ID、质量码、数值、数值刷新时刻;
管道返回结构体,用于表示从所述服务端返回至所述客户端的反馈,所述反馈包括通讯是否成功和/或数据是否保存。
7.根据权利要求1所述的方法,其特征在于,在服务端读取标签文件和配置文件之前,还包括:
所述客户端中的核心软件对数据库进行配置;
在所述配置之后,根据所述数据库生成所述标签文件。
8.根据权利要求7所述的方法,其特征在于,对数据库进行配置,包括:
获取管理员输入的服务器参数以及标签信息;
其中,所述服务器参数包括以下至少一项:服务器的名称,用户名、登录密码和互联网协议IP地址;
其中,所述标签信息包括以下至少一项:数据类型、是否需要记录、误差及记录间隔。
9.一种对历史数据进行压缩存储的***,其特征在于,所述***包括服务端,所述服务端包括:
初始化模块,用于读取标签文件和配置文件,并完成初始化;
连接模块,用于在所述初始化之后,创建命名管道并完成与客户端的连接;
数据读取模块,用于经由所述命名管道从所述客户端读取数据;
存储模块,用于启动保存线程,并按照数据类型将所述数据进行分类保存;
所述存储模块,具体用于创建和初始化历史文件;获取关于位号数据、数值刷新时刻及在所述历史文件中的存储位置的缓存记录;根据所述缓存记录,在所述历史文件中对应的所述存储位置处写入所述位号数据和所述数值刷新时刻;
其中,所述历史文件包括文件头和数据块信息,所述数据块信息包括多个标签;所述位号数据包括标签数值。
10.根据权利要求9所述的***,其特征在于,所述***还包括客户端,所述客户端包括:
配置模块,用于对数据库进行配置;
生成模块,用于根据所述数据库生成所述标签文件。
11.一种对历史数据进行压缩存储的***,包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至8中任一项所述方法的步骤。
12.一种计算机存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至8中任一项所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810825552.4A CN109086380B (zh) | 2018-07-25 | 2018-07-25 | 对历史数据进行压缩存储的方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810825552.4A CN109086380B (zh) | 2018-07-25 | 2018-07-25 | 对历史数据进行压缩存储的方法及*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109086380A CN109086380A (zh) | 2018-12-25 |
CN109086380B true CN109086380B (zh) | 2022-09-16 |
Family
ID=64838560
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810825552.4A Active CN109086380B (zh) | 2018-07-25 | 2018-07-25 | 对历史数据进行压缩存储的方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109086380B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110806996B (zh) * | 2019-09-20 | 2022-04-12 | 光大环境科技(中国)有限公司 | 对opc数据进行采集的***和方法 |
CN113806611A (zh) * | 2020-06-17 | 2021-12-17 | 海信集团有限公司 | 一种存储搜索引擎结果的方法及设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101729414A (zh) * | 2009-11-24 | 2010-06-09 | 北京雷霆万钧网络科技有限责任公司 | 一种基于用户请求信息响应的数据传输方法和*** |
CN101741640A (zh) * | 2009-11-24 | 2010-06-16 | 北京雷霆万钧网络科技有限责任公司 | 一种基于用户请求信息响应的管道选择方法和*** |
CN103885872A (zh) * | 2012-12-21 | 2014-06-25 | 上海格尔软件股份有限公司 | 一种基于管道的日志回滚实现方法 |
CN107526645A (zh) * | 2017-09-06 | 2017-12-29 | 武汉斗鱼网络科技有限公司 | 一种通信优化方法及*** |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB0524742D0 (en) * | 2005-12-03 | 2006-01-11 | Ibm | Methods and apparatus for remote monitoring |
CN102739720B (zh) * | 2011-04-14 | 2015-01-28 | 中兴通讯股份有限公司 | 分布式缓存服务器***及其应用方法、缓存客户端 |
CN102591749B (zh) * | 2011-12-30 | 2013-12-18 | 华中科技大学 | 一种连续数据存储方法 |
CN105045851A (zh) * | 2015-07-07 | 2015-11-11 | 福建天晴数码有限公司 | 根据日志分析自动创建数据库索引的方法及*** |
CN106021417A (zh) * | 2016-05-12 | 2016-10-12 | 京信通信***(广州)有限公司 | 日志压缩方法及装置 |
GB201615747D0 (en) * | 2016-09-15 | 2016-11-02 | Gb Gas Holdings Ltd | System for data management in a large scale data repository |
-
2018
- 2018-07-25 CN CN201810825552.4A patent/CN109086380B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101729414A (zh) * | 2009-11-24 | 2010-06-09 | 北京雷霆万钧网络科技有限责任公司 | 一种基于用户请求信息响应的数据传输方法和*** |
CN101741640A (zh) * | 2009-11-24 | 2010-06-16 | 北京雷霆万钧网络科技有限责任公司 | 一种基于用户请求信息响应的管道选择方法和*** |
CN103885872A (zh) * | 2012-12-21 | 2014-06-25 | 上海格尔软件股份有限公司 | 一种基于管道的日志回滚实现方法 |
CN107526645A (zh) * | 2017-09-06 | 2017-12-29 | 武汉斗鱼网络科技有限公司 | 一种通信优化方法及*** |
Non-Patent Citations (1)
Title |
---|
基于Socket的IPC消息平台设计;王崇文等;《小型微型计算机***》;20110415(第04期);14-19 * |
Also Published As
Publication number | Publication date |
---|---|
CN109086380A (zh) | 2018-12-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8504803B2 (en) | System and method for creating and executing portable software | |
CN102810057A (zh) | 一种记录日志的方法 | |
CN110908837B (zh) | 应用程序异常处理方法、装置、电子设备及存储介质 | |
CN109086380B (zh) | 对历史数据进行压缩存储的方法及*** | |
CN111556074A (zh) | 基于opc ua的通信协议配置方法及装置 | |
US12039302B2 (en) | Building base applications with user interface micro frontends | |
CN111309734A (zh) | 自动生成表数据的方法及*** | |
CN109598602A (zh) | 对账方法、装置、设备及计算机可读存储介质 | |
CN115455058A (zh) | 缓存数据的处理方法、装置、计算机设备及存储介质 | |
CN110175022A (zh) | 自动生成pojo类的方法、装置及存储介质、计算机设备 | |
CN111736825B (zh) | 一种信息展示方法、装置、设备和存储介质 | |
US10944587B2 (en) | Event processing associated with a smart device | |
CN117271122A (zh) | 基于cpu和gpu分离的任务处理方法、装置、设备及存储介质 | |
CN112799760A (zh) | 一种表单渲染方法及其装置 | |
CN114610597A (zh) | 一种压力测试方法、装置、设备及存储介质 | |
WO2016091068A1 (zh) | 一种特殊指令的执行方法及装置 | |
CN115048187A (zh) | 一种基于Operator的pvc文件导入方法、设备及存储介质 | |
CN112580706B (zh) | 应用于数据管理平台的训练数据处理方法、装置和电子设备 | |
KR101968501B1 (ko) | 데이터 처리 장치 및 데이터 처리 장치의 메모리에 기록된 데이터의 확인 방법 | |
CN103838586A (zh) | 文件开启的***及方法 | |
CN113791819A (zh) | 接口文档生成方法和装置、存储介质、电子设备 | |
CN113741953A (zh) | 表单处理方法、装置、电子设备和计算机存储介质 | |
CN108037949B (zh) | 安装包多渠道打包方法、装置、计算机设备及存储介质 | |
CN111444161A (zh) | 数据处理方法、装置、电子设备及存储介质 | |
CN112597058B (zh) | 一种基于卷创建的网页测试方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |