專利名稱：一種關系數(shù)據(jù)庫系統(tǒng)純xml引擎的評測方法
一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎的評測方法
技術領域：
本發(fā)明屬于數(shù)據(jù)庫測試領域，具體涉及一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎數(shù)據(jù)庫的 評測方法。
背景技術：
可擴展標記語言XML (extensible Markup Language)已成為Web上表示和交換數(shù) 據(jù)的標準格式。如何有效管理大規(guī)模XML文檔，已經成為當前數(shù)據(jù)庫領域中一個亟待解決 的研究課題。純 XML 數(shù)據(jù)庫，如 Software AG Tamino、Apache Xindice、Wolfgang Meier eXist等，以XML數(shù)據(jù)模型為中心，具有為XML量身定做的存儲方案和查詢引擎，以一種自 然的方式管理XML數(shù)據(jù)。然而純XML數(shù)據(jù)庫系統(tǒng)面臨的最大問題是，必須重新實現(xiàn)關系數(shù) 據(jù)庫領域已經研究和實踐了三十余年的眾多成熟理論和技術，如存儲管理，事務管理，鎖管 理，備份與恢復管理等。如此大規(guī)模的重復開發(fā)工作會浪費巨大的人力和物力。并且為了 能使XML數(shù)據(jù)庫具有更加廣闊的應用，應該和關系型數(shù)據(jù)庫進行整合，使之同時支持已有 的關系型數(shù)據(jù)和新增的XML數(shù)據(jù)的管理。因而，主流數(shù)據(jù)庫供應商如IBM、0racle和Microsoft都在研發(fā)如何將XML引擎技 術集成到關系數(shù)據(jù)庫管理系統(tǒng)中，使其既體現(xiàn)XML數(shù)據(jù)模型又重用已有系統(tǒng)模塊，目前都 已經在最新產品中以不同的方式加入了對XML的支持，并支持XPath/XQuery語言與SQL/ XML 2003標準。隨著關系數(shù)據(jù)庫上XML引擎的開發(fā)和XML需求的增加，擁有獨立的評測方 法來測試這些集成在關系數(shù)據(jù)庫系統(tǒng)中的XML功能也是一個必然的趨勢。所謂基準測試，就是指通過一定的測試方法和手段對特定的對象進行測試，從而 提供其性能參數(shù)，來作為對其進行分析和比較的基準。傳統(tǒng)關系數(shù)據(jù)庫上的評測基準很 多，尤以TPC系列(TPC-C、TPC-W、TPC-H/R)的使用最為廣泛。但它們從底層數(shù)據(jù)基礎到上 層的測試事務集全部基于關系型數(shù)據(jù)，很難被定制成XML數(shù)據(jù)庫上可行的方案。而針對純 XML數(shù)據(jù)庫的基準也已被許多研究機構提出，而它們各有側重考察的方面，如XMark、X007、 XBench更側重于通過大規(guī)模的查詢語句覆蓋盡量多的查詢功能，以檢測數(shù)據(jù)庫功能方面的 全面性，并沒有提出具體的性能指標。XMach-1、TPoX著眼于性能測試，但并沒有得到大規(guī) 模應用的檢測，覆蓋面不夠完善。至今仍未有一種測試基準是針對關系數(shù)據(jù)庫上XML引擎 提出的。

