一個支援串流查詢之XML文件壓縮技巧

一個支援串流查詢之 XML 文件壓縮技巧

An XML Document Compression Technique Supporting Stream

Query

賈坤芳 周健平 丁正文 國立中興大學資訊科學與工程系 {kfjea, phd9402, s9456039}@cs.nchu.edu.tw

摘要

串流 XML 文件的特性在於 XML 文件 樹狀的半結構化特性與串流本身特殊的傳 輸型態。使用串流的方式傳送 XML 文件 時，會使客戶端在接收的過程中，無法預 測後續的文件內容，亦無法重覆讀取串流 文件，故許多傳統加速查詢的技術－例如 索引，皆不適用於串流 XML 文件之查詢。 本研究提出一個壓縮 XML 文件的技 巧，以加速串流 XML 文件之查詢。藉由 處理 XML 文件結構中重複的路徑，可縮 短文件長度、簡化文件結構，使資料傳輸 的時間縮短；並且由於文件結構的簡化， 使查詢的複雜度降低，處理速度因而加 快。此外，我們設計的查詢演算法僅需針 對查詢的相關部分作解壓縮，避免完全解 壓縮文件所造成的負擔。 關鍵詞：XML、串流 XML 查詢、壓縮、 編碼

一、簡介

近年來，網際網路與無線通訊的使用 量大增，行動電話、個人數位助理（PDA） 等手持行動設備已經成為許多人生活上用 來接收訊息的必備工具。在此情境之下， 產生兩個重要的問題：第一是網路上各種 系統平台有著不同資料格式，造成資料交 換的困難；第二是行動客戶的數量龐大， 往往超出伺服器所能負荷。為了解決這兩 個問題，XML 資料串流管理系統（Data Stream Management System）如[6][7]應運 而生，理由是 XML[4]已經成為網路上資 料交換的標準格式，而採用串流系統可以 分散伺服器的負擔，讓行動客戶端在有限 的記憶體與運算能力的情況下，擷取所需 要的資訊。所謂 XML 資料串流是指在 XML 文件上循序瀏覽所取得的一連串資 料，如果就 XML 文件本身的結構關係來 看，可視為一連串的開始與結束標籤，如： <Sigmod><issue><articles>…</articles></i ssue><issue>…</issue></Sigmod>。 設計 XML 串流查詢系統有兩項主要 考量的因素。第一項因素是資料傳輸的時 間。因為串流傳輸的限制，使用者必須等 待整份 XML 文件傳送結束，才能結束查 詢，造成頻寬與客戶行動設備電力的浪 費。第二項考量因素是客戶端的查詢效 能。查詢的速度若太慢，會來不及處理串 流資料，進而影響查詢的正確性。為了加 速客戶端查詢的速度，傳統的方法是由伺 服器對文件進行編碼[9][10]，輔助客戶端 的查詢，但是編碼會增加文件額外的內

容，等於增加資料傳輸的時間，不利於第 一項因素。 根據上述兩項設計串流查詢系統所需 考量的因素，本研究針對 XML 文件格式 以及串流傳輸的特性，設計了資料壓縮與 查詢壓縮文的演算法。我們選擇在伺服器 端壓縮 XML 文件，然後廣播給每個客戶， 由客戶進行壓縮文的查詢處理。我們所提 出 的 查 詢 演 算 法 支 援 文 件 部 份 解 壓 縮 （partial decompression），讓使用者僅需要 將與其查詢相關的 XML 節點做部份解壓 縮，即可大幅減輕查詢的負擔；並又為了 增進查詢的效率，我們設計了適合 XML 串流查詢的編碼方式。經由壓縮的技巧及 支援部分解壓縮的查詢演算法，可縮短 XML 串流傳輸時間，提高的查詢速度。本 研究所提出的方法特色與技巧如下： 1. 除了 XML 文件本文（text）之外， 特別針對 XML 文件的結構（structure）進 行壓縮。我們先找出串流 XML 文件中重 複的標籤路徑，然後用一個單一節點來取 代，達到資料壓縮的目的。 2. 設計適合 XML 串流查詢的編碼 方式（labeling scheme），可加速查詢，且 不會對串流文件的傳輸造成過多的負擔。 3. 提出兩階段查詢方法，能夠將不 需要處理的 XML 節點略過，降低客戶端 查詢的時間成本。

二、相關研究

