XML Databases
Zachary G. IvesUniversity 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:
1. 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-progress2. How does structure affect ranking?
PageRank-style (e.g., Shanmugasundaram et al.) Query relaxation (FleXPath) Other?
3. How do we achieve efficient pruning? A* search [Cohen 98] Fagin’s Threshold Algorithm Custom logic?
4. 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
Example
Split point in parent page
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?