CN104885077A - 利用归档的关系管理连续查询 - Google Patents

Abstract

提供了利用归档的关系管理连续查询的技术。在一些例子中，可以识别包括至少数据流的查询。此外，查询可以利用历史数据的至少一部分被初始化。另外，在一些情况下，查询可以至少部分地基于所述数据流和历史数据的所述部分被评估。

Description

利用归档的关系管理连续查询

对相关申请的交叉引用

本申请要求于2013年3月14日提交的标题为“Managing Continuous Queries with Archived Relations”的美国专利申请No.13/829,958(代理案号88325-859813(128010US))、于2013年3月14日提交的标题为“Configurable Data Windows for Archived Relations”的美国专利申请No.13/830,129(代理案号88325-859814(128020US))和于2012年9月28日提交的标题为“Real Time Business Event Analysis and Monitoring”的美国临时申请No.61/707,641的优先权和利益，这些申请当中每一个的全部内容都通过引用被结合于此，用于所有目的。

背景技术

在传统的数据库系统中，数据是通常以表的形式存储在一个或多个数据库中。所存储的数据随后利用诸如结构化查询语言(SQL)的数据管理语言被查询和操纵。例如，SQL查询可以被定义和执行，以便从数据库中所存储的数据识别相关的数据。因此，SQL查询是对存储在数据库中的有限数据集执行的。另外，当SQL查询被执行时，它对有限数据集执行一次并且产生有限的静态结果。因此，数据库最有能力对有限存储的数据集运行查询。

但是，多个现代应用和系统生成形式为连续数据或事件流的数据，而不是有限的数据集。这种应用的例子包括但不限于传感器数据应用、金融行情、网络性能测量工具(例如，网络监控和流量管理应用)、点击流分析工具、汽车流量监控，等等。这种应用引发了对可以处理数据流的新种类应用的需求。例如，温度传感器可以被配置为发出温度读数。

为这些类型的基于事件流的应用管理和处理数据涉及建立具有强时间焦点的数据管理和查询能力。需要包括对连续无限数据集的长期运行查询的不同种类的查询机制。虽然现在有些供应商提供了针对事件流处理的产品套件，但是这些产品供应仍然缺乏处理如今事件处理需求所需的处理灵活性。

发明内容

在一些例子中，提供了管理连续查询中归档的关系的系统。该系统可以包括存储器和配置为访问存储器并执行指令以便识别查询的一个或多个处理器，其中查询识别至少数据流。指令还可以被执行，以利用历史数据的至少一部分初始化查询。此外，指令还可以被执行，以至少部分地基于数据流和历史数据的所述部分评估查询。在一些情况下，查询可以包括被配置为处理数据流的进入的实时数据或者数据流的归档的关系的连续查询。实时数据可以包括至少业务事件数据。此外，在一些例子中，数据流可以包括配置有窗口的关系，用于在窗口内引用数据流的一部分。窗口可以被配置为随时间沿数据流移动。在一些方面，历史数据在初始化查询之后的时间可以不包括在数据流中。查询还可以识别历史数据。此外，历史数据可以包括在初始化查询之前的时间来自数据流的业务事件数据。在一些方面，评估查询可以包括至少形成具有节点的查询图，其中节点代表查询的运算符。此外，一个或多个处理器还可以配置为执行多条指令，以便至少按拓扑次序遍历查询图。另外，一个或多个处理器还可以配置为执行多条指令，以便在查询图中识别出的最低的有状态运算符至少利用至少历史数据初始化查询。

此外，在一些例子中，可以提供计算机可读介质。该介质可以存储可由一个或多个处理器执行的多条指令。在一些例子中，指令可以包括接收被配置为处理数据流的连续查询，该连续查询可以包括数据流的标识符或历史数据的标识符当中至少一个。指令还可以包括至少部分地基于该连续查询生成查询图。在一些方面，指令还可以包括利 用历史数据的至少一部分初始化连续查询和/或关于数据流并至少部分地基于历史数据评估该连续查询。在一些例子中，数据流或历史数据当中至少一个可以通过连续查询的数据定义语言注释来识别。此外，数据定义语言注释可以识别历史数据的位置、数据流的源、与数据流关联的数据对象、与处理连续查询关联的操作信息、对应于历史数据的数据库的一个或多个相关列、对应于连续查询的输出的数据对象或者用于提供连续查询的输出的位置当中至少一个。另外，查询图可以包括至少代表连续查询的运算符的节点和/或连续查询可以在按拓扑次序遍历查询图的时候在查询图中识别出的最低的有状态运算符利用历史数据的至少一部分初始化。作为替代，可以提供包含以上指令的计算机可读程序。

另外，在一些例子中，可以提供方法。该方法可以被配置为接收配置为处理业务事件数据的流的连续查询，该连续查询可以包括所述流的标识符和与该流关联的历史数据的标识符。在一些方面，该方法还可以被配置为至少部分地基于该连续查询生成查询图，查询图可以包括至少代表该连续查询的运算符的节点。此外，该方法还可以被配置为遍历查询图，以识别最低的有状态运算符。该方法还可以被配置为在识别出的最低的有状态运算符利用历史数据的至少一部分初始化连续查询和/或关于所述流并至少部分地基于历史数据评估该连续查询。此外，在一些例子中，历史数据可以包括从流的之前时间点开始的业务事件数据。该方法还可以被配置为至少部分地基于连续查询的运算符确定利用其初始化连续查询的最佳历史数据量。此外，有状态的运算符可以至少部分地基于评估连续查询的至少一个节点来识别。

可以在存在具有可配置数据窗口的归档的关系的情况下提供连续查询。在一些例子中，可以提供系统，该系统可以包括存储指令的存储器和/或配置为访问存储器并执行指令以便至少识别查询的处理器，其中查询识别至少数据流。该系统还可以执行指令，以识别可配置的窗口尺寸。此外，在一些例子中，系统可以执行指令，以便至少部分地基于窗口尺寸利用历史数据的至少一部分初始化查询。另外， 系统还可以被配置为执行指令，以便至少部分地基于数据流和历史数据的所述部分评估查询。在一些方面，查询可以包括被配置为处理数据流的进入的实时业务事件数据的连续查询。查询的评估可以包括至少部分地基于可配置的窗口尺寸至少对照数据流应用查询。此外，在一些例子中，数据流可以包括配置有第二可配置窗口尺寸的关系，用于在第二窗口中定位数据流的一部分，其中第二窗口的尺寸至少部分地基于第二可配置窗口尺寸。

此外，在一些例子中，第二窗口可以被配置为随时间沿数据流移动。历史数据在初始化查询之后的时间可以不包括在数据流中。而且，历史数据可以包括在初始化查询之前的时间来自数据流的业务事件数据。在一些例子中，系统还可以被配置为执行指令，以便至少通过至少形成具有节点的查询图来评估查询，其中节点代表查询的运算符。此外，至少一个节点可以识别窗口尺寸。另外，在一些方面，系统可以被配置为执行指令，以便至少从源按拓扑遍历查询图。一个或多个处理器还可以被配置为执行指令，以便至少在查询图中识别出的最低的有状态运算符利用至少历史数据初始化查询。

此外，在一些例子中，可以提供计算机可读存储器。存储器可以被配置为存储使一个或多个处理器接收被配置为处理归档的关系的连续查询的指令，该连续查询包括数据流的标识符或历史数据的标识符当中至少一个。指令还可以使处理器至少部分地基于该连续查询生成查询图。此外，在一些例子中，指令可以使处理器从与归档的关系关联的实体接收窗口尺寸。在一些方面，指令还可以使处理器利用历史数据的至少一部分初始化连续查询。另外，在一些例子中，指令可以使一个或多个处理器至少部分地基于查询图关于归档的关系和窗口尺寸评估连续查询。归档的关系可以至少部分地基于历史数据。在一些方面，归档的关系或历史数据当中至少一个可以由连续查询的数据定义语言注释来识别。数据定义语言注释可以识别历史数据的位置、归档的关系的源、与归档的关系关联的数据对象、与处理连续查询关联的操作信息、对应于历史数据的数据库的一个或多个相关列、对应于 连续查询的输出的数据对象或者用于提供连续查询的输出的位置当中至少一个。此外，在一些例子中，多条指令还可以包括使一个或多个处理器至少部分地基于窗口尺寸确定利用其初始化连续查询的历史数据量的指令。另外，连续查询可以在以拓扑次序遍历查询图的时候在查询图中的有状态运算符利用历史数据的至少一部分初始化。

另外，在一些例子中，可以提供计算机实现的方法。该方法可以被配置为接收被配置为处理与业务事件数据关联的归档的关系的连续查询，该连续查询包括与流关联的归档的关系的标识符和历史数据的标识符。此外，该方法可以被配置为接收窗口尺寸，该窗口尺寸被配置为识别要处理的归档的关系的有界范围。该方法还可以被配置为至少部分地基于连续查询生成查询图，该查询图包括至少代表连续查询的运算符的节点。此外，在一些方面，该方法可以被配置为从查询图的源节点按拓扑遍历查询图，以识别有状态的运算符。该方法还可以被配置为在识别出的有状态的运算符利用历史数据的至少一部分初始化连续查询和/或至少部分地基于窗口尺寸关于归档的关系评估连续查询。在一些方面，历史数据可以包括从初始化连续查询之前归档的关系的时间点开始的业务事件数据。此外，在一些方面，该方法还可以被配置为至少部分地基于连续查询的运算符确定利用其初始化连续查询的最佳历史数据量。另外，该方法还可以被配置为至少部分地基于窗口尺寸确定利用其初始化连续查询的最佳历史数据量。

根据至少一个例子，系统可以包括用于识别识别至少数据流的查询的装置、用于利用历史数据的至少一部分初始化查询的装置，以及用于至少部分地基于数据流和历史数据的所述部分评估查询的装置。

当参考以下说明书、权利要求和附图时，连同其它特征和实施例，以上所述将变得更加显然。

附图说明

具体描述是参考附图来阐述的。在附图中，标号最左边的数字识别该标号首次在其中出现的图。相同标号在不同图中的使用指示相似 或完全相同的项。

图1是根据至少一个例子、说明利用归档的关系管理连续查询的示例体系架构的简化框图。

图2是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的简化框图。

图3是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些附加特征的简化框图。

图4是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些附加特征的简化框图。

图5是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些附加特征的简化框图。

图6是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的简化过程流。

图7是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图8是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图9是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图10是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图11是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图12是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图13是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图14是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图15是根据至少一个例子、说明系统环境的部件的简化框图，该系统环境可以根据利用本文所述归档的关系对连续查询进行管理的实施例被使用。

图16是根据至少一个例子、说明计算机系统的简化框图，该计算机系统可以根据利用本文所述归档的关系对连续查询进行管理的实施例被使用。

图17是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图18是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

图19是根据至少一个例子、说明利用本文所述归档的关系管理连续查询的至少一些特征的另一个简化过程流。

具体实施方式

在以下的描述中，将描述各种实施例。为了说明，阐述具体的配置和细节，以便提供对实施例的透彻理解。但是，对本领域技术人员也将很显然，实施例没有这些具体细节也可以实践。此外，为了不模糊所描述的实施例，众所周知的特征可以被略去或简化。

在一些例子中，可以提供利用一个或多个归档的关系支持连续查询语言(continuous query language，CQL)查询(也被称为“查询语句”)的机制，其中归档的关系例如包括，但不限于，在创建时可以非空的CQL关系。例如，在一些场景下，CQL关系可以通过对流应用窗口来定义。换句话说，关系可以是有界数据集。例如，给定事件流，关系可以首先由包括特定数量或集合的流元素的窗口定义(例如，在窗口内)。但是，在一些情况下，关系可以在空状态下创建。即，窗口可以被定义；但是可以没有事件包括在关系中。另一方面，归档的关系可以在创建时包括事件数据。在一些例子中，归档器或其它数据对象可以负责管理要在创建归档的关系时使用的实时数据和/或可以把这种数据提供给被配置为生成或以别的方式管理归档的 关系的引擎。

此外，在一些例子中，用于利用归档的关系支持CQL查询的机制还可以启用归档的关系的特定数据窗口的配置。这些数据窗口可以由用户、管理员或者与用户的归档的关系和/或事件数据(例如，业务事件数据)关联的其它实体配置、生成、管理、更新和/或以别的方式操纵。另外，在一些例子中，连续查询中的归档的关系可以以这样一种方式实现，使得避免错过和/或重复计数(double counting)变化通知。例如，当查询被运行时，它最初可以对照数据对象备份存储来运行，以确立查询的当前状态，然后监听并处理来自数据对象的变化通知。但是，当实现查询的复杂事件过程(complex event process，CEP)运行初始的查询时，变化通知可能被错过。此外，如果变化已经在初始的查询中，则变化通知还会被重复计数。然而，在一些例子中，通过在初始查询之前确立监听者和/或利用事务标识符(transaction identifier，TID)、上下文标识符(context identifier，CID)或其它用于管理变化事件的机制，可以避免错过的和/或重复计数的变化通知。

一般而言，连续的数据流(也被称为事件流)可以包括本质上可以是没有明确结束的连续或无界的数据或事件的流。在逻辑上，事件或数据流可以是数据元素(也被称为事件)的序列，每个数据元素具有关联的时间戳。连续的事件流可以在逻辑上表示为元素的组(bag)或集合(s,T)，其中“s”代表数据部分，并且“T”是在时间域内。“s”部分一般被称为元组或事件。因此，事件流可以是带时间戳的元组或事件的序列。

在一些方面，与流中的事件关联的时间戳可以等同于时钟时间。但是，在其它例子中，与事件流中的事件关联的时间戳可以由应用域定义并且可以不对应于时钟时间而是可以，例如，代替地由序列号表示。因而，与事件流中的事件关联的时间信息可以由数字、时间戳或者代表时间概念的任何其它信息表示。为了让系统接收输入事件流，事件按递增时间戳的次序到达系统。可以有多于一个具有相同时间戳 的事件。

在一些例子中，事件流中的事件可以代表某个世俗事件(worldly event)的发生(例如，当温度传感器把值变成新的值时、当股票代码的价格改变时)并且与该事件关联的时间信息可以指示由数据流事件表示的世俗事件发生的时间。

对于经事件流接收的事件，与事件关联的时间信息可以被用来确保事件流中的事件按递增的时间戳值的次序到达。这可以使在事件流中接收的事件基于它们关联的时间信息被排序。为了启用这种排序，时间戳可以以非递减的方式与事件流中的事件关联，使得晚生成的事件比早生成的事件具有更晚的时间戳。作为另一个例子，如果序列号被用作时间信息，则与晚生成的事件关联的序列号可以大于与早生成的事件关联的序列号。在一些例子中，多个事件可以与相同的时间戳或序列号关联，例如，当由数据流事件表示的世俗事件在相同的时间发生时。属于相同事件流的事件一般可以按由关联的时间信息强加给事件的次序来处理，较早的事件在较晚的事件之前被处理。

与事件流中的事件关联的时间信息(例如，时间戳)可以由流的源设置或者，作为替代，可以由接收流的系统设置。例如，在某些实施例中，可以在接收事件流的系统上维持心跳，并且与事件关联的时间可以基于由心跳测量的在系统的事件到达时间。有可能事件流中的两个事件具有相同的时间信息。应当指出，虽然时间戳排序需求是特定于一个事件流的，但是不同流的事件可以任意交错。

事件流具有关联的图式(schema)“S”，该图式包括时间信息和一组一个或多个命名的属性。属于特定事件流的所有事件都符合与该特定事件流关联的图式。因而，对于事件流(s,T)，事件流可以具有图式“S”为(<time_stamp>,<属性>)，其中<属性>代表图式的数据部分并且可以包括一个或多个属性。例如，用于股票行情事件流的图式可以包括属性<股票代码>和<股票价格>。经这种流接收的每个事件都将具有时间戳和两个属性。例如，股票行情事件流可以接收以下事件和关联的时间戳：

…

(<timestamp_N>,<NVDA,4>)

(<timestamp_N+1>,<ORCL,62>)

(<timestamp_N+2>,<PCAR,38>)

(<timestamp_N+3>,<SPOT,53>)

(<timestamp_N+4>,<PDCO,44>)

(<timestamp_N+5>,<PTEN,50>)

…

在以上的流中，对于流元素(<timestamp_N+1>,<ORCL,62>)，事件是具有属性“stock_symbol”和“stock_value”的<ORCL,62>。与该流元素关联的时间戳是“timestamp_N+1”。因此，连续事件流是事件的流，每个事件具有相同的属性序列。

如所指出的，流可以是CQL查询可以对其作用的数据的主要来源。流S可以是元素(s,T)的组(也被称为“多集”)，其中“s”是在S的图式中，并且“T”是在时间域中。此外，流元素可以是元组-时间戳对，这可以表示为带时间戳的元组插入的序列。换句话说，流可以是带时间戳的元组的序列。在一些情况下，可以有多于一个具有相同时间戳的元组。而且，输入流的元组可以被要求按递增时间戳的次序到达系统。作为替代，关系(也被称为“随时间变化的关系”，并且不与“关系数据”混淆，其中关系数据可以包括来自关系数据库的数据)可以是从时间域到图式R的无界元组组的映射。在一些例子中，关系可以是无序的、随时间变化的元组组(即，瞬时关系)。在一些情况下，在每个时刻，关系可以是有界集合。它还可以表示为带时间戳的元组的序列，可以包括插入、删除和/或更新，以捕捉关系的变化状态。类似于流，关系可以具有该关系的每个元组可以符合的固定图式。另外，如本文所使用的，连续查询一般可以能够处理流和/或关系的数据(即，对照其被查询)。此外，关系可以引用流的数据。

在一些例子中，业务智能(BI)可以以特定的间隔(例如，在一 些情况下按天为基础)帮助驱动和优化业务运营。这种类型的BI通常被称为运营业务智能、实时业务智能或者运营智能(operational intelligence，OI)。在一些例子中，运营智能模糊BI与业务活动监控(business activity monitoring，BAM)之间的界线。例如，BI可以集中在历史数据的周期性查询。照此，它可以具有向后查找的焦点。但是，BI也可以被放到运营应用中，并且因此它可以从仅仅策略分析工具扩展到业务运营的第一线(front line)中。照此，BI系统也可以被配置为实时地分析事件流并计算聚合。

在一些例子中，连续查询语言服务(CQ服务)可以被配置为把BI分析服务器扩展成处理连续查询并启用实时报警。在一些方面，CQ服务可以提供与BI分析服务器和CQL引擎的集成。仅仅作为例子，BI分析服务器可以把连续查询委托给CQ服务并且CQ服务也可以对CQL引擎充当逻辑数据库(DB)网关。以这种方式，CQL引擎可以能够充分利用BI分析服务器用于其分析能力和语义建模。

在一些例子中，除其它的之外，CQ服务还可以提供以下功能：

·让BI分析服务器作为CQL引擎网关的远程服务；

·事件源/接收器适配器 

·从逻辑SQL加CQL扩展生成数据定义语言(DDL)；

·为所有类型的连续查询和实现选择提供统一的模型；

·维护元数据并支持可重启性；及

·高可用性和伸缩性支持。

此外，在一些例子中，OI是实时动态的业务分析形式，它可以提供业务运营的可视性和洞察。在帮助使大量数据有意义的意义上，OI常常链接到BI或实时BI或者与BI或实时BI进行比较。但是存在一些基本的区别：OI可以主要是以活动为中心的，而BI可以主要是以数据为中心的。此外，OI可以更适合用于检测和响应于开发情形(例如，趋势和模式)，不像可以按照惯例用作事后和基于报告来识别模式的方法的BI。

在一些例子中，业务事件分析和监控(business event analysis  and monitoring，BEAM)系统可以包括CQL引擎，以处理和/或接收飞行(in-flight)数据。例如，CQL引擎可以是存储器内的实时事件处理引擎，被配置为查询或以别的方式处理进入的实时信息(例如，BI或OI)。CQL引擎可以利用或理解时间语义并且被配置为允许定义要处理的数据窗口。在一些情况下，利用CQL引擎可以涉及总是对进入的数据运行查询。

在一些方面，CQL引擎可以包括完全成熟的查询语言。照此，用户可以就查询而言指定计算。此外，CQL引擎可以被设计为用于优化存储器、利用查询语言特征、运算符共享、丰富的模式匹配、丰富的语言构造，等等。此外，在一些例子中，CQL引擎可以既处理历史数据又处理流数据。例如，用户可以设置当加州的销量超过一定的目标时发送报警的查询。因而，在一些例子中，报警可以至少部分地基于历史销售数据以及进入的实况(即，实时)销售数据。

在一些例子中，CQL引擎或者以下描述的概念的其它特征可以被配置为以实时的方式组合历史上下文(即，仓库数据)与进入的数据。因而，在一些情况下，本公开内容可以描述数据库存储的信息与飞行信息的界限。数据库存储的信息和飞行信息都可以包括BI数据。照此，在一些例子中，数据库可以是BI服务器或者它可以是任何类型的数据库。另外，在一些例子中，本公开内容的特征可以启用以上特征的实现，而无需用户知道如何编程或以别的方式写代码。换句话说，特征可以在特征丰富的用户接口(UI)中或者以允许非开发人员实现历史数据与实时数据的组合的其它方式提供。

在一些例子中，以上概念可以被用来充分利用与复杂事件处理关联的丰富的实时和连续事件处理能力。可以支持几个特征，诸如但不限于归档的关系。照此，为了充分利用这种特征(例如，丰富的实时和连续事件处理)，系统可以被配置为透明地处理关系数据的启动状态和运行时状态。换句话说，系统可以被配置为管理在创建时非空的查询(即，归档的关系)。

在一些例子中，可以使用归档的关系。照此，当CQL引擎看到 指示基于归档的关系的查询时；例如，归档的关系还可以指示存在某些为了查询历史上下文它可以调用的实体。在一些例子中，数据定义语言(DDL)可以指示关于归档的关系的注释，诸如但不限于，怎么做才能查询、什么是表中重要的列和/或数据的剩余部分发送到哪里。在一些例子中，一旦查询在CQL引擎中被构造(例如，作为图)，系统就可以分析查询图。此外，在一些方面，存在某些有状态的运算符，就像“distinct”、“group aggr”、“pattern”和/或“group by”。但是，无状态的运算符可以只取得输入并把它发送到父亲，例如，下游运算符。因此，在这里，一种方法是存储这整个表。但是，利用归档的关系，系统可以分析查询图并决定它可以使用哪个最低的有状态运算符来查询档案。在一些例子中，系统(或者一个或多个计算机实现的方法)可以检索在遍历图时达到的最低的有状态运算符的状态。例如，查询图可以按拓扑次序从源开始被分析。至少部分地基于这第一个有状态的运算符，为了初始化用于经归档的关系定义的查询的运算符的状态，CQL引擎可以确定要读取的最佳数据量。

在至少一个非限制性例子中，就像关系和/或源的源运算符可以首先利用来自上次的查询输出和/或根进入拓扑遍历。例如，如果CQL查询看起来像：select sum(c1)from R1where c2>c25，则用于这个查询的计划可以看起来像：RelationSource→SELECT→GroupAggr。因此，遵循拓扑次序，并且由于RelationSource和SELECT都是无状态的，因此最低的有状态运算符可以是GroupAggr。以这种方式，查询的有状态运算符(在这个例子中是GroupAggr)可以使查询引擎能够在接收流数据之前利用来自数据存储的历史数据填充查询引擎。这可以至少部分地基于查询正在分析归档的关系并且该归档的关系已经这样被指示的事实来启用。

在一些例子中，用于给定的归档的关系的窗口尺寸可以由用户指定。在一些方面，关于归档的关系，窗口可以包括查询图中分析或以别的方式评估进入的流化内容的节点。换句话说，窗口可以定义可以 被查询引擎分析和/或处理的流化内容的量和/或将包括在归档的关系中的历史数据的量。

在高级别，一旦对流应用窗口，它就变成关系，然后可以应用规律的关系逻辑，就像对关系数据库一样。随着元组到达和离开窗口，所考虑的关系随着对照其被编译的查询而变化，从而同时发出结果。CQL可以支持RANGE(高达纳秒粒度)、ROWS、PARTITION BY和可扩展的窗口。这些窗口是流到关系运算符的例子。另一方面，ISTREAM(即，插入流)，DSTREAM(即，删除流)和RSTREAM(即，关系流)是关系到流运算符。在一些例子中，用户、开发者和/或管理者可以设置由查询引擎或者操作或托管该查询引擎的一个或多个计算系统提供的窗口尺寸(例如，经UI)。在一些例子中，流上的窗口可以是基于时间的范围窗口。例如，归档的关系上可配置值的窗口可以利用窗口尺寸和关于其计算窗口的属性来指定。当存在在归档的关系之上指定的可配置值的窗口时，可以计算快照查询并且可以输出在窗口限制内的快照元组。此外，在状态初始化之后，值窗口可以应用到进入的活动数据。在一些例子中，只有进入的活动数据将被插入其窗口属性值与当前事件时间之差小于窗口尺寸的窗口中。

此外，在一些例子中，本公开内容的特征还可以充分利用CQL引擎和/或CEP引擎的连续查询处理能力来支持实时数据分析。在一些方面，CQL引擎和/或CEP引擎可以按照惯例被用作面向流的分析引擎；但是，它可以被增强，以支持通过持久存储(例如，以上描述的归档的关系)备份的面向流的数据。例如，本公开内容描述可以支持是持久存储(数据库和/或表)的数据对象(data object，DO)的概念的特征。对DO所作的修改可以使变化通知广播到感兴趣的监听者，从而实际上产生数据流。这种数据流可以被CQL引擎和/或CEP引擎消费，以支持任何运行的查询；但是，CQL引擎和/或CEP引擎可能未设计为考虑DO备份存储中的现有数据。例如，CQL引擎和/或CEP引擎可以要求在CQL引擎和/或CEP引擎中运 行的查询的初始状态反映包括目前在DO备份存储中的所有数据的DO的当前状态。一旦这种查询被这样初始化，CQL引擎和/或CEP引擎就只需要以传统面向流的风格关心从那个点开始的DO变化通知流。

在一些方面，CQL引擎和/或CEP引擎可以按照惯例处理流或非归档的关系，因此可能没有初始状态。例如，查询可以被加载，其中它可以开始运行并监听变化，等等。在一些情况下，如果用户在条形图中按州询问销售情况，然后有人做了新的销售，则表可以得到更新并且用户可以预期看到图中向其推出的变化。但是，如果他们关闭仪表板并且一周之后回来并带来一些销售，则用户可以预期具有根据总计的销售数据的表的销售总数。换句话说，查询可能需要把查询带到档案的状态，然后监听活动的变化。

在一些方面，例如，CQL引擎可以利用归档的数据预先初始化。一旦被初始化，CQL引擎就可以从Java消息传输服务(Java Messaging Service，JMS)或其它信使监听变化通知(例如，至少部分地基于从档案插入、删除等等数据的API)。因而，服务可以监听并且，如果JMS关于监听服务正在监听的相同主题发布，则它可以接收该数据。服务不必知道谁正在发布或者它们是否在发布。监听服务可以仅仅监听，并且如果发生了什么事，监听服务可以听到。在一些例子中，这是持久性如何从，例如，其消费者解耦合。此外，在一些例子中，报警引擎可以基于报警引擎可能听到什么而发出报警，并且进一步SQL可以在与监听者相关的查询过程中监听。

在一些例子中，查询可以在CQL、SQL和/或CEP引擎中开始并且指令可以被配置为获得归档的数据(例如，灌泵)，然后开始监听这些JMS消息。但是，对于众多的插入、删除等等，这可以包括大量的信息。此外，在消息被监听者听到之前会有滞后时间，并且在一些例子中，监听可以跳入、查询档案、复原并开始监听。因此，存在错过和/或重复计数事件的可能性。

此外，如果引擎仅仅运行查询，则在它运行查询的时候，会有事 情进入JMS并且在引擎不监听的地方被发布。因此，引擎可以被配置为首先设置监听者、运行档案查询，然后复原并实际开始拉出查询，使得它不错过任何情况。因此，JMS可以把情况排队并且，如果在引擎进行查询时情况被备份，则是正常的，因为它可在以后赶上并且不必担心它是否同步。如果这时候引擎不在监听，则也不会错过它，它只是被排队，直到引擎复原，只要它已确立了其监听者就行。

此外，在一些例子中，系统列可以添加到用户的数据。这个系统列可以用于指示事务ID，以尝试处理重复计数和/或错过操作问题。但是，在其它例子中，系统可以提供或以别的方式生成事务上下文表。此外，可以有两个附加的列TRANSACTION_CID和TRANSACTION_TID。上下文表可以总是由持久性服务维护，从而以线程(上下文)方式知道最后一个提交的事务ID。事务ID可以被保证对线程(上下文)按升序提交。例如，当服务器到来时，它可以运行持久性服务。每个可以分配一组上下文ID和事务ID，用于确定预先初始化的信息的数据是否包括经过JMS的所有数据。此外，在一些情况下，多个输出服务器可以被使用(与JTA兼容和/或实现高可用性(high availability，HA))，其中每个服务器可以管理与由其它服务器管理的其它表完全分离的单组上下文/事务表。

以上和以下描述的技术可以以多种方式并且在多种上下文中实现。参考以下的图提供几种示例实现和上下文，如以下更详细描述的。但是，以下的实现和上下文仅仅是许多中的一些。

图1绘出了利用归档的关系管理连续查询的技术可以在其中实现的简化示例系统或体系架构100。在体系架构100中，一个或多个用户102(例如，帐号持有人)可以利用用户计算设备104(1)-(N)(统称为“用户设备104”)经一个或多个网络108访问一个或多个服务提供商计算机106。在一些方面，服务提供商计算机106还可以经网络108与一个或多个流数据源计算机110和/或一个或多个数据库112通信。例如，用户102可以利用服务提供商计算机106访问或以别的方式管理流数据源计算机110和/或数据库112的数据(例如，查询 可以对照110、112当中任何一个或二者运行)。数据库112可以是关系数据库、SQL服务器等等并且，在一些例子中，可以代表用户102管理历史数据、事件数据、关系、归档的关系等等。此外，数据库112可以接收或以别的方式存储由流数据源计算机110提供的数据。在一些例子中，通过提供对数据(例如，历史事件数据、流事件数据等等)的查询(也被称为“查询语句”)或其它请求，用户102可以利用用户设备104与服务提供商计算机106交互。然后，这种查询或请求可以被服务提供商计算机106执行，以处理数据库112的数据和/或从流数据源计算机110进入的数据。另外，在一些例子中，流数据源计算机110和/或数据库112可以是与服务提供商计算机106关联的集成式、分布式环境的部分。

在一些例子中，网络108可以包括多种不同类型网络当中任何一个或者其组合，诸如有线网络、互联网、无线网络、蜂窝网络、内联网系统和/或其它专用和/或公共网络。虽然所说明的例子代表用户102经网络108访问服务提供商计算机106，但是所描述的技术可以同等地应用在用户102通过固定电话经一个或多个用户设备104、经信息站或者以任何其它方式与一个或多个服务提供商计算机106交互的情况中。还应当指出，所描述的技术可以应用在其它客户端/服务器布置(例如，机顶盒等等)当中，以及非客户端/服务器布置(例如，本地存储的应用等等)当中。

用户设备104可以是任何类型的计算设备，诸如但不限于，移动电话、智能电话、个人数字助理(PDA)、膝上型计算机、台式计算机、瘦客户端设备、平板PC等等。在一些例子中，用户设备104可以经网络108或者经其它网络连接与服务提供商计算机106通信。另外，用户设备104还可以被配置为提供一个或多个用于请求要处理的数据库112(或者其它数据存储)的数据的查询或查询语句。

在一些方面中，服务提供商计算机106也可以是任何类型的计算设备，诸如但不限于，移动、台式、瘦客户端和/或云计算设备，诸如服务器。在一些例子中，服务提供商计算机106可以经网络108或 者经其它网络连接与用户设备104通信。服务提供商计算机106可以包括一个或多个服务器，有可能布置在群集中、作为服务器群或者作为彼此不关联的单独服务器。这些服务器可以被配置为执行或以别的方式托管本文所述的特征，包括但不限于，归档的关系的管理、与归档的关系关联的可配置数据窗口，和/或准确计数与管理本文所述的归档的关系关联的变化事件。此外，在一些方面，服务提供商计算机106被配置为作为包括流数据源计算机110和/或数据库112的集成式、分布式计算环境的部分。

在一种说明性配置中，服务提供商计算机106可以包括至少一个存储器136和一个或多个处理单元(或(一个或多个)处理器)138。所述(一个或多个)处理器138可以适当地在硬件、计算机可执行指令、固件或者其组合中实现。所述(一个或多个)处理器138的计算机可执行指令或固件实现可以包括以任何合适的编程语言书写的计算机可执行或机器可执行指令，以执行所描述的各种功能。

存储器136可以存储可在(一个或多个)处理器138上加载并执行的程序指令，以及在这些程序执行过程中生成的数据。依赖于服务提供商计算机106的配置和类型，存储器136可以是易失性的(诸如随机存取存储器(RAM))和/或非易失性的(诸如只读存储器(ROM)、闪存存储器等等)。服务提供商计算机106或服务器还可以包括附加的储存器140，它可以包括可移除的储存器和/或不可移除的储存器。附加的储存器140可以包括，但不限于，磁储存器、光储存器和/或带储存器。盘驱动器及其关联的计算机可读介质可以提供用于计算设备的计算机可读指令、数据结构、程序模块和其它数据的非易失性存储。在一些实现中，存储器136可以包括多种不同类型的存储器，诸如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)或ROM。

都是可移除和不可移除的存储器136、附加的储存器140全是计算机可读存储介质的例子。例如，计算机可读存储介质可以包括以任何方法或技术实现的易失性或非易失性、可移除或不可移除的介质， 用于存储诸如计算机可读指令、数据结构、程序模块或其它数据的信息。存储器136和附加的储存器140都是计算机存储介质的例子。

服务提供商计算机106还可以包含允许身份接口计算机120与所存储的数据库、另一计算设备或服务器、用户终端和/或其它设备在网络108上通信的通信连接142。服务提供商计算机106还可以包括输入/输出(I/O)设备144，诸如键盘、鼠标、笔、语音输入设备、触摸输入设备、显示器、一个或多个扬声器、打印机等等。

更具体地转向存储器136的内容，存储器136可以包括操作系统146和用于实现本文所公开的特征的一个或多个应用程序或服务，包括至少归档的关系模块148、可配置窗口模块150和/或事件计数模块152。如本文所使用的，模块可以指由服务器或服务器群集执行的作为服务的部分的编程模块。在这种特定的语境下，模块可以被作为服务提供商计算机106的部分的服务器或服务器群集执行。在一些例子中，归档的关系模块148可以被配置为接收、识别、生成或以别的方式提供一个或多个归档的关系154，这可以包括对一个或多个事件流条目s1、s2…sN的引用。例如，归档的关系可以通过对包括这些条目(即，s1至sN)的流应用窗口来定义。照此，归档的关系可以是包括这些条目的有界数据集。但是，条目可以在生成时是非空的，包括但不限于，具有从持久性或历史数据的某个其它数据库预先加载的关系的一个或多个条目(例如，s1和/或s2、更多条目或更少)。照此，这些预先加载的条目可以包括历史数据，并且关系的剩余部分可以包括进入的流数据。在一些例子中，归档的关系154可以首先被识别为{s3,s4}。但是，当窗口从w1移动到w2时，归档的关系154可以被识别为{s4,s5}并且已经通过删除s3和/或插入s5而改变。

如以上所指出的，归档的关系154可以是在其创建“时刻”(有可能)非空的CQL关系。这与在创建“时刻”具有空内容的“正常”CQL关系形成对比。在一些例子中，可以想像成就好像归档的关系154的内容在其创建时刻从“时间开始”就存在(Long.MIN_VALUE)。在BEAM语境下，指出CQL引擎156的 对象(在一些例子中，所有对象)可以在每次服务器启动时创建是有用的。在一些方面，归档的关系154可以类似于“正常”CQL内部关系。特别地，操作(关系到关系操作，就像JOIN、GROUP AGGR、ORDER BY TOP N，以及关系到流操作，就像I/D/RSTREAM)可以保留与它们在“正常”CQL内部关系上所具有的相同语义。此外，在一些例子中，“归档器”可以是实现与CQL引擎156的特殊合同的Java类。它可以实现IArchiver接口或者能够启用归档器的某种其它接口。这种“归档器”连同由该“归档器”管理的、对应于归档的关系154的逻辑实体的身份(例如，Data Object的名字)可以作为用来创建归档的关系154的DDL语句的部分被指定。

在一些方面，归档器可以至少部分地基于与CQL引擎156的合同来实现，以便至少在创建归档的关系154时提供其内容。此外，归档器可以预期自己(例如，在CQL引擎156的外部)维持归档的关系154“随时间变化的”内容。但是，在一些例子中，归档器可以是无状态的。在这种例子中，归档器可以实现执行由归档的关系框架交给其的查询的方法(例如，“execute()”)。然后，一旦该方法被执行，归档器就可以把内容返回给归档的关系框架。归档器还可以被配置为对归档的关系154提供查询能力(例如，由SQL-99查询表示的)。此外，在一些例子中，给予“归档器”的查询中的FROM子句项可以是“归档器”实体的名字和/或(例如，在持久存储上维护的)DataObject的名字。当FROM子句项是DataObject的名字时，它们可以被映射到创建DDL中的归档的关系。此外，或者作为替代，归档器名字可以被用来查找归档器实例(可以有多于一个归档器)然后对那个归档器实例调用执行(查询)。根据需要，查询中所使用的属性名字可以是在CREATE ARCHIVED RELATION DDL或者其它适当DDL中指定的列名。在执行查询的时候，“归档器”可以对包含截至txn T_n提交的变化的Data Object的快照运行查询，其中T_n不早于用于Data Object的事件作为流输入给出的最后 一个事务。特别地，可能还没有流Data Object事件作为对应于“更晚”事务的输入提供。

另外，“归档器”可以返回截至这个查询被执行时事务的ID。这个ID可以是单调递增的数字(不必连续)，使得较晚的事务与较早的事务相比具有更大的ID。对于UPDATE事件，“归档器”可以作为流事件的部分提供，OLD以及NEW值。此外，或者作为替代，在一些例子中，持久性服务可以把具有OLD和NEW值的变化通知发送到CQ服务。以这种方式，CQ服务可以能够对归档的关系执行适当的操作。对于DELETE事件，如果(在一些例子中，“如果并且只有如果”)它通过验证(即，它与现有的Data Object记录匹配)，则“归档器”可以把DELETE事件作为流事件提供。在一些例子中，归档器的功能可以启用其中不存在查询不处理的Data Object事件的场景。通过跳过具有的事务标识符<＝由“归档器”作为执行“快照”查询的部分所返回的事务标识符的所有Data Object事件的处理，CQL引擎156还可以启用其中没有重复的事件被处理的场景。在一些例子中，归档器可以与持久性服务具有可比性。作为替代，或者附加地，在查询时刻的快照信息还可以从事务上下文表得出。这种快照信息可以在CQL引擎中维护并且snapshotID(递增的标识符)可以与其关联。在那个查询计划中一些选定的运算符的输入队列中，这同样可以被设置。这些被称为“连接器”运算符并且它们可以代表本地查询计划可与全局(整体)查询计划接合的地方。当事件到达CQL引擎时，可以利用其中的上下文ID和事务ID值为那个事件计算snapshotID。snapshotID可以利用CQL引擎中维护的快照信息计算。然后，事件的snapshotID可以与输入队列的snapshotID进行比较。如果事件中的ID>队列中的ID，则它可以被处理，否则，它之前已经被考虑过了并且因此可以被忽略，以避免重复计数。