本節回顧目前著名的 XML 資料串流 查詢系統 Expedite[6][7]，以及可查詢式 XML 壓縮器 XGRIND[12]。 2.1 XML 串流查詢系統 EXPedite[6][7] 系統為一架構在無線 網路環境下的主從式 XML 查詢系統，支 援路徑查詢（path query）及分支查詢（twig query）。EXPedite 伺服器將 XML 文件內 的元素與內容節點（text content）分別進 行編碼，元素的編碼格式為(Flag, T, Size, Depth)，其中 Flag＝0 代表此編碼格式屬 於元素或屬性節點，以與內容節點作區 別。T 是可對應到唯一元素名稱的數字， Size 表示此節點的子樹大小，Depth 表示 節點所在的樹的階層數（根節點的階層數 為 0 ）； 內 容 節 點 的 編 碼 格 式 為 (Flag, Length, Text)，其中 Flag＝1，Length 是指 內容字串的大小，Text 為內容字串。 w x z y Employee (0, 1, 22, 0) (1, 3, Amy) Name (0, 3, 5, 2) @Religion (0, 4, 13, 2) “Catholicism” Personal_Info (0, 2, 20, 1) “Amy” (1, 11, Catholicism) 圖一 EXPedite 編碼範例 圖一為 EXPedite 對一份 XML 文件的 編碼範例，其中實線圓形代表元素節點， 虛線圓形代表屬性節點，方塊代表文字內 容節點。以節點 x 為例，其編碼為(0, 2, 20, 1)，第一個欄位 0 表示 Flag；第二個欄位 2 表示利用字典編碼法（dictionary coding method）將節點 x 的標籤 Personal_Info 編 碼成唯一的識別碼 2；第三個欄位 20 表示 Size；第四個欄位 1 表示 Depth。以節點 y 內容編碼(1, 3, Amy)為例，第一個欄位表 示 Flag，第二個欄位 3 表示內容節點的大 小，第三個欄位值 Amy 為內容字串。 伺服器將編碼過後的 XML 文件廣播 給使用者，XML 文件串流中的元素編碼

(Flag, T, Size, Depth)代表文件的結構，被 客戶端接收到之後，逐一被轉換成區間編 碼（range-based labeling scheme）[9][10] 格式：(Flag, T, Start, End, Level)，以利查 詢。其中 Start＝客戶端目前所接收到的總 位 元 組 數 ； End ＝ Start ＋ Size ； Level ＝ Depth。EXPedite 查詢方法是利用對應於 查詢式標籤所分別建立的堆疊（稱為“查詢 堆疊”），處理與輸出查詢結果，演算法類 似於 Holistic twig joins[5]。

2.2 XML 文件壓縮 XGRIND[12] 屬 於 一 種 半 適 應 （semi-adaptive）壓縮方法，須先讀取文 件一遍，以得到統計資料後，再一次讀取 文件來產生壓縮文。XGRIND 將 XML 文 件分成三種不同類型的節點：標籤、列舉 型屬性、非列舉型屬性或內容，以進行壓 縮。XGRIND 壓縮粒度（granularity）為 XML 節點，保留了節點之間的結構關係， 並能利用一般路徑查詢的語法對查詢所需 要的部分進行解壓縮。 第一種是標籤的壓縮，將每一個 XML 開始標籤（start tag）以“T”加上一個唯一 的元素識別碼來表示，例如：T0、T1 分別 代表兩種不同的開始標籤。結束標籤（end tag ） 則 以 “/” 來 取 代 。 第 二 種 是 列 舉 型 （enumerated-type）屬性壓縮，例如：公 司裡的部門、國家的省分，屬於固定的屬 性集合，則採用字典編碼法將固定出現的 屬性集合分別編成唯一的數字，來達到壓 縮的效果。第三種是非列舉型屬性或內 容，採用霍夫曼編碼（Huffman encoding） [8]的方式來壓縮。 圖二為對圖一的範例進行壓縮的結 果。每個標籤節點都用唯一的代號取代， 例 如 T0 代 表 Employee ， T1 代 表 Personal_Info；屬性名稱之做法類似，如 A0 代表@Religion。內容節點採用霍夫曼 編碼，以 huff(Amy)表示之；列舉屬性採用 字 典 編 碼 法 ， 如 “Catholicism” 以 enum(Catholicism)函式表示。 圖二 XGRIND 壓縮範例 T0 T1 A0 enum(Catholicism) T2 huff(Amy) / / / XML 文 件 壓 縮 技 術 依 照 壓 縮 的 粒 度，可區分為兩類[11]。第一類是壓縮整 份 XML 文件，不能經由部分解壓縮或其 他方式來進行查詢，必須整份文件解壓縮 之後才能夠進行查詢，例如傳統的 RAR 或 ZIP 的壓縮方式。另一類是壓縮 XML 文件中的節點，如圖二，經過 XGRIND 壓 縮之後，我們仍可輕易地辨識壓縮文中的 節點結構關係，使客戶可以直接在壓縮文 上進行查詢，或僅需部份文件的解壓縮。 一般而言，第一類技術的壓縮率比較高， 但是在串流系統中，由於在客戶端無法保 留全部的 XML 文件，故亦無法接收整份 壓縮文件後再做解壓縮，所以並不適用。 本論文著重於第二類可查詢壓縮文的壓縮 方法之研究，以支援串流查詢系統。

三、問題與方法

3.1 環境及問題定義 我們的系統環境是在主從式架構之 下，伺服器端利用單一頻道，以串流的形 式將 XML 文件廣播出去；而客戶端所持 的是手機或其他行動裝置，其運算能力有 限。我們的系統支援 XPath[3]查詢語言的 核心，包括子代軸線（child axis）與後代 軸線（descendant axis）查詢。

