CN104516776B - 数据处理管理方法及信息处理设备 - Google Patents
数据处理管理方法及信息处理设备 Download PDFInfo
- Publication number
- CN104516776B CN104516776B CN201410522191.8A CN201410522191A CN104516776B CN 104516776 B CN104516776 B CN 104516776B CN 201410522191 A CN201410522191 A CN 201410522191A CN 104516776 B CN104516776 B CN 104516776B
- Authority
- CN
- China
- Prior art keywords
- event
- node
- inquiry
- processing
- state
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
- G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
Abstract
本申请涉及数据处理管理方法及信息处理设备。第一机器和第二机器执行多个分布式处理。存储单元存储有由第一机器执行的处理的进度信息。计算单元在接收到指示将处理重新分配给第二机器的重新分配指令时,将进度信息传送给第二机器。计算单元当在传送进度信息期间接收到待在处理中使用的数据时,将该数据以及进度信息一起传送给第二机器。第二机器在接收到进度信息和数据时,使用所述进度信息和数据来执行从第一机器重新分配的处理。
Description
技术领域
本文中讨论的实施方式涉及数据处理管理方法和信息处理设备。
背景技术
可以通过包括多个机器的分布式处理系统来处理数据。这样的机器可以包括物理计算机(有时被称为物理机或物理主机),或者在物理机上操作的虚拟计算机(有时被称为虚拟机或逻辑主机)。例如,可以使用分布式处理系统来进行复杂事件处理(CEP)。多个机器并行地执行由各种设备发出的多个事件,从而高速地处理所述多个事件。
在分布式处理系统中,为了平衡机器之间的处理负荷,有时存在改变对各个机器的处理分配的情况。因此,提出了用于改变处理分配的各种技术。例如,所提出的一种技术涉及将由第一计算机执行的处理迁移到第二计算机,并且涉及在将所述处理的副本传送给第二计算机的同时通过通过由第一计算机继续执行处理来缩短迁移期间的处理停止时间。
所提出的另一技术涉及将运行在处理器上的任务迁移到另一处理器,并且涉及源处理器执行传送任务以将迁移目标任务传送到目标处理器,并且当在传送期间接收到迁移目标任务的中断请求时,迁移任务开始中断处理。
此外,所提出的另一技术涉及:当检测到处理负荷超过预定阈值的虚拟机时,基于复杂事件处理之间的关联程度将所述复杂事件处理分发配给多个虚拟机。
日本已公开专利公布No.2004-78465
日本已公开专利公布No.2010-272076
日本已公开专利公布No.2012-79242
当改变数据处理的分配时,有时存在希望将在改变前处理的进度传送给改变后的处理的情况。例如,在针对多个事件执行处理的情况下,如果一些事件已发生,则可能希望已发生的那些事件的状态在改变处理的分配后依然保持。鉴于此,考虑到由最初分配的第一机器向新分配的第二机器提供关于处理的进度的报告,从而使得第二机器在中间接管所述处理。然而,在进度信息从第一机器到第二机器的传送期间,待在被重新分配给第二机器的处理中使用的数据可能被输入到第一机器。在该情况下的数据处理成为问题。
假设,例如,第一机器如在上述提出的技术中那样继续处理输入数据。然而,如果数据不断地发送到第一机器,则第一机器不能够结束处理,因此第一机器可能花费太长的时间而使得第二机器不能够开始处理。假设,另一方面,第一机器停止处理,并且在进度信息的传送完成后将输入到第一机器的数据传送给第二机器,从而使得第二机器继续执行处理。在该情况下,等待进度信息的传送完成,然后再等待将数据传送到第二机器可能使数据到达第二机器延迟,因此使在第二机器处继续执行处理延迟。
发明内容
实施方式的一个方面旨在提供一种能够缩短在新分配的目标处继续执行处理的延迟的数据处理管理方法和信息处理设备。
根据一个方面,提供了一种在包括第一计算机和第二计算机的系统中执行的数据处理管理方法。数据处理管理方法包括:第一计算机当接收到将由第一计算机执行的处理重新分配给第二计算机的指令时,将该处理的进度信息传送给第二计算机;以及第一计算机当在传送进度信息期间接收到与处理相关联的数据时,将该数据传送给第二计算机。
附图说明
图1示出了根据第一实施方式的分布式处理系统;
图2示出了根据第二实施方式的分布式处理系统;
图3示出了节点的硬件配置的示例;
图4示出了改变查询分配的示例;
图5示出了分布式处理系统的软件配置的示例;
图6出了分布式处理系统的软件配置的示例(续接图5);
图7示出了事件的示例;
图8示出了查询的示例;
图9示出了查询状态的示例;
图10示出了查询配置表的第一示例;
图11示出了查询配置表的第二示例;
图12示出了查询配置表的第三示例;
图13示出了传送数据管理结构的示例;
图14示出了传送列表的示例;
图15是示出查询状态传送管理的示例的流程图;
图16是示出事件接收管理(在最初分配的节点处)的示例的流程图;
图17是示出查询状态接收管理的示例的流程图;
图18是示出事件接收管理(在新分配的节点处)的示例的流程图;
图19是示出事件传送管理的示例的流程图;
图20示出了查询状态传送示例的第一部分;
图21示出了查询状态传送示例的第二部分;
图22是示出查询重新分配的第一示例的时序图;
图23是示出比较性查询重新分配的第一示例的时序图;
图24是示出查询重新分配的第二示例的时序图;
图25是示出比较性查询重新分配的第二示例的时序图;以及
图26示出了分布式处理系统的另一示例。
具体实施方式
下文将参照附图描述若干实施方式,其中贯穿全文相同的附图标记指代相同的元件。
(a)第一实施方式
图1示出了根据第一实施方式的分布式处理系统。第一实施方式的分布式处理系统具有包括机器1和机器2的多个机器。多个机器连接到网络,从而彼此能够进行通信。在该分布式处理系统中,多个处理被分发给多个机器,并且由所述多个机器执行。
此处假设第一实施方式的机器1和机器2是物理机。然而,注意到机器1和机器2可以是虚拟机。例如,机器1和机器2可以是运行在不同物理机上的虚拟机,或者可以是运行在单个物理机(配备有存储装置、处理单元等的计算机系统)上的虚拟机。
机器1包括存储单元1a和计算单元1b。机器2包括存储单元2a和计算单元2b。存储单元1a/2a可以是易失性存储装置,例如随机存取存储器(RAM);或者非易失性存储装置,例如硬盘驱动器(HDD)和闪速存储器。计算单元1b/2b可以包括例如中央处理单元(CPU)、数字信号处理器(DSP)、专用集成电路(ASIC),以及现场可编程门阵列(FPGA)。计算单元1b/2b可以是执行程序的处理器。此处术语“处理器”包括具有多个处理器(即,多处理器)的计算机系统。
存储单元1a存储分配给机器1的每个处理(process)的进度信息。进度信息3是处理之一的进度信息。例如,如果第一实施方式的分布式处理系统是执行用于多个输入数据集的预定处理的系统,则存储单元1a存储指示一些输入数据集已经到达的信息,作为进度信息3。执行CEP的系统是这样的系统的示例。在该情况下,存储单元1a将指示一系列事件中的一些事件已经到达的信息存储作为进度信息3。
计算单元1b执行分配给机器1的多个处理。计算单元1b将每个处理的执行状态记录作为处理的进度信息,并且将进度信息存储在存储单元1a中。例如,计算单元1b针对多个输入数据集中的每个输入数据集执行该过程。具体地,计算单元1b每当接收多个输入数据集之一时,可以将指示输入数据集已经到达(即,输入数据集已被处理)的信息记录在进度信息3中。
计算单元1b在接收到指令“将由机器1执行的处理重新分配给机器2”(重新分配指令4)时,将与由该指令指定的处理对应的进度信息3传送给机器2。例如,计算单元1b可以从对处理的分配进行管理的预定设备接收重新分配指令4。可替代地,计算单元1b可以接收响应于用户在连接到机器1的预定输入装置上进行的输入操作而发出的重新分配指令4。
此处注意,用于执行各个处理的程序被预存储在例如存储单元1a/2a中。例如,当处理被分配给其自身的机器时,计算单元1b/2b将对应于该处理的、存储在HDD等中的程序存储在RAM中,然后执行该程序,从而使处理处于等待数据输入的状态。
当在将重新分配的处理的进度信息3传送给机器2期间接收到待在该处理中使用的数据5时,计算单元1b通过将数据5添加到进度信息3来将数据5传送给机器2。信息传送的时间段包括用于将信息发送到网络上的准备时间段(用于传送准备的时间段)。例如准备时间段包括用于序列化(serialization)、缓冲等的时间段。序列化是将进度信息3变换为在网络中使用的传输格式的过程。缓冲是将待传送的信息累积到预定量的过程。在将进度信息3从机器1传送到机器2的期间,对应于进度信息3的处理的执行被中断。
例如,在接收到重新分配指令4时,计算单元1b对存储在存储单元1a中的进度信息3进行序列化和缓冲,并且生成包括进度信息3的传送数据。当在传送数据的生成期间接收到数据5时,计算单元1b将数据5包括在传送数据中,从而生成传送数据6。传送数据6可以包括与进度信息3和数据5不同的信息。计算单元1b将传送数据6传送给机器2。
在接收传送数据6时,机器2从传送数据6获取进度信息3和数据5。机器2使用进度信息3和数据5,继续执行从机器1重新分配给机器2的处理。
根据第一实施方式的分布式处理系统,机器1接收重新分配指令4以将由机器1执行的处理重新分配给机器2(步骤S1)。在将处理的进度信息3传送给机器2期间,机器1接收待在该处理中使用的数据5(步骤S2)。然后,机器1将数据5添加到进度信息3,然后将数据5传送到机器2(步骤S3)。
此处,可以缩短在新分配的目标(上述示例中的机器2)处继续执行处理的延迟。在这方面,例如,使得机器1在进度信息3的传送期间能够继续执行重新分配处理被认为是可接受的。然而,有时存在包括数据5的、与处理关联的多个数据集不断被输入到机器1的情况。在该情况下,机器1不能够结束处理,因此将处理重新分配到机器2会花费很长的时间来完成。此外,尽管处理的重新分配意在减轻机器1的高处理负荷,但是机器1的负荷不断地加重。而且,这样的情况在机器1的处理负荷更高时更可能出现。此外,当机器1继续执行处理时,在进度信息3中产生由于更新而造成的差异。因此,机器1还必须将进度信息3中的差异继续提供给机器2,从而耗用更多的网络带宽。
另一方面,以下情形是可接受的:在机器1处中断重新分配的处理,并且在进度信息3的传送完成时将数据5传送给机器2,从而使得机器2继续执行该处理。然而,由于在传送端执行的过程(例如序列化和缓冲)以及在接收端执行的过程(例如反序列化),导致信息传送花费很长时间。因此,等待进度信息3的传送完成之后,接着再等待传送数据5可能使数据5到达机器2延迟,因此使在机器2处继续执行处理延迟。
鉴于上述问题,如果在将重新分配的处理的进度信息3传送到机器2期间接收待用于该处理的数据5,则机器1通过将数据5添加到进度信息3来将数据5传送给机器2。例如,即使在包括数据5的多个数据集不断输入到机器1的情况下,机器1能够将所述数据集(或数据集中的一些数据集)以及进度信息3提供给机器2。由于能够获取数据5与进度消息3,所以机器2利用进度信息3和数据5立刻开始执行被重新分配的处理。此外,由于处理在机器1处被中止,因此机器1不需要继续将进度信息3提供给机器2。因此,与在机器1处继续执行处理的情况相比,机器1的处理负荷迅速降低,并且也降低了网络带宽的使用。
此外,由于数据5以及进度信息3一起被提供给机器2,所以不需要等待进度信息3的传送完成之后,接着再等待传送数据5。因此,缩短了数据5到达机器2的时间,这缩短了在机器2处继续执行被重新分配的处理的延迟。
(b)第二实施方式
图2示出了根据第二实施方式的分布式处理系统。第二实施方式的分布式处理系统包括节点100、节点200、节点300,以及管理节点400。节点100、节点200、节点300,以及管理节点400连接到网络10,例如为局域网(LAN)。
网络10连接到可以是广泛的区域网络(例如广域网(WAN))和因特网的网络20。下列各项无线地或通过有线的方式连接到网络20:智慧城市21、物流传感器22、气象卫星23、移动装置24,以及智能传感器25。发出事件的各种其他类型的设备可以连接到网络20。第二实施方式的分布式处理系统使用节点100、节点200和节点300来执行CEP。
节点100、节点200和节点300是用于处理事件的服务器计算机,并且并行地处理由智慧城市21、物流传感器22、气象卫星23、移动装置24,及智能传感器25等发出的各类事件。节点100、节点200和节点300可以对从多个事件获得的处理结果(新事件)执行预定处理。
节点100、节点200和节点300能够使用CEP来实现如下功能。例如,节点100、节点200和节点300基于由通过网络20连接的智慧城市21和智能传感器25获取的功耗信息来控制智慧城市21的节电。此外,节点100、节点200和节点300基于从连接到网络20的各种类型的设备获取的交通情况信息来为移动装置24提供适用于例如移动装置24的用户以及他的/她的车的情况的导航帮助。节点100、节点200和节点300还基于从气象卫星23和雷达获取的事件来为移动装置24提供天气预报信息。此外,节点100、节点200和节点300提供关于是否存在对房子的入侵的报告,以及关于家庭成员(例如,儿童和老人)的所在之处的报告。节点100、节点200和节点300能够为用户提供各种其他类型的信息。
注意,由节点100、节点200和节点300响应于事件执行的处理在下文中被称为查询(query)。预先向节点100、节点200和节点300提供描述查询的内容的程序。程序可以被称为描述与事件对应的处理的规则或规则信息。在下面的描述中,有时使用术语“每个节点”来指代节点100、节点200和节点300中之一。
管理节点400是用于指定负责每个查询的事件处理的节点(即,将每个查询分配给节点)的服务器计算机。例如,管理节点400横跨100、节点200及节点300分发处理负荷。管理节点400根据各节点100、节点200和节点300的处理负荷对查询分配进行改变,从而平衡节点100、节点200和节点300之间的处理负荷。
图3示出了节点的硬件配置的示例。节点100包括处理器101、RAM102、HDD 103、通信单元104、图像信号处理单元105、输入信号处理单元106、磁盘驱动器107,以及装置连接单元108。各个单元连接到节点100的总线。节点200、节点300和管理节点400中的每个可以设置有与节点100相同的硬件单元。
处理器101控制节点100的信息处理。处理器101可以是多处理器。处理器101是例如CPU、DSP、ASIC、FPGA或前述两个或更多个的任何组合。
RAM 102是节点100的主存储装置。RAM 102临时存储待由处理器101执行的操作系统(OS)程序和应用程序的至少一部分。RAM 102存储有待由处理器101用于其处理的各种类型的数据。
HDD 103用作为节点100的次级存储装置,并且将数据磁性地写到内置磁盘,并且从所述盘磁性地读取数据。HDD 103存储有OS程序、应用程序及各种类型的数据。注意,节点100可以配备有不同类型的次级存储装置,例如闪速存储器和固态驱动器(SSD),或者可以配置有两个或更多个次级存储装置。
通信单元104是经由网络10与其他计算机进行通信的接口。通信单元104可以是有线接口或无线接口。
图像信号处理单元105根据来自处理器101的指令将图像输出到连接至节点100的显示器11。例如将阴极射线管(CRT)显示器或液晶显示器可以用作为监测器11。
输入信号处理单元106从连接到节点100的输入装置12获取输入信号,并且将信号输出给处理器101。例如指示装置(例如鼠标和触摸面板或键盘)可以用作为输入装置12。
磁盘驱动器107是使用例如激光来读取记录在光盘13上的程序和数据的驱动单元。光盘13的示例包括数字多功能光盘(DVD)、DVD-RAM、致密盘只读存储器(CD-ROM)、可记录CD(CD-R),以及可重写CD(CD-RW)。磁盘驱动器107根据来自处理器101的指令将从光盘13读取的程序和数据存储在RAM 102或HDD 103中。
装置连接单元108是用于将外围设备连接到节点100的通信接口。可以例如将存储装置14和读/写器15连接到装置连接单元108。存储装置14是具有与装置连接单元108通信的功能的存储介质。读/写器15是用于将数据写到作为卡类型存储介质的存储卡16和从存储卡16读取数据的装置。装置连接单元108例如根据来自处理器101的指令将从存储装置14或存储卡16读取的程序和数据存储在RAM 102或HDD 103中。
图4示出了查询分配的变化的示例。节点100、节点200和节点300分别包括CEP引擎E1、CEP引擎E2和CEP引擎E3。CEP引擎E1、CEP引擎E2和CEP引擎E3执行CEP。例如,CEP引擎E1、CEP引擎E2和CEP引擎E3中的每个CEP引擎由相应节点上执行存储在该节点的RAM中的程序的处理器来实现。可替代地,CEP引擎E1、CEP引擎E2和CEP引擎E3中的每个CEP引擎可以由设置在相应节点中的专用硬件实现。
例如,与被分配给节点100的查询对应的事件被输入到CEP引擎E1。CEP引擎E1生成新事件,作为查询的结果,并且输出该新事件。输出事件被传送到连接至网络20的各种类型的不同的节点或设备。此处,CEP引擎E1使得不同的节点执行不同的事件处理,或控制连接到网络20的设备。CEP引擎E2和CEP引擎E3以与CEP引擎E1相同的方式操作。
管理节点400监测节点100、节点200和节点300的处理负荷。例如假设节点200的处理负荷高于节点100的处理负荷,并且节点300的处理负荷低于节点100的处理负荷。在该情况下,管理节点400确定将已分配给节点200的查询重新分配给节点300。这降低了节点200的处理负荷,并且也平衡了节点100、节点200和节点300之间的处理负荷。当节点300的处理负荷相对增加而节点200的处理负荷相对减小时,管理节点400可以确定将已分配给节点300的查询重新分配给节点200。
管理节点400向节点100、节点200和节点300发出所确定的分配改变的指令。节点100、节点200和节点300中的每个节点根据指令来改变查询分配。例如,在查询从节点200被重新分配给节点300的情况下,节点100、节点200和节点300将与负责查询的节点有关的信息更新为节点300。因此,第二实施方式提供了这样的可扩展系统。例如,第二实施方式使得查询分配能够灵活地响应于节点的添加或删除。
每个查询具有与多个事件的到达情况有关的状态(查询状态)。根据第二实施方式,在查询分配改变前后保持查询状态。具体地,最初分配的节点为新分配的节点提供重新分配的查询的查询状态,从而将查询的执行传递给新分配的节点。此处注意,查询状态是第一实施方式的进度信息的示例。
图5示出了分布式处理系统的软件配置的示例。节点100包括查询存储单元110、管理信息存储单元120、查询执行管理单元130、查询状态传送管理单元140、查询状态接收管理单元150、事件传送管理单元160、事件接收管理单元170,以及通信单元180。可以使用RAM102或HDD103的存储区域的一部分来实现查询存储单元110和管理信息存储单元120。可以将查询执行管理单元130、查询状态传送管理单元140、查询状态接收管理单元150、事件传送管理单元160、事件接收管理单元170,及通信单元180实现为由处理器101执行的软件的模块。可替代地,各个单元可以是CEP引擎E1的功能的一部分(同样适用于节点200和节点300)。
查询存储单元110存储查询及其查询状态。查询存储单元110预存储要在分布式处理系统中使用的所有查询。查询存储单元110也存储每个查询的当前查询状态。查询存储单元110预存储与被包括在各个事件中的流名称和用于处理事件的查询的标识信息(查询名称)之间的对应有关的信息。
管理信息存储单元120存储查询配置表和传送列表。查询配置表表示每个节点的查询分配,并且也指示查询与每个查询的当前查询状态之间的对应。传送列表是分别存储有待传送的数据的容器。为每个目标准备一个传送列表。
查询执行管理单元130管理与输入事件对应的查询的执行。在执行查询的情况下,查询执行管理单元130更新存储在查询存储单元110中的查询的查询状态。
查询状态传送管理单元140从管理节点400接收指示将已分配给其自身节点(即,该情况下的节点100)的查询重新分配给不同的节点的重新分配指令。作为响应,查询状态传送管理单元140从查询存储单元110获取查询的查询状态。查询状态传送管理单元140对所获取的查询状态进行序列化,然后将经序列化的查询状态添加到要发送给目标节点的传送列表。序列化是将信息变换为可在网络10上传送的数据格式的处理。查询状态传送管理单元140继续缓冲传送列表,直到传送列表的数据大小达到预定数据大小为止,然后将被包括在传送列表中的数据传送给目标节点。
查询状态接收管理单元150从不同的节点接收从所述不同的节点重新分配给其自身节点的查询的查询状态。查询状态接收管理单元150将重新分配的查询与其查询状态之间的对应登记在查询配置表中,该查询配置表存储在管理信息存储单元120中。如稍后所描述的,由查询状态接收管理单元150从不同的节点接收的查询状态可以包括与该查询对应的一个或更多个事件。在该情况下,查询状态接收管理单元150请求查询执行管理单元130使用所述事件执行查询。
事件传送管理单元160管理事件传送。具体地,为了将被分配给不同节点的查询的一个或更多个事件传送给该不同节点,事件传送管理单元160对事件进行序列化,并且将事件登记在传送列表中。事件传送管理单元160将被包括在传送列表中的事件传送给该不同节点。
事件接收管理单元170管理事件接收。具体地,事件接收管理单元170根据下面的情况#1至情况#4之一来执行处理。
情况#1,其中所获取的事件对应于被分配给其自身节点的查询。在该情况下,事件接收管理单元170请求查询执行管理单元130使用所述事件来执行查询。
情况#2,其中所获取的事件对应于从其自身节点被重新分配给不同的节点的查询,并且查询的查询状态被管理以指示查询处于从其自身节点到不同的节点传输中。在该情况下,事件接收管理单元170将事件添加到查询状态的传送列表。
情况#3,其中所获取的事件对应于从不同节点被重新分配给其自身节点的查询,并且查询的查询状态被管理以指示查询处于从不同节点到其自身节点的传送中。在该情况下,事件接收管理单元170将事件作为查询的等待事件登记在查询配置表中,所述查询配置表存储在管理信息存储单元120中。
情况#4,其中所获取的事件对应于被分配给不同的节点的查询。在该情况下,事件接收管理单元170将事件传输给不同节点。
事件接收管理单元170基于存储在管理信息存储单元120中的查询配置表来确定上述情况#1至情况#4。注意,在情况#2和情况#3下,在查询状态被管理成指示“查询处在传送中”期间的时间帧包括用于将查询状态发送到网络上的准备时间段(用于序列化、缓冲等的传送准备时间段)。
通信单元180与节点200、节点300、管理节点400,以及连接到网络20的各种设备通信。不同设备与各个查询状态传送管理单元140、查询状态接收管理单元150、事件传送管理单元160以及事件接收管理单元170之间的上述数据传送和接收经由通信单元180进行。
管理节点400包括管理信息存储单元410和配置控制单元420。可以使用管理节点400的RAM或HDD的存储区域的一部分来实现管理信息存储单元410。可以将配置控制单元420实现为由管理节点400的处理器执行的软件的模块。
管理信息存储单元410存储查询配置表。配置控制单元420监测节点100、节点200和节点300的处理负荷。配置控制单元420根据节点100、节点200和节点300中的每个节点的处理负荷来改变节点100、节点200和节点300中的每个的查询分配,从而平衡节点100、节点200和节点300之间的处理负荷。在改变查询分配的情况下,配置控制单元420更新存储在管理信息存储单元410中的查询配置表。
当改变查询分配时,配置控制单元420向所有的节点100、节点200和节点300发出查询重新分配的指令。指令包括重新分配的查询,以及最初分配的节点的标识信息和新分配的节点的标识信息。指令也包括更新由每个节点保存的查询配置表的指令。可以由用户通过连接到管理节点400的预定输入装置来输入该查询重新分配指令。在该情况下,管理节点400响应于从用户输入的操作来指示每个节点改变查询分配。
图6示出了分布式处理系统的软件配置的示例(接续图5)。节点200包括查询存储单元210、管理信息存储单元220、查询执行管理单元230、查询状态传送管理单元240、查询状态接收管理单元250、事件传送管理单元260、事件接收管理单元270,以及通信单元280。
节点300包括查询存储单元310、管理信息存储单元320、查询执行管理单元330、查询状态传送管理单元340、查询状态接收管理单元350、事件传送管理单元360、事件接收管理单元370,以及通信单元380。
可以使用节点200的RAM或HDD的存储区域的一部分来实现查询存储单元210和管理信息存储单元220,并且使用节点300的RAM或HDD的存储区域的一部分来实现查询存储单元310和管理信息存储单元320。可以将查询执行管理单元230、查询状态传送管理单元240、查询状态接收管理单元250、事件传送管理单元260、事件接收管理单元270及通信单元280实现为由节点200的处理器执行的软件的模块,并且可以将查询执行管理单元330、查询状态传送管理单元340、查询状态接收管理单元350、事件传送管理单元360、事件接收管理单元370及通信单元380实现为由节点300的处理器执行的软件的模块。由于节点200和节点300的每个功能与节点100的具有相同名称的对应部件的功能相同,因此将省略对其的说明。
图7示出了事件的示例。事件X示出了事件的格式。事件X包括事件类型项、流名称项及内容项。对于事件类型项而言,事件的类型被登记。对于流名称项而言,与事件对应的流的标识信息被登记。对于内容项而言,指示事件的内容的信息被登记。
事件X1是事件X的示例。例如,事件X1存储有事件类型为“P”、流名称为“输入流”、并且内容为“1000W”的信息。该信息指示事件X1的类型是表示与电功率有关的信息的“P”;对应于事件X1的流名称是“输入流”;以及事件X1的内容是检测到的功耗“1000W”。
图8示出了查询的示例。查询111存储在查询存储单元110中。查询111是以所谓的Esper的事件查询语言(EPL)的形式的查询描述示例。查询111限定了,如果事件以三个流A→B→C的顺序输入,则数据(事件)被输出到数据流。因此,每个查询能够限定用于各种事件的条件。在下面的描述中,可以将具有流名称“A”的事件表示为事件A。
图9示出了查询状态的示例。查询状态112是查询111的查询状态的示例。查询状态112存储在查询存储单元110中。查询状态112表示对于查询111而言,事件A和事件B已经到达,但是事件C尚未达到(即,等待事件C的到达的状态)。节点100、节点200和节点300保存每个查询的当前查询状态。每个查询与其查询状态之间的对应通过由节点100、节点200和节点300中的每个保存的查询配置表管理。
图10示出了查询配置表的第一示例。查询配置表121存储在管理信息存储单元120中。根据图10的示例,查询配置表121为表的形式,然而,作为替代可以使用不同的数据结构。例如,查询配置表121可以是使用查询名作为关键字的哈希映射(HashMap)。查询配置表121包括名为查询名称、分配节点名称、状态、查询状态引用、锁定,以及等待事件的栏。
在查询名称栏中,每个字段包括查询的标识信息。在分配节点名称栏中,每个字段包括分配(设置)有相应查询的节点(负责节点)的名称。在状态栏中,每个字段包括相应的查询的当前状态。
下面是每个查询的可能状态:(1)处在操作中(查询可在负责节点中执行);(2)正迁移到不同的节点(响应于查询分配的变化,查询状态从最初分配的节点传送到新分配的节点);以及(3)已迁移到不同节点(已经完成将查询状态从最初分配的节点传送到新分配的节点)。
在查询状态引用栏中,每个字段包括相应查询的查询状态的指针。然而,应注意,在查询状态不在其自身节点中被管理的情况下,则登记术语“不存在于节点中”。
在锁定栏中,每个字段包括指示相应查询的查询状态是否被锁定的信息。在等待事件栏中,每个字段包括用于相应查询的等待事件。等待事件是在完成将查询的查询状态从初始分配的节点传送到其自身节点之前,其自身节点已获取被重新分配给其自身节点的查询的事件。
例如,下列信息被登记在查询配置表121中:查询名称为“Query1”的;分配节点名称为“节点100”;状态为“正迁移到节点200”;查询状态引用为“&Query1State”;锁定为“解除锁定”;以及等待事件”为“空(null)”。该信息指示由“Query1”标识的查询当前被分配给节点100,并且查询的分配正经历从节点100到节点200的变化。该信息也指示查询的查询状态由指针“&Query1State”指向;查询状态未被锁定;以及不存在用于查询的等待事件。
图11示出了查询配置表的第二示例。查询配置表221存储在管理信息存储单元220中。图11示出了在与上述查询配置表121相同的时间点获得的查询配置表221的登记内容。查询配置表221包括与查询配置表121相同的栏项目,因此省略了对其的说明。
例如,对于由“Query1”标识的查询而言,查询配置表221与查询配置表121的不同之处在于:查询状态引用为“不存在于节点中”,并且等待事件为“α5、α6”。该信息指示查询的分配正经历变化(查询状态为正迁移到节点200),并且其自身节点(节点200)不具有查询状态。信息也指示,对于该查询,事件α5和事件α6被获取作为等待事件。
此外,对于由“Query8”标识的查询而言,查询配置表221与查询配置表121的不同之处在于:查询状态引用为“&Query8State”。这是因为节点200负责查询,因此保存查询的查询状态。
图12示出了查询配置表的第三示例。查询配置表321存储在管理信息存储单元320中。图12示出了在与上述查询配置表121和查询配置表221在相同的时间点获得的查询配置表321的登记内容。查询配置表321包括与查询配置表121相同的栏项目,因此省略了对其的说明。
例如,对于由“Query1”标识的查询而言,查询配置表321与查询配置表121和查询配置表221的不同之处在于:分配节点名称为“节点200”,并且状态为“操作中”。这是因为节点300在以下查询状态的传送和接收过程中不起作用:该查询状态与对查询名称为Query1”的查询的分配的改变相关联。也就是说,当从管理节点400接收查询重新分配指令时,每个节点在确定其自身节点不涉及与重新分配关联的查询状态的传送和接收后可以立即改变相应的分配节点名称。
此外,对于由“Query10”标识的查询而言,查询配置表321与查询配置表121和查询配置表221的不同之处在于:查询状态引用为“&Query10State”。这是因为节点300负责查询,因此保存该查询的查询状态。
注意,管理节点400保存与查询配置表121、查询配置表221及查询配置表321类似的查询配置表。在管理节点400的查询配置表中,每个节点的各个查询的最新分配状态被登记。然而,应注意,由管理节点400保存的查询配置表不需要管理与查询状态引用、锁定及等待事件有关的信息。
图13示出了传送数据管理结构的示例。传送数据管理结构D是用于将传送列表中的一个查询的查询状态存储在其中的结构。此处示出的数据结构是在传送列表为双向列表的情况下使用的数据结构,然而,传送列表不一定必须是双向的,并且传送列表可以是例如单向的。传送数据管理结构D包括前向项、后向项、查询状态项,以及事件项。
前向是提供对之后链接的传送数据管理结构的引用的指针(&SendBufStructure)。后向是提供对之前链接的传送数据管理结构的引用的指针(&SendBufStructure)。查询状态是提供对传送目标查询状态引用的指针(&QueryState)。事件是提供对存储一个或更多个事件的数组的引用的指针(&Events[])。
图14示出了传送列表的示例。传送列表122存储在管理信息存储单元120中,并且用于将信息从节点100传送到节点200。传送列表122是第一实施方式的传送数据6的示例。为每个目标节点生成这样的传送列表。当将信息从节点100传送到与节点200不同的节点时,节点100生成不同的传送列表。
传送列表122是双向列表,其中多个传送数据管理结构D(在下文中称为列表元素)是可链接的。传送列表122包括列表元素122a、列表元素122b,以及列表元素122c。列表元素122a是传送列表122的头部(Head)。此外,列表元素122a包括指示传送列表122是否被锁定的信息(例如,标记)(信息被设置在锁定项中)。
列表元素122b是列表元素122a后面的列表元素。列表元素122c是列表元素122b后面的列表元素。列表元素122b和列表元素122c中的每个单独地包括前向项、后向项、查询状态项,以及事件项。在下文描述具体设定内容。
对于列表元素122b而言,在各个项目中设定如下信息。在前向项中设定提供到列表元素122c的链接(前向链接)的指针。在后向项中设定提供到列表元素122a的链接(后向链接)的指针。在查询状态项中设定提供对由“Query1”标识的查询的查询状态(Query1State)的引用的指针。查询状态也包括指示其为由“Query1”标识的查询的查询状态的信息。在事件项中设定提供已接收到的用于查询的一列事件([α1、α2、α3])的引用的指针。
对于列表元素122c而言,在各个项目中设定如下信息。由于之后的列表元素不存在,所以在前向项中设定为空(null)。在后向项中设定提供到列表元素122b的链接的指针。在查询状态项中设定提供对由“Query13”标识的查询的查询状态(Query13State)的引用的指针。查询状态也包括指示其为由“Query13”标识的查询的查询状态的信息。由于不存在被接收的用于查询的事件,所以在事件中设定为空(null)。
接下来,将描述根据第二实施方式的当改变查询分配时所执行的处理过程。假设在下面的描述中查询从节点100被重新分配给节点200。然而,应当注意,类似的过程发生在查询在其他节点之间被重新分配的情况下。
图15是示出查询状态传送管理的示例的流程图。接下来根据流程图中的步骤编号来描述图15的处理。在查询从节点100被重新分配给节点200的情况下,下面的过程由节点100进行。
(步骤S11)查询状态传送管理单元140从管理节点400接收指令,以便将已分配给节点100的查询(例如,具有查询名称“Query1”的查询)重新分配给节点200。查询状态传送管理单元140操纵查询配置表121,以锁定重新分配目标查询的查询状态(与该查询对应的条目的锁定栏中的“解除锁定”变为“锁定”)。
(步骤S12)查询状态传送管理单元140操纵查询配置表121,以将对应于查询的条目的状态栏中的“操作中”变为“正迁移到节点200”(新分配节点200也在其查询配置表221中进行相同的设置变化)。从此刻开始,查询的执行被中断直到重新分配完成为止,然后在节点200处继续查询的执行。
(步骤S13)查询状态传送管理单元140生成传送数据管理结构D。
(步骤S14)查询状态传送管理单元140参照查询配置表121,使用设定在对应于查询的条目的查询状态引用栏中的指针来获取查询状态。查询状态传送管理单元140操纵查询配置表121,以将该条目的查询状态引用栏中的信息变为在图13中生成的传送数据管理结构D的指针。
(步骤S15)查询状态传送管理单元140操纵查询配置表121,以解除对重新分配目标查询的查询状态的锁定(该条目的锁定栏中的“锁定”变为“解除锁定”)。
(步骤S16)查询状态传送管理单元140对在步骤S14中获取的查询状态进行序列化。
(步骤S17)查询状态传送管理单元140将序列化的查询状态登记在在步骤S13中生成的传送数据管理结构D中。具体地,查询状态传送管理单元140将查询状态的指针登记在传送数据管理结构D中。
(步骤S18)查询状态传送管理单元140锁定传送列表122。
(步骤S19)查询状态传送管理单元140将传送数据管理结构D(具有登记的查询状态)链接到传送列表122。
(步骤S20)查询状态传送管理单元140确定传送列表122的总数据大小是否大于或等于阈值。如果总数据大小大于或等于阈值,则查询状态传送管理单元140将过程移动到步骤S21。如果总数据大小小于阈值,则查询状态传送管理单元140将过程移动到步骤S24。注意,例如用户可以将阈值设定为取决于通信环境的值。
(步骤S21)查询状态传送管理单元140操作查询配置表121,以锁定登记在传送列表122中的所有的查询状态。此处,登记在传送列表122中的查询状态是各个条目具有设定在查询配置表121的状态栏中的“正迁移到节点200”的查询状态。
(步骤S22)查询状态传送管理单元140将登记在传送列表122中的查询状态之一通过网络10发送给节点200。查询状态传送管理单元140操纵查询配置表121以对与发出的查询状态对应的条目进行如下变化:将分配节点名称栏中的信息(从“节点100”)变为“节点200”;将状态栏中的信息变为“迁移完成”;以及将查询状态引用栏中的信息变为“不存在于节点中”。随后,查询状态传送管理单元140操纵查询配置表121,以解除对条目的查询状态的锁定。
(步骤S23)如果,在传送列表122中,一个或更多个事件附加到在步骤S22中传送的查询状态,则管理单元140也将所述事件传送给节点200。注意,步骤S22和步骤S23针对登记在传送列表122中每个查询状态而执行。在多个查询状态被登记在传送列表122中的情况下,查询状态传送管理单元140针对查询状态中的每个查询状态重复执行步骤S22和步骤S23。
(步骤S24)查询状态传送管理单元140解除对传送列表122的锁定。
如上所述,如果传送列表122包括与重新分配的目标查询关联的事件,则节点100将所述事件以及查询的查询状态一起传送给节点200。
随后,例如,查询状态传送管理单元140从管理节点400接收完成查询重新分配的通知。例如,查询状态传送管理单元140在接收到通知时,在查询配置表121中将对应于查询的条目的状态栏中的信息(从“迁移完成”)变为“操作中”。
如上所述,在步骤S12中,在查询状态的传送和接收过程中不起作用的节点300可以响应于步骤S11中的指令在查询配置表321中将对应于查询的条目的分配节点名称栏中的信息变为“节点200”。类似地,管理节点400可以在发出查询重新分配指令时在其自身的查询配置表中将对应于查询的条目的分配节点名称栏中的信息变为“节点200”。
图16是示出事件接收管理(在最初分配的节点处)的示例的流程图。接下来根据流程图中的步骤编号来描述图16的处理。图16示出节点100作为示例的情况,然而,其他节点遵循类似的过程。
(步骤S31)事件接收管理单元170获取事件。已经发出事件的源可以是连接到网络20的设备或节点100、节点200和节点300之一。事件接收管理单元170对获取的事件进行反序列化(在事件发出源是节点100的情况下可以不进行反序列化)。
(步骤S32)事件接收管理单元170从被包括在事件中的流名称获取查询的标识信息(查询名称)。查询存储单元110存储有与每个流名称和以下查询的查询名称之间的对应有关的信息:所述查询用于处理包括流名称的事件。因此,事件接收管理单元170通过参照所述信息,能够基于流名称来获取查询名称。事件接收管理单元170使用查询名称作为关键字,针对对应于事件的条目来搜索查询配置表121。
(步骤S33)事件接收管理单元170操纵查询配置表121,以锁定条目的查询状态。
(步骤S34)事件接收管理单元170参照查询配置表121来确定对条目的查询是否可执行。如果查询是可执行的,则事件接收管理单元170将过程移动到步骤S35。如果查询是不可执行的,则事件接收管理单元170将过程移动到步骤S36。当其自身节点负责查询并且状态是“操作中”时,查询是可执行的。另一方面,当其自身节点不负责查询时,或者即使其自身节点负责查询而状态不是“操作中”时,查询是不可执行的。
(步骤S35)查询执行管理单元130使用所获取的事件来执行查询,然后根据执行结果来改变查询的查询状态。查询执行管理单元130操纵查询配置表121,以解除对查询的查询状态的锁定。随后,查询执行管理单元130结束过程。
(步骤S36)事件接收管理单元170参照查询配置表121来确定与获取的事件对应的查询的查询状态是否被缓冲。在查询状态被缓冲的情况下,事件接收管理单元170将处理移动到步骤S37。如果查询状态未被缓冲,则事件接收管理单元170将处理移动到步骤S42。通过参照与查询配置表121中的查询对应的条目的状态栏中的信息来确定查询状态是否被缓冲。如果其自身节点负责查询并且状态是“正迁移到不同的节点”(例如,节点200),则查询状态被缓冲。如果状态是不同于“正迁移到不同节点”的状态,则查询状态未被缓冲。
(步骤S37)事件接收管理单元170对所获取的事件进行序列化。
(步骤S38)事件接收管理单元170在传送列表中锁定到传送数据管理结构D(列表元素)的链接,在该传送数据管理结构D中登记有对应于事件的查询的查询状态。
(步骤S39)事件接收管理单元170将获取的事件登记在传送数据管理结构D中(事件链接起来)。
(步骤S40)事件接收管理单元170解除对传送数据管理结构D的链接的锁定。
(步骤S41)事件接收管理单元170操纵查询配置表121,以解除对查询的查询状态的锁定,然后结束过程。
(步骤S42)事件接收管理单元170操纵查询配置表121,以解除对查询的查询状态的锁定。
(步骤S43)事件接收管理单元170使得事件传送管理单元160传送所获取的事件。稍后将详细描述由事件传送管理单元160执行的处理。
如上所述,当事件接收管理单元170获取事件时,如果用于处理事件的查询的查询状态正处在传送过程中,则事件接收管理单元170在传送列表中将事件登记在存储查询状态的列表元素中(步骤S37至步骤S40)。在这方面,例如可以通过使用被称为“聚集”的应用编程接口(API)以低成本实现通过查询状态传送管理单元140和事件接收管理单元170来生成传送列表的上述处理。
此外,如果事件与被分配给其自身节点的查询关联,于是查询状态未处在传送中,则以通常的方式执行查询(步骤S35)。此外,当获取的事件与被分配到不同的节点的查询相关联时,则通过事件传送管理单元160将事件传送给不同的节点。(步骤S43)。
图17是示出查询状态接收管理的示例的流程图。接下来根据流程图中的步骤编号来描述图17的处理。在查询从节点100被重新分配给节点200的情况下,下面的过程由节点200执行。注意,在步骤S51之前,节点200已从管理节点400接收到查询重新分配指令,其指示查询从节点100重新分配给节点200。节点200在接收到查询重新分配指令时,在查询配置表221中将在查询重新分配指令中指定的查询状态设定为“正迁移到节点200”。
(步骤S51)查询状态接收管理单元250从节点100接收重新分配目标查询(例如,具有查询名称“Query1”的查询)的查询状态。查询状态接收管理单元250对所接收的查询状态进行反序列化,并且将该查询状态存储在查询存储单元210中。
(步骤S52)查询状态接收管理单元250确定一个或更多个事件是否被附加到所接收的查询状态。如果事件被附加,则查询状态接收管理单元250将过程移动到步骤S53。如果事件未被附加,则查询状态接收管理单元250将过程移动到步骤S55。
(步骤S53)查询状态接收管理单元250对附加的事件(例如,事件α1、α2、α3)进行反序列化,并且将反序列化的事件输出给查询执行管理单元230。
(步骤S54)查询执行管理单元230使用所获取的事件和查询状态来执行查询,然后改变存储在查询存储单元210中的查询状态。
(步骤S55)查询状态接收管理单元250参照存储在管理信息存储单元220中的查询配置表221来搜索查询的条目。
(步骤S56)查询状态接收管理单元250锁定条目。
(步骤S57)查询状态接收管理单元250将存储在查询存储单元210中的查询状态的指针登记在条目的查询状态引用栏下的字段中。由指针指示的查询状态是在步骤S54未执行的情况下在步骤S51中获得的的查询状态。另一方面,如果步骤S54已执行,则由指针指示的查询状态是根据步骤54的执行结果的查询状态。
(步骤S58)查询状态接收管理单元250确定在条目中是否存在一个或更多个等待事件。如果存在一个或更多个等待事件,则查询状态接收管理单元250将过程移动到步骤S59。如果不存在一个或更多个等待事件,则查询状态接收管理单元250将过程移动到S60。
(步骤S59)查询执行管理单元230使用等待事件(例如,α5和α6)和当前查询状态来执行查询,然后改变查询状态。
(步骤S60)查询状态接收管理单元250操纵查询配置表221,以针对在步骤S55的搜索中找到的条目进行如下变化:将在分配节点名称栏中的信息(从“节点100”)变为“节点200”;以及将状态栏中的信息变为“迁移完成”。
(步骤S61)查询状态接收管理单元250解除对条目的锁定。
因此,如果一个或更多个事件被附加到接收的查询状态,则查询状态接收管理单元250使用所述事件和查询状态来执行查询,然后更新查询状态。此外,如果存在用于查询的一个或更多个等待事件,则查询状态接收管理单元250使用等待事件来执行查询,然后更新查询状态。
在这方面,有时存在以下情况:待在查询中使用的事件在等待事件之前发生,但是尚未到达节点200(稍后描述)。在该情况下,也使得节点200能够使用查询状态和等待事件来执行查询。
在步骤S51后的某一时间,查询状态接收管理单元250将查询状态的适当接收通知给管理节点400。然后,在接收到来自管理节点400的对所述通知的响应(即,完成查询重新分配的通知)时,例如,查询状态接收管理单元250在查询配置表221中将对应于查询的条目的状态栏中的信息改为“操作中”(如果状态在步骤S60之前已为“操作中”,则在步骤S60中不需要将该状态改变为“迁移完成”)。
图18是示出事件接收管理(在新分配的节点处)的示例的流程图。接下来将根据流程图中的步骤编号来描述图18的处理。图18示出了节点200作为示例的情况,然而,其他节点遵循类似的过程。
(步骤S71)事件接收管理单元270获取事件。已经发出事件的源可以是连接到网络20的设备,或节点100、节点200和节点300之一。事件接收管理单元270对获取的事件进行反序列化(在事件发出源是节点200的情况下可以不进行反序列化)。
(步骤S72)事件接收管理单元270从被包括在事件中的流名称获取查询的标识信息(查询名称)。查询存储单元210存储有与每个流名称和以下查询的查询名称之间的对应有关的信息,所述查询用于处理包含流名称的事件。因此,事件接收管理单元270通过参照信息,能够基于流名称来获取查询名称。事件接收管理单元270使用查询名称作为关键字,针对与事件对应的条目来搜索查询配置表221。
(步骤S73)事件接收管理单元270操纵查询配置表221,以锁定条目的查询状态。
(步骤S74)事件接收管理单元270通过参照查询配置表221来确定条目的查询是否是可执行的。如果查询是可执行的,则事件接收管理单元270将过程移动到步骤S75。如果查询是不可执行的,则事件接收管理单元270将过程移动到步骤S76。在其自身节点负责查询并且状态是“操作中”或“迁移完成”时,查询是可执行的。另一方面,在其自身节点不负责查询时或者即使其自身节点负责查询但是状态既不是“操作中”也不是“迁移完成”的情况下,查询是不可执行的。
(步骤S75)查询执行管理单元230使用获取的事件来执行查询,然后改变存储在查询存储单元210中的、查询的查询状态。查询执行管理单元230操纵查询配置表221,以解除对查询的查询状态的锁定。随后,查询执行管理单元230结束过程。
(步骤S76)事件接收管理单元270通过参照查询配置表221来确定与获取的事件对应的查询是否等待查询状态的到达。如果查询在等待查询状态的到达,则事件接收管理单元270将过程移动到步骤S77。如果查询不等待查询状态的到达,则事件接收管理单元270将过程移动到步骤S79。当在对应于查询状态的条目的状态栏下的字段中设定“正迁移到其自身节点(在该情况下,为节点200)”时,查询等待查询状态的到达。另一方面,当在前述字段中设定不同于“正迁移到其自身节点”的信息时,查询不等待查询状态的到达。
(步骤S77)事件接收管理单元270将获取的事件(例如,α5和α6)登记在查询配置表221的等待事件栏下的条目的字段中。
(步骤S78)事件接收管理单元270操纵查询配置表221,以解除对条目的查询状态的锁定。随后,事件接收管理单元270结束过程。
(步骤S79)事件接收管理单元270操纵查询配置表221,以解除对与获取的事件对应的查询的查询状态的锁定。
(步骤S80)事件接收管理单元270使得事件传送管理单元260传送获取的事件。
如上所述,当获取与等待查询状态的到达的查询对应的事件时,事件接收管理单元270将事件作为等待事件登记在查询配置表221中(步骤S76和步骤S77)。在获取与分配给其自身节点但是不等待查询状态的到达的查询对应的事件时,事件接收管理单元270按照通常的方式执行查询(步骤S75)。在获取与分配给不同节点的查询对应的事件时,事件接收管理单元270使得事件传送管理单元260将事件传送给所述不同的节点(步骤S80)。
接下来描述的是由各个事件传送管理单元160、事件传送管理单元260和事件传送管理单元360进行的事件传送管理的过程。下面的描述示出了由事件传送管理单元160执行的过程,但是事件传送管理单元260和事件传送管理单元360中的每个遵循类似的过程。
图19是示出事件传送管理的示例的流程图。接下来根据流程图中的步骤编号来描述图19的处理。
(步骤S81)事件传送管理单元160获取事件。发出事件的源可以是连接到网络20的设备或节点100、节点200和节点300之一。如上所述,事件传送管理单元160可以从事件接收管理单元170获取与分配给不同的节点的查询对应的事件。事件传送管理单元160对事件进行序列化。
(步骤S82)事件传送管理单元160通过参照查询配置表121确来定将事件传送给其的节点。注意,与图16的步骤S32和图18的步骤S72一样,事件传送管理单元160基于被包括在事件中的流名称来确定用于处理事件的查询的查询名称。负责具有所述查询名称的查询的节点是事件被发送给其的节点。事件传送管理单元160锁定对应于传送目标节点的传送列表。
(步骤S83)事件传送管理单元160将序列化的事件添加到传送列表。
(步骤S84)事件传送管理单元160确定传送列表的总数据大小是否超过或等于阈值。如果总数据大小大于或等于阈值,则事件传送管理单元160将过程移动到步骤S85。如果总数据大小小于阈值,则事件传送管理单元160将过程移动到步骤S86。注意,可以例如由用户根据通信环境来将阈值设定为某个值。
(步骤S85)事件传送管理单元160将传送列表中的事件通过网络10发送给传送目标节点。在这方面,如果其他事件的数据存储在传送列表中,则也传送该数据。
(步骤S86)事件传送管理单元160解除对传送列表的锁定。
因此,事件传送管理单元160在获取与未分配给其自身节点的查询对应的事件时,将事件传送给负责查询的节点。
图20示出了查询状态传送示例的第一部分。图20示出了具有查询名称“Query1”的查询从节点100被重新分配给节点200的示例。在从管理节点400接收到指示查询从节点100重新分配给节点200的查询重新分配指令时,节点100对查询的查询状态进行序列化,然后将查询状态添加到传送列表122。在节点100处,查询状态被管理成处于传送中。节点100保持将待传送的数据添加到传送列表122(即,缓冲)直到传送列表122达到预定大小为止。
(1)节点100在缓冲期间顺序地获取事件α1、事件α2和事件α3。节点100确认事件α1、事件α2和事件α3是与重新分配目标查询对应的事件。
(2)节点100对事件α1、事件α2和事件α3进行序列化,然后将事件α1、事件α2和事件α3按照顺序添加到在传送列表122中的查询的列表元素。
图21示出了查询状态传送示例的第二部分。图21示出了在图20的处理后的处理。注意,除了上述事件α1、事件α2和事件α3之外,事件α4、事件α5、事件α6和事件α7也是待在具有查询名称“Query1”的查询中使用的事件。
(3)当传送列表122的数据大小达到阈值时,节点100将传送列表122的内容通过网络10发送给节点200。此处,事件α1、事件α2和事件α3以及具有查询名称“Query1”的查询的查询状态一起被发送。
(4)接下来,节点100从节点300获取事件α4。该情况在以下时刻发生:当节点300在查询重新分配指令到达节点300之前通过网络10发出事件α4时。具体地,当节点300发出事件α4时,在查询配置表321中节点100仍为负责对应于事件α4的查询的节点。因此,节点100需要在比事件α1、事件α2和事件α3的传送更晚的时刻来将事件α4传送给节点200。
(5)节点200在由节点100传送的传送列表122的内容到达节点200之前获取事件α5和事件α6。在该情况下,节点200将事件α5和事件α6保存作为等待事件。
(6)节点200从节点300获取事件α7。这样的情况在以下时刻发生:当节点300在查询重新分配指令到达节点300之后通过网络10发出事件α7时(也就是说,在节点300的查询配置表321中,负责对应于事件α7的查询的节点已变为节点200)。
根据上述示例,在从节点100接收到查询状态及事件α1、事件α2和事件α3时,节点200使用查询状态及事件α1、事件α2和事件α3来执行具有查询名称“Query1”的查询。随后,节点200使用作为等待事件的事件α5和事件α6来执行查询。此外,节点200按照到达的顺序使用事件α4和事件α7来执行查询。
因此,事件α1、事件α2和事件α3的处理以及查询状态一起被发送给节点200。因此,节点200在获取查询状态后能够使用事件α1、事件α2和事件α3来立即执行具有查询名称“Query1”的查询。也就是说,与事件α1、事件α2和事件α3没有连同查询状态一起被发送给节点200的情况相比,这可以缩短在节点200处继续执行查询的时间。
此处注意,根据第二实施方式的方法,例如可以按照事件α1、事件α2、事件α3、事件α5、事件α6、事件α4和事件α7的顺序使用事件来执行查询。另一方面,一些查询注重事件的时间顺序。例如,有时存在以下情形:如果事件α1、事件α2、事件α3、事件α4、事件α5、事件α6和事件α7以该顺序发生,则希望按照时间顺序使用这些事件来执行相应的查询(例如,在严格检测事件之间的时间差异的科学测量的情况下)。鉴于该情况,每个查询可用包括对是否需要严格按照时间顺利使用事件来执行查询或者是否允许按照与时间顺序不同的顺序使用事件来执行查询进行限定的信息。
对于允许按照与时间顺序不同的顺序使用事件来执行每个查询的情形,可以将指示所述情况的注解(即,表示说明性注释的元数据,该元数据例如为字符串,诸如“@XXX”)添加到查询。例如,如果注解被包括在查询中,则事件连同查询状态一起以上述方式被传送。另一方面,如果注解未被包括在查询中,则例如各个节点暂停向负责查询的节点传送与查询对应的所有事件,直到完成查询状态的发送为止,并且使得负责节点能够在完成查询状态的传送后以时间顺序来执行事件中的每个事件。
以该方式,可以支持通过传送事件连同查询状态来执行查询的方法和严格按照时间顺序使用事件来执行查询的方法二者。尤其是当事件能够在不考虑事件的时间顺序的情况下被处理时,在不等待尚未到达的事件(事件α4)的情况下处理等待事件(上述示例中的事件α5和事件α6)。这使得新分配节点能够快速继续进行事件处理。
此外,当事件被附加到查询状态时,在使用等待事件前首先使用附加的事件。以该方式,尽管允许以非时间顺序来处理事件,但是查询执行在某种程度上按照事件的时间顺序来进行。这是因为附加到查询状态的事件更可能在等待事件发生前被生成。这样的设置在以下情形下是有效的:允许在事件发生的时间差异相对较小的情况下搅乱事件的顺序,但是不允许在事件发生的时间差异相对较大的情况下搅乱事件的顺序。
注意,对于图21中的(4),如果在完成将被包括在传送列表122中的所有信息发送给网络10之前,事件α4到达并且已准备好传送事件α4,则可以将事件α4的信息插入到所述所有信息中并且被发出。例如,可以在其他信息之前发出事件α4,以使得节点100为节点200提供事件α1、事件α2、事件α3和事件α4以及查询状态。
图22是示出查询重新分配的第一示例的时序图。接下来根据时序图中的步骤编号来描述图22的处理。
(步骤ST11)管理节点400向节点100、节点200和节点300中的每个节点发出将查询从节点100重新分配给节点200的指令。在此时,指令尚未到达节点100、节点200和节点300。
(步骤ST12)节点300获取新事件(事件发生在节点300处)。该新事件是对应于重新分配的查询的事件。
(步骤ST13)节点300参照查询配置表321来确定节点100是负责查询的节点。节点300将所获取的事件发送给节点100。在此时,事件尚未到达节点100。
(步骤ST14)节点100、节点200和节点300中的每个节点接收在步骤ST11中发出的指令。节点100和节点200分别操纵查询配置表121和查询配置表221,以将查询在状态栏中的信息变为“正迁移到节点200”。节点300在查询配置表321中将查询在分配节点名称中的信息变为“节点200”。节点100对指定查询的查询状态进行序列化,然后将登记有查询状态的列表元素添加到传送列表122。随后,节点100从节点300接收对应于查询的事件。节点100对事件进行序列化,并且将序列化的事件添加到具有查询状态的列表元素。
(步骤ST15)节点100保持缓冲,直到传送列表122的数据大小超过或等于阈值为止。
(步骤ST16)当传送列表122的数据大小超过或等于阈值时,节点100将传送列表122的内容发送给节点200。在此时,节点100也发出在步骤ST14中登记在传送列表122中的查询状态。
(步骤ST17)节点100也发出在步骤ST14中添加到查询状态的事件。
(步骤ST18)在从节点100接收查询状态时,节点200对查询状态进行反序列化。在从节点100接收到附加到查询状态的事件时,节点200对事件进行反序列化。
(步骤ST19)节点200将查询状态的迁移完成通知给管理节点400。
(步骤ST20)节点200使用在步骤ST18中获取的查询状态和事件来执行从节点100重新分配给节点200的查询。
如上所述,可以在查询重新分配指令到达节点300前,将对应于重新分配的查询的事件从节点300发送到节点100。在该情况下,直到新分配节点200开始使用事件来执行重新分配的查询为止的延迟时间(被称为“事件传输延迟”)对应于从步骤ST12的开始到步骤ST18的完成的时间段。注意,管理节点400可以在步骤ST19后将查询重新分配的完成通知给节点100、节点200和节点300。
图23是示出比较性查询重新分配的第一示例的时序图。接下来根据时序图中的步骤编号来描述图23的处理。图23呈现了相对于图22的比较示例,其中未采用第二实施方式的方法。在图23的描述中,出于描述的目的,用与第二实施方式的那些参考标记相同的参考标记来指定各个节点。
(步骤ST21)管理节点400向节点100、节点200和节点300中的每个节点发出将查询从节点100重新分配给节点200的指令。在此时,指令尚未到达节点100、节点200和节点300。
(步骤ST22)节点300获取新事件(事件发生在节点300处)。该新事件是对应于重新分配的查询的事件。
(步骤ST23)节点300确定节点100是负责查询的节点。节点300将获取的事件发送给节点100。在此时,事件未到达节点100。
(步骤ST24)节点100、节点200和节点300中的每个节点接收步骤ST21中发出的指令。节点100对指定查询的查询状态进行序列化,然后将序列化的查询状态添加到传送数据。随后,节点100从节点300接收对应于查询的事件。
(步骤ST25)节点100保持缓冲,直到传送数据的数据大小超过或等于阈值为止。
(步骤ST26)当传送数据的数据大小超过或等于阈值时,节点100将传送数据的内容发送给节点200。传送数据包括重新分配的查询的查询状态,但是不包括在步骤ST24中接收的事件。
(步骤ST27)在从节点100接收到查询状态时,节点200对查询状态进行反序列化。
(步骤ST28)节点200向管理节点400通知查询状态的迁移已完成。
(步骤ST29)管理节点400向节点100、节点200和节点300中的每个通知查询重新分配已完成。节点100、节点200和节点300单独地接收所述通知。
(步骤ST30)节点100将从节点300接收的事件传送给负责查询的新分配的节点200(注意,还针对该事件进行序列化和缓冲)。在从节点100接收到事件后,节点200对事件进行反序列化。
(步骤ST31)节点200使用从步骤ST27获取的查询状态和在步骤ST30中获得的事件来将查询从节点100重新分配给节点200。
在上述比较示例的情况下,直到节点200结束接收已在节点300处发生的事件为止的事件传输延迟对应于从步骤ST22的开始到步骤ST30的完成的时间段。根据比较示例,与图22的情况相比,事件传输延迟由于与从步骤ST28到步骤ST30对应的额外时间段而更长。尤其是,尽管未在图23中示出,但是步骤ST30与步骤ST24至步骤ST26的情况一样包括多个处理阶段,例如锁定等待、缓冲、传输、反序列化、登记,以及解除等待的锁定。因此,比较示例的事件传输延迟也包括用于处理这些阶段的延迟。
另一方面,在图22的情况下,与步骤ST28至步骤ST30对应的延迟时间被消除。因此,与比较示例相比,在图22的情况下可以缩短在节点200处继续执行重新分配查询的延迟。
注意,如果在步骤ST24和步骤ST25中传送数据的数据大小未达到阈值,则在步骤ST26中,自节点300发送的事件可以连同查询状态一起被传送给节点200。然而,应注意,在比较示例的情况下,传送数据仅被缓冲。也就是说,与第二实施方式不同,查询状态和事件没有利用传送数据管理结构D来管理为完整的实体。因此,将彼此没有关联的查询状态和事件从节点100被传送给节点200。在该情况下,节点200可能涉及与针对查询状态和与该查询状态有关的数据来搜索所接收的数据相关联的计算成本和延迟。计算成本和延迟是改进的目标。
另一方面,在图22的情况下,使用传送数据管理结构D对查询状态和事件一起进行管理。这使得查询状态和事件能够从节点100顺序地被传送。在对接收数据进行反序列化时,节点200紧接在提取查询状态之后提取事件,从而确定事件与紧接在其之前的查询状态相关联。也就是说,可以通过使得节点200能够有效地获取查询状态和事件来使得继续执行重新分配的查询的延迟进一步被减小(即,可以改善上述计算成本和延迟)。因此,优选的是从节点100顺序地传送查询状态和事件。
图24是示出查询重新分配的第二示例的时序图。接下来根据时序图中的步骤编号来描述图24的处理。
(步骤ST41)管理节点400向节点100、节点200和节点300中的每个节点发出将查询从节点100重新分配给节点200的指令。
(步骤ST42)节点100、节点200和节点300中的每个节点接收在步骤ST41发出的指令。节点100和节点200分别操纵查询配置表121和查询配置表221,以将查询在状态栏中的信息变为“正迁移到节点200”。节点300在查询配置表321中将查询在分配节点名称中的信息变为“节点200”。节点100对指定查询的查询状态进行序列化,然后将查询状态添加到传送列表122。
(步骤ST43)节点300获取新事件(事件发生在节点300处)。该新事件是对应于重新分配的查询的事件。
(步骤ST44)节点300参照查询配置表321,以确定节点200是负责查询的节点。节点300将获取的事件发送给节点200。随后,节点200接收事件,然后对所接收的事件进行反序列化。节点200将事件作为重新分配的查询的等待事件登记在查询配置表221中。这是因为,在节点200的查询配置表221中,“正迁移到其自身节点(在该情况下的节点200)”被设定在与从节点300接收的事件对应的查询的状态栏下的字段中。
(步骤ST45)节点100保持缓冲直到传送列表122的数据大小超过或等于阈值为止。
(步骤ST46)当传送列表122的数据大小超过或等于阈值时,节点100将传送列表122的内容发送给节点200。
(步骤ST47)在从节点100接收到查询状态时,节点200对查询状态进行反序列化。
(步骤ST48)节点200向管理节点400通知已完成查询状态的迁移。
(步骤ST49)节点200使用在步骤ST46中获取的查询状态和在步骤ST44中获取的事件(等待事件)来执行从节点100重新分配给节点200的查询。
如上所述,可以紧接在查询重新分配指令到达节点300后将对应于重新分配的查询的事件从节点300发送给节点200。在该情况下,事件传输延迟对应于从步骤ST43的开始到步骤ST47的完成的时间段。注意,管理节点400可以在步骤ST48后向节点100、节点200和节点300通知查询重新分配完成。
图25是示出比较性查询重新分配的第二示例的时序图。接下来根据时序图中的步骤编号来描述图25的处理。图25呈现了相对于图24的比较示例,其中未采用第二实施方式的方法。在图25的描述中,出于描述的目的,用与第二实施方式的那些附图标记相同的附图标记来指定各个节点。
(步骤ST51)管理节点400向节点100、节点200和节点300中的每个节点发出将查询从节点100重新分配给节点200的指令。
(步骤ST52)节点100、节点200和节点300中的每个节点接收在步骤ST51发出的指令。节点100对指定查询的查询状态进行序列化,然后将查询状态添加到传送数据。
(步骤ST53)节点300获取新事件(事件发生在节点300处)。该新事件是对应于重新分配的查询的事件。节点300在检测到事件对应于重新分配的查询后,拒绝将该事件提供给负责查询的节点。
(步骤ST54)节点100保持缓冲直到传送数据的数据大小超过或等于阈值为止。
(步骤ST55)当传送数据的数据大小超过或等于阈值时,节点100将传送数据的内容发送给节点200。传送数据包括查询状态。
(步骤ST56)节点200在从节点100接收到查询状态时,对查询状态进行反序列化。
(步骤ST57)节点200向管理节点400通知查询状态的迁移完成。
(步骤ST58)管理节点400向节点100、节点200和节点300中的每个节点通知查询重新分配的完成。节点100、节点200和节点300单独地接收通知。
(步骤ST59)节点300确定在步骤ST53中获取的事件的目标节点是节点200。节点300将事件传送给节点200(注意,序列化和缓冲也针对所述事件进行)。节点200在从节点300接收到事件时,对事件进行反序列化。
(步骤ST60)节点200使用在步骤ST56中获取的查询状态和在步骤ST59中获取的事件来执行从节点100重新分配给节点200的查询。
在上述比较示例的情况下,在节点200结束接收在节点300处已经发生的事件之前的事件传输延迟对应于从步骤ST53的开始到步骤ST59的完成的时间段。根据比较示例,与图24的情况相比,事件传输延迟由于对应于步骤ST57至步骤ST59的额外时间段而更长。尤其是,尽管未在图25中示出,但是与步骤ST52至步骤ST56的情况一样,步骤ST59包括多个处理阶段,例如锁定等待、缓冲、传输、反序列化、登记,以及解除等待的锁定。因此,比较示例的事件传输延迟也包括用于处理这些阶段的延迟。
另一方面,在图24的情况下,在步骤ST44中允许将事件从节点300传送到节点200,并且节点200将事件作为等待事件来管理。因此,消除了对应于步骤ST57至步骤ST59的延迟时间。也就是说,与比较示例相比,可以缩短在节点200处继续执行重新分配的查询的延迟。
图26示出了分布式处理系统的另一示例。图2示出了使用服务器计算机(物理机)来实现节点100、节点200和节点300的示例。另一方面,可以通过虚拟机来实现每个节点。例如,服务器51、服务器52和服务器53连接到网络10。注意,图26省略了网络20和其他设备的图示。
例如,服务器51、服务器52和服务器53执行被称为管理程序或虚拟机监测器的监管软件,并且将设置在服务器51、服务器52和服务器53中的资源(例如CPU和RAM)分配给服务器51、服务器52和服务器53上的多个虚拟机。例如,服务器51包括虚拟机100a、虚拟机200a和虚拟机300a。
可以将虚拟机100a、虚拟机200a和虚拟机300a用作为用于分布式处理的节点。例如,虚拟机100a能够实现与节点100相同的功能。虚拟机200a能够实现与节点200相同的功能。虚拟机300a能够实现与节点300相同的功能。注意,可以将物理机和虚拟机二者用作为用于分布式处理的节点。同样,在使用虚拟机100a、虚拟机200a和虚拟机300a来进行分布式处理的情况下,可以缩短在新分配的目标节点处继续执行查询的延迟。也就是说,节点100、节点200和节点300是第一实施方式的机器(物理机)的示例。虚拟机100a、虚拟机200a和虚拟机300a是第一实施方式的机器(虚拟机)的示例。
在上述示例中,每个查询被分配给节点。然而,可以基于查询和被包括在对应于查询的每个事件中的预定关键字来进行查询分配。有时存在以下情形:对于一个查询而言,希望根据关键字来分配不同的节点。例如,假设每个事件包括指示事件已发生的多个区域之一的信息(关键字),并且希望不同的节点负责区域中的每个区域。在该情况下,在查询配置表121、查询配置表221和查询配置表321中,以与成对的查询和关键字相关联的方式来管理每个分配节点名称。同样,在该情况下,上述同样的方法可以通过为每个查询和关键字对指定查询名称来应用。
注意,通过使得计算单元1b执行程序来实现第一实施方式的信息处理。同样,通过使得处理器101执行程序来实现第二实施方式的信息处理。程序可以记录在计算机可读存储介质(例如,光盘13、存储装置14,或存储卡16)中。
例如,记录有程序的存储介质是分布式的,以便分发程序。此外,可以将程序存储在不同的计算机中,然后经由网络分发。计算机将记录在存储介质中或从不同的计算机接收的程序存储或安装在存储装置(例如RAM 102和HDD 103)中,并且从存储装置读取程序以执行所述程序。
根据一个方面,可以缩短在新分配的目标节点处继续进行处理的延迟。
Claims (5)
1.一种在包括第一计算机和第二计算机的系统中执行的数据处理管理方法,所述数据处理管理方法包括:
响应于属于事件模式的到达事件,所述第一计算机执行与所述事件模式对应的处理,并且将所述到达事件记录在存储器中,所述事件模式指示多个事件并且存储在所述存储器中;
接收将所述处理重新分配给所述第二计算机的指令;
在准备传送指示所述到达事件的进度信息期间,接收属于所述事件模式的第一事件;
所述第一计算机生成包括所述进度信息和所述第一事件的传送数据;
所述第一计算机向所述第二计算机传送所述传送数据;
在所述传送数据到达之前,所述第二计算机接收属于所述事件模式的第二事件,并且使用存储装置来保存所述第二事件;
所述第二计算机使用所述进度信息和所述第二事件来执行所述处理;以及
所述第二计算机在使用所述进度信息和所述第二事件执行所述处理之后,接收属于所述事件模式的第三事件,所述第三事件在所述第二事件之前发生。
2.根据权利要求1所述的数据处理管理方法,还包括:
所述第二计算机在接收到所述进度信息和所述第一事件时,使用所述进度信息和所述第一事件来执行所述处理,并且随后使用所述第二事件来执行所述处理。
3.根据权利要求1所述的数据处理管理方法,其中:
所述第一计算机顺序地传送所述进度信息和所述第一事件。
4.根据权利要求1所述的数据处理管理方法,还包括:
所述第一计算机在接收到所述指令时,停止对所述处理的执行;以及
所述第二计算机使用所述进度信息和所述第一事件来继续执行所述处理。
5.一种信息处理系统,包括:
第一信息处理装置和第二信息处理装置,
所述第一信息处理装置包括:
第一存储装置,所述第一存储装置用于存储指示与处理对应的多个事件的事件模式;以及
第一计算装置,所述第一计算装置用于执行程序,所述程序包括:
响应于属于所述事件模式的到达事件来执行所述处理,并且将所述到达事件记录在所述第一存储装置中;
接收将所述处理重新分配给不同的第二信息处理装置的指令;
在准备传送指示所述到达事件的进度信息期间,接收属于所述事件模式的第一事件;
生成包括所述进度信息和所述第一事件的传送数据;
向不同的第二信息处理装置传送所述传送数据;
所述第二信息处理装置包括:
第二存储装置,所述第二存储装置用于存储属于所述事件模式的第二事件;
第二计算装置,所述第二计算装置用于执行程序,所述程序包括:
在所述传送数据到达之前接收所述第二事件,并且使用所述第二存储装置来保存所述第二事件;
使用所述进度信息和所述第二事件来执行所述处理;
在使用所述进度信息和所述第二事件来执行所述处理之后,接收属于所述事件模式的第三事件,所述第三事件在所述第二事件之前发生。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013209824A JP6248523B2 (ja) | 2013-10-07 | 2013-10-07 | データ処理管理方法、情報処理装置およびデータ処理管理プログラム |
JP2013-209824 | 2013-10-07 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104516776A CN104516776A (zh) | 2015-04-15 |
CN104516776B true CN104516776B (zh) | 2018-05-22 |
Family
ID=51687807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410522191.8A Active CN104516776B (zh) | 2013-10-07 | 2014-09-30 | 数据处理管理方法及信息处理设备 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9742841B2 (zh) |
EP (1) | EP2857969B1 (zh) |
JP (1) | JP6248523B2 (zh) |
CN (1) | CN104516776B (zh) |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10089362B2 (en) * | 2014-08-13 | 2018-10-02 | Software Ag | Systems and/or methods for investigating event streams in complex event processing (CEP) applications |
US11615104B2 (en) | 2016-09-26 | 2023-03-28 | Splunk Inc. | Subquery generation based on a data ingest estimate of an external data system |
US11874691B1 (en) | 2016-09-26 | 2024-01-16 | Splunk Inc. | Managing efficient query execution including mapping of buckets to search nodes |
US11281706B2 (en) | 2016-09-26 | 2022-03-22 | Splunk Inc. | Multi-layer partition allocation for query execution |
US11222066B1 (en) | 2016-09-26 | 2022-01-11 | Splunk Inc. | Processing data using containerized state-free indexing nodes in a containerized scalable environment |
US11567993B1 (en) | 2016-09-26 | 2023-01-31 | Splunk Inc. | Copying buckets from a remote shared storage system to memory associated with a search node for query execution |
US10956415B2 (en) | 2016-09-26 | 2021-03-23 | Splunk Inc. | Generating a subquery for an external data system using a configuration file |
US11586627B2 (en) | 2016-09-26 | 2023-02-21 | Splunk Inc. | Partitioning and reducing records at ingest of a worker node |
US10977260B2 (en) | 2016-09-26 | 2021-04-13 | Splunk Inc. | Task distribution in an execution node of a distributed execution environment |
US11250056B1 (en) | 2016-09-26 | 2022-02-15 | Splunk Inc. | Updating a location marker of an ingestion buffer based on storing buckets in a shared storage system |
US10353965B2 (en) | 2016-09-26 | 2019-07-16 | Splunk Inc. | Data fabric service system architecture |
US11461334B2 (en) | 2016-09-26 | 2022-10-04 | Splunk Inc. | Data conditioning for dataset destination |
US11003714B1 (en) | 2016-09-26 | 2021-05-11 | Splunk Inc. | Search node and bucket identification using a search node catalog and a data store catalog |
US11599541B2 (en) | 2016-09-26 | 2023-03-07 | Splunk Inc. | Determining records generated by a processing task of a query |
US11294941B1 (en) | 2016-09-26 | 2022-04-05 | Splunk Inc. | Message-based data ingestion to a data intake and query system |
US10984044B1 (en) | 2016-09-26 | 2021-04-20 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets stored in a remote shared storage system |
US11023463B2 (en) | 2016-09-26 | 2021-06-01 | Splunk Inc. | Converting and modifying a subquery for an external data system |
US11580107B2 (en) | 2016-09-26 | 2023-02-14 | Splunk Inc. | Bucket data distribution for exporting data to worker nodes |
US20180089324A1 (en) | 2016-09-26 | 2018-03-29 | Splunk Inc. | Dynamic resource allocation for real-time search |
US11232100B2 (en) | 2016-09-26 | 2022-01-25 | Splunk Inc. | Resource allocation for multiple datasets |
US11243963B2 (en) | 2016-09-26 | 2022-02-08 | Splunk Inc. | Distributing partial results to worker nodes from an external data system |
US11620336B1 (en) | 2016-09-26 | 2023-04-04 | Splunk Inc. | Managing and storing buckets to a remote shared storage system based on a collective bucket size |
US11106734B1 (en) * | 2016-09-26 | 2021-08-31 | Splunk Inc. | Query execution using containerized state-free search nodes in a containerized scalable environment |
US11442935B2 (en) | 2016-09-26 | 2022-09-13 | Splunk Inc. | Determining a record generation estimate of a processing task |
US11269939B1 (en) | 2016-09-26 | 2022-03-08 | Splunk Inc. | Iterative message-based data processing including streaming analytics |
US11126632B2 (en) | 2016-09-26 | 2021-09-21 | Splunk Inc. | Subquery generation based on search configuration data from an external data system |
US11314753B2 (en) | 2016-09-26 | 2022-04-26 | Splunk Inc. | Execution of a query received from a data intake and query system |
US11321321B2 (en) | 2016-09-26 | 2022-05-03 | Splunk Inc. | Record expansion and reduction based on a processing task in a data intake and query system |
US11562023B1 (en) | 2016-09-26 | 2023-01-24 | Splunk Inc. | Merging buckets in a data intake and query system |
US11416528B2 (en) | 2016-09-26 | 2022-08-16 | Splunk Inc. | Query acceleration data store |
US11550847B1 (en) | 2016-09-26 | 2023-01-10 | Splunk Inc. | Hashing bucket identifiers to identify search nodes for efficient query execution |
US11860940B1 (en) | 2016-09-26 | 2024-01-02 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets |
US11163758B2 (en) | 2016-09-26 | 2021-11-02 | Splunk Inc. | External dataset capability compensation |
US11593377B2 (en) | 2016-09-26 | 2023-02-28 | Splunk Inc. | Assigning processing tasks in a data intake and query system |
US11663227B2 (en) | 2016-09-26 | 2023-05-30 | Splunk Inc. | Generating a subquery for a distinct data intake and query system |
US11604795B2 (en) | 2016-09-26 | 2023-03-14 | Splunk Inc. | Distributing partial results from an external data system between worker nodes |
US11226887B1 (en) * | 2016-12-06 | 2022-01-18 | Amazon Technologies, Inc. | User code deployment across compute resource partitions |
US11921672B2 (en) | 2017-07-31 | 2024-03-05 | Splunk Inc. | Query execution at a remote heterogeneous data store of a data fabric service |
US10896182B2 (en) | 2017-09-25 | 2021-01-19 | Splunk Inc. | Multi-partitioning determination for combination operations |
US11151137B2 (en) | 2017-09-25 | 2021-10-19 | Splunk Inc. | Multi-partition operation in combination operations |
US11334543B1 (en) | 2018-04-30 | 2022-05-17 | Splunk Inc. | Scalable bucket merging for a data intake and query system |
WO2020220216A1 (en) | 2019-04-29 | 2020-11-05 | Splunk Inc. | Search time estimate in data intake and query system |
US11715051B1 (en) | 2019-04-30 | 2023-08-01 | Splunk Inc. | Service provider instance recommendations using machine-learned classifications and reconciliation |
US11494380B2 (en) | 2019-10-18 | 2022-11-08 | Splunk Inc. | Management of distributed computing framework components in a data fabric service system |
US11922222B1 (en) | 2020-01-30 | 2024-03-05 | Splunk Inc. | Generating a modified component for a data intake and query system using an isolated execution environment image |
CN111401033B (zh) * | 2020-03-19 | 2023-07-25 | 北京百度网讯科技有限公司 | 事件抽取方法、事件抽取装置和电子设备 |
US11704313B1 (en) | 2020-10-19 | 2023-07-18 | Splunk Inc. | Parallel branch operation using intermediary nodes |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1836211A (zh) * | 2003-08-14 | 2006-09-20 | 甲骨文国际公司 | 在群集计算系统中的快速应用程序通知 |
CN102446217A (zh) * | 2010-10-05 | 2012-05-09 | 富士通株式会社 | 复合事件处理设备和复合事件处理方法 |
CN102667718A (zh) * | 2009-10-30 | 2012-09-12 | 国际商业机器公司 | 处理网络事件的方法和系统 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3749208B2 (ja) | 2002-08-14 | 2006-02-22 | 株式会社東芝 | プロセスマイグレーション方法、計算機 |
US7484208B1 (en) * | 2002-12-12 | 2009-01-27 | Michael Nelson | Virtual machine migration |
US20040260862A1 (en) * | 2003-06-20 | 2004-12-23 | Eric Anderson | Adaptive migration planning and execution |
US7577657B2 (en) * | 2005-03-18 | 2009-08-18 | Microsoft Corporation | System and method for updating objects in a multi-threaded computing environment |
US7536526B2 (en) * | 2005-07-11 | 2009-05-19 | General Electric Company | Hierarchical state based migration of structured data |
JP5214537B2 (ja) | 2009-05-25 | 2013-06-19 | 株式会社東芝 | マルチプロセッサシステム |
JP5664098B2 (ja) | 2010-10-05 | 2015-02-04 | 富士通株式会社 | 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム |
JP2012248169A (ja) * | 2011-05-31 | 2012-12-13 | Nippon Telegr & Teleph Corp <Ntt> | サービス閉塞方法、処理装置、処理プログラム、負荷分散装置および負荷分散プログラム |
JP5980335B2 (ja) * | 2012-08-22 | 2016-08-31 | 株式会社日立製作所 | 仮想計算機システム、管理計算機及び仮想計算機管理方法 |
US20150234618A1 (en) * | 2013-04-22 | 2015-08-20 | Hitachi, Ltd. | Storage management computer, storage management method, and storage system |
-
2013
- 2013-10-07 JP JP2013209824A patent/JP6248523B2/ja active Active
-
2014
- 2014-09-26 EP EP14186610.3A patent/EP2857969B1/en active Active
- 2014-09-29 US US14/499,321 patent/US9742841B2/en active Active
- 2014-09-30 CN CN201410522191.8A patent/CN104516776B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1836211A (zh) * | 2003-08-14 | 2006-09-20 | 甲骨文国际公司 | 在群集计算系统中的快速应用程序通知 |
CN102667718A (zh) * | 2009-10-30 | 2012-09-12 | 国际商业机器公司 | 处理网络事件的方法和系统 |
CN102446217A (zh) * | 2010-10-05 | 2012-05-09 | 富士通株式会社 | 复合事件处理设备和复合事件处理方法 |
Also Published As
Publication number | Publication date |
---|---|
EP2857969A3 (en) | 2016-07-06 |
EP2857969B1 (en) | 2022-08-24 |
JP6248523B2 (ja) | 2017-12-20 |
CN104516776A (zh) | 2015-04-15 |
US9742841B2 (en) | 2017-08-22 |
EP2857969A2 (en) | 2015-04-08 |
US20150100616A1 (en) | 2015-04-09 |
JP2015075803A (ja) | 2015-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104516776B (zh) | 数据处理管理方法及信息处理设备 | |
CN107977376B (zh) | 分布式数据库系统及事务处理方法 | |
US7543000B2 (en) | Method and system combining state replication and operational-replay synchronization | |
CN104793988B (zh) | 跨数据库分布式事务的实现方法和装置 | |
US6513056B1 (en) | System and method for efficiently synchronizing cache and persistant data in an object oriented transaction processing system | |
CN109144994A (zh) | 索引更新方法、系统及相关装置 | |
WO2011108695A1 (ja) | 並列データ処理システム、並列データ処理方法及びプログラム | |
US11586614B2 (en) | Native persistent store support for blockchains | |
US8499298B2 (en) | Multiprocessing transaction recovery manager | |
JP6613320B2 (ja) | トランザクション処理環境において分散型キャッシングを提供するためのシステムおよび方法 | |
US20030041069A1 (en) | System and method for managing bi-directional relationships between objects | |
US9449041B2 (en) | Database system lock operation method and device | |
JPWO2010041515A1 (ja) | 複数のアプリケーションサーバにより共有データをアクセスするシステム | |
JPH09244896A (ja) | 永続性オブジェクトのオブジェクトベース構築方法、コンピュータ読み取り可能媒体、および情報操作システム | |
US7752399B2 (en) | Exclusion control method and information processing apparatus | |
US11741081B2 (en) | Method and system for data handling | |
US20090100082A1 (en) | Replication and mapping mechanism for recreating memory durations | |
JP2022521412A (ja) | 分散システムにおける非同期ストレージ管理 | |
US8140493B2 (en) | Changing metadata without invalidating cursors | |
US6513030B2 (en) | Persistence storage architecture | |
US11138231B2 (en) | Method and system for data handling | |
Krizevnik et al. | Improved SOA persistence architectural model | |
WO2020222855A1 (en) | System and methods for loading objects from hash chains | |
JP3330006B2 (ja) | 情報記憶システムを備えるネットワークシステム、該システムの入力システムならびに | |
JP6902579B2 (ja) | トランザクション処理環境において分散型キャッシングを提供するためのシステムおよび方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |