1 / 41

TIMBER A Native XML Database

TIMBER A Native XML Database. The Overview of the TIMBER System in University of Michigan. Xiali He. Outline. Introduction Motivations and Related Work System Architecture Tree Algebra Query Evaluation Query Optimization Updates Issue. Introduction. Why Native XML Database?

pandora-athans
Télécharger la présentation

TIMBER A Native XML Database

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TIMBERA Native XML Database The Overview of the TIMBER System in University of Michigan Xiali He

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

  3. 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 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

  4. 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

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

  6. Motivations and Related Work • Mapping techniques between tree-based XML data to flat relational schema 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.

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

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

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

  10. System Architecture 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) • Node Identifier in Timber System: (S, E, L) – Start label, End Label, Level Label • Physical Storage Order: Sorted nodes by the value of start Labels.

  11. 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

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

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

  14. Tree Algebra - TAX Timber System develop a suite of operators suited to manipulating trees instead of tuples: • Selection • Projection • Ordering • Grouping • Product • Set Union • Set Difference • Renaming

  15. Pattern Tree Tree Algebra - TAX • 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. Pattern Tree Witness Tree

  16. Pattern tree can also associate element content etc – another example

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

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

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

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

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

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

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

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

  25. TAX group root • Apply the GROUPBY operator on the collection of trees generated from step 1. TAX group subroot TAX group basis article author article title year author title year author

  26. A projection is necessary to extract from intermediate grouping nodes necessary for the outcome. $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* $1 $2 $3 $4 $5 $6 5. Use rename operator to change the dummy root to the tag specified in the return clause.

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

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

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

  30. 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. Partial materialization is needed to minimize the size of the intermediate results being manipulated.

  31. Query Evaluation 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.

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

  33. Whole Stack-Tree Family of Structural Join Algorithm. merge Push AList DList stack

  34. Query Evaluation 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.

  35. 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.

  36. 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 Y- END 5(faculty) * 3(TA) = 15 Upper bound of number of matches = 2*2+1*3 = 7 faculty TA X-START

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

  38. 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!

  39. DISCUSSIONS Thank You!

More Related