归档的关系154作为本地CQL概念的引入使得CQL引擎156能够确定为了为经归档的关系154定义的查询初始化运算符的状态而要被读取的最佳数据量。在一些例子中，作为查询编译的最后步骤， 在查询计划生成(和/或与全局计划合并)之后，可以引入状态初始化阶段，以确定要对照“归档器”运行的最佳查询集合(例如，为了运算符状态初始化的目的)。在一些情况下，被用来确定查询集合(例如，最佳集合)的状态初始化算法可以在运算符链上向上推迟状态的具体化(materialization)，直到遇到有状态的运算符(该运算符聚集数据并且由此，与存储器中所有细节/事实的具体化相比，可以检索更少数据)。甚至在运行状态初始化查询之前，查询执行中的第一步可以是快照查询的执行和/或结果向客户的输送。在一些例子中，快照查询(也被称为“归档器查询”)可以是状态初始化的部分，其中，运算符可以利用结果的内容被初始化。然后，这些结果可以传播到下游运算符(例如，所有的下游运算符)，因此输出结果。接下来，由状态初始化算法确定的查询可以被运行。在这个第一步结束时，所有运算符的状态都已经被适当地初始化并且查询可以准备好处理流事件。

当CQL查询提到归档的关系154时，在系统重启过程中，CQL引擎156可以被配置为启用其中查询中的执行运算符的状态被初始化为它们在关机之前所具有的值的场景。作为替代，或者附加地，每次(重新)启动查询时，不管是作为关机的一部分还是自动地，查询都可以发布新的归档器查询，以再次初始化状态。在一些例子中，这在时间t0+delta与在t0可以不同。在一些情况下，状态初始化算法可以被配置为处理这种功能。在一些例子中，每个(或者每一个)归档的关系154可以映射到对构成关系的事件保持跟踪的归档器对象并且可以能够对发布给其的SQL查询(类似于数据库表)作出应答。此外，初始化CQL查询中的执行运算符的状态可以是两步的过程，包括至少：向归档器发布映射到CQL查询依赖于其的归档的关系154的适当SQL查询；并且使用返回的结果初始化运算符的状态。推迟(从归档器获得的)事件的具体化会导致更少的存储器和/或处理时间消耗。此外，或者作为备选，存储器节约可以是由于发现了最小化存储器的适当运算符。例如，聚合的/汇总的数据可以被带到存储器 中，从而导致显著的存储器节约。

在一些例子中，状态初始化过程(这可以是整个过程的一步，并且可以在CQL查询开始时实现并且涉及归档的关系)可以包括：利用元数据对象为查询获得逻辑计划、从该逻辑计划构造物理计划、利用优化器优化本地物理计划、共享操作以获得全局物理计划、添加辅助结构(例如，大纲、存储、队列等等)并且实例化查询(例如，构造执行运算符和/或支持执行结构)。此外，从其调用状态初始化算法的适当位置可以刚好在本地物理计划优化之后。在一些例子中，状态初始化算法可以只在查询依赖于一个或多个归档的关系154时被调用。

在一些例子中，给定二元运算符，孩子运算符可以被标记为查询运算符。而且，如果在遍历整个查询计划之后没有识别出查询运算符，则根可以被标记为查询运算符。一旦运算符被识别为查询运算符，在实例化阶段中如果设置了isQueryOperator标记，则执行所构造的归档器查询的方法将从Operator Factory代码被调用。然后，返回的结果集可以被转换成一组元组并且列表可以在执行运算符实例中设置。以这种方式，当实例化时，需要状态的执行运算符可以具有足以初始化其状态的元组列表。在实例化时，可以以拓扑次序对查询执行多于一次，其中将使用这些元组初始化状态并且把它向下游传播的方法可以被调用。这种方法可以是特定于运算符的和/或初始化处理可以类似于填充大纲、维护内部数据结构，等等。

在一些例子中，可以实现在“sales”归档的关系154之上的以下CQL查询：

SELECT SUM(sales),productid

FROM sales

WHERE region＝“APAC”

GROUP BY productid

在一些例子中，当在CQL引擎156中被编译时，查询计划可以被描述为：

OUTPUT

↑

PROJECT

↑

GROUP BY AGGREGATION(<grouping key>,sum(sales)) 

↑

FILTER(region＝“APAC”)

↑

REL_SOURCE(归档的关系:sales)

在一些例子中，当CQL引擎156编译以上提到的查询时，它可以确定查询是对照关系(例如，归档的关系154)来表达的，其中在启动时关系的状态可在外部获得并且有可能大。在CQL中可以存在一组有状态的运算符(例如，GROUP BY、PATTERN)，而其它(例如，FILTER、PROJECT、OUTPUT)可以不是有状态的。状态初始化算法可以如下对所考虑的场景工作：REL_SOURCE运算符可以跳过调用归档器，因为它对于归档的关系是无状态的。接下来上一个是FILTER，它也是无状态的，因此它也可以对状态跳过调用归档器。接下来，会遇到GROUP BY运算符，并且它可以调用归档器，以便利用以下SQL查询填充其状态(根据需要，归档器查询可以是通过利用基于子查询的方法构成的SQL查询并且可以比以下更复杂)：

SELECT SUM(sales),COUNT(*),productid

FROM SALES_DO

WHERE region＝”APAC”

GROUP BY productid

应当指出，尽管用户的查询可以不包括COUNT聚合，但是GROUP BY可以发布具有COUNT聚合的SQL查询。这可以是因为这条信息可以被GROUP BY运算符请求(作为其状态的部分)，以确定一个组(在这个例子中，对应于“productid”)是否变成空，使得它可以释放可能关于该组使用的任何资源(就像存储器)。

现在，考虑其中-ve元组到达的情形。在以上场景中，REL_SOURCE不能维护任何状态，因此这可以让链中下一个运算符决定(而不是像“常规”CQL关系那样扔出异常)。FILTER运算符也不能维持任何状态，并且它同样这么做。接下来，GROUP BY运算符可以看到该元组。由于其状态已经被初始化，因此它可以能够成功地定位对应的组并且继续处理的剩余部分。例如，如果它是具有region＝”APAC”并且productid＝“Mobile Phones”的元组，则SUM聚合函数可以将对“Mobile Phones”的运行总数减少该元组中存在的数量。

在一些例子中，在“sales”归档的关系154之上的以下CQL查询可以被实现，用于确定与上例中的总计相对的中值：

SELECT MEDIAN(sales),productid

FROM sales

WHERE region＝“APAC”

GROUP BY productid

在一些例子中，当在CQL引擎156中被编译时，查询计划可以被描述为：

OUTPUT

↑

PROJECT

↑

GROUP BY(MEDIAN)(<grouping key>,median(sales)) 

↑

FILTER(region＝“APAC”)

↑

REL_SOURCE(archived relation:sales)

在一些例子中，状态初始化算法如下对所考虑的场景工作。REL_SOURCE运算符可以跳过调用归档器，因为它对归档的关系可以是无状态的。接下来上一个是FILTER，它也可以是无状态的，因此它也可以对状态跳过调用归档器。接下来，会遇到GROUP BY运算符。这个运算符可以是有状态的并且因此可以请求状态初始化。在这里，查询涉及至少一个整体函数(MEDIAN)，因此从数据库带来聚合的/汇总的状态可能不够。可以对GROUP BY状态请求MEDIAN要对其计算的整个值集合。

因而，在这个阶段，在识别出最低的有状态运算符并且确定可以请求更多细节以构成其状态之后，运算符计划可以在相反的方向(即，“下”)遍历。即，计划可以从这个阶段开始自顶向至下被遍历。在一些例子中，构造状态的责任将落在树中向下的下一个运算符上，在这种情况下可以是FILTER并且它可以(向“归档器”)发布以下可以把所请求的值集合带入存储器的SQL查询：

SELECT sales,productid

FROM SALES_DO

WHERE region＝“APAC”

在一些例子中，一旦检索出这些元组，FILTER就可以把这些值向上游传播并且GROUP BY可以通过构造树或图(例如，但不限于，增强的红黑树(Augmented Red-Black tree)等等)来建立其状态。这种数据结构可以启用非常快速的后续(O(log n)时间)递增MEDIAN计算。在一些例子中，如果FILTER在以上查询中缺少，则构造状态的责任将落在REL_SOURCE运算符上并且关系的整个内容(作为优化，与整个行相比，只有被查询访问的相关字段针对每一行被检索。当然，如果所有字段都被访问，则整个行将被读取)可以被带入存储器。

在一些方面，为了基于归档的关系154处理到达查询的minus事件，附加的支持会是有用的。一些就像Project的CQL引擎156运算符、就像join的二进制运算符维护世系大纲。这种世系大纲中的查找基于TupleId。当PLUS元组到来时，它可以被插入该大纲。当MINUS元组到达那个运算符时，我们查找碰到该tupleId的世系大纲。在归档的关系154的语境下会遇到的问题如下：

1.当查询开始时，维护世系大纲的运算符可以被识别为查询运算符并且它可以查询归档器并且把所返回的结果转换成元组并把它们放在世系大纲中。

2.此外，当查询开始运行时，它接收的第一个元组可以是对应于归档的plus元组之一的MINUS。在这里，PLUS和MINUS元组的ID可能不匹配并且这将导致失败的查找和不正确的结果。

3.在正常关系情况下，关系源可以帮助确保PLUS和MINUS元组具有相同的ID，因为它可以维护大纲，但是对于归档的情况，这可能是不可能的。

照此，BEAM持久性层可以向每个事件分配事件ID，并且事件的INSERT(PLUS)、DELETE(MINUS)和UPDATE通知可以全都具有这个ID的相同值。这种措施可以被用来避免以上提到的问题。因此，多于一个子句可以添加到归档的关系154DDL，以指定EVENT IDENTIFIER子句。这可以是类型为CQL bigint的列并且这个列可以对用于事件的plus、minus和update元组具有相同的值。

在一些情况下，在CQL引擎156中，在EVENT IDENTIFIER子句中指定的列可以被使用。例如，当归档器被查询时，这个字段可以被强制在SELECT列表中存在并且在把记录转换成元组的时候使用这个字段的值来设置tupleId。而且，当正常的输入事件到来时(例如，当运行查询时)，在把TupleValue转换成关系源代码中的ITuple的时候这个字段中的值可以被分配为tupleId。这可以启用确保事件的PLUS和MINUS具有相同元组ID的配置。

在一些例子中，以下语法可以被用于归档的关系DDL：

CREATE ARCHIVED RELATION

SalesDataObjectChannel(region char(8),productid int,sales float,eventid bigint) 

ARCHIVER com.oracle.beam.PersistenceServiceArchiverImpl ENTITY“SALES_DO”

EVENT IDENTIFIER eventid

这个创建归档的关系的DDL可以对终端用户以及其它部件是不可见的。例如，归档的关系的创建可以在EPN包含连接到CQL处理器节点的Data Object节点时由CQL处理器代码“在幕后”处理。例如，考虑以下EPN：

(SalesDataObjectNode for SALES_DO)→

(SalesDataObjectChannel)→(CQL处理器)

这种EPN代码可以使用Data Object的字段名作为它在CQL引擎156中创建的归档的关系的列名，由此确保字段的名称与字段的次序匹配。

此外，在一些例子中，归档的流可以经CQL引擎156和/或其它引擎启用。从概念上讲，归档的流可以非常类似于归档的关系特征。但是由于流与关系之间的语义差别，因此与归档的关系特征相比，可 以对归档的流的设计和语法进行某些改变。例如，关系内容可以在添加、更新或删除发生时经历变化。照此，内容的尺寸会随时间增长或收缩。但是，对于流，通过定义，更新和删除是不可能的。因此，流的尺寸可以只保持递增。因此，过去的流的内容的尺寸会大得惊人并且大部分时候用户只对由归档器维护的刚刚过去的子集感兴趣。

照此，以下语法可以用于归档的流DDL：

CREATE ARCHIVED STREAM<stream_name>(stream schema) 

ARCHIVER<archiver_name>ENTITY“<entity_name>”

TIMESTAMP COLUMN<timestamp_col_name>

REPLAY LAST(<time_spec>|<intToken>ROWS)

[IS SYSTEM TIMESTAMPED]

在这里，ARCHIVER和ENTITY子句可以具有与对于归档的关系154相同的意义。但是，EVENT IDENTIFIER可能是不需要的，因为它一般只用于处理MINUS事件，而这对于流是不会发生的。此外，REPLAY LAST子句可以允许用户指定刚过去的感兴趣的部分。用户可以把它指定为时间范围或者就行数来指定。因此，例如，REPLAY子句可以是REPLAY LAST 30 MINUTES(在这种情况下，在过去30分钟内到达的记录可以从归档器读取)或者REPLAY LAST 50 ROWS(在这种情况下，按到达时间排序的最近50条记录可以从归档器读取)。

TIMESTAMP COLUMN子句可以被用于识别在查询归档器时可返回的记录。这可以在归档器查询的WHERE子句中使用，该子句确定作为归档器查询的结果集的部分的记录。这一列中的值还可以在把时间戳分配给CQL引擎156中的(可以通过查询归档器获得的)元组时使用。这个列名可以是DO中具有由BEAM持久性分配的创 建时间戳的列的名称。

