XML流数据的复杂小枝模式查询匹配方法

摘要

本发明属于XML流数据处理技术领域，具体为一种XML流数据的复杂小枝模式查询匹配方法。问题的提出如下：给定一个包含复杂小枝模式的查询集合Q，以及一个XML文档D，找出Q`Q，满足对每一个q∈Q`，都匹配文档D。本发明通过定义的紧凑小枝模式查询树，将复杂的AND/OR谓词作为单独的抽象语法树来处理，同时，将所有小枝模式查询组合成单个可共享公共前缀的查询树，利用提出的基于运行栈的算法，结合自顶向下和自顶向上过程，单遍、高效处理基于XML流的任何复杂小枝查询。本发明与已有系统和方法相比，避免产生大量中间结果，查询处理性能有明显提高，特别是对大XML文档，处理效率成倍提高。

说明书

技术领域

本发明属于可扩充标记语言(XML)流数据处理技术领域，具体涉及XML的复杂小枝模式(twig pattern)查询匹配方法。

背景技术

随着互连网的发展，出现了大量的数据密集的新型应用，包括传感器网络、位置搜寻、网络监控、金融分析、在线拍卖、股票行情系统、交通控制系统等诸多领域，例如，上海证券股票行情系统的某个客户可能要求在中石化股票的大于6元或小于5元的时候通知他；出租车司机可能要求交通控制系统在某个路口的交通流量大于某个值时通知他，交管部门可能要求在发生交通事故的时候通知他们；等等。类似这样的应用的共同特点是实时地、持续地处理连续到达的、无限的数据流，它与传统数据库管理系统不同。传统数据库管理系统的主要特点是：数据持久存储，在某一时刻执行查询并通过稳定查询计划给出精确的回答；而流数据处理系统强调：数据在线到达、查询持久存储。在流数据处理系统中，不可能控制数据到达的顺序，将所有到达的数据存储在本地进行管理和查询也是不现实的。流数据处理技术是一种新型技术，具有极其广阔的应用前景。

由于可扩充标记语言(XML)已经成为Web上数据交换的标准，用于各种应用和信息源之间的数据交换，处理XML流数据的理论和技术更值得关注。这样的应用所带来的挑战是：

1. XML流数据处理系统通常运行在Web上，其上的用户会迅速增加到十万，百万级的数量。

2.用户查询通常用XPath^[1]等语言表示。由于一个用户可以提交若干查询，查询的数量更是十分巨大。

3. XML文档是递归的、层次的，用户可以提交复杂的查询。

因此，XML流数据处理研究的一个关键问题是如何同时有效处理大量来自用户的查询并及时将结果返回给用户。目前，已有一些方法能够处理XML流数据，但是，对与复杂的XML小枝模式查询(通常同时包含逻辑OR和逻辑AND谓词)，目前尚没有有效的方法，例如，对于一个数字图书馆系统，用户可能要求得到下面的实时信息：选择paper的author，其发表过title为XML Stream的文章或者在2006年的VLDB上发表过文章，查询可表示如下：

Q＝/dblp/paper[title＝‘XML Stream’or(year＝2006 and conf＝‘VLDB’)]//author

我们提出一种新的方法(XML流数据的复杂小枝查询匹配方法)，具有下面独特的特性：

1.能够处理具有AND/OR谓词的复杂小枝查询。

2.在我们的方法中，将AND/OR谓词作为单独的抽象语法树来处理，这样，利用提出的基于运行栈的算法，结合自顶向下和自顶向上过程，能够单遍处理基于XML流的任何复杂小枝查询，避免中间结果的产生。

3.将所有小枝查询组合成单个可共享公共前缀的查询树，从而可以同时处理大量查询。

4.与已有系统和算法相比，查询处理性能有明显提高，特别是对于大XML文档(1M以上)，处理性能成倍提高。

XML小枝模式查询本质上是具有针对XML文档结构和内容的选择谓词的查询。将一组小枝模式与随时到达的XML文档进行匹配是XML流数据处理的核心操作。

