Efficient Relational Storage and Retrieval of XML Documents

Jill ChenMojdeh Makabi

CS240B

References

Kanda Runapongsa and Jignesh M. Patel. Storing and Querying XML Data in Object-Relational DBMSs. In A.B. Chaudhri al. (Eds): EDBT 2002 Workshops, LNCS 2490, pp.266-285, 2002.

H. Liefke and D. Suciu. XMill: an Efficient Compressor for XML Data. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pp 153-164, Dallas, Texas, May 2000.

C. Kanne and G. Moerkotte. Efficient storage of XML Data. et al. ICDE 2000. available at http://citeseer.nj.nec.com/kanne99efficient.html

Albrecht Schmidt, Martin Kersten, Menzo Windhouwer, and Florian Waas. Efficient Relational Storage and Retrieval of XML Documents. et al. WebDB 2000. available at http://www.research.att.com/conf/webdb2000/program.html

XML XML assumes the role of the standard data

exchange format in Web database environments XML is semi-structured and one consequence of

that is we can expect all instances of one type to share the same structure

Modeling issues arises from the inconsistency between semi-structured data on the one hand side and fully structured database schemas on the other hand

To make XML the language of Web databases, there should be effective tools for the management of the XML documents

Monet XML Model Efficient Relational Storage and Retrieval

of XML Documents The data model is based on the notion of

binary associations It decomposes XML documents into small,

flexible and semantically homogenous units

It is very efficient

<bibliography><article key= “BB88”>

<author>Ben Bit</author><title>How to Hack</title>

</article><article key= “BK99”>

<editor>Ed Itor</editor><author>Bob Byte</author><author>Ken Key</author><title>Hacking & RSI</title>

</article></ bibliography >

XML documents and Syntax Tree

Main Question

The question central to querying XML documents is how to store the syntax tree as database instance that provides efficient retrieval capabilities

Different Approaches Tree could be stored using a single

database table Makes querying expensive

By enforcing scans over large amounts of data in relevant to a query

With few Joins, large data volumes may have to processed

Tree could be stored by storing all associations of the same type in the same binary relation.

Being used in Monet XML Model

Monet XML Model

The basis for the Monet XML Model:PathsAssociations Binary Relations

Path For a node o in the syntax tree, its path is the sequence of labels along

the path (vertex and edge labels) from the root to o Path describe the position of the element in the graph relative to the

root node

For Node with OID O3, its path is : bibliography article author

The Ben Bit has path: bibliography article author cdata string

Associations

A pair (o,.) Є oid x (oid U string) is called an association

The different types of associations describe different parts of the tree Association of type oid x oid

represents edges Association of type oid x

string represents attributes values

Binary Relation

In order to transform XML document to Monet Model, we need to get the set of binary relations that contain all associations between nodes Store all association of the same type in the same binary relation

Example:

For association of bibliography and article: {(O1, O2) , (O1, O7)}

Monet Transformation

bibliography article title cdata string = {(O6, “How to Hack” ) , (O15, “Hacking & RSI”)},

bibliography article = {(O1, O2) , (O1, O7)},

bibliography article author = {(O2, O3) , (O7, O10), (O7, O12)},

bibliography article title = {(O2, O5) , (O7, O14)},

bibliography article author cdata = {(O3, O4) , (O10, O11), (O12, O13)},

bibliography article author cdata string ={(O4, “Ben Bit” ) , (O11, “Bob Byte”), (O13, “Ken Key”)},

bibliography article title cdata = {(O5, O6) , (O14, O15)},

bibliography article editor = {(O7, O8)},

bibliography article editor cdata = {(O8, O9)},

bibliography article editor cdata string = {(O9, “Ed Itor” )},

bibliography article key = {(O2, “BB88” ) , (O7, “BK99”)},

Query

p = {O2, O7},

= {(O2, “Ben Bit” ) , (O7, “Bob Byte”), (O7, “Ken Key”)},assoc(p a)

= {(O2, “How to Hack” ) , (O7, “Hacking & RSI”)},assoc(p t)

SELECT pFROM bibliography article p, p author cdata a, p title cdata tWHERE a=“Ben Bit” and t like “Hack”

Show Ben Bit’s publication whose titles contain the word “Hack”

Specify sets

Specify associations between the first and last element of the path

Obtained by equality joins of binary relations along the path

Single Database Table

Key Author title EditorBB88 Ben Bit How to

HackNULL

BK99 Bob Byte Hacking & RSI

Ed Itor

BK99 Ken Key Hacking & RSI

Ed Itor

….

Disadvantages: Scans over large

amounts of data Large data volumes may

have to be processed by few joins

