1. 介绍<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

XML成为数据交换实际上的（defacto）标准。然而它产生的灵活性和可移植性是以大量的冗余数据为代价的，这是用一系列重复使用的标记来表示数据的结果（a consequence of）。这阻碍了XML在数据交换和数据存档中的应用。近几年，许多XML压缩工具提出解决这一数据冗余问题。包括两种类型的压缩：不可检索压缩和可检索压缩。

不可检索压缩使用语义上相关的XML数据的类似之处来消除数据冗余，因此可以保证一个好的压缩率，如XMill。然而，在这种方法中，已压缩的数据不是直接可用的，整块的数据必须先解压缩才能进行检索。

可检索压缩单独编码每一个XML数据项，因此已压缩数据项能够直接存取，而不需对整个文件全部解压缩。然而，单独压缩的数据单元的小粒度（fine-granularity）并没有利用XML数据的通用性（commonalities），因此，相对于（with respect to）不可检索压缩工具中使用的整块压缩策略，它的压缩率常更退化。
<site>

<open_auctions>

<open_auction id="open1">

<initial>$12.00</initial>

<bid>

<date>12/02/2000</date>

<increase>$2.00</increase>

</bid>

<bid>

<date><?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />12/03/2003</date>

<increase>$1.50</increase>

</bid>

<seller person="person71"/>

</open_auction>

<open_auction id="open2">

<initial>$500.00</initial>

<seller person="person8"/>

</open_auction>

<open_auction id="open3">

<initial>$1.50</initial>
<bid>

<date>11/29/2002</date>

<increase>$0.50</increase>

</bid>

<seller person="person15"/>

</open_auction>

<open_auction id="open4">

<initial>$100.00</initial>

<seller person="person11"/>

</open_auction>

<open_auction id="open5">

<initial>$8.50</initial>

<bid>

<date>08/20/2002</date>

<increase>$5.00</increase>

</bid>

<seller person="person7"/>

</open_auction>

</open_auctions>

</site>

表1 拍卖（Auction）实例的XML摘录

ROOT        -> 0

site           -> 217

open_auctions  -> 111

open_auction   -> 17

@id    -> 3

Initial   -> 33

Bid     -> 7

Date    -> 17

Increase  -> 9

Seller    -> 81

@person  -> 70

 

元素ID分配（Element ID Assignment）
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /> 
图2  拍卖（Auction）实例XML摘录的结构树
（Structure Tree of the Auction XML Extract）
图3  拍卖（Auction）实例XML摘录结构树的
（SIT of the Auction Structure Tree）
可检索压缩工具同态分析处理（homomorphic transformation）来保留XML数据的结构，因此可以在此结构上进行检索，如XGrind[14]和XPRESS[10]。然而，所保留的结构总是太大（与XML文档的大小呈线性关系）。搜索这么大的结构空间效率将会非常低，即使是简单的路径检索。如图1是从XML样例的已压缩文件中摘录的，要在里面搜索原始成本低于$10的“bidding（出价）”项。XGrind解析整个XML压缩文档，并且对要解析的每个元素/属性，XGrind要把它的路径与输入的检索路径进行匹配。XPRESS有所改进，它通过将路径编码为明确的间隔值[0.0，1.0]，把逐元素的匹配简化为逐路径的匹配，从而一个路径可以用间隔之间的包容关系进行匹配。但逐路径匹配也是低效的，因为XML文档中的大部分路径是重复的，尤其是那些数据为中心（data-centric）的XML文档。

贡献    我们提出的XQzip有以下特征：（1）达到一个好的压缩率和一个好的压缩/解压缩时间；（2）支持在XML压缩数据上的有效的检索处理；（3）支持有表达力的检索语言。XQzip为可检索和不可检索的压缩中遇到的问题提供可行的解释。

首先，XQzip用一个索引结构去除XML文档中的重复结构来改善检索性能，这个索引结构称为结构索引树（Structure Index Tree，SIT）。一个SIT的例子如图3所示，它是图2中的树的索引，是从XML样例中的摘录的图1的结构。图2中的重复结构在SIT中去除。事实上，大多数XML文档的大部分结构是冗余的，可以去除。例如，如果一个XML文档含有1000个我们的XML样例摘录的复制（其中的数据内容不同），相应的树结构将比图2中的树结构大1000倍。而它的SIT实质上与图3中的SIT有相同的结构。这预示着检索的搜索空间通过索引下降到了千分之一。

其次，XQzip将数据压缩成能分别解压缩的块的序列，同时允许利用XML数据的通用性达到好的压缩，从而避免了整体解压缩。XQzip也通过为XML数据已解压的块设置一个缓冲区有效地减少检索中的解压缩开销（overhead）。

第三，XQzip利用索引来检索压缩的XML数据。XQzip支持大部分XPath[15]，多重的、深层嵌套的、有混合的基于数值和基于结构的检索条件的谓词的检索。它扩展了XPath查询，用单一的查询选取任意一套独特的元素。我们也给出了一个简单的映射模式，使详细的XPath查询更具可读性。此外，我们设计了一个简单的算法评估XPath平均情况下在多项式时间内的查询。

最后，我们评价XQzip在各种各样的基准XML数据源上的性能，并与XMill，gzip，XGrind比较压缩和查询性能。结果显示ZQzip的压缩率可以与XMill相比拟，大约比XGrind好16.7%。XQzip的压缩和解压缩速度可与XMill和gzip相比拟，但比XGrind快数倍。在检索评估中，我们记录了竞争性的数据。平均而言，若最初缓冲池为空，XQzip完成查询比XGind快12.48倍，若最初为暖缓冲池，比XGrind快80倍。此外，XQzip支持对许多XGrind不支持的复杂查询的高效处理。尽管由于无效的代码，我们不能直接与XPRESS直接比较，我们相信XQzip的压缩和查询性能都比XPRESS好，因为根据XPRESS的试验评估结果[10]，XPRESS仅能达到和XGrind相比拟的压缩率，查询时间优于XGrind 2.83倍。

相关的工作    我们也知道另一个XML压缩工具XqueC[2]，XQueC也支持查询，它单独压缩每个数据项，这常常导致压缩率的降低（与XMill相比）。XqueC的一个重要特点是它使用各种结构信息，如DataGuide[5]，结构树（tructure tree）及其它索引，以支持XQuery[16]。然而，这些结构信息连同指向单独压缩的数据项的指针，会产生极大的空间开销。以一个可查询压缩也在最近提出了[3]，它压缩XML文档的结构树，从而允许把它放入内存中以支持Core XPath[6]查询。这种对压缩结构的使用类似于XQzip中SIT的使用，也就是[3]在SIT为树节点作索引的同时浓缩树的范围（condenses the tree edges）。[3]没有压缩XML文本数据项，因此不能用来作直接的比较。

    本文的组织如下。我们在第二节描绘XQzip的体系结构，第三节介绍SIT和它的构造算法。第四节描述一个可查询的、已压缩数据的存储模型。第五节讨论查询覆盖（query coverage）和查询实现（query evaluation）。我们在第六节评估XQzip的性能，第七节给出我们的总结，讨论我们将来的工作。