此外，在一些例子中，配置窗口模块150可以被配置为生成、接收和/或确定窗口尺寸158，用于配置CQL引擎156的一个或多个归档的关系154。但是，在一些例子中，在归档的关系上定义不同窗口不会产生单独的归档的关系实例。相反，当应用窗口时，只有单个归档的关系实例，并且该窗口可以确定那个归档的关系中对那个特定查询来说“感兴趣”的数据。如以上所指出的，窗口尺寸158可以配置归档的关系154的窗口w1、w2和/或wN的尺寸。以这种方式，根据需要，用户可以具有对窗口尺寸的控制并且可以至少部分地基于与业务事件数据和/或个人关注、业务目标和/或其它因素关联的信息指定尺寸。

另外，在一些例子中，事件计数模块152可以被配置为在CQL引擎156或其它引擎中实现一个或多个监听服务160，其中引擎被配置为在流或归档的关系154中启用变化事件的正确计数。如简单讨论过的，当连续查询162指示对由CQL引擎156管理的流和/或归档的关系164的依赖性时，CQL引擎156可以实现监听服务160。在至少一些例子中，监听服务实现的定时可以确定流/关系164中的变化事件是否被正确计数。此外，如指出的，在一些例子中，连续查询162可以被配置为通过对照历史和/或仓库数据的数据存储166进行查询来初始化归档的关系164的数据。

在一些例子中，当查询在CQL引擎156中运行时，它可以首先对照DataObject备份存储运行查询，以确立DataObject的当前状态，然后从那个DataObject监听并处理变化通知。这产生了两个问题：在CQL引擎156运行初始查询的时候，变化通知可能被错过；如果变化已经在初始查询中，则变化通知可能被重复计数。

错过变化通知可以通过在开始初始查询之前确立变化通知监听者但是一直到归档器查询执行完成和/或状态初始化完成才处理它们来消除。这些变化通知可以被缓冲在消息传输服务(JMS)中，一直到CQL引擎156准备好处理它们。在一些情况下，消除变化通知的重 复计数可以通过向持久性服务供给附加信息来执行，以允许CQL引擎156确定哪些变化通知包括在初始查询结果中以及哪些不包括。

在一些例子中，可以向每个包含影响该DataObject实例(行)的最后一个事务的事务ID的DataObject添加附加列(例如，DATAOBJECT_ID)。但是，在其它例子中，不添加附加的列并且，作为替代，可以使用事务上下文。这种事务ID可以是不与任何其它事务机制，诸如JTA，混淆的内部BEAM人工因素。在一些例子中，这种事务ID可以是单调递增的整数。被同一JTA事务修改的一些(或全部)DataObject实例(例如，行)可以利用相同的事务ID作标记。此外，事务ID可以按升序提交。这个相同的列可以包括在DataObject变化通知中。给定以上所述，如果查询包括MAX(DATAOBJECT_TID)，则我们的查询结果中存在的最高事务ID可以被知道。照此，任何变化通知中的事务ID可以对照该最高值进行比较，因为小于或等于的值可以被忽略(即，因为它已经被计数过了)并且大于的值可以被处理(即，因为它还没有被计数)。

但是，在一些情况下，为了具有按升序提交的事务ID，DataObject事务可以被串行化。然而，这会对并发性具有不利的影响。并发性仍然可以通过引入上下文ID的概念来递增。在一些例子中，每个上下文ID可以维护其自己的事务ID。对BEAM上下文的专门访问可以通过对照BEAM DataObject执行操作的JTA事务获取。然后，这相同的BEAM上下文可以被用于由那个JTA事务执行并且最终在该JTA事务提交或回滚时被释放的操作(例如，全部操作)。这可以允许处理跨BEAM上下文并行地前进。于是，并发性的水平可以与BEAM上下文的分配成比例。附加的列(DATAOBJECT_CID)可以添加到每个DataObject，以保持最后一个上下文的ID，来修改那个DataObject实例(行)。但是，在其它例子中，不添加附加的列并且，代替地，可以利用事务上下文。上下文ID，就像事务ID，也可以包括在DataObject变化通知中。然而，这会改变对查询侧的需求，因为，为了消除重复计数，可能需要 获得上下文ID的MAX(DATAOBJECT_TID)。

在一些例子中，如果引入事务上下文实体的概念，则相同水平的并发性可以在不向DataObject添加附加列的情况下实现。于是，可以创建新的Java类和关联的JPA实体来维护数据库中上下文ID的状态。事务上下文实体可以包括上下文ID及其关联的(最高的、最后使用的)事务ID。上下文ID可以作为序列生成并且可以是实体的主键。

当持久性服务被初始化时，它可以创建被配置个数的事务上下文实例。这些事务上下文实例可以仅仅让那个持久性服务使用。如果另一个持久性服务在另一个服务器上被初始化，则它也可以创建被配置个数的事务上下文实例。以这种方式，每个持久性服务可以被保证具有独特的上下文集合。持久性服务可以创建事务上下文的实例并且可以经JPA持久化它们。由于这是序列化的实体并且该序列是上下文ID，因此所创建的事务上下文实例可以自动地是独特的。所创建的每个事务上下文可以得到下一个序列号。当持久性服务被关闭时，它可以删除它创建的事务上下文实例。在一些情况下，这可以从数据库除去它们。

在一些例子中，DataObject操作(例如，所有或一些DataObject操作)可以最终通过EJB方法(例如，称为processDataObjectOperations)进行。这种方法可以取得DataObjectOperations的集合，关于其，存在对插入、更新、插入更新(upsert)和/或删除的派生。每个DataObjectOperations可以通过名字、特定的操作以及那个操作所需的数据来指定目标DataObject。DataObjectOperations可以包含DataObjectOperation目标(targeting)和/或任何数量DataObject的任意组合。DataObjectOperation可以按它们添加到DataObjectOperations的次序执行。processDataObjectOperations方法可以被定义为TransactionAttributeType.REQUIRED，这意味着，如果在JTA事务内被调用，则它可以参与那个事务。但是，如果在JTA事务之外被 调用，则应用服务器可以对该方法调用的持续时间开始JTA事务。在一些情况下，这意味着processDataObjectOperations可以总是在JTA事务中操作。此外，对照DataObject的一些或全部操作可以在JTA事务中发生。

在一些例子中，消除变化事件的重复计数可以通过以下操作被启用(根据需要，这可以按任何适当的次序执行)。例如，当processDataObjectOperations被调用时(虽然以下操作被编号，但是这些编号仅仅是为了帮助解释而不是要把操作集合限制到任何特定的次序或者限定到所需的任何操作)：

1.可以尝试从关联的JTA事务读取事务上下文。如果存在关联的事务上下文，则它可以被使用。但是，如果不存在关联的事务上下文，则：

a)排它锁可以从在启动时由持久性服务创建的可用事务上下文实例集合(池)对事务上下文实例获得。如果事务上下文不可用，则调用可以被阻塞，直到事务上下文变得可用。这种锁定可以在Java中和/或在数据库中进行。

b)这种事务上下文中的事务ID可以递增到序列中下一个数字，该数字可以变成用于关联的JTA事务的事务ID。

c)事务上下文实例可以“附连”到JTA事务，作为应用资源。如果多个调用在其关联的JTA事务中进行，则这可以允许持久性服务从那一个JTA事务获得事务上下文(例如，就像在以上的操作#1中一样)。这可以确保相同的事务上下文用于在相同JTA事务中执行的操作，而不管那个JTA事务是否从BEAM服务器中还是不从BEAM服务器开始。

d)事务上下文实例可以作为事务同步监听者添加到关联的JTA事务。这可以允许在JTA事务完成时通知持久性服务，使得它可以采取适当的动作。

e)具有递增的事务ID的事务上下文实体可以合并。在一些例子中，这种数据库更新也可以在关联的JTA事务中发生。

2.指定的DataObject操作可以被执行。被触发的变化通知可以利用来自事务上下文的上下文ID和事务ID标记。

3.processDataObjectOperations方法调用可以完成。

4.如果附加的调用要在相同的JTA事务中进行，则以上的操作#1可以拾取“附连”的事务上下文并且前进到操作#2。

5.在一些情况下，如果JTA事务提交： 

a)所执行的DataObject操作可以被提交到数据库。

b)DataObject变化通知可以被发送(JMS)。

c)事务上下文合并可以被提交。

d)持久性可以得到事务已完成的通知并且可以把事务上下文释放回池中供后续事务使用。在一些方面，这可以发生在提交之后某个时间点。

6.在一些情况下，如果JTA事务回滚： 

a)所执行的DataObject操作可以被回滚。

b)DataObject变化通知可以被丢弃(JMS)。

c)BeamTransactionContext合并可以被回滚。

d)持久性可以得到事务已完成的通知，使得它可以把事务上下文释放回池中供后续事务使用。在一些方面，这可以发生在回滚之后。

在一些例子中，当执行查询以便从DataObject备份存储获得初始状态时，查询可以原子地执行，以便还在事务上下文表中包括UNION。以这种方式，对于我们的查询结果中的所有数据，可以接收查询结果加用于每个BEAM上下文的最高提交的事务ID。事务上下文信息允许任何DataObject变化通知被检查，以便通过对照事务上下文表中的ID检查变化通知中的ID来消除重复计数。作为替代，或者附加地，在查询时刻的快照信息也可以从事务上下文表得 出。这种快照信息可以在CQL引擎中维护并且snapshotID(递增的标识符)可以与其关联。这同样可以在那个查询计划中一些选定的运算符的输入队列中设置。这些被称为“连接器”运算符并且它们可以代表本地查询计划可与全局(整体)查询计划接合的地方。当事件到达CQL引擎时，可以利用其中的上下文ID和事务ID值为那个事件计算snapshotID。snapshotID可以利用CQL引擎中维护的快照信息计算。然后，事件的snapshotID可以与输入队列的snapshotID进行比较。如果事件中的ID>队列中的ID，则它可以被处理，否则它可能已经在之前被考虑过了并且因此可以被忽略，以避免重复计数。

在一些例子中，持久性层可以关于每个变化事件通知支持上下文ID(工作者标识符)和事务ID(事务标识符)和/或持久性层可以维护事务上下文表。此外，在查询开始时，CQL引擎可以从事务上下文表查询“快照”信息(工作者标识符、事务标识符对)并且把递增的快照ID与其关联。CQL引擎还可以在开始时在“连接器”运算符的输入队列设置快照ID。此外，在查询运行时，CQL引擎可以使用输入事件中的工作者标识符和/或事务标识符字段以及所维护的“快照”信息来为每个输入事件计算Snapshot Id。在查询运行时，CQL引擎还可以比较输入事件的快照ID与在输入队列中(在查询开始时)设置的快照ID，以决定是处理还是忽略事件。以下是用于工作者和事务ID子句的DDL的一般形式的例子：

CREATE ARCHIVED RELATION<relation_name>(schema) 

ARCHIVER<archiver_name>ENTITY“entity_name”

EVENT IDENTIFIER<col_name>WORKER IDENTIFIER<col_name> 

TRANSACTION IDENTIFIER<col_name>IS SYSTEM TIMESTAMPED 

在一些例子中，Archiver可以由CQ服务维护；Entity可以是作为加引号的串的Data Object的名字；Event ID可以是类型为long的列，它可以充当用于这个关系的唯一事件ID；Worker ID可以是 类型为long的列，它可以映射到持久性生成的变化通知中的上下文ID列；并且Transaction ID可以是类型为long的列，它可以映射到持久性生成的变化通知中的事务ID。以下是示例实现：

CREATE ARCHIVED RELATION sales_info(prodid integer,sales double,eid bigint,wid bigint,tid bigint)ARCHIVER myArchiver ENTITY“sales_do”EVENT IDENTIFIER eid WORKER IDENTIFIER wid TRANSACTION IDENTIFIER tid IS SYSTEM TIMESTAMPED 

类似地，在一些例子中，这两个子句可以在用于归档的流的REPLAY子句之后添加。

如前面所提到的，可能不需要利用修改过它的最后一个上下文和事务ID实际标记每个DataObject实例。在一些例子中，这种信息可以代替地从事务上下文实体接收。如前所述，实现这的一条途径是从DataObject以及事务上下文实体的内容原子地查询期望的数据。对于原子性，这可以只利用一个查询执行。例如，利用允许来自两个全异查询的结果集追加在单个查询中的UNION子句。在一些例子中，上述DataObject和/或持久性服务可以由图1的数据存储166体现。

可以在服务提供商计算机106和/或用户设备104中存在的计算机存储介质的附加类型(也可以是非临时性的)可以包括，但不限于，可编程随机存取存储器(PRAM)、SRAM、DRAM、RAM、ROM、电可擦除可编程只读存储器(EEPROM)、闪存存储器或其它存储器技术、光盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其它光学储存器、磁带盒、磁带、磁盘储存器或其它磁存储设备、或者可以用来存储所需信息并且可以被服务提供商计算机106和/或用户设备104访问的任何其它介质。以上所述的任意组合也应当包括在计算机可读介质的范围内。

作为替代，计算机可读通信介质可以包括计算机可读指令、程序模块，或者在数据信号中发送的其它数据，诸如载波或其它传输。但是，如本文所使用的，计算机可读存储介质不包括计算机可读通信介 质。

