XML Query Processing Talk prepared by Bhavana Dalvi ( ) Uma Sawant ( )

Structural Joins: A Primitive for Efficient XML Query Pattern Matching Al Khalifa, H. Jagadish, N. Koudas, J. Patel D. Srivastava, Yuquing Wu ICDE 2002

Motivation Query : book[title='XML'] //author[. ='jane']

Query Tree book[title='XML'] //author[.='jane']

Decomposition Of Query Tree

Evaluation of Query Matching each of the binary structural relationships against database. Stitching together these basic matches

Different ways of matching structural relationships Tuple-at-a-time approach ➢ Tree traversal ➢ Using child & parent pointers ➢ Inefficient because complete pass through data Pointer based approach ➢ Maintain (Parent,Child) pairs & identifying (ancestor,descendants) : Time complexity ➢ Maintain (ancestor,descendant) pairs : space complexity ➢ Either case is infeasible

Solution: Set-at-a-time approach Uses mechanism ➢ Positional representation of occurrences of XML elements and string values ➢ Element 3 tuple (DocId, StartPos:EndPos, LevelNum) ➢ String 3 tuple (DocId, StartPos, LevelNum)

Positional Representation

Structural Relationship Test (D1, S1:E1, L1) (D2, S2:E2, L2) Ancestor-Descendant ➢ D1 = D2, S1 < S2, E2 < E1 Parent-Child ➢ D1 = D2, S1 < S2, E2 < E1, L1 + 1 = L2

Goal Given ancestor-descendant (or parent-child) structural relationship (e1,e2), find all node pairs which satisfy this

Traditional merge join ➢ Does equi-join on doc-id ➢ Tests for inequalities on cross-product of two sets Multi-Predicate Merge Join (MPMGJN) ➢ MPMGJN uses Positional representation ➢ Better than traditional merge join ➢ Applies multiple predicates simultaneously ➢ Still lot of unnecessary computation and I/O Previous Approaches

Need of better I/O and CPU optimal algorithm

Solution: Structural Joins Set-at-a-time approach Uses positional representation of XML elements. I/O and CPU optimal

Structural Join To locate elements matching a tag: ➢ Index on Node (ElementTag, DocID, StartPos, EndPos, LevelNum) Index on ElementTag tag List : elements sorted by (DocID, StartPos, EndPos, LevelNum)

Structural Join Goal: join two lists based on either parent-child or ancestor-descendant Input : ➢ AList (a.DocID, a.StartPos : a.EndPos, d.LevelNum) ➢ DList (d.DocID, d.StartPos : d.EndPos, d.LevelNum) Output can be sorted by ➢ Ancestor: (DocID, a.StartPos, d.StartPos), or ➢ Descendant: (DocID, d.StartPos, a.StartPos)

Two families of structural join algorithms Tree-merge Algorithm : MPMGJN is member of this family Stack-tree Algorithm

Algorithm Tree-Merge-Anc Output : ordered by ancestors Algorithm : Loop through list of ancestors in increasing order of startPos ➢ For each ancestor, skip over unmatchable descendants ➢ check for ancestor-descendant relationship ( or parent-child relationship ) ➢ Append result to output list

Worst case for Tree-Merge-Anc

Analysis Ancestor-descendent relationship ➢ |Output List| = O(|AList| * |DList|) ➢ Time complexity is optimal O( |AList| * |DList| ) ➢ But poor I/O performance Parent-child relationship ➢ |Output List| = O(|AList| + |DList|) ➢ Time complexity is O (|AList| * |DList| )

Tree-Merge-Desc Algorithm Output : ordered by descendants Algorithm : Loop over Descendants list in increasing order of startPos ➢ For each descendant, skip over unmatchable ancestors ➢ check for ancestor-descendant relationship ( or parent-child relationship ) ➢ Append result to output list

Worst case for Tree-Merge-Desc

Analysis Ancestor-descendent relationship ➢ |Output List| = O( |AList| * |DList| ) ➢ Time Complexity : O( |AList| * |DList| ) Parent-child relationship ➢ |Output List| = O(|AList| + |DList|) ➢ Space and Time complexities are O (|AList| * |DList| )

