TIMBER A Native XML Database Xiali He The Overview of the TIMBER System in University of Michigan

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue

Introduction Why Native XML Database?  Mapping between XML data and existing database has some problems due to the flexible nature of XML Results in an unnormalized relational representation Results in an unnormalized relational representation Results in large number of tables Results in large number of tables Challenges in TIMBER system:  Start from scratch  Retain XML data’s natural structures and flexibility and heterogeneity  Efficient processing on tree structures  Updates

Reuse the existing database technologies  Transaction Management Facilities  Declarative Querying  Set-at-a-time Processing Redesign and tailor certain components for the XML domain  Bulk Algebra – TAX  Query Evaluation  Query Optimization

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue

Motivations and Related Work Mapping techniques between tree-based XML data to flat relational schema Problems: Problems:  XML has very rich tree structure.  Relational has rigid table structure.  A simple tree schema produces complex relational schema with many tables.  A simple XML query get translated into expensive sequences of joins in relational database.

Other Direct XML data management systems:  Implementation Procedural  Tuple-at-a-time  Poor Performance On Top of object-oriented database and semi-structure database

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue System Study

System Architecture Data Storage Index Storage Metadata Storage Query Processing TIMBER- An efficient XML database engine

Data Storage Nodes in Timber System:  Node for each element  Child node for each sub-element  Child node for all attributes of an element  Child node for content of an element node  Child node for all processing instructions, comments. ( in future) ( in future) Node Identifier in Timber System: (S, E, L) – Start label, End Label, Level Label (S, E, L) – Start label, End Label, Level Label Physical Storage Order: Sorted nodes by the value of start Labels. Sorted nodes by the value of start Labels. System Architecture

Index Storage Indices in Timber System:  On attribute values  On element content  On tag name Index structure return lists of (S, E, L) labels (S, E, L) labels System Architecture

Metadata Storage Use histograms for cost estimation Timber is independent of XML schema System Architecture Query Processing

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue System Study

Tree Algebra - TAX Timber System develop a suite of operators suited to manipulating trees instead of tuples: SelectionProjectionOrderingGroupingProduct Set Union Set Difference Renaming

Pattern Tree XML: Can not reference the component of the tree by position or name! Solution: Pattern trees to specify homogeneous tuples of node binding. Witness tree is produced for each combination of node bindings that matches the pattern. Pattern tree can bind as many variables as there are nodes in the pattern tree. While XPath binds only one variable. Tree Algebra - TAX Pattern Tree Witness Tree

Pattern tree can also associate element content etc – another example

Selection Selection Tree Algebra - TAX C - Collection SL – Selection List P - pattern Output : is the witness tree induced by some embedding of P into C, modified as possibly prescribed in SL. (Lists nodes from P for which not just the nodes themselves, but all descendants, are to be returned in the output) More than just filter! Order is preserved!

Projection Projection Tree Algebra - TAX C - Collection PL – Projection List P - pattern Output : Could be zero, one or more output trees in a projection. (A list of node labels from P, possible with *)

Example - Projection $1 $2 $3 pc Pattern Tree $1.tag = faculty & $2.tag = RA & $3.tag = name PL: $1, $3 faculty RA name pc TA projection faculty name faculty name pc TA projection no match pc

Ordering Ordering Tree Algebra - TAX Timber system specify pattern trees to be unordered except where ordering constraints are explicitly specified!

Grouping Grouping Tree Algebra - TAX C - Collection OL - Ordering List P - pattern Output : Output tree Si corresponding each group Wi (witness tree) is showed in the next page. (compose an order direction and an element or element attribute, with values drawn from an ordered domain) GB - Grouping basis With the use of grouping, we can produce a simpler and mode efficient execution! (lists elements by label in P, whose value are used to partition the set W of witness tree of P against the collection C) Grouping may not induce a partitioning

tax_group_root tax_grouping_basis tax_group_subroot Output tree: Si one child for each element In the grouping basis roots of the input tree in C that corresponding to Wi

How to make FLWR execution more efficient by using grouping operator? FOR $a IN distint-value(document(“bib.xml”)//author) RETURN {$a} { FOR $b IN document(“bib.xml”)//article WHERE $a = $b/author RETURN $b/title }

1.Construct an initial pattern tree from the “inner” FLWR statement and consisting of bound variables and their paths from the document root. $1 $2 $1.tag = doc_root & $2.tag = articleAlgorithm: 2.Construct the input for the GROUPBY operator $1 $2 $1.tag = article & $2.tag = author pc

3.Apply the GROUPBY operator on the collection of trees generated from step 1. TAX group root TAX group basis TAX group subroot authorarticle titleyearauthortitleauthoryear

4.A projection is necessary to extract from intermediate grouping nodes necessary for the outcome. 5. Use rename operator to change the dummy root to the tag specified in the return clause. $1 $2 $4 $3 $5 $6 $1.tag = TAX Group root & $2.tag = TAX.Grouping basis & $3.tag = TAX group subroot & $4.tag = author & $5.tag = article & $6.tag = title PL: $1, $4*, $6*

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue

Query Evaluation Physical Algebra  Separation of physical algebra and logical algebra  Pattern Tree Reuse  Node Materialization Structural Joins in Pattern Tree Matching GroupBy

Physical Algebra Pattern Tree Reuse Query Evaluation $1 $3$4 $2 $1.tag = department& $2.tag = faculty & $3.tag = RA & $4.tag = name $1 $2 $1 $2 Isroot($1) & $2.tag = secretary $1.tag = PID1WID2 & $2.tag = secretary Find out the secretary for each faculty? Selection projection

Node Materialization Timber system has materialization in the physical algebra, which takes a node identifier(s) as input and returns a set of XML tree(s) that correspond. Timber system has materialization in the physical algebra, which takes a node identifier(s) as input and returns a set of XML tree(s) that correspond. Partial materialization is needed to minimize the size of the intermediate results being manipulated. Partial materialization is needed to minimize the size of the intermediate results being manipulated.

Structural Joins in Pattern Tree Matching For performance reason, full database scan is not be able to find all the matches in a single pass. Locate one node in each pattern match by indices and scan part of database is good but still expensive. Timber!- Use all available indices and independently locate candidates for as many nodes in pattern tree. Query Evaluation

Q: Seeking a faculty who has a secretary reporting to them

 Whole Stack-Tree Family of Structural Join Algorithm x AListDList stack Push merge

GroupBy RDBMS implement grouping rely on sorting (or hashing) Tree structure grouping not necessarily partition the set. So timber system use pattern tree to identify group list node and thus produce all possible tuples of bindings. Sorting (hashing) then can be performed by using them. Query Evaluation

Query Optimization Structural Join Order Selection  In relational query processing, it is almost good idea to evaluate selections first.  Not in XML! Since structural join may sometimes be more selective than selection predicate; Also, structural joins can be computed with node identifier alone, while selection predicate may require access to the actual data.  Finding the best fully pipelined evaluation plan by using algorithm FP-Optimization.

Result Size Estimation  Need an accurate estimate of the cardinality of the final query as well as each intermediate result for each query plan!  Position Histogram facultyTA X-START Y- END Upper bound of number of matches = 2*2+1*3 = 7 5(faculty) * 3(TA) = 15

Outline Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue

Update Issue Start and End label? (floating number) Changes in the sizes and numbers of elements could cause pages to overflow or underflow. Space management!

DISCUSSIONS Thank You!