图2说明了用于利用归档的关系管理连续查询的特征可以关于其进行描述的简化框图200。如以上所指出的，在一些例子中，归档的关系、可配置的归档的关系窗口和/或变化事件计数可以在本文描述。如所示出的，图2描述了用于管理(例如，与项目203关联的)归档的关系的CQL引擎156和/或CQ服务202的至少一种实现。在一些例子中，当识别出包括归档的关系的查询(例如，连续查询)162时(例如，相对于流或历史数据，如果与项目203关联的Group By运算符204和/或Sales Info运算符206引用归档的关系)，CQL引擎156可以解析查询162并且把它发送到CQ服务202中的归档器208。此外，在一些例子中，CQL引擎156在这种情况下可以把GroupAggr(或Group By 204)运算符识别为查询运算符并且可以为那个运算符构造归档器查询。然后，这种归档器查询可以被发送到归档器208。在一些情况下，在那个时候，CQ服务202可以过时(go out)并得到快照(例如，从持久数据存储166和/或从BI服务器)。并且，虽然(包括BI/DB的)持久性层210可以具有数以千计或更多的条目，但是CQ服务202可以只检索产品的总计(例如，由于Group By运算符204)。照此，CQL引擎156可以接收变化事件212以及历史数据166。然后，输出214可以反映来自数据存储166的原始历史数据加上检索出的变化事件212。在一些例子中，在接收到-12，75变化事件时，+12，125可以在输出214中反映更新后的总计值。把CQL服务202连接到变化事件212的虚线指示CQL服务202可以在从持久性层210接收到变化事件之后把其发送到CQL引擎156。查询162中向上指的箭头是要指示与查询162关联的查询计划中的事件流。

图3绘出了可以结合本发明实施例的事件处理系统300的简化高级图。事件处理系统300可以包括一个或多个事件源(304、306、308)、配置为提供用于处理事件流的环境的事件处理服务器(EPS)302，以及一个或多个事件接收器(310、312)。事件源生成被EPS 302接收的事件流。EPS 302可以从一个或多个事件源接收一个或多个事件流。例如，如图3中所示，EPS 302从事件源304接收输入事件流314、从事件源306接收第二输入事件流316并从事件源308接收第三输入事件流318。一个或多个事件处理应用(320、322和324)可以部署在EPS 302上并被其执行。由EPS 302执行的事件处理应用可以被配置为监听一个或多个输入事件流、基于从输入事件流选择一个或多个事件作为值得注意的事件的处理逻辑来处理经一个或多个输入事件流接收的事件。然后，值得注意的事件可以以一个或多个输出事件流的形式被发送到一个或多个事件接收器(310、312)。例如，在图3中，EPS 302把输出事件流326输出到事件接收器310，把第二输出事件流328输出到事件接收器312。在某些实施例中，事件源、事件处理应用和事件接收器彼此解耦合，使得可以在不对其它部件造成变化的情况下除去这些部件当中任何一个。

在一种实施例中，EPS 302可以实现为包括轻量级Java应用容器的Java服务器，诸如基于Equinox OSGi的Java服务器，带共享的服务。在一些实施例中，EPS 302可以对处理事件支持超高吞吐量和微秒级等待时间，例如，通过使用JRockit Real Time。EPS 302还可以提供包括用于开发事件处理应用的工具(例如，Oracle CEP Visualizer和Oracle CEP IDE)的开发平台(例如，完全实时的端到端Java事件驱动体系架构(Event-Driven Architecture，EDA)开发平台)。

事件处理应用被配置为监听一个或多个输入事件流、执行用于从这一个或多个输入事件流选择一个或多个值得注意的事件的逻辑(例如，查询)，并且经一个或多个输出事件流把选定的值得注意的事件输出到一个或多个事件接收器。图3提供了对一个这种事件处理应用320的深度讨论。如图3中所示，事件处理应用320被配置为监听输入事件流318、执行包括用于从输入事件流318选择一个或多个值得注意的事件的逻辑的查询330，并且经输出事件流328把选定的值得注意的事件输出到事件接收器312。事件源的例子包括，但不限于， 适配器(例如，JMS、HTTP和文件)、信道、处理器、表、高速缓存，等等。事件接收器的例子包括，但不限于，适配器(例如，JMS、HTTP和文件)、信道、处理器、高速缓存，等等。

虽然图3中的事件处理应用320被示为监听一个输入流并且经一个输出流输出选定的事件，但这不是要作为限制。在备选实施例中，事件处理应用可以被配置为监听从一个或多个事件源接收的多个输入流、从被监视的流选择事件，并且经一个或多个输出事件流把选定的事件输出到一个或多个事件接收器。同一个查询可以与多于一个事件接收器并与不同类型的事件接收器关联。

由于其无限的本质，经事件流接收的数据的量一般非常大。因此，为了查询目的而存储或归档所有数据一般是不实际和不期望的。事件流的处理要求在事件被EPS 302接收时实时地处理事件，而不必存储全部接收到的事件数据。因而，EPS 302提供具体的查询机制，该机制使得事件的处理在事件被EPS 302接收时执行，而不必存储全部接收到的事件。

事件驱动的应用是规则驱动的并且这些规则可以以被用来处理输入流的连续查询的形式表达。连续查询可以包括识别对所接收的事件要执行的处理的指令(例如，业务逻辑)，其中查询处理包括什么事件要被选作值得注意的事件并且作为查询处理的结果输出。连续查询可以被持久化到数据存储并且用于输入事件流的处理和生成输出事件流。连续查询通常执行过滤和聚合功能，以便从输入事件流发现和提取值得注意的事件。因此，输出事件流中的离站事件的数量一般比从其选择事件的输入事件流中的事件数量少得多。

不像对有限数据集运行一次的SQL查询，已经由应用利用EPS 302对特定事件流注册的连续查询可以在每次那个事件流中接收到事件时被执行。作为连续查询执行的部分，EPS 302基于由连续查询指定的指令来评估所接收的事件，以确定是否有一个或多个事件要被选作值得注意的事件，并且作为连续查询执行的结果输出。

连续查询可以利用不同的语言编程。在某些实施例中，连续查询 可以利用由Oracle公司提供并被Oracle的复杂事件处理(Complex Events Processing，CEP)产品系列使用的CQL。Oracle的CQL是可以被用来编程可以对照事件流执行的查询(被称为CQL查询)的声明性语言。在某些实施例中，CQL基于SQL，具有支持流事件数据的处理的附加构造。

在一种实施例中，事件处理应用可以由以下部件类型组成：

(1)直接接口到输入和输出流以及关系源和接收器的一个或多个适配器。适配器被配置为理解输入和输出流协议，并且负责把事件数据转换为可以被应用处理器查询的规格化形式。适配器可以把规格化的事件数据转发到信道或者输出流和关系接收器。事件适配器可以为各种各样的数据源和接收器定义。

(2)充当事件处理端点的一个或多个信道。除其它的之外，信道负责把事件数据排队，直到事件处理代理可以对其作用。

(3)一个或多个应用处理器(或者事件处理代理)被配置为消费来自信道的规格化事件数据、利用查询处理它以便选择值得注意的事件，并且把选定的值得注意的事件转发(或拷贝)到输出信道。

(4)一个或多个bean被配置为监听输出信道，并且由于新事件插入输出信道而被触发。在一些实施例中，这种用户代码是简单的老Java对象(plain-old-Java-object，POJO)。用户应用可以使用一组外部服务，诸如JMS、Web服务和文件书写器，把生成的事件转发到外部事件接收器。

(5)事件bean可以被注册，以监听输出信道，并且由于新事件插入输出信道而被触发。在一些实施例中，这种用户代码可以使用Oracle CEP事件bean API，使得bean可以由Oracle CEP管理。

在一种实施例中，事件适配器向输入信道提供事件数据。输入信道连接到与一个或多个CQL查询关联的CQL处理器，其中CQL查询对由输入信道提供的事件操作。CQL处理器连接到查询结果要写到其的输出信道。

在一些实施例中，组装文件可以为事件处理应用提供，该文件描 述事件处理应用的各种部件、部件如何连接到一起、应用处理的事件类型。可以提供单独的文件，用于为事件的选择指定连续查询或业务逻辑。

应当认识到，图3中所绘出的系统300可以具有除图3中所绘出的之外的其它部件。另外，图3中所示的实施例仅仅是可以结合本公开内容实施例的系统的一个例子。在一些其它实施例中，系统300可以具有比图3中所示更多或更少的部件、可以组合两个或更多个部件，或者可以具有部件的不同配置或布置。系统300可以是各种类型，包括个人计算机、便携式设备(例如，移动电话或设备)、工作站、网络计算机、大型机、信息站、服务器，或者任何其它数据处理系统。在一些其它实施例中，系统300可以被配置为分布式系统，其中系统300的一个或多个部件跨云中的一个或多个网络分布。

图3中所绘出的一个或多个部件可以在软件中、在硬件中或者其组合中实现。在一些实施例中，软件可以存储在存储器(例如，非临时性计算机可读介质)、存储器设备或某种其它物理存储器上，并且可以由一个或多个处理单元(例如，一个或多个处理器、一个或多个处理器核心、一个或多个GPU，等等)执行。

图4说明了管理归档的关系的特征可以关于其进行描述的简化框图400。如图4中所示，归档的关系可以表示为查询图402。在一些例子中，查询图402可以包括代表查询的运算符的节点和代表查询图402的运算符之间的路径的顶点。在一个非限制性例子中，图4的查询图402包括Project(项目)运算符404、Group By(分组)运算符406和Relational Source(关系源)运算符408。另外，在一些例子中，Project运算符404和Relational Source 408可以是无状态的，而Group By运算符406可以是有状态的。在一些情况下，无状态的运算符不保持跟踪、管理或以别的方式请求状态，而有状态的运算符这么做。如以上所指出的，在一些情况下，查询图402可以以自顶向下的方式被分析或以别的方式被评估410，从而在有状态的运算符(在一些例子中，在第一个或者最低的有状态运算符)导入历史数 据。在分析410查询图402的时候，服务和/或引擎(例如，如参考图1-3所描述的CQ服务202和/或CQL引擎156)可以被配置为确定查询图402中的第一个有状态运算符。在图4的例子中，第一个有状态的运算符是Group By 406。照此，当服务到达Project运算符404(它在这个例子中是无状态的)时，表数据(即，历史数据)不能在412导入。但是，在414，当到达Group By运算符406时，历史的、仓库的和/或表数据可以被导入，以初始化归档的关系。

作为替代，或者附加地，在一些例子中，查询图402(也被称为计划)可以从源(在这里是Relational Source运算符408)开始以拓扑次序被遍历。照此，在这个例子中，遍历可以是自底向上的方式。在这种遍历中，当到达第一个有状态的运算符时，它可以被标记为查询运算符，然后图402可能不需要在那个分支中进一步遍历。应当指出，对于就像aggregate distinct的一些CQL查询，查询计划可以具有多于一个分支。在当前的例子中，Relational Source 408可以是无状态的，因此遍历可以向上移动并且看到Group By 406。由于Group By 406可以是有状态的，因此它可以被标记为查询运算符。照此，遍历可以完成，并且不需要向上到Project运算符404，因为Group By 406将查询归档器、填充其状态，并且还向Project 404传播快照输出，并且如果有的话进一步传播到下游运算符。

图5说明了用于利用一个或多个表ID，诸如但不限于TRANSACTION_CID和/或TRANSACTION_TID(如上所述)，计数与归档的关系关联的变化事件的至少一个非限制性例子500。如图5中所示，示出了初始的事务上下文表502和插入之后的事务上下文表504。在一些例子中，被配置为管理事务ID的服务器可以被初始化或以别的方式启动。当持久性服务被这种服务器启动时，它可以创建一组事务实例。照此，事务上下文表502说明在单个持久性服务被启动之后的内容，其中该服务为了其自己使用而创建了10个上下文实例。TRANSACTION_CID列包含上下文ID并且TRANSACTION_TID列包含由那个上下文ID提交的最高事务ID。

在一个非限制性例子中，如果第二持久性服务在这个时候被启动，它也为了其自己使用而创建了10个上下文实例，则表502可以说明具有TRANSACTION_CID值11-20的10个新条目。现在持久性服务在运行名为“Alpha”的DataObject，包含可以创建的每个DataObject列数据类型中一个。在一些例子中，无论何时当DataObject被创建时，持久性服务都可以创建代表用于那个DataObject的持久性存储的对应数据库视图。在一个例子中，一旦DataObject生成，插入命令就可以对其执行。为了最好地说明上下文和事务ID的处理，可以对总共24个插入利用12个线程执行每线程两个插入操作。每个线程可以启动JTA事务、执行一个插入操作、执行第二插入操作，然后提交该事务。使用多个线程的原因是它可以创建多个并行执行的JTA事务，这将更好地说明上下文ID如何开始起作用。这也证明其中多个(在这个例子中是每线程两个)DataObject操作方法调用可以在同一JTA事务中进行并且其中JTA事务在持久性之外被启动并提交的场景。

对于这个例子，12个线程可以同时运行代码。每个线程可以在服务器外面开始事务，对持久性(Persistence)进行两个插入调用，然后提交该事务。由于持久性已经分配了10个上下文ID，因此这些线程当中的10个可以获得上下文，而两个最初会被阻塞。两个JTA事务可以被一直阻塞到另一个JTA事务完成并释放上下文。然后，被阻塞的JTA事务可以抓住释放的上下文并处理持久性API调用。在一些例子中，在插入操作完成之后，(在插入之后)表504的检查显示刚好这个结果。事务上下文1和2示出事务ID 2为“最后提交的”事务ID，而所有其它事务上下文示出事务ID 1为它们最后提交的事务ID。