由于流数据处理系统所具有的广泛应用前景，以及XML作为Web上数据交换的标准，XML流数据处理引起了广泛的研究兴趣。很多研究采用基于自动机的方法处理XML流数据^{[2，3，4，5，6，7，8]}。XFilter^[2]首次利用基于有限状态自动机(FSM)的方法过虑XML文档。XFilter对每一个路径查询使用一个单独的FSM，并在文档处理的过程中，同时运行所有的FSM。YFilter^[3]在XFilter的基础上进行了改进：将所有的XPaht查询合并成一个单独的非确定有限自动机(NFA)，并共享所有查询的公共前缀。YFilter将小枝查询视作嵌套路径表达式，并使用查询分解进行处理。在他们的方法中，当一个查询包含嵌套路径时，就被分为主路径和一组扩展路径，每一个扩展路径都用一个相对独立的NFA进行处理。对它的处理分为两步：路径匹配和路径匹配结果的后置处理(执行连接操作)。针对嵌套路径，YFilter主要考虑的是具有AND谓词的查询，还不能处理OR谓词的查询，并且，这种后置处理的方式可能会产生大量中间结果，从而影响系统性能。XPush^[4]将所有的XPath表达式构造为单个定制的确定下推自动机(XPush机)，Green^[4]等人将NFA转换为确定有限自动机(DFA)，并使用懒惰DFA控制状态爆炸带来的运行时负载，以提高处理性能。Dan等^[10]使用状态机处理XPath表达式，将一个XPath表达式转换为多个下推自动机构成的网络，这种方法难以处理大量XPath查询。