Tree-Merge algorithms are not I/O optimal Repetitive accesses to Anc or Desc list

Motivation for Stack-Tree Algorithm Basic idea: depth first traversal of XML tree ➢ takes linear time with stack of size equal to tree depth ➢ all ancestor-descendant relationships appear on stack during traversal Main problem: do not want to traverse the whole database, just nodes in Alist or Dlist Solution : Stack-Tree algorithm ➢ Stack: Sequence of nodes in Alist

Stack-Tree-Desc Initialize start pointers (a*, d*, s->top) While input lists are not empty and stack is not empty ➢ if new nodes (a* and d*) are not descendants of current s->top, pop the stack ➢ else if a* is ancestor of d*, push a* on stack and increment a* else ➔ compute output list for d*, by matching with all nodes in current stack, in bottom-up order ➔ Increment d* to point to next node

Example of Stack-Tree-Desc Execution Alist : a1, a2,... DList : d1, d2,...

Step 1

Step 2

Step 3

Stack-Tree-Desc Analysis * Time complexity (for anc-desc and parent-child) O(|AList| + |DList| + |OutputList|) * I/O Complexity (for anc-desc and par-child) O(|AList| / B + |DList| / B + |OutputList| / B) ➢ Where B is blocking factor

Stack-Tree-Anc Output ordered by ancestors Cannot use same algorithm, as in Stack-Tree-Desc Basic problem: results from a particular descendant cannot be output immediately ➢ Later descendants may match earlier ancestor, hence have to be output first

Stack-Tree-Anc Solution: keep lists of matching descendant nodes with each stack node ➢ Self-list Descendants that match this node Add descendant node to self-lists of all matching ancestor nodes ➢ Inherit list Inherited from nodes already popped from stack, to be output after self-list matches are output

Algorithm Stack-Tree-Anc ● Initialize start pointers (a*, d*, s->top) ● While the input lists are not empty and the stack is not empty if new nodes (a* and d*) are not descendants of current s->top, pop the stack (p* = popped ancestor node) ➢ Append p*. inherit_list to p*. self_list ➢ Append resulting list to (s->top). inherit_list else ➢ if a* is ancestor of d*, push a* on stack and increment a* ➢ else Append corresp. tuple to self list of all nodes in stack Increment d* to point to next node

Example of Stack -Tree-Anc

Step 1 Step 2 Alist : a1, a2, a3 Dlist : d1, d2

Step 3

Step 4

Step 5

Final output is : (a1, d1), (a1, d2), (a2, d1), (a3, d2)

Stack-Tree-Anc Analysis Requires careful handling of lists (linked lists) Time complexity (for anc-desc and parent-child relation) O(|AList| + |DList| + |OutputList|) Careful buffer management needed

Performance Study

Data Set

Queries

Performance

Conclusion The performance of the traversal-style algorithms degrades considerably with the size of the dataset. Performance of STJD is superior compared to others (STJA, TMJA, TMJD).

ORDPATHs: Insert Friendly XML Node Labels Patrik O'Neil, Elizabeth O'Neil Shankar Pal, Istvan Cseri, Gideon Schaller, Nigel Westbury (SIGMOD 2004)

Motivation Previous schemes adequate for static XML data. But poor response for arbitrary inserts Relabeling of many nodes is necessary Hence if data is not static, need for an insert-friendly labeling method.

Traditional Methods for Positional Representation Dewey Order : Hierarchical scheme

Is independent of database schema Allows efficient access through Dewey List indexing But arbitrary inserts are costly. Dewey ID representation

Solution: ORDPATH Similar to Dewey ID Differs in initial labeling & encoding scheme Provides efficient insertion at any position in tree Encodes the path efficiently to give maximum possible compression Byte by Byte comparison : to get proper document order Supports extremely high performance query plans

Example

Initial Load: only positive and odd integers are assigned. Later Insertions: even-numbered and negative integer components