在一些例子中，作为在这个例子中执行的插入操作的结果，DataObject变化通知可以经JMS广播。记住，在每个JTA事务中执行两个插入并且对总共24个插入操作执行12个事务。事务上下文1和2每个都用于两个事务，因此我们将看到来自上下文1和2的4个 变化通知，事务ID 1用于两个插入并且事务ID 2用于另两个插入。所有其它上下文都只用于一个事务并且应当生成都具有事务ID 1的两个插入。

图6-8说明了示出利用本文所述归档的关系实现连续查询的管理的相应过程600、700和800的示例流程图。这些过程600、700和800被说明为逻辑流程图，其每个操作都代表可以在硬件、计算机指令或者其组合中实现的操作序列。在计算机指令的语境下，操作代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，当指令被一个或多个处理器执行时，执行所述操作。一般而言，计算机可执行指令包括执行特定功能或实现特定数据类型的例程、程序、对象、组件、数据结构等。操作被描述的次序并不是要被解释为限制，并且任何数量的所描述操作都可以以任何次序和/或并行地被组合，以实现过程。

此外，一些、任何或全部过程可以在利用可执行指令配置的一个或多个计算机系统的控制下执行并且可以实现为在一个或多个处理器上共同执行的代码(例如，可执行指令、一个或多个计算机程序，或者一个或多个应用)、硬件或者其组合。如以上所指出的，代码可以存储在计算机可读存储介质上，例如，以包括可由一个或多个处理器执行的多条指令的计算机程序的形式。计算机可读存储介质可以是非临时性的。

在一些例子中，至少图1(以及其它图)中所示的一个或多个服务提供商计算机106(例如，利用至少归档的关系模块148)可以执行图6的过程600。过程600可以在602通过包括识别和/或接收查询开始，其中查询识别归档的流或归档的关系作为数据源。在一些例子中，在604，过程600可以包括利用历史数据初始化查询。在606，过程600可以包括至少部分地基于归档的流或归档的关系和历史数据评估查询。在608，过程600还可以包括构成代表查询的运算符的查询图。在610，过程600可以包括从图的顶部向下遍历查询图。另外，在一些例子中，过程600可以在612通过包括在查询图中识别出 的第一个有状态运算符利用历史数据初始化查询而结束。

图7说明了示出利用本文所述归档的关系实现连续查询的管理的过程700的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少归档的关系模块148)可以执行图7的过程700。过程700可以在702通过包括接收连续查询以处理数据流或归档的关系而开始，其中归档的关系包括用于数据流或历史数据的ID。在704，过程700可以包括至少部分地基于所接收的连续查询生成查询图。此外，在一些例子中，过程700可以包括利用历史数据的一部分初始化连续查询。另外，在708，过程700可以通过包括关于数据流或归档的关系并至少部分地基于历史数据来评估连续查询而结束。

图8说明了示出利用本文所述归档的关系实现连续查询的管理的过程800的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少归档的关系模块148)可以执行图8的过程800。过程800可以在802通过包括接收连续查询以处理与业务事件数据关联的流或归档的关系而开始。在804，过程800可以包括至少部分地基于该连续查询生成查询图。在806，过程800可以包括从源按拓扑遍历查询图，以识别最低的有状态运算符(例如，最低的有状态运算符可以是在遍历时识别出的最后一个有状态运算符和/或它可以是分支的运算符)。在一些例子中，在808，过程800可以包括至少部分地基于查询的运算符确定用于初始化的最佳历史数据量。在810，过程800可以包括在识别出的最低的有状态运算符利用历史数据初始化该连续查询。另外，在一些例子中，在812，过程800可以通过包括至少部分地基于历史数据关于数据流或归档的关系评估连续查询而结束。

图9-11说明了示出利用本文所述可配置的数据窗口实现归档的关系的相应过程900、1000和1100的示例流程图。这些过程900、1000和1100被说明为逻辑流程图，其每个操作都代表可以在硬件、计算机指令或者其组合中实现的操作序列。在计算机指令的语境下， 操作代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，当指令被一个或多个处理器执行时，执行所述操作。一般而言，计算机可执行指令包括执行特定功能或实现特定数据类型的例程、程序、对象、组件、数据结构等。操作被描述的次序并不是要被解释为限制，并且任何数量的所描述操作都可以以任何次序和/或并行地被组合，以实现过程。

此外，一些、任何或全部过程可以在利用可执行指令配置的一个或多个计算机系统的控制下执行并且可以实现为在一个或多个处理器上共同执行的代码(例如，可执行指令、一个或多个计算机程序，或者一个或多个应用)、硬件或者其组合。如以上所指出的，代码可以存储在计算机可读存储介质上，例如，以包括可由一个或多个处理器执行的多条指令的计算机程序的形式。计算机可读存储介质可以是非临时性的。

在一些例子中，至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少可配置窗口模块150)可以执行图9的过程900。过程900可以在902通过包括识别或以别的方式接收识别数据流或归档的关系的查询而开始。在904，过程900可以包括识别用户配置的窗口尺寸。在906，过程900可以包括至少部分地基于窗口尺寸利用历史数据初始化查询。另外，在908，过程900可以通过包括至少部分地基于历史数据以及归档的流或归档的关系来评估查询而结束。

图10说明了示出利用本文所述可配置的数据窗口实现归档的关系的过程1000的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少可配置窗口模块150)可以执行图10的过程1000。过程1000可以在1002通过包括接收被配置为处理数据流或归档的关系的连续查询而开始。在1004，过程1000可以包括至少部分地基于该连续查询而生成查询图。在1006，过程1000可以包括从被配置为处理数据流或归档的关系的连续查询计算窗口尺寸。在一些例子中，在1008，过程1000可以包括至少部分地基于窗 口尺寸确定用于初始化的历史数据量。在1010，过程1000可以包括利用所确定的历史数据初始化连续查询。另外，在1012，过程1000可以包括关于归档的流或归档的关系以及窗口尺寸评估连续查询。

图11说明了示出利用本文所述可配置的数据窗口实现归档的关系的过程1100的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少可配置窗口模块150)可以执行图11的过程1100。过程1100可以在1102通过包括接收被配置为处理归档的流或归档的关系的连续查询而开始。在1104，过程1100可以包括从连续查询计算窗口尺寸，以识别要处理的流或归档的关系的有限范围。在1106，过程1100可以包括至少部分地基于该连续查询生成查询图。此外，在一些方面，过程1100可以包括向下(例如，自顶向下的方法)遍历查询图，以便识别有状态的运算符。在1110，过程1100可以包括确定用于初始化的最佳历史数据量。在1112，过程1100可以包括在所识别出的有状态的运算符利用历史数据初始化连续查询。另外，在一些例子中，过程1100可以包括关于流或归档的关系并且至少部分地基于窗口尺寸评估连续查询。

图12-14说明了示出用于实现与本文所述归档的关系关联的事件计数特征的相应过程1200、1300和1400的示例流程图。这些过程1200、1300和1400被说明为逻辑流程图，其每个操作都代表可以在硬件、计算机指令或者其组合中实现的操作序列。在计算机指令的语境下，操作代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，当指令被一个或多个处理器执行时，执行所述操作。一般而言，计算机可执行指令包括执行特定功能或实现特定数据类型的例程、程序、对象、组件、数据结构等。操作被描述的次序并不是要被解释为限制，并且任何数量的所描述操作都可以以任何次序和/或并行地被组合，以实现过程。

此外，一些、任何或全部过程可以在利用可执行指令配置的一个或多个计算机系统的控制下执行并且可以实现为在一个或多个处理器上共同执行的代码(例如，可执行指令、一个或多个计算机程序，或 者一个或多个应用)、硬件或者其组合。如以上所指出的，代码可以存储在计算机可读存储介质上，例如，以包括可由一个或多个处理器执行的多条指令的计算机程序的形式。计算机可读存储介质可以是非临时性的。

在一些例子中，至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少事件计数模块152)可以执行图12的过程1200。过程1200可以在1202通过包括识别查询而开始，该查询识别数据对象。在1204，过程1200可以包括对照与该数据对象关联的历史数据评估查询。在1206，过程1200可以包括利用该数据对象注册监听服务。过程1200还可以包括在1208接收用于由监听服务识别出的变化的事务ID。在一些例子中，在1210，过程1200可以包括比较该事务ID与历史数据的最高事务ID。在1212，过程1200可以包括只有当所接收的事务ID大于所述最高事务ID时才处理变化。在1214，过程1200可以通过包括至少部分地基于所述数据对象和历史数据评估查询而结束。

图13说明了示出利用本文所述可配置的数据窗口实现归档的关系的过程1300的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少事件计数模块152)可以执行图13的过程1300。过程1300可以在1302通过包括接收识别或以别的方式接收数据对象的连续查询而开始。在1304，过程1300可以包括注册与该数据对象关联的监听服务。此外，在一些例子中，过程1300可以包括在1306在注册监听服务之后对照历史数据评估该连续查询。在1308，过程1300可以包括在对照历史数据评估之后处理由监听服务识别的变化。在1310，过程1300可以通过包括对照数据对象评估连续查询而结束。

图14说明了示出利用本文所述可配置的数据窗口实现归档的关系的过程1400的示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少事件计数模块152)可以执行图14的过程1400。过程1400可以在1402通过包括接收被配置为处理数 据对象的连续查询而开始。在1404，过程1400可以包括利用该数据对象注册监听服务。在1406，过程1400可以包括对照与该数据对象关联的历史数据评估连续查询。在一些例子中，过程1400还可以包括在1408接收用于由监听服务识别的变化的事务ID。此外，在1410，过程1400可以包括比较所接收的事务ID和与当前和历史数据关联的最高事务ID。在1412，过程1400可以包括当所接收的ID大于与历史数据关联的最高事务ID时处理变化。在1414，过程1400可以通过包括关于所述数据对象评估连续查询而结束。

以上描述了用于实现连续和有计划查询的混合执行的说明性方法和系统。这些系统和方法当中的一些或全部可以，但不必，至少部分地通过诸如至少在以上图1-14中所示的体系架构和过程来实现。

图15是说明可以根据本公开内容实施例使用的系统环境1500的部件的简化框图。如图所示，系统环境1500包括一个或多个客户端计算设备1502、1504、1506、1508，它们被配置为经一个或多个网络1510(诸如，但不限于，类似于图1和3的网络108的网络)操作客户端应用，诸如web浏览器、专有客户端(例如，Oracle Forms)等。在各种实施例中，客户端计算设备1502、1504、1506和1508可以经网络1510与服务器1512交互。

客户端计算设备1502、1504、1506、1508可以是通用个人计算机(作为例子，包括运行各种版本的Microsoft Windows和/或Apple Macintosh操作系统的个人计算机和/或膝上型计算机)、手机或PDA(运行诸如Microsoft Windows Mobile的软件，并且是启用互联网、电子邮件、SMS、Blackberry或其它通信协议的)，和/或运行任何各种市售UNIX或类UNIX操作系统(包括但不限于各种GNU/Linux操作系统)的工作站计算机。作为替代，客户端计算设备1502、1504、1506和1508可以是能够经网络(例如，下面描述的网络1510)进行通信的任何其它电子设备，诸如瘦客户端计算机、启用互联网的游戏系统，以及个人消息传输设备。虽然示例性系统环境1500被示为具有四个客户端计算设备，但是任何数量的客户端计算 设备都可以被支持。其它设备，诸如带传感器的设备等，可以与服务器1512交互。

系统环境1500可以包括网络1510。网络1510可以是本领域技术人员熟悉的任何类型的网络，这些网络可以利用任何各种市售的协议，包括但不限于TCP/IP、SNA、IPX、AppleTalk等，支持数据通信。仅仅作为例子，网络1510可以是局域网(LAN)，诸如以太网网络、令牌环网等；广域网；虚拟网络，包括但不限于虚拟专用网(VPN)；互联网；内联网；外联网；公共交换电话网(PSTN)；红外线网络；无线网络(例如，按照任何IEEE802.11协议套件、本领域中已知的蓝牙协议和/或任何其它无线协议操作的网络)；和/或这些和/或其它网络的任何组合。

系统环境1500还包括一个或多个服务器计算机1512，这可以是通用计算机、专用服务器计算机(作为例子，包括PC服务器、UNIX服务器、中档服务器、大型计算机、机架式服务器等)，服务器群、服务器群集，或者任何其它适当的布置和/或组合。在各种实施例中，服务器1512可以适合于运行在前述公开内容中描述的一个或多个服务或软件应用。例如，服务器1512可以对应于用于执行根据本公开内容实施例的上述处理的服务器。

服务器1512可以运行操作系统，包括以上讨论的任何操作系统，以及任何市售的服务器操作系统。服务器1512还可以运行任何各种附加的服务器应用和/或中间层应用，包括HTTP服务器、FTP服务器、CGI服务器、Java服务器、数据库服务器等。示例性数据库服务器包括但不限于可从Oracle，Microsoft、Sybase、IBM等商购的那些。