在串流系統中無法像一般環境，可以 利用索引等技巧來輔助查詢。倘若客戶端 的查詢演算法效率不佳，就無法及時處理 接收到的大量連續之串流資料，造成客戶 端須使用大量的緩衝區，勢必消耗行動裝 置有限的記憶體以及電力。所以如何縮短 整體資料傳輸的時間，以及提高客戶端串 流資料查詢演算法之效能，就是我們要探 討的研究問題。 3.2 XSC 壓縮技巧 我們提出一個 XSC 壓縮方法以支援 XML 文件串流查詢，可分成三個部份來說 明。首先在 XML 文件中，將多次重複出 現的結構路徑找出，稱為頻繁樣式路徑 （FPP），然後利用 FPP 去取代重複的路 徑，達到壓縮文件的目的；其次，利用編 碼與其他壓縮技巧，進一步增加壓縮率及 提升查詢的效率；最後是針對 XSC 壓縮文 件所設計的查詢演算法。 3.3 尋找頻繁樣式路徑 資料串流的環境下，大量 XML 文件 從資料伺服器依序不斷被傳送給客戶端。 對客戶端而言，所接收到的 XML 文件資 料，可視為一連串的標籤（tag）序列。圖 三為一份範例 XML 文件，其中 A、B、C、 D、E、F 為標籤名稱。當資料在單一頻道 上 循 序 傳 送 出 去 時 ， 按 深 度 優 先 搜 尋 （ depth-first search ） 的 順 序 傳 送 ， 如 <A><B><C><D>Asia</D></C><E>NCS20 07</E></B><B><C><D>Dec.20</D><F>T aichung</F></C></B></A>。我們可從資料 串流觀察到：(1) 所有 XML 資料串流的頻 繁路徑樣式，皆為 XML 文件某個具有分 支 的 節 點 與 其 第 一 子 節 點 （ first child node）所遞迴組成的路徑。例如在前述的 資料串流中，路徑樣式<B><C><D>重複出 現了兩次；(2) 資料串流中重複敘述 XML 文 件 結 構 的 頻 繁 路 徑 都 會 被 內 容 節 點 （text）所切斷，無法形成很長的頻繁路 徑。於是，我們可搜尋到的最長頻繁路徑 圖三 XML 文件範例 樣式，將不會超過 XML 文件的最大深度。 基於 縮 XML 文件 首先 C ~ 為路徑必須由連續的節點所組成）。以動態 <A> <B> <C> <D>Asia</D> </C> <E>NCS2007</E> </B> <B> <C> <D>Dec.20</D> <F>Taichung</F> </C> </B> </A> 上述的觀察，為了達到壓 中重複結構的目的，我們將搜尋頻繁 子樹樣式這個複雜的問題，簡化成搜尋有 限長度的頻繁路徑樣式。根據文獻[2]，一 般 XML 文件的深度平均在 4，且絕大部分 的文件的深度都不超過 8，所以搜尋有限 長度的頻繁路徑樣式，其計算量不高。 搜尋頻繁路徑樣式的步驟簡述如下： 利用 SAX（simple API for XML）分 析整份 XML 文件，將文件中有分支的節 點的第一個分支節點（即第一個子節點） 以遞迴的方式取出，形成有序的路徑，即 路徑樣式（path pattern），各個路徑樣式以 文件中的內容節點或標籤結束符號作為分 隔。接著拆解路徑獲得子序列路徑，例如： A~B~C 代表一條會經過節點標籤依序為 A、B、 的路徑，A~B~C 路徑須分解出 A~B 與 B C 子序列路徑（沒有 A~C，因

配置方式儲存這些路徑並累計它們出現的 頻 率 ， 最 後 利 用 預 先 設 定 的 門 檻 值 （min_supp）來判斷是否成為頻繁路徑樣 式（FPP）。尋找 FPP 演算法步驟如圖四。 Algorithm XSC_Find_FPP 輸入：XML 文件 D，參數 Y：FPP 最小門檻值 輸出：List L：存放所有的 FPP 之串列 初始設定：暫存串列 TL 為 步驟 1： X分析文件D， Null i加入 步驟 頻率；否則，新增 f 於 L 頻率設為 1。 用SA 依序產生的每一個 事件event 。 i 步驟 2：如果event 是i 開始標籤，則將event 暫存串列TL中，回到 驟 1；步 若eventi是內 容節點或結束標籤，則繼續步驟 3。 TL中所

步驟 3： 有開始標籤event1…eventTL.length形