Add NULL values for irregularities

SELECT *FROM bibliography WHERE Author=“Ben Bit” and t like “Hack”

<bibliography><article key= “BB88”>

<author>Ben Bit</author><title>How to Hack</title>

</article><article key= “BK99”>

<editor>Ed Itor</editor><author>Bob Byte</author><author>Ken Key</author><title>Hacking & RSI</title>

</article></ bibliography >

Monet XML Model Results in higher degree of fragmentation

In our example, we have 11 tables Path is used to group semantically related

associations into the same relation. No need to scan the entire documents There is no need to introduce novel features on

the storage level to cope with irregularities induced by semi-structured nature of XML

The complete decomposition is linear in the size of the documents

Memory requirements is linear in the height of the syntax tree

Quantitative Assessments

Documents Size in XML Size in Monet XML #Tables Loading

ACM Anthology 46.6 MB 44.2 MB 187 30.4s

Shakespeare's Plays

7.9 MB 8.2 MB 95 4.5s

Database Size Resulting size of the decomposition scheme are a

critical issues In the worst case, the size of the path summary

can be linear in the size of the documents – if the documents are completely unstructured

In practical applications, there are generally large structured portions

The Monet XML version of the ACM anthology is of smaller size than the original documents

Reduction is due to the removal of redundancy occurring character data – and removal of tags

Comparison of Response Times Comparing Monet XML against SYU/Postgres SYU store all data on a single table and have to scan

these data repeatedly Monet transform yields smaller data volumes We have a set of 10 queries using Shakespeare's plays The substantial difference in response time shows that

Monet XML outruns the competitor by up to two orders of magnitude

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10

Monet XML

1.2ms 5.6 6.8 8.0 4.4 4.9 5.0 5.0 8.8 12.7

SYU 150ms 180 160 180 190 340 350 370 1300 1040

Summary

Presented a data model for efficient processing of XML documents

The experiences show that it is worth taking the plunge and fully decompose XML documents into binary associations

This approach combines the elegance of clear semantics with a highly efficient execution model by means of a simple and effective mapping between XML documents and a relational schema

XORator & Object-Relational DBMSs

Two Dominating Approaches

Use a native XML database engine for storing and querying data sets Provide a more natural data model and query

language for XML data – hierarchical or graph representation

Map the XML data and queries to constructs provided by Relational DBMS (RDBMS) XML data is mapped to relations, queries on XML

data are converted into SQL queries

RDBMS

Advantage user is not involved in the complexity of mapping it can be used for querying both XML data and data

that exists in the relational systems Disadvantage

it can lower performance since a mapping from XML data to the relational data may produce a database schema with many relations

queries on XML data when translated to SQL queries may have many joins, making the queries expensive to evaluate

In the Paper

Object-Relational DBMS (ORDBMS) Has all the advantages of an RDBMS More expressive type system than RDBMS Better suited for XML documents that may use a riche

r set of data types XORator Algorithm

Uses Document Type Definitions (DTDs) to map XML documents to tables in ORDBMS

New XML data type: XADT (XML Abstract Data Type)

Storing XML Documents in an ORDBMS – Reducing DTD Complexity

Apply transformations to reduce the number of nested expressions and the number of element items, making the mapping process easier Flattening (to convert a nested definition into a flat rep

resentation): (e1, e2)* → e1*, e2* Simplification (to reduce multiple unary operators into

a single unary operator): e1** → e1* Grouping (to group subelements that have the same n

ame): e0, e1*, e1*, e2 → e0, e1*, e2

e+ → e*

Reducing DTD Complexity (cont.)

Storing XML Documents in an ORDBMS – Building a DTD Graph

Storing XML Documents in an ORDBMS – XORator XML to OR Translator Algorithm builds on Hybrid Algorithm

If a non-leaf node N has exactly one parent, and if there are no links incident on any of the descendants of this node, then node N is assigned to an XADT attribute. (If node N is assigned to a relation, then queries on this node and its parent requires a join.)

XORator (cont.)

If a non-leaf node below a * node is accessed by multiple nodes, then it is assigned to a relation. (For nodes that are mapped to relations, the ancestors of these nodes must also be assigned as relations.) e.g. scene

If a leaf node is below a * node, then it is assigned as an attribute of the XADT. Otherwise, it is assigned as an attribute of string type. e.g. line

XORator (cont.)

Storing XML Documents in an ORDBMS – Defining an XML Data Type

Compressed representation for the XML fragment Element tags are mapped to integer codes, and

element tags are replaced by these integer codes. A small dictionary is stored along with the XML

fragment to record the mapping between the integer codes and the actual element tag names.

