1 / 22

XML Databases

XML Databases. Zachary G. Ives University of Pennsylvania CIS 650 – Database & Information Systems March 23, 2005. Administrivia. We’re moving beyond simple databases now… For Monday – read & compare focus of: Hanson: Scalable Trigger Processing Stanford STREAM processor For Wednesday:

donny
Download Presentation

XML Databases

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. XML Databases Zachary G. Ives University of Pennsylvania CIS 650 – Database & Information Systems March 23, 2005

  2. Administrivia • We’re moving beyond simple databases now… • For Monday – read & compare focus of: • Hanson: Scalable Trigger Processing • Stanford STREAM processor • For Wednesday: • Retrospective on Aurora

  3. Today’s Trivia Question

  4. XML: What Makes It Hard? • It’s not normalized… • It conceptually centers around some origin, meaning that navigation becomes central • Contrast with E-R diagrams • How to store the hierarchy? • Complex navigation • Updates, locking • Optimization • Also, it’s ordered • May restrict order of evaluation (or at least presentation) • Makes updates more complex • Many of these issues aren’t unique to XML • Semistructured databases, esp. with ordered collections, were similar • But our efforts in that area basically failed…

  5. XML: What’s It Good For? • Collections of text documents, e.g., the Web, doc DBs • … How would we want to query those? • IR/text queries, path queries, XQueries? • Interchanging data • SOAP messages, RSS, XML streams • Perhaps subsets of data from RDBMSs • Storing native, database-like XML data • Caching • Logging of XML messages • …?

  6. Lots of XML Research Out There • Text: • Hybrids of database and IR techniques for search • (e.g., Amer-Yahia & Shanmugasundaram, Weikum & Ramakrishnan, …) • Interchange: • Web service verification • XML stream processing • XML databases: • Natix, TIMBER, … • Tamino, DB2 UDB, Oracle, …

  7. The Main Focal Points • XML with documents • Inverted indices • Integration of ranking into DBMS • Interaction between structure and content • “Streaming XML” • RDBMS  XML export • Partitioning of computation between source and mediator • “Streaming XPath” engines • XML databases • Hierarchical storage + locking (Natix, TIMBER, BerkeleyDB, Tamino, …) • Query optimization

  8. Text-Based XML • The fundamental questions: • How should we model ranking in query processing? • Simply as another value (e.g., Amer-Yahia & Shanmugasundaram) • Using a probabilistic model or as an undefined metric • e.g., Weikum and Ramakrishnan work-in-progress • How does structure affect ranking? • PageRank-style (e.g., Shanmugasundaram et al.) • Query relaxation (FleXPath) • Other? • How do we achieve efficient pruning? • A* search [Cohen 98] • Fagin’s Threshold Algorithm • Custom logic? • How do we integrate keyword indexing with structural indexing? • Multiple indices (e.g., Lore, Natix, …) • Integrated indices (e.g., ViST)

  9. XML as a Wire Format • RDBMS  XML export • SilkRoute and Xperanto, outer unions • Interaction with RDBMS optimization techniques • Updates [Tatarinov+01] • Cascading updates are already possible in RDBMSs • Updating XML views • Streaming XML • SAX-based XPath-matching engines [Ives+01][Altinel&Franklin00][Green+02] [Diao&Franklin][Chen+] … • Push-down of XPath matching as early as possible • Query decomposition (still in need of a standard means of pushing XQuery to a source) • Subsets of XQuery that are amenable to streaming

  10. XML in a Database • Use a legacy RDBMS • Shredding [Shanmugasundaram+99] and many others • Path-based encodings [Cooper+01] • Region-based encodings [Bruno+02][Chen+04] • Order preservation in updates [Tatarinov+02], … • What’s novel here? How does this relate to materialized views and warehousing? • Native XML databases • Hierarchical storage (Natix, TIMBER, BerkeleyDB, Tamino, …) • Updates and locking • Query optimization (e.g., that on Galax)

  11. Query Processing for XML • Why is optimization harder? • Hierarchy means many more joins (conceptually) • “traverse”, “tree-match”, “x-scan”, “unnest”, “path”, … op • Though typically parent-child relationships • Often don’t have good measure of “fan-out” • More ways of optimizing this • Order preservation limits processing in many ways • Nested content ~ left outer join • Except that we need to cluster a collection with the parent • Relationship with NF2 approach • Tags (don’t really add much complexity except in trying to encode efficiently) • Complex functions and recursion • Few real DB systems implement these fully • Why is storage harder? • That’s the focus of Natix, really

  12. The Natix System • In contrast to many pieces of work on XML, focuses on the bottom layers, equivalent to System R’s RSS • Physical layout • Indexing • Locking/concurrency control • Logging/recovery

  13. Physical Layout • What are our options in storing XML trees? • At some level, it’s all smoke-and-mirrors • Need to map to “flat” byte sequences on disk • But several options: • Shred completely, as in many RDBMS mappings • Each path may get its own contiguous set of pages • e.g., vectorized XML [Buneman et al.] • An element may get its 1:1 children • e.g., shared inlining [Shanmugasundaram+] and [Chen+] • All content may be in one table • e.g., [Florescu/Kossmann] and most interval encoded XML • We may embed a few items on the same page and “overflow” the rest • How collections are often stored in ORDBMS • We may try to cluster XML trees on the same page, as “interpreted BLOBs” • This is Natix’s approach (and also IBM’s DB2) • Pros and cons of these approaches?

  14. Challenges of the Page-per-Tree Approach • How big of a tree? • What happens if the XML overflows the tree? • Natix claims an adaptive approach to choosing the tree’s granularity • Primarily based on balancing the tree, constraints on children that must appear with a parent • What other possibilities make sense? • Natix uses a B+ Tree-like scheme for achieving balance and splitting a tree across pages

  15. Split point in parent page Example Note “proxy” nodes

  16. That Was Simple – But What about Updates? • Clearly, insertions and deletions can affect things • Deletion may ultimately require us to rebalance • Ditto with insertion • But insertion also may make us run out of space – what to do? • Their approach: add another page; ultimately may need to split at multiple levels, as in B+ Tree • Others have studied this problem and used integer encoding schemes (plus B+ Trees) for the order

  17. Does this Help? • According to general lore, yes • The Natix experiments in this paper were limited in their query and adaptivity loads • But the IBM guys say their approach, which is similar, works significantly better than Oracle’s shredded approach

  18. There’s More to Updates than the Pages • What about concurrency control and recovery? • We already have a notion of hierarchical locks, but they claim: • If we want to support IDREF traversal, and indexing directly to nodes, we need more • What’s the idea behind SPP locking?

  19. Logging • They claim ARIES needs some modifications – why? • Their changes: • Need to make subtree updates more efficient – don’t want to write a log entry for each subtree insertion • Use (a copy of) the page itself as a means of tracking what was inserted, then batch-apply to WAL • “Annihilators”: if we undo a tree creation, then we probably don’t need to worry about undoing later changes to that tree • A few minor tweaks to minimize undo/redo when only one transaction touches a page

  20. Annihilators

  21. Assessment • Native XML storage isn’t really all that different from other means of storage • There are probably some good reasons to make a few tweaks in locking • Optimization stays harder • A real solution to materialized view creation would probably make RDBMSs come close to delivering the same performance, modulo locking

  22. Questions • Where are the main challenges of XML processing at this point? • Impact of BinaryXML? • Are we working on the right problems? What’s XML going to be used for, anyway?

More Related