成一個序列路徑P，呼叫 Update_L(P)；將 P分解出所有長度大於 1 的子序列路徑 Psub，呼叫 Update_L(Psub)。清空TL。 步驟 4：重複步驟 1 到 3，直到文件 D 結束。 5：將低於門檻值 Y 的序列路徑從 L 中刪 除後，輸出 L。 Procedure Update_L(f) 步驟：若發現序列路徑 f 已存在於串列 L 中， 則累加 f 的出現 中，並將 f 的出現 圖四 XSC－尋找 FPP 演算法 每 用來 置換在XML ，被置換的 路徑 須循序讀取的特性， 我們捨棄傳統區間編碼需給定每個節點一 組編 我們將 每個 ，FPP 表格 FPP_table 個 將eventi加入 。 步驟 的序列路徑 於 FPP_table，則將 f 的第一個標籤節點 一個FPP都有唯一的識別碼， 文件中相同的路徑 則放置一個FPP節點來表示，達到壓 縮 文 件 結 構 的 效 果 。 例 如 ： 令 FPP1＝ <B><C><D>，則圖三XML範例文件的資 料 串 流 會 壓 縮 為 ： <A><FPP1>Asia</ FPP1><E>NCS2007</E><FPP1>Dec.20</F PP1><F>Taichung</F></A>。我們將所有的 FPP資訊記錄於FPP表格中，包括FPP的識 別碼以及其所取代的序列路徑。 3.4 XSC 壓縮方法 利用串流資料必

碼(Start, End, Level)來表示文件結構 的方式，而僅保留 Level，大幅降低編碼所 額外需要的儲存空間。藉由持續觀測各節 點 Level 的變化，推算出各個節點的子樹 範圍，藉此判定文件的結構關係。如圖一 的範例，假設客戶端循序讀取到節點 x 時，其階層為 1，則之前已讀取到的節點， 若其階層小於或等於 1，必不屬於節點 x 的子樹範圍內，例如根節點 w（階層為 0）； 而後陸續接收到節點如 y、z，階層皆大於 1，且自節點 x 以來，尚未出現其他階層小 於或等於 1 的節點，則可斷定節點 y、z 皆屬於節點 x 的子樹範圍內。另外，我們 也刪去文件中每個標籤節點的結束標籤， 以節省更多的空間，且不影響 XSC 方法用 Level 來判斷文件結構的正確性。 除了結構上的編碼法之外，XSC 尚運 用字典編碼法進一步去壓縮文件。 標籤都編一個唯一可識別的數字，例 如 Employee、Personal_Info 分別對應到數 字 1、2，來節省文件的空間。同樣地，節 點的屬性名稱也利用字典編碼法去壓縮。 至於內容節點的處理則與 XGRIND[12]相 同，採用霍夫曼編碼（Huffman encoding） [8]來進行壓縮。 Algorithm XSC_Compression //產生壓縮 XML 文件 輸入：XML 文件 D 輸出：壓縮之 XML 文件 CXML 始設定： 串列 TL 為 Null 初 暫存 步驟 1：用SAX分析文件D，依序產生的每一 事件eventi。 步驟 2：如果event 是i 開始標籤，則 T 中，L 回到步驟 1； 是內容若 節點或結束 標籤，則繼續步驟 3。 ：TL中

步驟 3 的所有的事件event1…eventTL.length-1

形成一個序列路徑P，呼叫Output(P)；若 eventTL.length 為 內 容 節 點 ， 則 呼 叫

OutputHuffman(eventTL.length)。清空TL

步驟 4：重複步驟 1 到 3，直到文件 D 結束。 5：輸出 CXML。 e ure Output(f Proc d ) //將壓縮節點輸出至壓縮文 輸入： f：由多個標籤組成 步驟：若序列路徑 f 存在 所對應的 FPP_id 與 f Level 寫入檔案 CX 的 ML；若 f 不存在於 FPP_table， 將 f（包則 括 f 內每個標籤的 Level）寫入檔案 CXML。 圖五 XSC－壓縮演算法 XSC 五。當我們對 文件壓縮完畢，壓縮 後的 壓縮（包含編碼）演算法如圖 XML XML 文件會含有三種類型節點的編

碼：分別是 FPP 節點、一般節點與內容節 點。各種節點的資料格式如：FPP 節點為 (Flag, FPP_id, Level)、一般節點為(Flag, Node_id, Level)、內容節點為(Flag, Length, Text)。Flag 用來區分三種不同格式的節 點，FPP_id 或 Node_id 分別表示節點的識 別碼，Length 與 Text 的意義與 EXPedite [6][7]編碼相同，差別在於 Text 是以霍夫曼 編碼壓縮（圖五之 OutputHuffman 函式）。 內容節點的 Flag＝0；若 Flag＝1，則需額 外識別 FPP_id 或 Node_id，進一步判斷是 屬於 FPP 節點或一般節點。 3.5 XSC 壓縮文件之查詢演算法 XPath 子代軸線與後代軸線查詢[3]。XSC查詢方 法分 於 Holi _Table，並標記FPPi 支援XSC壓縮文件之查詢包括 為兩個階段：第一階段根據使用者查 詢式預先處理FPP表格內所有的FPP，演算 法步驟如圖六(a)。首先將FPP表格傳送給 客戶端，客戶端根據查詢式需要的特定標 籤節點，從FPP表格中找出符合查詢式的 FPP，並將這些FPP節點及相關資訊存入客 戶端的查詢表格Q_Table中（步驟 2）。查 詢表格紀錄FPP節點取代的路徑上的標籤 與查詢式相符標籤的對應位置。舉例來 說 ， 若 查 詢 式 為 //A/B/D ， 而 FPP1＝ <B><C><D>，則查詢表格中會新增一筆紀 錄(FPP1, 0, 1, 3)，分別表示FPP識別碼與查 詢式中三個標籤的對應位置。第二個欄位 0 代表查詢式的A標籤並未出現於FPP1；第 三個欄位 1 代表查詢式的B標籤出現於 FPP1第 1 個位置；第四個欄位 3 代表查詢 式的D標籤出現於FPP1第 3 個位置。 第二階段是在XSC壓縮文件上做查 詢，XSC查詢演算法主要的概念來自