其它处理XML流的方法主要有基于索引的方法^[9]，基于Bloom Filter的方法^[10]以及FiST方法^[11]。Index-Filter^[9]采用基于索引的技术处理XML流数据。Index-Filter利用XML文档流的文档标记动态地建立XML文档的索引，从而避免处理一部分XML文档。与YFilter的相比，他们通过实验表明，当查询数量相对较小XML文档相对较大时，Index-Filter更有效(在不考虑建立索引所花费的代价的前提下)；当查询数量相对较大XML文档相对较小时，Y-Filter更有效。在Index-Filter的方法中，建立索引要花费一定的时间代价。另外，不能单遍处理XML文档，因此，缓存文档要花费的一定空间代价。基于Bloom Filter的XML包过滤器^[10]是一种近似查询方法，利用Bloom Filter，将Xpah表达式作为字符串，将XPath与XML包之间的匹配转换为字符串之间的匹配，从而提高查询性能。它只是用来处理简单的XPath表达式(不包括谓词，只包括“/”“//”“*”，称为XP^{/，//，*})，并且有一定失误率。FiST^[11]针对小枝模式提出一种有别于YFilter的方法，将一组小枝模式转换为prufer序列，并对一组小枝模式与XML流数据进行整体性(holostic)匹配。FiST考虑的是具有AND谓词的小枝模式，而没有考虑如何处理OR谓词。目前为止，所有这些工作还不能够有效进行复杂的小枝模式的XML流数据处理。

发明内容

本发明的目的在于提出一种能实现实时复杂查询和大量查询，且查询效率高的XML流数据的复杂小枝模式查询匹配方法。

本发明提出的XML流数据的复杂小枝模式查询匹配方法可以记为CTPQ。所要处理的基本问题定义如下：

给定一个包含复杂小枝模式的查询集合Q，以及一个XML文档D，找出Q`Q，满足对每一个q∈Q`，都匹配文档D。

方法的具体过程如下：

(1)将用户提交的一个复杂小枝模式查询用一种易于XML流处理的树(紧凑小枝模式查询树)表示为内部形式。

(2)将所有的用户查询合并为单个查询树，并共享这些查询的公共部分。

(3)结合自顶向下和自底向上的过程，单遍处理复杂小枝模式查询与XML流数据的查询匹配，避免中间结果的产生。

各部分的具体内容分别介绍如下：

1.复杂小枝模式查询的内部表示

直观地，可将小枝模式表示为一颗查询树(本发明称为通常的查询树)，在树中插入相应的AND节点和OR节点，以表示相应的谓词，例如，对于XPath表达式Q＝/dblp/paper[title＝‘XML Stream’or(year＝2006 and conf/title＝‘VLDB’)]//author，其查询树如图1所示。但针对XML流数据处理问题，这种表示带来两点不便：树中含有大量AND节点和OR节点；当合并多个小枝模式时，AND节点和OR节点难以处理，例如查询/a[b andc]和查询/a/[b or c]的合并。为此，本发明将AND谓词和OR谓词剥离出来，单独表示为相关节点的抽象语法树，本发明称之为紧凑小枝模式查询树。同样例子，图1的紧凑查询树的如图2所示。

定义1：一个紧凑小枝模式查询树是一颗表示小枝模式的查询树，查询树中的节点称为查询节点(QNode)，每一个QNode具有惟一标识(如对于上面例子的查询Q，定位步/dblp标识为n1)，分为以下两种类型：

(1)OQNode：不带有谓词的定位步，称为通常查询节点(Ordinary Query Node，OQNode)。在紧凑查询树中，OQNode关联相关信息，包括节点名字(“*”的名字为“*”)和表示父子(“/”)或子孙(“//”)关系的算子，用两元组<name，“/”or“//”>表示。

(2)PQNode：带有谓词的定位步称为谓词查询节点(Predicate Query Node，OQNode)。谓词查询节点是紧凑查询树中的特殊节点，它通过AND/OR逻辑谓词将其子树连接起来。除了节点标识，节点名和“/”或者“//”外，还关联一个逻辑表达式.该逻辑表达式在内部表示为抽象语法树。该抽象语法树的每一个叶子节点都维护一个到其对应的节点(谓词节点的孩子节点)的引用。

2.小枝模式与XML文档流的匹配

定义1给出了与通常的具有AND/OR谓词的查询树的等价定义。在对XML文档流处理的过程中，本发明对带有谓词的节点及其子节点，采用自底向上的匹配过程，而对于其它部分采用自顶向下的匹配过程。为了适应这样的匹配过程，本发明对定义1进行扩充。

定义2：谓词子树(Predicate Sub-Tree)。在一个紧凑小枝模式查询树的表示中，以距离根节点最近的谓词节点为根所形成的子树称为谓词子树。同时扩充相应的节点结构：谓词子树中的OQNode(叶子节点除外)，也关联一个逻辑表达式，该逻辑表达式是只含有一个项，即其孩子节点的标识。而如果OQNode是叶子节点，则含有一个逻辑标记，初始为真(TRUE)，当遇到CLOSE事件后，将逻辑标记的值赋为假(FALSE)。

定义3：接受节点(Accepting Node)。在一个紧凑小枝模式查询树的表示中，距离根节点最近的谓词节点称为该树所表示查询的接受节点。如果计算过程中，接受节点相关逻辑表达式的值为真，则该文档与查询匹配。对于不带谓词的XPath表达式(XP{/，//，*})，通常查询树与紧凑查询树相同。如果一个XPath表达式是不带谓词的一般查询(XP{/，//，*})，其接受节点则是其通常查询树的叶子节点。如果在匹配过程中到达接受节点，则该文档与查询匹配。

图3给出用于说明匹配过程的三个查询的例子，查询的接受节点用加粗的黑框表示。查询Q1是一个不带谓词的查询，n3是其接受节点。查询Q2是一个含有AND/OR谓词的小枝模式(为了简单起见，节点的相关逻辑表达式用文本表示)，n2是它的接受节点，其相关逻辑表达式是[n3 and(n4 or n5)]；n2为根的子树是它的谓词子树。由于n5是谓词子树中的OQNode，它关联有包含其孩子节点的一个逻辑表达式。Q3的表示与Q2类似。

XML流数据处理系统应该能够同时处理大量用户查询，而来自用户的大量查询中，可能会具有许多共同的部分，共享其共同部分可以节省系统的存储空间和执行时间，对改善系统性能非常重要。为此，本发明将所有的小枝模式合并为一个单一结构，称为共享前缀的紧凑小枝模式查询树。合并方法具体如下：

对于任意两个小枝模式查询Q_a和Q_b，其共享前缀的紧凑小枝模式查询树为Q_ab。

为Q_ab创建一个根r₀，以Q_a为基础构造Q_ab。

前序遍历Q_a和Q_b，若Q_b中存在与Q_a节点名以及算子(“/”或“//”)相同的前缀则可以合并，否则，将Q_b中的节点加入到Q_a中。

重复步骤(3)，直到完成对Q_b的遍历。

图4是图3中3个查询合并后的共享前缀的紧凑查询树。在图4中，节点n4是Q1的接受节点，节点n4是Q2和Q3的接受节点。这里需要注意的是，节点n4关联有两个查询表达式，每一个查询表达式与其查询标识(查询标识由XPath解析器生成)相关联。

2.1数据结构

每一个查询节点都有一个惟一标识，并包含下面基本信息：

(4)name。表示节点名字的字符串。

(5)axis。整数值0表示“/”，1表示“//”。

(6)documentLevel。表示XML文档的层次的整数。

每一个接受节点关联一组查询标识。如果一个节点是谓词节点或谓词节点的子节点，则对每一个查询(该节点可能被多个查询所共享)，关联的信息是<QID，status，lExpression>。其中，

(1)QID是查询标识。

(2)lExpression：该节点相相关的逻辑表达式。逻辑表达式的每一项被其对应的孩子节点引用。如果是谓词子树的叶子节点，则它的逻辑表达式为空。

(3)status：该状态标记是一布尔值，表示节点的匹配状态(逻辑表达式的计算结果)。其初始值为假(FALSE)。

2.2节点匹配和查询匹配

当文档到达系统时，通过XML解析器产生相应事件，流处理引擎通过回调函数对事件做出反应，将事件翻译为(Name，Type，DocumentLevel)的形式驱动匹配过程。其中，name(名字)是节点测试名；type(类型)是事件类型，包括StartDocument，EndDocument，OPEN和CLOSE；documentLevel通过XML文档元素的OPEN和CLOSE标记来计算，文档的根的DocumentLevel是0。

对于一个查询，当遇到的节点是OQNode，且不属于谓词子树的子节点时，如果事件名、节点名、文档层次匹配时，则一个节点匹配成功。当一个节点包含父子关系算子时，文档层次要求相同；当一个节点包含子孙关系算子时，若节点名相同，则节点匹配成功，这时忽略文档层次的检查。当查询节点名字是“*”时，节点名字的测试永远返回真(TRUE)。这是自顶向下的过程，遇到OPEN事件时进行计算。

当遇到的节点是PQNode或谓词子树中的子节点时，且基本信息<Name，IsChild，DocumentLevel>的检查通过时，这时需要计算它所关联的逻辑表达式并检查状态标记。如果状态标记为真，则节点匹配成功。这是自底向上的过程。状态标记的初始值为假(FALSE)，当遇到CLOSE事件时，对相应逻辑表达式进行计算，并将结果值赋给状态标记。

如果节点匹配发生，则该节点通过，继续下一个节点。如果匹配的节点是接受节点(在此注意，一个节点可能对一个查询是接受节点，对另一个查询不是接受节点；或者对一个查询是OQNode节点，而对另一个查询是PQNode)，则该XML文档匹配查询。

2.3算法

算法基于运行栈，分为OPEN和CLOSE两部分。

OPEN：OPEN事件通过回调函数调用该句柄，传入事件名字，元素名字和元素的文档层次。 

(1)对每一个到达的XML元素，进行节点测试和文档层次检查。

(2)如果节点检查返回真(TRUE)，则该节点被压入一个运行时栈。若遇到的节点是PQNode或谓词子树的子节点，其状态标记的值设为假(FALSE)。若遇到的节点是一个查询的接受节点，且不是PQNode节点，则一个查询匹配发生。如果该接受节点是PQNode，则需要等到遇到CLOSE事件时才能判定文档与查询是否匹配。

CLOSE：如果遇到的节点是OQNode，简单地将节点从栈中弹出。如果遇到的节点是PQNode或谓词子树的子节点，将执行下列步骤：

(1)如果是叶子节点，将其状态标记赋为真(TRUE)，意味着该节点匹配成功。从运行栈弹出该节点，并将当前栈顶节点(当前栈顶节点是其父节点)中相关的逻辑表达式中对应的项赋值为真(TRUE)。

(2)如果是谓词子树中的中间节点，计算其逻辑表达式(此时，它的孩子节点都已经处理过)。如果逻辑表达式的值为TRUE，意味着该节点匹配，将其状态标记赋值为TRUE；否则，将其状态标记赋值为FALSE。从栈中弹出该节点，并将当前栈顶节点的相关逻辑表达式中的对应项赋值为其状态标记的值：真(TRUE)或假(FALSE)。

(3)如果是一个查询的接受节点，计算其逻辑表达式，并将逻辑表达式的结果赋给状态标记。如果是真(TRUE)，则文档与该查询匹配；如果是假(FALSE)，则文档与该查询不匹配。

(4)继续上述过程，直到所有PQNode得到处理节点。

3优化

3.1逻辑表达式的短路计算

对于一个逻辑表达式，例如，E1＝e1 and e2，E2＝e3 or e4，如果e1为假(FALSE)，则不用计算整个表达式，就可得知E1为FALSE；如果e3为TRUE，则可得知E2为真，即对逻辑表达式适时地进行短路求值计算。这样节省逻辑表达式的计算时间，同样可以略过部分文档的解析，从而也可节省文档解析时间。

例如，图4中的查询Q3的接受节点n3中，与其相关联的逻辑表达式是n6 or n8，在遇到元素c的CLOSE事件时(图5)，对于节点n3，其相关于Q3的表达式为TRUE or n8。这时可对计算出逻辑表达式的结果(短路求值)，提前得知文档与查询Q3匹配。因此，后面只与Q3有关的文档解析与查询匹配操作都可忽略。

3.2逻辑表达式的共享计算

针对大量的查询，在共享前缀的谓词查询树中，一个谓词查询节点可能会关联很多的逻辑表达式。在这种情况下，可能会存在许多相同的逻辑表达式子项，如果对这些相同的逻辑表达式子项进行共享：即共享的逻辑表达式子只存储且只计算一次，不仅可以降低逻辑表达式的空间复杂度，而且可以加速逻辑表达式的计算。为此，本发明将逻辑表达式表示成一棵抽象语法树，对公共逻辑表达式子项进行共享处理：合并多棵语法树中相同的节点或分支。

例如，有Q1：n1/n2[(n3 and n4)or n5]、Q2：n1/n2[n3]/n4、Q3：n1/n2[n3 and n4]这样三个查询，由它们建立的共享前缀紧凑查询树的简化表示(只用元素名表示相应节点)如下图左面部分所示，其中n2为接受节点，关联有这三个查询各自的逻辑表达式。不难发现，对q2和q3查询来说，逻辑表达式都是n3 and n4，而这也是q1的逻辑表达式(n3 and n4)orn5的子项。因此，只需为n2节点建立一棵共享逻辑分支的抽象语法树，如图5右面部分所示。

本发明提出一种新的方法(XML流数据的复杂小枝查询匹配方法)，具有下面独特的特性：

5.能够处理具有AND/OR谓词的复杂小枝查询。

6.在本发明的方法中，将AND/OR谓词作为单独的抽象语法树来处理，这样，利用提出的基于运行栈的算法，结合自顶向下和自顶向上过程，能够单遍处理基于XML流的任何复杂小枝查询，避免中间结果的产生。

7.将所有小枝查询组合成单个可共享公共前缀的查询树，从而可以同时处理大量查询。

8.与已有系统和算法相比，查询处理性能有明显提高，特别是对于大XML文档(1M以上)，处理性能成倍提高。

XML流数据的复杂小枝模式查询匹配算法(CTPQ)可以在广泛的领域得到应用，例如在线拍卖、股票行情系统、交通控制系统、个性化推荐服务、传感器网络、位置搜寻、网络监控、金融分析等。

附图说明

图1为小枝模式分析树。

图2为小枝模式紧凑分析树。

图3为例子。

图4为共享前缀的紧凑查询树。

图5为公共逻辑表达式的共享。

图6为示例。

图7为针对小XML文档的实验。其中(a)为YFilter，(b)为本发明。

图8为针对大XML文档的实验。其中(a)为YFilter，(b)为本发明。

具体实施方式

本发明用Java实现了该算法系统。系统运行的环境是Eclipse3.1，机器的主频是2.7G，内存为512M。构成实验的组件包括：文档生成器，DTD解析器，XPath生成器，基于事件的XML解析器。本发明使用IBM的文档生成工具^[12]生成文档；DTD解析器来自WUTKA^[13]，XPath解析器使用JXPath^[14]，使用的DTD来自于Xmark^[15]，使用的基于事件的文档解析器是^[16]。

XML流数据的复杂小枝模式查询匹配算法(CTPQ)的实施包括两部分，第一部分是处理XML的OPEN标记的部分，第二部分是处理CLOSE标记的部分。算法使用伪码描述如下：

基于运行时栈的匹配算法(OPEN部分)

输入：元素开始标记事件Event；

输出：当某个查询间匹配发生，则输出匹配。

1.NodeSet<QNode>NewActiveNodeSet＝new NodeSet<QNode>()；

2.Foreach active query node N In current active node set of RmStack

3.   If(N is $-Node)

4.       If(N has a child C with its name equals Event.Name)

5.           NewActiveNodeSet.add(C)；

6.           NewActiveNodeSet.add(N)；

7.           CheckOpenAccepting(C，Event)；

8.       Endif

9.   Else

10.      If(N has $-Node C as a child)

11.          NewActiveNodeSet.add(C)；

12.          If(C has a child C`with its name equals Event.Name)

13.              NewActiveNoeSet.add(C`)；

14.              CheckOpenAccepting(C`，Event)；

15.          Endif

16.          If(N’s name equals Event.Name)

17.              NewActiveNodeSet.add(N)；

18.          Endif

19.      Endif

20.      If(N has*-Node C as a child)

21.          NewActiveNodeSet.add(C)；

22.          CheckOpenAccepting(C，Event)；

23.      Endif

24.      If(N has a child C with its name equals Event.Name)

25.          NewActiveNodeSet.add(C)；

26.          CheckOpenAccepting(C，Event)；

27.          If(C has $-node C`as a child)

28.              NewActiveNodeSet.add(C`)；

29.          Endif

30.       Endif

31.   Endif

32.Endfor

33.If(NewActiveNodeSet is NOT EMPTY)

34.   RmStack.push(NewActiveNodeSet)；

35.Endif。

算法3.2基于运行时栈的匹配算法(CLOSE部分)

输入：元素结束标记事件Event；

输出：当某个查询间匹配发生，则输出匹配。

1.Foreach active query node N In current active node set of RmStack

2.   If(N is NOT $-Node)

3.       N.setExisted(TRUE)；

4.       Foreach query information item QII associated with N

5.          If(N is a predicate node of the query QII.Qid)

6.              QII.LE.evaluate()；

7.              If(QII.IsAcceptingNode＝TRUE AND QII.Status＝

TRUE)

8.              A matching between the doc and query QII.Qid has been

found ！

9.              Endif

10.         Endif

11.      Endfor

12.   Endif

13.Endfor

14.If(There existed Event.Name node OR $-Node OR*-Node in the top of

RmStack)

15.RmStack.pop()；

16.Endif、

示例

本发明的方法将自顶向下和自底向上的过程结合起来，下面使用例子说明查询匹配的执行过程。

图6使用图4的三个查询以及一个XML片断作为例子，展示了查询匹配的过程。运行栈中的节点对应于图4共享前缀紧凑查询树的节点标识。黑体斜体字表示接受节点，下划线节点表示接受节点是PQNode。当遇到b元素的OPEN事件，节点n2和n3被压入栈中。这时，n3的状态标记的值是FALSE。当遇到c元素的OPEN事件时，n4，n5和n6被压入栈中。由于节点n4是OQNode，且是查询Q1的接受节点，这时可以判定文档与查询Q1匹配。节点n5和n6的状态标记的值为FALSE。当遇到c元素的CLOSE事件时，将节点n5和n6的状态标记值赋为TRUE，弹出节点n4，n5和n6(这时，当前栈顶节点是n2和n3)，并将n5和n6的状态标记值赋给n3中对应的逻辑表达式中的项，即<Q2，FALSE，(TRUE and(n7 or n8))>和<Q3，FALSE，(TRUE or n8))。类似地，当遇到b元素的CLOSE时，计算b元素相关的逻辑表达式，并将计算结果赋给对应查询的状态标记，即：<Q2，TRUE，(TRUE and(TRUE or TRUE))和<Q3，TRUE，(TRUE or TRUE))>，由于b元素是Q2和Q3的接受节点，可以判定Q2和Q3与文档匹配。

效果

用下面几个指标进行与YFilter进行实验比较和分析：(1)小枝模式的总数量，(2)小枝模式的分支数目(也从一定程度上反映小枝模式的谓词子树的深度)，(3)输入文档的大小。实验分为两类：针对小XML文档(10k，30k，50k)的实验和针对大XML文档(500K，1M，2M)的实验。由于YFilter不支持OR逻辑谓词，因此选择具有嵌套的AND逻辑谓词的小枝模式进行实验。具体进行了一系列的实验：针对不同的分支节点的数目；针对不同的数据集(例如Xmark，DBLP^[17]，这里的实验结果使用的是Xmark，使用DBLP的效果相类似)；针对不同的文档大小等。结果表明，在处理小枝模式的时候，性能比YFilter有所提高，尤其是在处理大文档的情况下。

首先给出针对小文档的部分实验结果。以查询的分支节点(PQNode)数是3为例，借用YFilter的XPath生成器，生成小枝模式的参数是：6 0.2 0.2--num_nestedpaths＝3--distinct＝TRUE，其中，6表示查询深度，两个0.2表示“//”和“*”出现的概率，3表示分支节点数，TRUE表示每个小枝模式都不相同。实验结果如图7所示，其中，纵轴表示时间(ms*10)，横轴表示查询个数，分别为5000，10000，50000，100000，文档的大小为10k，20k，50k。

YFilter的查询处理时间分为基本处理时间和后置处理时间，其中，后置处理时间是处理小枝模式谓词部分的耗时。在处理小文档和少量查询时，YFilter的后置处理时间占非常小的比例，例如，对于分支为3，查询数量为5000，文档大小为10k时，处理时间265ms，而后置处理时间为51妙，约占20％，随着查询数量和文档的增大，后置处理时间所占比例会增大，例如，同样条件下，查询数为100000时，文档为50k时，后置处理时间超过55％。正如实验结果表明的，随着查询数量的增大和XML文档的增大，性能提高越来越明显。

下面给出针对大文档的实验部分结果。本发明使用与上面相同的参数生成小枝模式。实验的结果如图8所示，其中，纵轴表示时间(ms*100)，横轴表示查询个数，分别为5000，10000，50000，100000，所使用的文档大小分别为500K，1MB，2MB。在处理大文档的情况下，无论是对大量查询还是少量查询，本发明的系统具有非常明显的优势，在文档为1MB，性能提高2倍以上。例如，在文档为1MB，查询数目为5000时，本发明的处理时间是4406ms，而YFilter的处理时间是(3594+8422)＝12016ms，括号中的前一个数字3594是基本处理时间，后一个数字8422是后置处理时间。可以看出，YFilter仅仅后置处理的时间就是本发明系统的近两倍。当文档大小不变(1MB)，查询数量增加到100000时，而本发明的处理时间是86062，YFilter的处理时间是(14733+168844)＝183577ms，其后置处理时间已经超出两倍。当文档为2M时，分别对5000和10000个查询，系统与YFilter的性能对比是8969/(7047+33906)17218/(9703+71188)，可以看出，仅后置处理时间就已经超出4倍左右。因此，YFilter的方法不适合于大文档和复杂查询的应用，而适合于处理简单查询的消息过滤。由于本发明针对复杂小枝模式查询，采用单遍处理XML流的方法，避免了中间结果的产生和后置处理的过程，因此，也利于处理大文档的复杂查询。除了Xmark，本发明还在其他常用数据集的基础上进行了实验，例如DBLP，得到类似的实验结果。

参考文献

^[1]Anders Berglund，Scott Boag，Dong Chamberlin，Mary F.Fernandez，Michael Kay，Jonathan Robie，and Jrme Simon.XML Path Language(XPath)2.0 W3C working draft 16.Technical Report WD-xpath20-20020816：USA，World Wide Web Consortium，2002.http://www.w3.org/TR/2002/WD-xpath20-20020816/.

^[2]Altinel，M.，and Franklin，M.J.Efficient Filtering of XML Documents for SelectiveDissemination of Information.Abbadi，A.E.，Brodie，M.L.，Chakravarthy，S.，Dayal，U.，Kamel，N.Schlageter，G.，Whang，K.Y.，eds.Proceedings of the 26^th InternationalConference on Very Large Data Bases(VLDB00).Cairo，Egypt：Morgan Kaufmann，2000.53-64.

^[3]Yanlei Diao，Mehmet Altinel，Michael J.Franklin，Hao Zhang and Peter Fischer.PathSharing and Predicate Evaluation for High-performance XML Filtering.ACM Transactionson Database System(TODS03).2003，28(4)：467-516.

^[4]Gupta，A.and Suciu，D.Stream Processing of XPath Queries with Predicates.Halevy，A.Y.，Ives，Z.G.，Doan，A.，eds.Proceedings of 2003 ACM SIGMOD International Conference onManagement of data(SIGMOD03).San Diego，California：ACM Press，2003.419-430.

^[5]Green，T.J.，Miklau，G.，Onizuka，M.，and Suciu，D.Processing XML Streams withDeterministic Automata and Stream Indexes.ACM Transactions on Database Systems(TODS04).2004，29(4)：752-788.

^[6]Dan Olteanu，Tobias Kiesling，Francois Bry.An Evaluation of Regular Path Expressionswith Qualifiers against XML Streams.Dayal，U.，Ramaritham，K.，Vijayaraman，T.M.，eds.Proceedings of 19^th International Conference on Data Engineering(ICDE’03).Bangalore，India：IEEE Computer Society，2003.702-704

^[7]Bertram Ludscher，Pratik Mukhopadhyay and Yannis Papakonstantinou.ATransducer-Based XML Query Processor.Bressan，S.，Chaudhri，A.B.，Lee，M.L.，Yu，J.X.，Lacroix，Z.，eds.Proceedings of the 28^th International Conference on Very Large Data Bases(VLDB02).Hong Kong，China：ACM Press，2002.227-238.

^[8]GAO Jun，YANG Dong-Qing，TANG Shi-Wei，WANG Teng-Jiao.Tree-Automata BasedEfficient XPath Evaluation over XML Data Stream.Journal of Software.2005.16(2)：223-232.

^[9]Bruno，N.，Gravano，L.，Koudas，N.，and Srivastava，D.Navigation-vs.Index-Based XMLMulti-Query Processing.Dayal，U.，Ramaritham，K.，Vijayaraman，T.M.，eds.Proceedingsof the 19^th International Conference on Data Engineering(ICDE’03).Bangalore，India：IEEE Computer Society，2003.139-150

^[10]Xueqing Gong，Weining Qian，Ying Yan，and Aoying Zhou，Bloom Filter-based XMLPackets Filtering for Millions of Path Queries.Proceedings of the 21^st InternationalConference on Data Engineering(ICDE’05).Tokyo，Japan；IEEE Computer Society，2005.890-901.

^[11]Joonho Kwon，Praveen Rao，Bongki Moon，Sukho Lee.FiST：Scalable XML DocumentFiltering by Sequencing Twig Patterns.Bhm，K.，Jensen，C.S.，Haas.L.M.，Kersten，M.L.，Larson，P.，Ooi，B.C.，eds.Proceedings of 31^st International Conference on Very Large DataBases(VLDB05).Trondheim，Norway：VLDB Endowment，2005.217-228.

^[12]Angel Luis Diaz and Douglas Lovell.XML Generator.http://www.alphaworks.ibm.com/tech/xmlgenerator，September 1999

^[13]Wutka.2000.DTD parser.http://www.wutka.com/dtdparser.html.

^[14]JXPath-http://jakarta.apache.org/commons/jxpath/

^[15]Busse，R.，Carey，M.，Florescu，D.，Kersten，M.，Manolescu，I.，Schmidt，A.，and Waas，F.2001.Xmark：An XML benchmark project.http://monetdb.cwi.nl/xml/index.html.

^[16]David Megginson.Simple API for XML.http://sax.sourceforge.netLEY，M.2001.DBLP DTD.http://www.acm.org/sigmod/dblp/db/about/dblp.dtd.