發(fā)明內容本發(fā)明目的是提供一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎的評測方法，以正確評價關系 數(shù)據(jù)庫上XML引擎的效率。為實現(xiàn)本發(fā)明目的需要著重從以下幾方面考慮1、存儲管理層XML數(shù)據(jù)是半結構化的數(shù)據(jù)，要做到無損的存儲XML數(shù)據(jù)，就要完 整的存儲其內容信息和結構信息到關系表中。2、索引結構的實現(xiàn)在關系數(shù)據(jù)庫中普遍實現(xiàn)的經典索引結構的基礎上，要求建立各種適當?shù)慕Y構索引，使得利用這些索引可以快速地定位到滿足指定結構關系的節(jié)點。3、查詢優(yōu)化將XML數(shù)據(jù)置于DBMS的環(huán)境中，充分發(fā)揮XML結構摘要索引的作用， 使XML引擎在執(zhí)行器層面上無縫地集成到關系數(shù)據(jù)庫系統(tǒng)中，構造最優(yōu)化查詢。4、擴展基本SQL語法，提供XML數(shù)據(jù)管理語言要求在關系查詢引擎的SQL解析器 中實現(xiàn)SQL 2003標準規(guī)定的SQL/XML擴展，且要實現(xiàn)在SQL語法中XPath/XQuery的內嵌 式查詢。5、更新操作與聯(lián)機事務處理在傳統(tǒng)關系數(shù)據(jù)庫中，由事務管理器和鎖管理器組 成的并發(fā)控制模塊與數(shù)據(jù)庫底層存儲進行通信，從而保證了多個事務同時更新數(shù)據(jù)時的邏 輯正確性。要求將概念模型根本不同的XML數(shù)據(jù)更新有機地融入到關系數(shù)據(jù)事務處理的體 系中。本發(fā)明在綜合考慮以上幾點的基礎上，提出了一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎的 評測方法，該方法包括以下步驟第1、定義文獻管理系統(tǒng)作為測試場景，并定義了邏輯功能；第2、根據(jù)測試場景設計并生成XML文檔集合作為測試數(shù)據(jù)集并填充入待測數(shù)據(jù) 庫；第3、針對第2步生成的測試數(shù)據(jù)集定義待測事務集，包括查詢事務集和更新事務 集；第4、在待測數(shù)據(jù)庫上單獨運行第3步定義的事務作為功能測試，驗證待測事務能 否順利完成并統(tǒng)計功能性指標，并可以通過加索引的方式比較索引前后的待測事務響應來 測試索引的效率；第5、設計、執(zhí)行并度量三種XML工作負載更新負載，查詢負載，混合負載，這些工 作負載是對第3步中的待測事務集選擇性的組合構成，每種負載工作在不同的并發(fā)強度和 不同的數(shù)據(jù)量下，測試待測數(shù)據(jù)庫系統(tǒng)的承受能力，統(tǒng)計性能性指標。本發(fā)明的具體評測流程如下1、定義文獻管理系統(tǒng)，即測試場景設計本發(fā)明第1步首先定義了一個完整的文獻管理系統(tǒng)作為測試場景，定義的數(shù)據(jù) 信息包括用戶信息、用戶賬戶、交費歷史、文獻信息和文獻內容，定義的操作包括用戶管 理、信息查看、文獻管理、用戶注冊、用戶交費、文獻檢索，這樣生成的XML數(shù)據(jù)集涵蓋以數(shù) 據(jù)為中心的文檔和以文字為中心的文檔，能夠體現(xiàn)XML文檔的特征。測試場景與具體數(shù)據(jù) 的關系如圖1所示。2、數(shù)據(jù)結構設計本發(fā)明第2步所述的測試數(shù)據(jù)集根據(jù)測試場景設計而來，將實體包含在5張XML 表中，其中User、Category、Order、Databases四張表是虛擬數(shù)據(jù)，其Schema結構包含了權 利要求2在測試場景中定義的所有數(shù)據(jù)信息，由XML生成工具生成；而Literature表是實 際數(shù)據(jù)，存放所有實際的XML文檔。數(shù)據(jù)結構如圖2所示。根據(jù)以上結構產生的XML文檔 兼具有以數(shù)據(jù)為中心和以文檔為中心兩種類型的文檔的特點。如對Order實體，其屬性分 布比較規(guī)整，體現(xiàn)了以數(shù)據(jù)為中心的文檔的特點，而以文檔為中心的文檔的特點主要通過 Literature實體體現(xiàn)。因此，這樣的XML文檔集合是典型的、能體現(xiàn)出XML文檔特點的。3、測試事務集
本發(fā)明第3步針對測試數(shù)據(jù)集，定義了一個測試事務集，包括14條查詢事務 和5條更新事務，這些事務的制定是根據(jù)XML Query (XQuery) Requirements、XQuery UpdateFacility 1.0 Requirements標準而來。具體的事務如下1)查詢事務Ql 根據(jù)id查看某用戶(id)的詳細信息，包括及訂閱的數(shù)據(jù)庫、分類——集合Q2 查看訂閱某分類(農業(yè))的所有用戶——引用Q3:將某一用戶(id)訂閱的數(shù)據(jù)庫以列舉方式顯示，以固定分隔符分隔—— string函數(shù)Q4:判斷是否存在文獻數(shù)量大于32655062的數(shù)據(jù)庫，是的話返回真——some (存 在量詞)Q5 判斷是否所有數(shù)據(jù)庫的文獻書目都大于32655062，是則返回真——every (全 稱量詞)Q6 列表顯示所有某一級的文獻類及直接子類——層次結構Q7 列出所有文獻的第一作者——序列Q8 列表查看order信息，統(tǒng)計某日(2005-7-22)，顯示當日order數(shù)量、當日總 額、最大額度、最小額度、平均額度Q9 嵌套查詢，查詢所有余額為2981的用戶發(fā)出的新訂單QlO 列表顯示未進行任何訂閱的用戶-EMPTY關鍵字Qll 根據(jù)名稱查看一個數(shù)據(jù)庫的詳細信息Q12 傳入用戶id及日期返回訂單，實現(xiàn)放入自定義函數(shù)內部Q13 統(tǒng)計各年齡段的用戶數(shù)量Q14 在所有文檔中檢索包含一個特定關鍵詞(customer)的文檔并返回2)更新事務Ul 用戶充值或消費，根據(jù)用戶id修改其賬戶余額U2 處理訂單，將某訂單中的<new_order>標記刪除U3 向某分類中新增子分類U4 用戶訂閱成功，用order中的databases禾Π category替換user中的對應元素U5 用戶訂閱某數(shù)據(jù)庫中某分類，訂單信息通過參數(shù)傳入而W3C的Requirements與本發(fā)明所設計的事務功能對應關系如下表1查詢事務至Ij Requirements的映射Requirements事務
Supported OperationsQl Q2
Text and Element BoundariesQ3
Universal and Existential QuantifiersQ4 Q5
Hierarchy and SequenceQ6 Q7
CombinationQl Q2
AggregationQ8
SortingQ8
Composition of OperationsQ9 NULLValuesQlO
Structural PreservationQ6 Q7
Structural TransformationQ3 Q6 Q7
ReferencesQ2 Q6
Identity PreservationQl
Operations on Literal DataQll
Operations on NamesQ3 Q6
Extensibility (FUNCTION)Q12
Environment InformationQ13
Full-Text SearchQ14 表2更新事務到Requirements的映射
Requirements事務Locus of modificationsUlDeleteU2InsertU3ReplaceU4Changing valuesUlModifying propertiesU2Conditional updatesU4ValidationSchema驗證CompositionalityU4U6ParameterizationU5所有這些事務以內嵌XQuery的SQL語言或者SQL/XML標準編寫，單獨運行并得到 功能性指標。4、并發(fā)負載
本發(fā)明第5步設計了三種并發(fā)負載更新(只寫)、查詢(只讀)、混合(讀-寫) 負載，每個并發(fā)用戶連接到數(shù)據(jù)庫并提交一個事務，每個事務被分配一個權重，這個權重決 定這個事務在工作負載中的百分比；其中，更新負載由兩部分構成首先插入海量XML文檔至Literature表作為原始數(shù)據(jù)， 其中原始數(shù)據(jù)量的大小要根據(jù)待測數(shù)據(jù)庫所運行的硬件環(huán)境配置，然后分階段調用5個更 新事務，從而在檢驗鎖的基礎上，檢驗更新性能是可伸縮的；只讀負載由14條查詢事務組成，它們的權重相同，使用遞增的并發(fā)用戶數(shù)以不同 的并發(fā)度執(zhí)行；混合負載由查詢事務和更新事務共同組成，其中70%的讀操作，30%的寫操作，寫 操作包括6%的更新操作，12%的文檔刪除操作，12%的插入操作。根據(jù)這樣的負載運行系統(tǒng)并統(tǒng)計性能性指標。5、指標體系本發(fā)明第4步和第5步中的指標所定義的指標體系涵蓋關系數(shù)據(jù)庫系統(tǒng)純XML引 擎的存儲、索引、查詢、更新各方面性能，考察數(shù)據(jù)庫系統(tǒng)對不同數(shù)據(jù)量和事務的時空開銷 和并發(fā)能力，具體包括在存儲能力上考察裝入原始數(shù)據(jù)的時間開銷和空間開銷，其中原始 數(shù)據(jù)量的大小要根據(jù)待測數(shù)據(jù)庫所運行的硬件環(huán)境配置；在索引能力上考察建立索引的時 間開銷和空間開銷，以及在更新過程中索引維護的時間開銷；在查詢能力上考察有無輔助 索引的響應時間和有無XML Schema的響應時間；在更新能力上考察有無索引的響應時間； 在并發(fā)控制上考察事務回滾率、事務等待時間和事務平均響應時間；以上的指標都在不同 的數(shù)據(jù)量和用戶并發(fā)度下進行評測，對待測數(shù)據(jù)庫系統(tǒng)進行增量式驗證。以上所述指標體系具體如下表所示 本發(fā)明的優(yōu)點和積極效果本發(fā)明提出了一種完整的關系數(shù)據(jù)庫系統(tǒng)純XML引擎評測方法，該方法以W3C標 準為基準，設計了測試場景、測試數(shù)據(jù)集、測試查詢集和測試指標集，涵蓋評測中的功能測 試和性能測試兩大方向。本發(fā)明的方法是在對關系數(shù)據(jù)庫系統(tǒng)上的純XML引擎的特征進行 研究的基礎上制定的，使用SQL/XML標準編寫的事務也更有針對性，適用于關系數(shù)據(jù)庫系 統(tǒng)純XML引擎的評測。