stic twig joins[5]，並融入我們設計的 FPP技巧，其演算法步驟如圖六(b)所示。 以下舉例說明演算法相關的術語與符號。 XPath查詢式可視為一個查詢樹，各節點都 有 對 應 的 查 詢 堆 疊 。 假 設 查 詢 式 為 //A[/B]/C/D ，則對應的查詢堆疊分別為 SA、SB、SC、SD，其中SA稱為“根查詢堆 疊＂，SB、SD稱為“葉查詢堆疊＂，而SD稱 為“結果堆疊＂，是查詢式所需要傳回的結 果。查詢處理過程中，暫存於查詢堆疊裡 的元素以q代表，如qA、qB、qC、qD。 Algorithm：XSC_Query_Phase1 輸入：FPP表格 FT、查詢Q及Q所含的標籤 t1t2…tn 輸出：查詢表格 Q_Table 步驟 1：逐一取出FT中的FPP 稱， 為FPPi。 步驟 2：若FPPi有節點與t1t2…tn的標籤相同，則 將FPP 加i 入查詢表格Q 與查詢式相符標籤的對應位置。 (a) 第一階段 Algo 輸入 XML文 件D每個 event1…eventj 丟棄並 步驟 出 ≦x≦k 。若是，傳回 rithm XSC_Query_Phase2 ：查詢Q，查詢表格Q_Table，壓縮 節點產生的事件： 輸出：符合查詢式之節點內容 初始設定：事件順序i=1，根據查詢Q建立對應 的查詢堆疊S1…Sk，及對應的暫存結 果緩衝區C …C1 k

步驟 1：讀取event ，根據eventi i.Level判斷查詢

堆疊S1…Sk可被丟棄（pop）的節點，將其

輸出已成立之查詢結果。

： event

步 驟 2.1 如 果 i為 一 般 節 點 ， 令

x=Condition(Q, eventi)，若x＞0 則將eventi放

到對應的查詢堆疊中。跳到步驟 3。 2 如果even P節點且Q_T 步驟 .2： ti是FP able中有 符合FPP的紀錄，則逐項分析FPP路徑上每 個 事 件 標 籤 eventz， 令 x=Condition(Q, event )，若xz ＞0 則 ev將 ent 放到z 對應的查詢 堆疊Sx中。跳到步驟 3。 2.3：如果eventi是內容節點且為結果堆疊 Sk內節點的內容，則將eventi放入Ck。跳到 步驟 3。 3 i＝i+ i＞j 則程 步驟 ：令 1；若 式結束，否則回 到步驟 1。 c on C nd

Fun ti o ition(Q, eventi)

輸入：查詢Q與查詢堆疊：S1…Sk，事件eventi 輸 ：數字 x，0 步驟：判斷節點是否符合查詢式 符合的查詢堆疊編號 x；若否，傳回 0。 (b) 第二階段 圖六 XSC－查詢演算法 查詢 種情形：一般節點、FPP 節點以及內容節 點。 處理 XSC 壓縮文的節點分為三 首先如圖六(b)步驟 1，根據節點的階 層（Level）判斷，刪除查詢堆疊 S 中可被

丟棄（pop）的節點 q，以節省暫存空間。 接著，若節點屬一般節點，且符合查詢式 之堆疊的結構及標籤名稱（由步驟 2.1 之 Condition 函式判斷），則放入（push）查 詢堆疊中。若屬 FPP 節點，則搜尋客戶端 的查詢表格是否存在此節點，若是，則分 解 FPP 節點以進行 Condition 函式判斷； 否則可略過（步驟 2.2）。若節點屬內容節 點，且為結果堆疊內節點的內容（步驟 2.3），則需要暫存起來。圖六所有副程式 的詳細演算法請參考論文[1]。 舉圖三的XML文件壓縮後為例，其中 有FPP節點FPP1＝<B><C><D>。若查詢式 為 /

、實驗

我們進行三 XSC 方法在 壓縮與查詢上的效能，並且對高壓縮率所 帶來 ML 實驗測試資料 數 小 階層 層 對內容的 比率 /A/B/D，在第一階段查詢時，客戶端 先接收到FPP表格並搜尋發現FPP1有符合 查詢式//A/B/D，故將(FPP1, 0, 1, 3)存入查 詢表格。第二階段開始進行查詢，演算法 首先依據查詢式建立三個查詢堆疊SA、 SB、SD，並陸續接收XML文件節點。第一 個接收到的是A節點，符合查詢式，故將A 節點放入查詢堆疊SA中；其後是FPP1，位 於查詢表格中，故可查表得知FPP1的第 1 及第 3 個標籤（B、D）符合查詢第 2 及第 3 個標籤，於是解開FPP1獲得B、D節點並 放入查詢堆疊SB、SD。此時查詢堆疊SA、 SB、SD已經全部都包含節點，代表查詢式 已完全被滿足，故輸出結果SD，並隨即將 之丟棄。而後E節點與B節點陸續出現，使 SB、SD堆疊內的節點也被丟棄。如此不斷 地接收串流資料並立即做查詢處理，直到 查詢結束為止。