系统环境1500还可以包括一个或多个数据库1514、1516。数据库1514、1516可以驻留在各种不同的位置。作为例子，一个或多个数据库1514、1516可以驻留在服务器1512本地的非临时性存储介质上(和/或驻留在服务器1512中)。作为替代，数据库1514、1516可以远离服务器1512，并且经基于网络的或专用的连接与服务器1512 通信。在一组实施例中，数据库1514、1516可以驻留在本领域技术人员熟悉的存储区域网络(SAN)中。类似地，用于执行服务器1512所具有的功能的任何必要的文件都可以适当地本地存储在服务器1512上和/或远程存储。在一组实施例中，数据库1514、1516可以包括适于响应于SQL格式的命令而存储、更新和检索数据的关系数据库，例如由Oracle提供的数据库。

图16是可以根据本公开内容的实施例使用的计算机系统1600的简化框图。例如，服务提供商计算机106可以利用诸如系统1600的系统实现。计算机系统1600被示为包括可以经总线1601电和/或通信耦合的硬件元件。硬件元件可以包括一个或多个中央处理单元(CPU)1602、一个或多个输入设备1604(例如，鼠标、键盘等)，以及一个或多个输出设备1606(例如，显示设备、打印机等)。计算机系统1600还可以包括一个或多个存储设备1608。作为例子，存储设备1608可以包括可编程、闪存可更新等的设备，诸如盘驱动器、光存储设备以及诸如随机存取存储器(RAM)和/或只读存储器(ROM)的固态存储设备。

计算机系统1600还可以包括计算机可读存储介质读取器1612、通信子系统1614(例如，调制解调器、网卡(无线的或有线的)、红外通信设备等)和工作存储器1618，其中存储器1618可包括如上所述的RAM和ROM设备。在一些实施例中，计算机系统1600还可以包括处理加速单元1616，这可以包括数字信号处理器(DSP)、专用处理器等。

计算机可读存储介质读取器1612还可被连接到计算机可读存储介质1610，一起(并且，可选地，结合存储设备1608)全面地表示远程、本地、固定和/或可移除存储设备加上用于临时和/或更永久地包含计算机可读信息的存储介质。通信系统1614可以允许数据与网络1612和/或以上关于系统环境1600所描述的任何其它计算机进行交换。

计算机系统1600还可以包括软件元件，当前示为位于工作存储 器1618中，包括操作系统1620和/或其它代码1622，诸如应用程序(这可以是客户端应用、Web浏览器、中间层应用、RDBMS等等)。在示例性实施例中，工作存储器1618可以包括用于如上所述依赖方和开放式授权相关的处理的可执行代码和关联的数据结构。应当认识到，计算机系统1600的备选实施例可以具有不同于以上所述的众多变化。例如，定制的硬件也可被使用和/或特定的元件可以在硬件、软件(包括便携式软件，诸如小程序)或两者当中实现。另外，可以采用到诸如网络输入/输出设备的其它计算设备的连接。

图17说明了示出利用本文所述归档的关系实现连续查询的管理的过程1700的另一示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少归档的关系模块148)可以执行图17的过程1700。过程1700可以在1702通过包括至少部分地基于归档的关系识别查询而开始。在1704，过程1700可以包括利用该查询的运算符生成查询运算符图。此外，在一些例子中，过程1700可以包括在1706把运算符图排序(例如，按拓扑)。在1708，过程1700可以包括分析该图，以确定可以查询归档器以便初始化状态的运算符(例如，有状态的运算符)。在1710，过程1700可以包括构造要给予归档器的适当查询(例如，归档器查询)。在一些例子中，过程1700还可以包括在1712决定运算符共享。在1714，过程1700可以包括通过向CQ服务发布归档器查询来初始化所确定的运算符的状态(例如，如上所述)。在1716，过程1700可以(例如，从CQ服务或持久性)接收历史结果。另外，在1718，过程1700可以通过包括，如果还未被计数，则作为查询历史结果的部分处理进入的事件而结束。

图18说明了示出利用本文所述归档的关系实现连续查询的管理的过程1800的另一示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少可配置窗口模块150)可以执行图18的过程1800。过程1800可以在1802通过包括关于归档器源评估归档器查询并获得一个或多个快照输出而开始。在1804，过程 1800可以包括利用两个可配置参数当中的至少一个关于关系指定窗口。可配置参数包括窗口尺寸和/或关系属性。此外，在一些例子中，过程1800可以包括在1806，对每个快照元组，通过比较指定的属性的值与当前事件时间来测试该元组是否位于窗口内。在1808，过程1800可以包括确定快照元组是否通过测试。在一些例子中，如果通过测试，则在1810，过程1800可以包括把该元组插入窗口。但是，在一些例子中，如果未通过测试，则过程1800可以代替地包括在1812忽略该元组。然后，过程1800可以返回1802，以便结束或者包括评估下一个归档器查询。

图19说明了示出利用本文所述归档的关系实现连续查询的管理的过程1900的另一示例流程图。至少图1中所示的一个或多个服务提供商计算机106(例如，利用至少事件计数模块152)可以执行图19的过程1900。过程1900可以在1902通过包括从数据对象查询状态运算符而开始。在1904，过程1900可以包括从事务上下文表导出快照信息。在1906，过程1900可以包括在CQL引擎中维护该快照信息并且递增关联的快照ID。在1908，过程1900可以包括在查询计划的“连接器”运算符中设置快照ID。“连接器”运算符可以接合本地计划与全局计划。在1910，过程1900可以包括利用事件中的上下文ID(CID)和事务ID(TID)为到达的事件计算快照ID。在1912，过程1900可以包括比较事件的快照ID与输入队列的快照ID。在1914，过程1900可以包括确定事件中的ID是否大于输入队列的ID。在一些例子中，如果在1914事件ID大于队列ID，则过程1900可以包括处理该事件。但是，在一些例子中，如果在1914事件ID不大于队列ID，则过程1900可以代替地包括在1918忽略该事件。然后，过程1900可以返回1902，以便结束或者再次开始。

作为替代，或者附加地，在查询时快照信息还可以从事务上下文表得出。这种快照信息可以在CQL引擎中维护并且snapshotID(递增的标识符)可以与其关联。这同样可以在那个查询计划中一些选定的运算符的输入队列中设置。这些被称为“连接器”运算符并且它们 可以代表本地查询计划可与全局(整体)查询计划接合的地方。当事件到达CQL引擎时，可以利用其中的上下文ID和事务ID值为那个事件计算snapshotID。snapshotID可以利用在CQL引擎中维护的快照信息来计算。然后，事件的snapshotID可以与输入队列的snapshotID进行比较。如果事件中的ID>队列中的ID，则它可以被处理，否则它已经被考虑过了并且因此被忽略，以避免重复计数。用于包含代码或代码部分的存储介质和计算机可读介质可以包括本领域中已知或被使用的任何适当的介质，包括存储介质和通信介质，诸如但不限于，以任何方法或技术实现的用于诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息存储和/或传输的易失性和非易失性(非临时性)、可移除和不可移除介质，包括RAM、ROM、EEPROM、闪存存储器或其它存储器技术、CD-ROM、数字多样化盘(DVD)或其它光储存器、磁带盒、磁带、磁盘储存器或其它磁存储设备、数据信号、数据传输，或者可以被用来存储或发送期望信息并且可以被计算机访问的任何其它介质。

虽然已经描述了本公开内容的具体实施例，但是各种修改、变更、备选构造和等价物也包含在本公开内容的范围内。这各种修改、变更、备选构造和等价物包括所公开特征的相关组合。本公开内容的实施例不限于在某些具体数据处理环境中的操作，而是可以自由地在多种数据处理环境中操作。此外，虽然本公开内容的实施例已经利用事务或步骤的特定序列进行了描述，但是对本领域技术人员来说很显然，本公开内容的范围不限于所描述的事务或步骤的序列。

另外，虽然本公开内容的实施例已经利用硬件和软件的特定组合进行了描述，但是应当认识到，硬件和软件的其它组合也在本公开内容的范围之内。本公开内容的实施例可以只在硬件中或者只在软件中或者利用其组合来实现。

因而，本说明书和附图要在说明性而不是限制性的意义上理解。但是，很显然，在不背离更广泛精神和范围的情况下，可以对其进行添加、减少、删除以及其它修改和变化。以上描述了用于提供本公开 内容特征的说明性方法和系统。这些系统和方法当中的一些或全部可以，但不必，至少部分地由诸如以上图1-12中所示的体系架构实现。

虽然实施例已经以特定于结构特征和/或方法动作的语言进行了描述，但是应当理解，本公开内容不必局限于所描述的具体特征或动作。更确切地说，所述具体特征和动作是作为实现实施例的说明性形式公开的。除其它的之外，除非具体地另外声明或者在所使用的上下文中以别的方式被理解，否则有条件的语言，诸如“可以”、“可能”，一般要传达某些实施例可以包括，而其它实施例不包括，某些特征、元件和/或步骤。因此，这种有条件的语言一般不是要暗示特征、元件和/或步骤以任何方式被一种或多种实施例需要或者一种或多种实施例必需包括用于，在有或没有用户输入或提示的情况下，决定这些特征、元件和/或步骤要在任何特定实施例中包括或执行的逻辑。

Claims (26)

1.一种系统，包括：

用于识别查询的装置，其中查询识别至少数据流；

用于利用历史数据的至少一部分初始化该查询的装置；及

用于至少部分地基于所述数据流和历史数据的所述部分评估该查询的装置。

2.如权利要求1所述的系统，其中查询包括被配置为处理数据流的进入的实时数据或者数据流的归档的关系的连续查询。

3.如权利要求2所述的系统，其中实时数据包括至少业务事件数据。

4.如权利要求1或3中任何一项所述的系统，其中数据流包括配置有窗口的关系，用于在窗口中引用该数据流的一部分。

5.如权利要求4所述的系统，其中窗口被配置为随着时间沿数据流移动。

6.如权利要求1至5中任何一项所述的系统，其中，在初始化查询之后的时间，历史数据不包括在数据流中。

7.如权利要求1至6中任何一项所述的系统，其中查询还识别历史数据。

8.如权利要求1至7中任何一项所述的系统，其中历史数据包括在初始化查询之前的时间来自数据流的业务事件数据。

9.如权利要求1至8中任何一项所述的系统，其中评估查询包括至少形成具有节点的查询图，其中节点代表查询的运算符。

10.如权利要求9所述的系统，其中至少一个节点识别窗口尺寸。

11.如权利要求9或10所述的系统，还包括用于执行多条指令以便至少按拓扑次序遍历查询图的装置。

12.如权利要求11所述的系统，还包括用于在查询图中识别出的最低有状态运算符利用至少历史数据初始化查询的装置。

13.如权利要求11所述的系统，还包括用于识别可配置窗口尺寸的装置。

14.如权利要求13所述的系统，其中查询是至少部分地基于可配置窗口尺寸来初始化的。

15.如权利要求1所述的系统，其中查询的评估包括至少部分地基于可配置窗口尺寸至少对照数据流应用查询。

16.如权利要求1至15中任何一项所述的系统，其中数据流包括配置有第二可配置窗口尺寸的关系，用于在第二窗口中引用数据流的一部分，其中第二窗口的尺寸至少部分地基于第二可配置窗口尺寸。

17.如权利要求1所述的系统，其中第二窗口被配置为随着时间沿数据流移动。

18.一种存储可由一个或多个处理器执行的多条指令的计算机可读程序，这多条指令包括：

使一个或多个处理器接收被配置为处理数据流的连续查询的指令，其中连续查询包括数据流的标识符或历史数据的标识符当中至少一个；

使一个或多个处理器至少部分地基于该连续查询生成查询图的指令；

使一个或多个处理器利用历史数据的至少一部分初始化该连续查询的指令；及

使一个或多个处理器关于数据流并至少部分地基于历史数据评估该连续查询的指令。

19.如权利要求18所述的计算机可读程序，其中数据流或历史数据当中至少一个是由连续查询的数据定义语言注释识别的。

20.如权利要求19所述的计算机可读程序，其中数据定义语言注释识别历史数据的位置、数据流的源、与数据流关联的数据对象、与处理连续查询关联的操作信息、对应于历史数据的数据库的一个或多个相关列、对应于连续查询的输出的数据对象或者用于提供连续查询的输出的位置当中至少一个。

21.如权利要求18所述的计算机可读程序，其中查询图包括至少代表连续查询的运算符的节点。

22.如权利要求18所述的计算机可读程序，其中连续查询是在按拓扑次序遍历查询图的时候在查询图的有状态运算符利用历史数据的至少一部分初始化的。

23.一种方法，包括：

接收被配置为处理业务事件数据的流的连续查询，连续查询包括所述流的标识符和与该流关联的历史数据的标识符；

至少部分地基于该连续查询生成查询图，查询图包括至少代表该连续查询的运算符的节点；

遍历该查询图，以识别最低的有状态运算符；

在所识别出的最低的有状态运算符利用历史数据的至少一部分初始化该连续查询；及

关于所述流并至少部分地基于历史数据评估该连续查询。

24.如权利要求23所述的方法，其中历史数据包括从流的之前时间点开始的业务事件数据。

25.如权利要求23所述的方法，还包括至少部分地基于连续查询的运算符确定利用其初始化该连续查询的最佳历史数据量。

26.如权利要求23所述的方法，其中有状态的运算符是至少部分地基于评估连续查询的至少一个节点来识别的。