圖1為測試場景示意圖。圖2為數(shù)據(jù)結構示意圖。圖3為關系數(shù)據(jù)庫系統(tǒng)純XML引擎評測工作流程圖。
具體實施方式實施例1圖3給出了本發(fā)明的工作流程，現(xiàn)結合具體的應用實例來對本發(fā)明進行詳細描 述。本實例中所用到的XML文獻來自DBLP數(shù)據(jù)庫；UWXMLR印ository ； NiagaraXMLrepository ；中文Web信息檢索論壇(CWIRF)；萬方RSS ；中文網站RSS。 首先使用自定義的XML Schema創(chuàng)建XML文檔集合，XML文檔集分布在5張XML表 中，表的數(shù)據(jù)結構如圖2所示，其中 User表示登陸文獻檢索系統(tǒng)的用戶，其屬性包括firstname (名hlastname (姓)、birthday (生日)、balance (賬戶余額)、role (職位)、databases (訂閱的數(shù)據(jù)庫)等。Databases描述文獻檢索系統(tǒng)中不同的數(shù)據(jù)庫，其屬性包括name (名稱)、year_ from(開始日期)、year_to (終止日期)、literature_count (庫中文獻總數(shù))等。Category描述XML文獻的分類情況。它具有多層結構，每一層大的分類下面可能 包含多個小的分類，每層的每個分類都有自己的name (名稱)屬性。在最深層的Category 下面包含實際XML文獻，對Literature表作引用。Literature表中是實際的XML文獻。其屬性包括title (文獻題目)、authors (作 者列表)、keywords (關鍵字)、content (文獻內容)、databasejd (所屬數(shù)據(jù)庫)等。Order表表示了用戶下的訂單，其屬性包括user_id(訂閱用戶)、databases (訂 閱數(shù)據(jù)庫)、categorys (訂閱的分類)、amount (訂單金額)、datetime (訂閱時間)、new_ order (是否新訂單)等。這里User、Databases、Category和Order四張表表現(xiàn)了在圖1中的用戶信息、文 獻信息和訂單信息，屬于以數(shù)據(jù)為中心的XML范疇，使用Toxgene等XML生成工具生成，每 一個文檔約在幾百K到IOm之間不等；而Literature表現(xiàn)了圖1中的文獻內容，屬于以文 字為中心的XML范疇，使用真實XML數(shù)據(jù)。將生成的數(shù)據(jù)以一定規(guī)模的原始數(shù)據(jù)量填充入待測數(shù)據(jù)庫中，此例中以DB2作為 待測數(shù)據(jù)庫，選擇用大約IGB的原始XML數(shù)據(jù)填充數(shù)據(jù)庫，其中包括 6 萬個 User 30 萬個 Orders 20 Databases 2000 個 Category記錄填充這些數(shù)據(jù)的時間和空間使用情況，為建立好的數(shù)據(jù)庫做備份。在步驟4中，單獨運行設計好的事務集，測試關系數(shù)據(jù)庫系統(tǒng)純XML引擎的基本功 能，將14條查詢和5條更新事務用嵌入SQL的XQuery語句來實現(xiàn)，這些事務表現(xiàn)了圖1中 的用戶管理、文獻管理、文獻檢索、訂單管理等功能，以這樣的數(shù)據(jù)集和事務集構成的系統(tǒng) 運行起來統(tǒng)計指標集。以U3舉例說明update c_categorysset cateinfo = xmlqueryC copy$newinfo: = $CATEINFOmodify do insert<category><name> 新分類 </name><literaturesX/ literaturesX/category)into$newinfo/category/categorysreturn$newinfo')where xmlexistsC $CATEINF0/category [iid = 1]')；其中(Sid = 1的數(shù)字在實際運行中將被參數(shù)化為給定范圍中的某一數(shù)值，提交給 數(shù)據(jù)庫，得到返回結果并記錄每條事務的運行時間，可多次測試取平均值。在此基礎上，添加輔助索引，記錄創(chuàng)建索引的時空消耗，再次單獨運行事務集，對 比添加索引前后查詢事務的效率和更新事務的維護效率。以Q2舉例，在添加輔助索引之 前它的單獨運行平均時間為2. 364s，而添加之后的運行平均時間為1.422s，索引效率為 166%。之后將數(shù)據(jù)庫恢復到初始狀態(tài)。
在步驟5中，設計并度量三種XML工作負載更新負載(只寫)，查詢負載(只 讀)，混合負載(讀寫)，這些工作負載都具有很高的并發(fā)性。在此實例中，工作負載由 Loadrunner工具執(zhí)行，這個測試工具產生一個到多個并發(fā)線程。每個線程模擬一個用戶，該 用戶連接到數(shù)據(jù)庫并提交一個事務。每個事務被分配一個權重，這個權重決定這個事務在 工作負載中的百分比。在運行時，事務中的參數(shù)標志替換為具體的值，這些值是從可配置的 隨機值分布和輸入列表中提取的。當一個事務運行完畢退出，會馬上建立一個新的用戶，確 保并發(fā)用戶數(shù)目不變。對于插入工作負載，首先使50個并發(fā)用戶插入所有Literature。然后，分階段調 用5個更新語句，從而在檢驗鎖的基礎上，檢驗更新性能是可伸縮的。在每個階段使用50 150個并發(fā)用戶，測試直至插入所有Literature為止，記錄事務的回滾率為28%、事務平均 等待時間1. 276s和事務平均響應時間是2. 823s。對于只讀工作負載，在插入負載填充數(shù)據(jù)庫之后，對數(shù)據(jù)庫執(zhí)行只讀的工作負載。 這個工作負載由14個XML查詢組成，使用25、50、75、100、125和150個并發(fā)用戶以不同的 并發(fā)度執(zhí)行。測試的時間長度是這6種測試各運行一個小時，觀察系統(tǒng)吞吐量的峰值約為 600，而事務的平均響應時間為4. 951s。對于混合工作負載，與只讀工作負載相似，混合工作負載選擇在TO (插入)的同 時，使用U2(刪除)U4(更改)和14個查詢語句，并使用25、50、75、100、125和150個并發(fā) 用戶產生不同的并發(fā)度。測試的時間長度是每個測試各運行一個小時。統(tǒng)計的性能指標綜 合了插入工作負載和只讀工作負載的指標。這里混合工作負載的權重比率是70%的讀操作查詢；30%的寫操作6%的更新操作，12%的文檔刪除操作，12% 的插入操作。按照上述步驟做實驗，并統(tǒng)計結果指標，記錄事務的回滾率為35%，系統(tǒng)吞吐量的 峰值約為410，而事務的平均響應時間為3. 319s。而此次評測中最好的吞吐量出現(xiàn)在75個用戶的并發(fā)狀態(tài)下，此時CPU的利用率接 近100%，只讀吞吐量達到591，混合吞吐量達到408。再增加并發(fā)用戶數(shù)，已不能再使系統(tǒng) 得到更好的吞吐量，因為系統(tǒng)已經接近極限了。而混合負載的吞吐量比只讀和只寫的情況 下都小了很多，這是由于讀寫事務的并發(fā)執(zhí)行會造成死鎖和回滾，正如預期的一樣。
權利要求
一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎的評測方法，其特征在于該方法包括以下步驟第1、定義文獻管理系統(tǒng)作為測試場景，并定義了邏輯功能；第2、根據(jù)測試場景設計并生成XML文檔集合作為測試數(shù)據(jù)集并填充入待測數(shù)據(jù)庫；第3、針對第2步生成的測試數(shù)據(jù)集定義待測事務集，包括查詢事務集和更新事務集；第4、在待測數(shù)據(jù)庫上單獨運行第3步定義的事務作為功能測試，驗證待測事務能否順利完成并統(tǒng)計功能性指標，并可以通過加索引的方式比較索引前后的待測事務響應來測試索引的效率；第5、設計、執(zhí)行并度量三種XML工作負載更新負載，查詢負載，混合負載，這些工作負載是對第3步中的待測事務集選擇性的組合構成，每種負載工作在不同的并發(fā)強度和不同的數(shù)據(jù)量下，測試待測數(shù)據(jù)庫系統(tǒng)的承受能力，統(tǒng)計性能性指標。
2.根據(jù)權利要求1所述的方法，其特征在于第1步所述的定義文獻管理系統(tǒng)作為測 試場景中，定義的數(shù)據(jù)信息包括用戶信息、用戶賬戶、交費歷史、文獻信息和文獻內容，定 義的操作包括用戶管理、信息查看、文獻管理、用戶注冊、用戶交費、文獻檢索，這樣生成的 XML數(shù)據(jù)集涵蓋以數(shù)據(jù)為中心的文檔和以文字為中心的文檔，能夠體現(xiàn)XML文檔的特征。
3.根據(jù)權利要求1所述的方法，其特征在于第2步所述的測試數(shù)據(jù)集包含5張XML數(shù) 據(jù)表其中User、Category、Order、Databases四張表是虛擬數(shù)據(jù)，其Schema結構包含了權 利要求2在測試場景中定義的所有數(shù)據(jù)信息，由XML生成工具生成；而Literature表是實 際數(shù)據(jù)，存放所有實際的XML文檔。
4.根據(jù)權利要求1所述的方法，其特征在于第3步所述的測試事務集，定義了14條查 詢事務和5條更新事務，這些事務的制定是根據(jù)XML Query (XQuery) Requirements,XQuery Update Facility 1.0 Requirements 標準而來，其中1)查詢事務Ql 根據(jù)id查看某用戶(id)的詳細信息，包括及訂閱的數(shù)據(jù)庫、分類——集合 Q2 查看訂閱某分類(農業(yè))的所有用戶——引用Q3 將某一用戶(id)訂閱的數(shù)據(jù)庫以列舉方式顯示，以固定分隔符分隔——string函數(shù)Q4 判斷是否存在文獻數(shù)量大于32655062的數(shù)據(jù)庫，是的話返回真——some (存在量詞)Q5:判斷是否所有數(shù)據(jù)庫的文獻書目都大于32655062，是則返回真一一every (全稱量詞)Q6 列表顯示所有某一級的文獻類及直接子類——層次結構 Q7 列出所有文獻的第一作者——序列Q8 列表查看order信息，統(tǒng)計某日(2005-7-22)，顯示當日order數(shù)量、當日總額、最 大額度、最小額度、平均額度Q9 嵌套查詢，查詢所有余額為2981的用戶發(fā)出的新訂單 QlO 列表顯示未進行任何訂閱的用戶-EMPTY關鍵字 Qll 根據(jù)名稱查看一個數(shù)據(jù)庫的詳細信息 Q12 傳入用戶id及日期返回訂單，實現(xiàn)放入自定義函數(shù)內部 Q13 統(tǒng)計各年齡段的用戶數(shù)量Q14 在所有文檔中檢索包含一個特定關鍵詞(customer)的文檔并返回2)更新事務Ul 用戶充值或消費，根據(jù)用戶id修改其賬戶余額U2 處理訂單，將某訂單中的<new_order>標記刪除U3:向某分類中新增子分類U4 用戶訂閱成功，用order中的databases禾口 category替換user中的對應元素U5 用戶訂閱某數(shù)據(jù)庫中某分類，訂單信息通過參數(shù)傳入所有這些事務以內嵌XQuery的SQL語言或者SQL/XML標準編寫，單獨運行并得到功能 性指標集。
5.根據(jù)權利要求1所述的方法，其特征在于第5步所述的工作負載中，每個并發(fā)用戶連 接到數(shù)據(jù)庫并提交一個事務，每個事務被分配一個權重，這個權重決定這個事務在工作負 載中的百分比；其中，更新負載由兩部分構成首先插入海量XML文檔至Literature表作為原始數(shù)據(jù)，然后 分階段調用權利要求4所述的5個更新事務，從而在檢驗鎖的基礎上，檢驗更新性能是可伸 縮的；只讀負載由權利要求4所述的14條查詢事務組成，它們的權重相同；混合負載由查詢事務和更新事務共同組成，其中70%的讀操作，30%的寫操作，寫操作 包括6%的更新操作，12%的文檔刪除操作，12%的插入操作，根據(jù)這樣的負載運行系統(tǒng)并統(tǒng)計性能性指標集。
6.根據(jù)權利要求4所述的方法，其特征在于所述的指標集，考察待測數(shù)據(jù)庫對不同數(shù) 據(jù)量和事務的時空開銷和并發(fā)能力，具體包括在存儲能力上考察裝入原始數(shù)據(jù)的時間開 銷和空間開銷，其中原始數(shù)據(jù)量的大小要根據(jù)待測數(shù)據(jù)庫所運行的硬件環(huán)境配置；在索引 能力上考察建立索引的時間開銷和空間開銷，以及在更新過程中索引維護的時間開銷；在 查詢能力上考察有無輔助索引的響應時間和有無XML Schema的響應時間；在更新能力上 考察有無索引的響應時間；在并發(fā)控制上考察事務回滾率、事務等待時間和事務平均響應 時間；以上的指標都在不同的數(shù)據(jù)量和用戶并發(fā)度下進行評測，對待測數(shù)據(jù)庫進行增量式 驗證。
全文摘要
一種關系數(shù)據(jù)庫系統(tǒng)純XML引擎的評測方法，涵蓋關系數(shù)據(jù)庫系統(tǒng)純XML引擎的功能評測和性能評測。該方法根據(jù)關系數(shù)據(jù)庫上純XML引擎的特點，設計了一套完整的測試場景，模擬了一個文獻管理系統(tǒng)，設計并生成了XML文檔集作為測試數(shù)據(jù)集，并按照W3C標準設計了包括查詢事務集和更新事務集的測試事務集并以SQL/XML語言實現(xiàn)，運行單獨的查詢和更新語句作為功能測試，運行并發(fā)負載多個查詢和更新事務作為性能測試，可對數(shù)據(jù)庫系統(tǒng)的存儲能力、索引能力、承受能力等做出全面評估，并定義了一套評測指標集。本發(fā)明方法經在DB2等數(shù)據(jù)庫上的實驗證明是具有普遍意義的，具有系統(tǒng)性和完備性，可用于數(shù)據(jù)庫測試領域。
文檔編號G06F17/30GK101887465SQ20101024155
公開日2010年11月17日 申請日期2010年7月30日 優(yōu)先權日2010年7月30日
發(fā)明者任宇涵, 司冠南, 周正吉, 李楠, 許靜, 高小紅 申請人:南開大學