四

個實驗，模擬 的額外負擔也做了評比。模擬實驗的 環境為個人電腦（中央處理器 Intel Core 2 T5600 1.83GHz，1GB 記憶體），Windows XP 作業系統，程式用 Microsoft C# .Net 撰寫。實驗文件特徵如表一所示，XMark 是用網站 http://monetdb.cwi.nl/xml/ 提供 的程式與 DTD 綱要所產生的人造 XML 文 件，其餘為真實文件，取自公開於網際網 路 上 的 專 案 ， 如 GSFC/NASA XML project、Penn Treebank project 等。實驗 1 比較 XSC、XGRIND 及 EXPedite 三種演 算法對文件的壓縮率。實驗 2 量測上述三 種演算法查詢壓縮文件的時間。實驗 3 量 測三種演算法壓縮文件所需要的壓縮與編 碼的時間。 表一 X 節點 文件大 屬性數 最大 平均階 結構 All_Shakes 180K 7.7MB 0 6 4 0.25: 1 Nasa 477K 24MB 56317 8 58 5. 0.56: 1 Lineitem 1023K 31MB 1 3 2.94 3.7: 1 Treebank_e 2438K 84MB 1 36 7.87 0.451: 1 XMark 1666K 115MB 381878 11 4 0.32: 1 4.1 實驗 文件與單就結構部份 的壓縮率比較。進行模擬實驗時，以各份 文件 1：壓縮率 實驗 1 進行整份 總節點數的 1%來當作頻繁路徑模式 的門檻值，故出現次數超過該文件節點數 百分之一的序列路徑，即視為 FPP。實驗 程序是將表一之五份 XML 文件檔案讀取 之後，利用我們實做出的三種不同的方法 去壓縮，輸出壓縮後的文件檔案。圖七為 整份文件的壓縮率比較圖，圖八為文件結 構部份的壓縮率比較圖。圖中的壓縮率計

算公式為＝（壓縮後文件的大小）/（原始 文件大小）×100%，所以壓縮率愈低表示 壓縮的效果愈好。 圖 七 的 實 驗 結 果 顯 示 ， XSC 與 XGRIND 都可將文件壓縮至 65%以下，壓 縮率優於 EXPedite 約 13%~28%的差異。 EXPedite 雖對文件加入額外的編碼資訊， 但編碼後文件仍然比原始文件小，主要原 因是它利用字典編碼法，將標籤節點取代 為唯一的識別碼，所省下的空間多於額外 的編碼資訊，故達到壓縮的效果。 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% 80.00% 90.00% 100.00%

All_Shakes Lineitem Nasa Treebank_e XMark XSC XGRIND EXPedite 圖七 XML 文件壓縮率比較圖 以圖七整份文件壓縮率而言 優 於 XGRIND 3.5%的差異。由於 XSC 壓縮 ，XSC 平均約 技巧主要是針對結構上重複出現的路 徑，一般而言，結構重複性愈高，出現 FPP 路徑愈長，則預期 XSC 效果會愈好。以 Treebank_e 文件為例，最大的階層數為 36，XSC 能搜尋出更多、更長的 FPP 路徑， 故 有 較 好 的 壓 縮 率 （ 49.26% ）， 優 於 XGRIND 方法（54.99%）；反之，以 XMark 文件為例，其結構與內容的比例為 0.32： 1，階層數平均為 4，其結構較 Treebank_e 單純，可預期壓縮率不佳；實驗結果顯示， XSC 對 XMark 的壓縮率僅優於 XGRIND 1.21%的差異。然而 XSC 壓縮率高低非單 一因素可決定，以 Lineitem 文件為例，結 構與內容比率為五份實驗文件中最高者 （3.7：1），但壓縮率卻不如 Treebank_e， 原因在於 Lineitem 的標籤結構十分簡單， XSC 只能找到一組 FPP。總體分析發現， 當文件的結構複雜、節點的標籤長，以及 結構與內容的比率高的文件，XSC 的壓縮 率會比較高。 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% 120.00% 140.00%

All_Shakes Lineitem Nasa Treebank_e XMark XSC XGRIND EXPedite 160.00% 圖八 XML 文件結構壓縮率比較圖 言， XSC Treebank_e 文件 法在串流查詢上所 花費的時間。我們分別採用三份 XML 文 件： 所以我們根據 若以圖八僅比較結構部份的壓縮率而 表現最好仍然是在 ，壓縮率 52.87%，優於 XGRIND 的 88.79%，差異有 35.92%之多；Lineitem 壓 縮率 17.11%，優於 XGRIND 的 22.37%， 差異最小僅 5.26%。從實驗數據可知，XSC 針對結構的壓縮表現良好，優於 XGRIND 差異平均有 16.61%。 4.2 實驗 2：查詢時間 實驗 2 比較三種方 Nasa、Lineitem、Treebank_e 進行實 驗，利用個人電腦模擬串流環境，循序讀 取壓縮後的 XML 文件，然後將查詢所得 的結果直接輸出在螢幕上，並重複執行實 驗十次以獲得平均查詢時間。三份實驗文 件的大小、結構對內容的比率以及結構複 雜程度都不相同，藉此驗證 XSC 方法運用 在各類文件上的優缺點。 由於 XGRIND[12]論文中並沒有詳細 描寫所使用的查詢演算法，