Compression is used only if the space efficiency is above a certain threshold value.

Defining an XML Data Type (XADT) (cont.) Methods on the XADT

XADT getElm(XADT inXML, VARCHAR rootElm, VARCHAR searchElm, VARCHAR searchKey, INTEGER level)

INTEGER findKeyInElm(XADT in XML, VARCHAR searchElm, VARCHAR searchKey)

XADT getElmIndex(XADT inXML, VARCHAR parentElm, VARCHAR childElm, INTEGER startPos, INTEGER endPos)

Defining an XML Data Type (XADT) (cont.)

Defining an XML Data Type (XADT) (cont.) Unnest Operator

Required when a query needs to examine individual elements in the set.

E.g. A distinct list of all speakers who speak in at least one play.

Implemented using a table User-Defined Function (UDF).

Defining an XML Data Type (XADT) – Unnest Operator (cont.)

Performance Evaluation

Randomly parse a few sample documents to obtain the storage space sizes in both uncompressed and compressed cases. Compressed format is chosen only if it reduces the storage space by at least 20%

Performance – Shakespeare Plays

XORator algorithm chooses not to use the compressed storage alternative.

The size of the database produced by the XORator algorithm is about 60% of the size of the database produced by the Hybrid algorithm.

Performance – Larger Data Set

Took the original Shakespeare data set and loaded it multiple times, producing data sets that were two, four and eight times the original database size (DSx2, DSx4, and DSx8).

Query sets: QS1: Flattening – list speakers and the lines that they speak QS2: Full path expression – retrieve the lines that have the

keyword “Rising” in the text of the stage direction QS3: Selection QS4: Multiple selections QS5: Twig with selection QS6: Order access

Performance – Larger Data Set

Much less loading times Significantly better execution ti

mes for all queries, except query QS6

All queries requested at least one few join

QS6 is slower because the database needs to scan the XADT attribute to extract elements in the specified order when using the XORator algorithm, while the Hybrid database needs to only extract the value of the element order attribute

Performance – SIGMOD Proceedings Data Set

Deep DTD – representative of the worst-case scenario for the XORator algorithm.

Compressed storage alternative is used – it reduces the database size by about 38%.

The size of the database produced by the XORator algorithm is about 65% of the size of the database produced by the Hybrid algorithm

Performance – Larger Data Set

Took the original SIGMOD Proceedings data set and loaded it multiple times, producing data sets that were two, four and eight times the original database size (DPx2, DPx4, and DPx8).

Query Sets QG1: Selection and extraction – retrieve the authors of the papers with

the keyword “join” in the paper title QG2: Flattening – list all authors and the names of the proceeding

sections in which their papers appear QG3: Flattening with selection QG4: Aggregation QG5: Aggregation with selection QG6: Order access with selection

Performance – Larger Data Set

When the size of data is small (DPx1 and DPx2), the XORator algorithm performs worse than the Hybrid algorithm.

When the size of data becomes large (DPx4 and DPx8), the XORator algorithm outperforms the Hybrid algorithm.

No table joins, but each query has 4 to 8 calls of UDFs to extract subelements or to join elements inside XADT attribute.

Analysis

The cost of invoking UDFs is significant component of the query evaluation of XORator algorithm.

Does UDF incur a higher performance penalty than an equivalent built-in function? Implement two string functions to return length and su

bstring using UDFs and built-in functions, and test the following queries.

QT1: Return the length of string in the SPEAKER attribute.

QT2: Return a substring of string in the SPEAKER attribute from the fifth position to the last position.

Analysis (cont.)

Using UDFs is about 40% more expensive than using built-in functions.

Analysis (cont.)

Invoking UDFs are expensive because:

XADT methods use string compare and copy functions on VARCHAR. This sometimes requires scanning a large amount of data.

Associate metadata with each XADT attribute to quickly access the starting position of each element.

Cost of evaluating UDF is higher compared to equivalent built-in function.

Implement XADT as a native data type

Performance

As the data size increases, the ratios of the response times between two algorithms become more than 1.

Queries using the XORator algorithm have no join and thus the response time grow at O(n) rate (scan cost), n = # of tuples

Queries using the Hybrid algorithm have many joins grow at either O(nlogn) rate (merge sort join cost), or O(n2) rate (nested loop join cost).

Summary

New algorithm: XORator New data type: XADT Outperforms Hybrid algorithm due to less j

oins Future work: Implementation and evaluatio

n of UDF

Conclusion

We presented some efficient models for storing and querying XML documentsMonet XML ModelXORator Algorithm

There is still a lot of work that needs to be done in order to bridge the gap between the structured web databases and semi-structured XML documents