ORDPATH : Primary key Relational node table

Compressed ORDPATH Format L i : Length in bits of successive O i bitstring ➢ Uses prefix free encoding O i (Ordinal): Variable length representation of node depending on L i

L i /O i Pair Design ORDPATH = ”1.-9” L0 O0 L1 O Complex ORDPATH Format Table Of Length Li & Oi pairs

Comparing ORDPATH values Simple bitstring comparison yields document order Ancestor-descendent relationships –X is strict substring of Y implies that X is ancestor of Y

ORDPATH Insertions Insertions at extreme ends Right of all: Add 2 to last ordinal of last child Left of all: Add -2 to last ordinal of first child

Other insertions Arbitrary insertions: ➢ Careting in : Create a component with even ordinal falling between final ordinals of two siblings. ➢ Append with a new odd component ➢ Depth of tree remains constant

Example Adding a node under 5 between 5.5 & > ➢ Create a new caret 6 (5 < 6 < 7) ➢ New siblings are 5.6.1, 5.6.3,....

We can caret in entire subtree

Use of ORDPATH representation in Query plans

ORDPATH Primitives PARENT(ORDPATH X). ➢ Parent of X ➢ Remove rightmost component of X (odd) ➢ Remove all rightmost even ordinals ➢ e.g. PARENT( ) = (1.3) GRDESC(ORDPATH X) ➢ Smallest ORDPATH-like value greater than any descendent of X ➢ Increment last ordinal component of X ➢ e.g. GRDESC(1.3.1) = (1.3.2)

Secondary Indices Element and Attribute TAG index supporting fast look up of elements and attributes by name. Element and Attribute VALUE index supporting fast look up of elements and attributes by value

Query Plans Query : //Book//Publisher[.=”xyz”] Plan-1 : #descendants are small ➢ Retrieve all book elements(sec. Index on Attribute TAG) & all descendants (Using GRDESC(X)) Plan-2 : #descendants are large ➢ Separate sequences of Book & Publisher [value=”xyz”] (sec. Index on Attribute value) ➢ Join by ancestor//descendent

Query plans contd... Plan-3: #descendants are extremely small ➢ Start at publisher & look for a Book element as ancestor (Using PARENT(X))

Insert Friendly Ids Generate labels to reflect document order but not path information ➢ Pass through XML tree in document order. ➢ Generate single component L 0 /O 0 pairs with ordinals = 1, 3, 5, 7... ➢ Later insertions: ORDPATH careting-in Method --> Multiple even Oi components Short ID : Primary key in Node table No relabeling required on inserts

Example

Insert between 5 & 7

Insert children of 6.1

Conclusion Thus ORDPATH suggests an hierarchical naming scheme. Supports insertion of nodes at arbitrary positions without relabeling ORDPATH primitives along with secondary indices leads to efficient query plans

References Structural Joins: A Primitive for Efficient XML Query Pattern Matching, D. Srivastava, S. Al-Khalifa, H.V. Jagadish, N. Koudas, J.M. Patel, Y.Wu, ICDE ORDPATHs: Insert-Friendly XML Node Labels, Patrick E. O'Neil, Elizabeth J. O'Neil, Shankar Pal, Istvan Cseri, Gideon Schaller, Nigel Westbury, SIGMOD On Supporting Containment Queries in Relational Database Management Systems, Chun Zhang, Jerey Naughton, David DeWitt, Qiong Luon, Guy Lohmano, SIGMOD 2001.

Thank You !

Comparing ORDPATH values Simple bitstring comparison --> document order Ancestor-descendent relationships

ORDPATH Length Worst case: small fanout at each level (2) Proved result: ➢ Avg. depth P(n) of such tree obeys inequality : P(n) <= log 2 (n) ● If max. depth = d, max. degree = t then max. bitlength L of labels is bounded: d.log 2 (t) – 1 <= L <= 4dlog 2 (t)

Alternate Representation Of Li

Traditional Merge Join vs. MPMGJN

Performance Study Data Tree