其壓 2 查詢集 縮文件格式，自行編寫查詢程式，稱 為 XGRIND’，以利進行實驗比較。實驗 2 所使用的查詢集如表二，混合了長度不等 的路徑查詢與分支查詢；實驗結果如圖九 (a)、(b)、(c)所示。 表二 實驗 Nasa 查詢一：//sou 查詢二：//field/name ：//field[/name]//definition liation]/creator/lastName 查詢二：//T/L_PARTKEY /L_PARTKEY]/L_SUPPKEY 查詢二：//VBP/VP/VBN [//NN]/JJ BN//VB]/NN/PP/IN rce/other/title 查詢三 查詢四：//history/ingest[/affi Lineitem 查詢一：//T/L_ORDERKEY 查詢三：//T[ Treebank_e 查詢一：//NP/JJ 查詢三：//NP 查詢四：//NP[//V 圖九(a)為 Nasa 文件的查詢時間比較 圖，EXPedite 由於有區間編碼的輔助，所 以查 簡 單， 詢時間比 XGRIND’短，而 XSC 不僅 利用編碼的 Level（階層），更採用兩階段 查詢，略過不需要的 FPP 節點，所以實驗 結果平均最佳。在查詢三的數據中，XSC 的查詢時間最接近 EXPedite，原因是查詢 三所獲得的內容節點較多，XSC 在進行霍 夫曼編碼的解壓縮時間增加，故相對於查 詢一、二、四而言，能改善的幅度較少， 僅優於 EXPedite 0.019 秒，約 2.7%。 圖九(b)為 Lineitem 文件的查詢時間 比較圖。由於 Lineitem 文件的結構十分 文件最大階層只有 3，故我們僅設計 三個查詢（兩個路徑查詢，一個分支查詢） 來進行模擬實驗。根據實驗結果，XSC 具 有最短的查詢時間。Lineitem 標籤結構簡 單，並沒有許多 FPP 節點可以取代，XSC 於查詢一、二中，改進 EXPedite 查詢效能 約 3%、12%；對於分支查詢三，XSC 效 能最好，改進 EXPedite 效能約 16%。 0 0.2 0.4 0.6 0.8 1 1.2 1.4 查詢一 查詢二 查詢三 查詢四 單位 ： 秒 XSC XGRIND' EXPedite 圖九(a) Nasa 查詢時間比較圖 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 查詢一 查詢二 查詢三 單位：秒 XSC XGRIND' EXPedite 圖九(b) Lineitem 查詢時間比較圖 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 查詢一 查詢二 查詢三 查詢四 單位:秒 XSC XGRIND' EXPedite 圖九(c) Treebank_e 查詢時間比較圖 間比較圖 EXP 。 圖九(c)為 Treebank_e 文件的查詢時 ，顯示 XSC 查詢效能仍然是優於 edite，而 EXPedite 優於 XGRIND’。 並 且 改 進 效 能 明 顯 比 前 面 兩 份 文 件 Nasa、Lineitem 要高，因為 Treebank_e 文 件結構複雜，XSC 能夠用來壓縮的 FPP 節 點也較多，故在兩階段查詢中，可預先於 第一階段摒除不合查詢的 FPP 節點，但 EXPedite 及 XGRIND’並沒有這種預先過 濾的動作。Treebank_e 模擬實驗共四個查 詢 式 ， XSC 平均查詢時間為 1.7 秒， EXPedite 2.7 秒，XGRIND’ 3.4 秒；XSC 改進 EXPedite 查詢效能平均達 37%

4.3 實驗 3：壓縮與編碼時間 實驗 3 比較三種方法在壓縮文件上所 ，我們採用 三份文件：Nasa、Lineitem、Treebank_e 進行 花費的時間成本。如同實驗 2 效能比較。圖十顯示 XSC-、XSC、 XGRIND 及 EXPedite 壓縮文件所需要的 時間，XSC-代表 XSC 整體壓縮時間扣掉 搜尋 FPP 的時間，而 XSC 代表整體壓縮 時間。 0 5 10 15 20 25 30

Nasa Lineitem Treebank_e

單位 :秒 XSC- XSC XGRIND EXPedite 圖十 壓縮時間比較圖 就壓縮文件的速度而言，XGRIND 與 XSC、EX 縮時間都是最短的，因為 XSC、 都加 新，

五、結論與未來工作

本研究主要貢獻在於，提出一個適用 於主從式串流環境的 XML 文件壓縮演算 法， 試利用文件綱要 （如 Pedite 相比，在三份文件上的壓 EXPedite 入了編碼等輔助查詢的機制，故使整 體壓縮速度變慢。另外，EXPedite 在 Nasa 與 Lineitem 文件上壓縮時間低於 XSC，但 在 Lineitem 文件高於 XSC；原因是 XSC 方法必須處理 FPP，增加了壓縮的時間， 而由於 Lineitem 文件簡單，FPP 數量少， 故處理 FPP 佔整體壓縮時間比例小，於是 XSC 方法可優於 EXPedite。若將搜尋 FPP 的時間去除掉，即用 XSC-與 EXPedite 相 比，則發現，XSC-在壓縮文件的時間上皆 優於 EXPedite，且與 XGRIND 不相上下， 原因是 XSC 採用了更簡單的編碼，大幅縮 短了編碼所需額外的時間所致。 在串流系統中，編碼及壓縮的時間只 在伺服器中執行一次，除非文件時常更 否則不需重複執行。故在文件沒有更 新的情況下，我們壓縮及編碼的時間，可 算是一次性的成本。當 XML 串流資料被 大量且多次傳送至客戶端，壓縮成本相對 於查詢所節省下來的時間而言，更顯得微 不足道。另一方面，若文件內容有更新， 而結構不變的情形之下，XSC 只需對更改 的內容重新做霍夫曼編碼，不需重新搜尋 FPP，亦不須重新編碼，可節省約 25~44% 的壓縮時間（以實驗 3 為例）。 以及特殊的兩階段查詢方法，提升查 詢串流壓縮文件的效能。壓縮演算法保留 原始 XML 文件特性，可供客戶端直接在 壓縮的文件上作查詢，不用暫存整份壓縮 文件，節省了大量的記憶體需求；兩階段 查詢方法可以讓客戶端預先在第一階段過 濾掉不可能為查詢結果的文件片段，避免 因解壓縮非查詢文件片段所增加的計算成 本，減少比對符合查詢式的節點數，進而 提高 XML 串流查詢的速度。實驗數據顯 示，雖然我們提出的 XSC 方法的壓縮時間 略 高 於 實 驗 比 較 的 對 象 EXPedite 和 XGRIND，但是在壓縮率與查詢的時間方 面，皆有較好的表現。 在未來工作方面，我們認為在不影響 查詢效能的原則下，可嘗 DTD 或 XML Schema）去獲得語義方 面的資訊，達到更高的壓縮率。另外，目 前 XSC 方法適用於單一文件，未來將朝向 相似綱要之多文件壓縮演算法進行研究。

致謝

本論文由國科會研究經費補助，計畫編號 -95-2221-E-005-048，特此致謝。 [1] 丁正文， 之 XML 文 件壓縮技巧，國立中興大學資訊科學 [2]

the XML Web: Gathering

[3] A (XP Recommendation, 3C [5] N L [6] Y han, “EXPedite: a [7] Y Path [8] uction of Minimum-Redundancy [9] H

ery Large Data

[10]

ng XML Data for Regular Path

[11] XML 2] 為 NSC

六、參考文獻

一個支援串流查詢 系，碩士論文 (指導教授：賈坤芳)， 2007 年。

D. Barbosa, L. Mignet, and P. Veltri, “Studying

Statistics from an XML Sample,” World Wide Web, Volume 8, Number 4, pp.413-438, 2005.

. Berglund et al., XML Path Language ath) 2.0, W3C

Available at http://www.w3.org/TR/xpath20/, 2007.

[4] T. Bray et al., Extensible Markup Language (XML) 1.1, W

Recommendation, Available at http://www.w3.org/TR/xml11/, 2006.

. Bruno, N. Koudas, and D. Srivastava, “Holistic Twig Joins: Optimal XM

[1

Pattern Matching,” Proceedings of ACM SIGMOD Conference, pp.310-321, 2002.

. Chen, G. A. Mihaila, S. B. Davidson, and S. Padmanab

System for Encoded XML Processing,” Proceedings of the 13th ACM International Conference on Information and Knowledge Management, pp.108-117, 2004.

. Chen, G. A. Mihaila, S. B. Davidson, and S. Padmanabhan, “Efficient

Query Processing on Encoded XML,” Proceedings of International Workshop on High Performance XML Processing, 2004.

D. A. Huffman, “A Method for the Constr

Codes,” Proceedings of the Institute of Radio Engineers, Volume 40, pp.1098-1101, 1952.

. Jagadish et al., “TIMBER: A Native XML Database,” V

Bases, Volume 11, Issue 4, pp.274-291, 2002.

Q. Li and B. Moon, “Indexing and Queryi

Expressions,” Proceedings of the 27th International Conference on Very Large Data Bases, pp.361-370, 2001.

W. Ng, L.W. Yeung, and J. Cheng, “Comparative Analysis of

Compression Technologies,” World Wide Web Journal, Volume 9, Issue 1, pp.5-33, 2006.

P. M. Tolani and J. R. Haritsa, “XGRIND: A Query-friendly XML Compressor,” Proceedings of 18th International Conference on Database Engineering, pp.225-234, 2002.