Storing Semi-structured Data on Disk Drives 1mbhadkam/Medha-semi-structured.pdf2 · Medha Bhadkamkar...

Storing Semi-structured Data on Disk Drives 1

MEDHA BHADKAMKAR, FERNANDO FARFAN, VAGELIS HRISTIDIS, and RAJU

RANGASWAMI

Florida International University

Applications that manage semi-structured data are becoming increasingly commonplace. Currentapproaches for storing semi-structured data use existing storage machinery - they either map thedata to relational databases, or use a combination of flat files and indexes. While employingthese existing storage mechanisms provide readily available solutions, there is a need to moreclosely examine their suitability to this class of data. Particularly, retrofitting existing solutionsfor semi-structured data can result in a mismatch between the tree structure of the data and theaccess characteristics of the underlying storage device (disk drive). This study explores variouspossibilities in the design space of native storage solutions for semi-structured data by exploringalternative approaches that match application data access characteristics to those of the under-lying disk drive. For evaluating the effectiveness of the proposed native techniques in relation tothe existing solution, we experiment with XML data using the XPathMark benchmark. Extensiveevaluation reveals the strengths and weaknesses of the proposed native data layout techniques.While the existing solutions work really well for deep-focused queries into a semi-structured docu-ment (those that result in retrieving entire subtrees), the proposed native solutions substantiallyoutperform for the non-deep-focused queries, which we demonstrate are at least as importantas the deep-focused. We believe that native data layout techniques offer a unique direction forimproving the performance of semi-structured data stores for a variety of important workloads.However, given that the proposed native techniques require circumventing current storage stackabstractions, further investigation is warranted before they can be applied to general purposestorage systems.

Categories and Subject Descriptors: D.4.2 [OPERATING SYSTEMS]: Storage Management

General Terms: Architecture, Design, Algorithms, Performance

Additional Key Words and Phrases: Semi-structured data, Storage management, XML

1. INTRODUCTION

An increasing number of applications manage large amounts of semi-structureddata. Common applications that use semi-structured data today include Bioinfor-matics sequence search and alignment [Delcher et al. 1999], genomic data analy-sis [Rokhsar 2007], multi-resolution video storage [Finkelstein et al. 1996], clinicaldata systems [CDA 2007], XML databases, and more [Papakonstantinou et al.1995]. Given that a semi-structure such as a tree provides a more intuitive way ofmanaging large amounts of data, the trend of storing data in such formats is likelyto strengthen in the future.

Current approaches to store semi-structured data either map the data to an un-derlying relational database system (e.g., [Bohannon et al. 2002; Deutsch et al. 1999;Mergen and Heuser 2004; Ramanath et al. ; Shanmugasundaram et al. ]), use the

1This work is sponsored in part by NSF grant IIS-0534530 and DoE grant ER25739. Author’saddresses: M. Bhadkamkar, F. Farfan, V. Hristidis, and R. Rangaswami, School of Computing andInformation Sciences, Florida International University, 11200 S.W. 8th Street, Miami FL 33199,email: [email protected], [email protected], [email protected], [email protected].

ACM Transactions on Storage, Vol. V, No. N, Month 20YY, Pages 1–0??.

2 · Medha Bhadkamkar et. al.

abstraction provided by a general-purpose object storage manager [Carey et al.1994], or use a combination of flat files and indices (e.g., XALAN [Xalan 2007],XT [XT 2007], Galax [Galax 2007], BLAST [Altschul et al. 1990], Timber [Ja-gadish et al. 2002] and Natix [Kanne and Moerkotte 2006]). Since these approachesretrofit existing storage mechanisms to work with semi-structured data, their scopeis restricted to the underlying mechanisms, which are predominantly optimized forsequential accesses. Consequently, these approaches may result in a mismatchbetween the structure and navigational primitives of semi-structured data and theaccess characteristics of disk drives. In particular, semi-structured data have atree (or graph) structure with tree-type operations. Relational databases, on theother hand, store structured tables that are optimized for row-based access, andflat files are unstructured, optimized for sequential access. Further complicatingthis mismatch, the underlying storage device, i.e. disk drives, store informationin circular tracks that are accessed with mechanical seek and rotational overhead.Given the growing amount of semi-structured data, there is a need for re-examiningthe current storage and access machinery that support them.

In this paper, we explore strategies to optimize the storage and retrieval of semi-structured data on disk drives by explicitly accounting for the mismatch betweenthe structure of the data and the disk drive storage and access characteristics.In particular, we present algorithms that given the physical characteristics of adisk drive (number of tracks, sectors per track and rotational speed.), place semi-structured data on the disk drive in a way that facilitates navigation of the data byreducing access overheads. Such low-level control of data layout is made possibleusing information provided by standard disk profiling tools [Worthington et al.1995; Talagala et al. 1999; Dimitrijevic et al. 2004].

The proposed technique first addresses the problem of grouping nodes of semi-structured data trees so that they can be mapped to disk blocks. We develop andexperimentally evaluate our proposed grouping strategies and compare it with theEnhanced Kundu Misra (EKM) grouping strategy [Kanne and Moerkotte 2006].Second, our proposed on-disk layout strategy for node groups optimizes commontree navigation operations such as parent-to-child and node-to-next-sibling traver-sals. Our on-disk layout strategies make use of semi-sequential disk access tech-nique [Schindler et al. 2004] that allows the reduction and even elimination ofrotational delay overhead during disk accesses.

Given that our approach requires circumventing the prevalent logical block ab-straction, applying our layout strategy to a general purpose storage system is notstraightforward.2 Our goal in this paper is simply to expose the merits and demer-its of this approach. Through experiments we show that our proposed approachis superior for a dedicated single-user storage system with standard caching andprefetching capabilities – for instance, a specialized system for analysis of biologi-cal data (suffix trees) [Bedathur and Haritsa 2006]. Based on this study, we believethat our approach provides a fresh perspective on the problem of storing semi-structured data that is worth the attention and research time of the community.

To evaluate the proposed native data layout techniques, we used XML as a case

2Prior research has made a similar argument in favor of fine-grained data layout by circumventingthe logical block abstraction, for the case of tabular data [Schindler et al. 2004].

ACM Transactions on Storage, Vol. V, No. N, Month 20YY.

Storing Semi-structured Data on Disk Drives · 3

study. XML is becoming increasingly popular due to its ability to represent arbi-trary semi-structured data. It is the de facto data representation format for manymodern applications, including Geographic Information Systems Markup Language(GML) [GML 2008], Medical Markup Language (MML) [MML 2008], Health LevelHL7 [HL7 2008], Clinical Document Architecture (CDA) [Dolin et al. 2006] used torepresent Electronic Health Records (EHRs), Open Document Format (ODF) [ODS2008; OOX 2008], and Scalable Vector Graphics (SVG) [SVG 2008] used to describetwo-dimensional graphics and graphical applications. Despite the widespread useof XML, the challenge of optimizing access to XML data stores is a key challengealso identified in the latest report [Abiteboul et al. 2005] on the future directions ondatabase research, published every few years by the database research community.

Table I. Query classification of popular XML benchmarks.

Benchmark Workload Document Total # Non-deep- # Deep-size queries focused focused

TPoX Financial app 2 - 25 KB 11 4 7XMach-1 E-commerce app 2 - 100 KB 7 4 3XMark Auction Website 10MB - 10 GB 20 13 7XPathMark Education app 10MB - 10GB 54 20 34XOO7 Web app 4MB - 1GB 23 4 19XBench Publications DB 1KB - 10 GB 17 11 6MemBeR Synthetic 11 MB 7 0 7MBench Synthetic 50MB - 50GB 37 37 0

Total 176 93 83

Recent surveys of popular XML benchmarks [Afanasiev and Marx 2006; Bohmeand Rahm 2003; Nambiar et al. 2001] show that all queries to XML data can beclassified into deep-focused and non deep-focused queries. In Table I, we summarizethe key XML benchmarks available in the public domain. The Transaction Process-ing over XML (TPoX) benchmark [Nicola et al. 2007] evaluates the performanceof XML stores, XML databases, indexes, etc. by generating a mix of XQueries forvarious financial transactions on the generated XML documents. XMach-1 [Bohmeand Rahm 2001; 2003], XOO7 [Bressan et al. ], XMark [Schmidt et al. 2002a]and XPathMark [Franceschet 2005] are typically used to evaluate query optimiza-tions in XML. XMach-1 is based on an E-commerce website while XMark gener-ates queries for an E-commerce website with information on bids, items, brokersand customers. XPathMark [Franceschet 2005] is an XPath based benchmark forXMark and generates an educational document that represents the English alpha-bet. The XBench [Yao et al. 2003] benchmark is an application oriented benchmarkfor XML databases. Finally, the MemBer [Afanasiev et al. 2005; Manolescu et al.2006] and the Michigan Benchmark (MBench) [Runapongsa et al. 2003] are bothmicro-benchmarks that generate synthetic workloads wherein document structurecan be finely controlled (varying their depth and fan-out) so as to be able to repro-duce the access patterns of a variety of different real-world workloads.

This collection of well-accepted and standardized XML benchmarks demonstrate(i) that XML document sizes can be fairly large running sometimes into tens ofgigabytes; this combined with the fact that XML parsers can consume as much as



5X the amount of main memory during parsing as the original size of the XMLdocument [Nicola and John 2003] implies that secondary storage accesses must beoptimized if at all possible, and (ii) that the non deep-focused queries, form atleast half of the total queries suggested within these popular XML benchmarks ;this implies that optimizing accesses to the non-deep-focused query class is at leastas important as optimizing for the deep-focused class. Further, in the event thata workload generates both classes of queries with similar frequency, the storagesystem could conceivably store data using both the traditional approach and tree-based approach with the caveat that this approach requires more consideration forwrite-dominant workloads that can incur an unacceptable amount of overhead formaintaining consistency.

For evaluating our native layout proposals, we employ XPath queries [XPath2007] obtained from the XPathMark benchmark for the evaluation. We examinethe relative performance of native layout against the default approach, which storesXML files sequentially. To do so, we augmented an existing XML parsing engineto implement the grouping techniques that we propose. To evaluate disk I/O per-formance, we use an instrumented DiskSim disk simulator [Bucy et al. 2003] andreplayed the block access traces generated by XML query processing engines. Ourevaluation also addresses I/O performance in the presence of query parallelism aswould be typical for server environments. Summarizing, these experiments revealthat while the default sequential layout provides superior performance for the deep-focused class of XML queries (or access patterns retrieving entire subtrees of semi-structured data), the proposed native layout techniques outperform the default forall other query access patterns.

The rest of the paper is organized as follows. Section 2 presents the architectureof a native semi-structured storage system and the model used for semi-structureddata and their access. In Section 3, we present native data-layout strategies forsemi-structured data on disk drives. In Section 4, we present strategies for orga-nizing and grouping nodes in the tree so that they can be mapped to disk blocks.In Section 5 we conduct a theoretical analysis of the performance impact of datalayout. In Section 6, we evaluate the proposed approach for the case of XML databy comparing it against the default sequential layout. We survey related work inSection 7. We conclude and discuss future directions in Section 8.

2. SYSTEM ARCHITECTURE AND DATA MODEL

In this section, we propose an architecture for building a native semi-structuredstorage system which allows the use of our layout techniques with minimal changesto the current storage stack. We also present the semi-structured data and accessmodel abstractions.

2.1 Modifying the Storage Stack

Modern disk drives provide a high-level logical block abstraction to the operatingsystem, which does not export information about the physical data layout, per-formance characteristics, and internal operation of the disk drive. We propose amodified storage stack inside the operating system that will facilitate native datalayout strategies by including mechanisms to effect low-level data layout.

The lowest levels of the current storage stack (shown in Figure 1(a)) form the



Application

Filesystem DB Engine

DB APIFS API

Storage Device(s)

Block I/O InterfaceDevice Driver

Storage Network

Sto

rage

Sub

syst

em(a) Current Stack

Application

Filesystem* DB Engine*

DB APIFS API

Storage Device(s)

Block I/O InterfaceDevice Driver

Storage Network

Sto

rage

Sub

syst

em

SSS EngineSSS Interface

DatapathNon−SSS

(b) Proposed Stack

Fig. 1. Storage stack modification.

storage subsystem, which exports a logical block I/O interface. The dominantstorage mechanisms, i.e., databases and file systems, form the middle layer thataccesses data on the storage device(s) using the logical block interface while alsoproviding high-level APIs for applications. These storage mechanisms are optimizedfor relational data and sequential files respectively.

The proposed storage stack (Figure 1(b)) builds a native Semi-Structured Storage(SSS) engine on top of the block I/O interface to provide native storage and accesssupport for semi-structured data. The SSS engine employs disk profiling to performnative data layout on a reserved contiguous area (partition) of the disk drive. Stor-age access modules (File system, DB Engine, etc.) need to be minimally modifiedto use the SSS interface in order to efficiently store and retrieve semi-structureddata, or bypass it for non-semi-structured data. We chose not to build-in nativesupport into an existing file system or existing DBMS, because we believe that theSSS engine as well as its interface can be made generic enough to work with anystorage access module. Existing file and database systems can then be extendedwith native layout support for semi-structured data via the SSS engine. While theproposed approach call for significant changes to the operating system storage man-agement, it is important to point out that applications retain their original interfaceto the operating system and remain transparent to the underlying mechanisms.

2.2 Data and Access Model

We view a semi-structured document as a labeled tree T , where each node v hasa label λ(v), which is a tag name for non-leaf nodes and a value for leaf nodes.Also, non-leaf nodes v have an optional set A(v) of attributes, where each attributea ∈ A(v) has a name and a value. Note that our layout technique can also beapplied to documents with cycles (e.g., ID-IDREF edges for XML documents);however, the navigation on such edges has not been optimized.



root

Book [title = “ XML Databases”, year= 2002 ]

Chapter [title= “ XML Introduction” ]

Chapter [title= “ Semistructured Data” ]

Chapter [title= “ Implementation

Issues” ]

Section [title= “ Concurrency” ]

Section [title= “Converting to

XML ” ]

Chapter [title= “ Conclusions” ]

Chapter [title= “ Overview” ]

Section [title= “ Hard Disks” ]

Section [title= “ Main Memory” ]

Section [title= “ Conclusions” ]

Chapter [title= “ Introduction” ]

Chapter [title= “ XPath” ]

Chapter [title= “Conclusions ” ]

Section [title= “ Discussion” ]

Section [title= “ Open Issues” ]

Book [title = “ Storage Principles”, year= 2001 ]

Book [title = “ XML Queries”, year= 2002 ]

Fig. 2. A sample semi-structured document.

Q

N

J

M

O P

A

I

K L R SGF

C D E H

B

1

2

3 5

6

7

4

Fig. 3. Tree structure for the XML document in Figure 2.

Figure 2 shows an example of a semi-structured document (in this case an XMLdocument) and Figure 3 shows the corresponding tree structure.

In the default layout strategy as is employed by current day file systems, the semi-structured data (say an XML document) is stored sequentially on the disk, whichis equivalent to placing the tree in depth-first order. To ensure a fair comparisonof our storage method to the default layout, a physical pointer is added from eachnode to its first child and its right sibling, thereby allowing to avoid reading theentire subtree of a node to access its right sibling. This optimization is used for thedefault strategy in all the experimental results we report.

For XML data, which we use as a case-study for evaluating our approach, XPathqueries form the core navigation component of XML query processing systems.For evaluating XPath queries, we adopt the “standard” XPath evaluation strategy[Gottlob et al. 2002] shown in Figure 1. Intuitively, this strategy processes an XPathquery Q in a depth-first manner on the XML document, one step of Q (Q.first) ata time, and stores the intermediate results in a set S. In [Bhadkamkar et al. 2006]we explain how optimizing XPath also leads to optimized XQuery.

Current implementations of XML parsers create an in-memory document treestructure that is populated (on-demand in some implementations [Noga et al. 2002])by retrieving corresponding sections of the disk-resident XML document. XML



stores typically handle documents that are both smaller (i.e., tens of KB) as well asmuch larger size (several GB). Consequently, trivial solutions such as loading theentire XML document in memory prior to parsing are not deemed practical.

Algorithm 1: Standard XPath evaluation strategy [Gottlob et al.2002]

1: procedure process-location-step(n0,Q)2: /* n0 is the context node;3: query Q is a list of location steps */4: node set S := apply Q.first to node n0;5: if Q.tail not empty then6: for each node n in S do7: process-location-step(n, Q.tail)8: end for9: end if

3. SEMI-STRUCTURED DATA LAYOUT

In this section, we present disk layout strategies for semi-structured data. First,we introduce a basic tree-structured placement strategy, a simple strategy whichillustrates the basic ideas of our approach. Next, we present an improved andoptimized variant of the basic strategy, which addresses the shortcomings of thebasic strategy. Finally, we discuss some practical challenges that must be addressedwhen implementing the proposed placement strategies.

3.1 Basic Tree-structured Placement

A key limitation of the default storage method is that it is optimized only for ac-cessing the semi-structured data tree in depth-first order since it places the data filesequentially on disk. For example, for the tree in Figure 3 (created by replacing thelabels with node IDs in the semi-structured tree of Figure 2), the nodes would bestored sequentially in alphabetical order. We refer to this henceforth as the defaultlayout and use it for comparison purposes in Section 6. If this file is accessed instrictly depth-first order, such a placement scheme would be optimal. However,typical tree navigation during the answering of queries displays the following char-acteristics: (a) nodes are accessed along any path from the root to a leaf of the tree,and (b) siblings are often accessed together, without accessing their descendants.The default layout of the nodes would result in random accesses (and thereforepoor I/O performance) for both the above accesses, except for the leftmost path ortraversals along leaf levels.

Based on the above observations, we design our basic layout strategy, tree-structured placement. To simplify the presentation of the algorithm we assumethat each node in the tree occupies an entire disk block. This assumption is relaxedin Section 4 where we discuss in detail the grouping methods that can be employedto minimize internal fragmentation within disk blocks while maintaining the treestructure of the file.



In the basic tree-structured placement, nodes are placed on the disk starting fromthe outermost available track (we choose the outermost track due to its higherbandwidth, favoring the more frequently accessed higher levels of the tree). Inparticular, we first place the root node v on the block with the smallest logical-block-number (LBN), on the outermost available track of the disk. Second, weplace its children sequentially on the next free track such that accessing the firstchild u of v after accessing v results in a semi-sequential access [Schindler et al.2004]. This is accomplished by choosing a block for u rotationally skewed from vsuch that when accessing u after accessing v, the rotational delay incurred is zero.Further, accessing a non-first child from a parent node involves a semi-sequentialaccess to reach the first child and a short rotational-delay based on the child index.The children of the first-child of the root node are then placed on the next availabletrack, once again at a rotationally-optimal point relative to their parent. Next, thegrandchildren of the first child of the root are placed following a similar approach,and so on.

A

B

I

NC

E

H

D

RS

*

*

*

*

*

*

*

**

***

*

*

*

*

****

*

*

*

*

*

** * *

*

*

*

*

**

**

*

*****

*

*

**

**

* *

O

P

Q

G

*

**

F

*

J

KM L

Fig. 4. Basic tree-structured placement strategy.

As described above, the basic tree structured layout chooses parent nodes toplace their respective children in depth-first order (DFO). We also experimentedwith breadth-first-ordering (BFO) in choosing parents, but found DFO to consis-tently outperform in the experiments due to its significantly shorter seek timesduring parent-child traversals. Intuitively, this can be visualized in Figure 3 wherewe present the DFO numbering for parent nodes (above each node); notice thelocalization of the numbers within each subtree. The BFO ordering, on the otherhand, scatters numbering over the entire tree, resulting in large seek times forparent-child traversals.

Example 3.1. Figure 4 shows the layout of the tree of Figure 3 on a disk platter.To simplify presentation, we assume that the disk has a single platter with a singlesurface (and consequently a single disk head). Furthermore, we assume that therotational skew between tracks is the seek-distance × quarter-rotation. The rootnode A is placed on the outermost track, track 0. Its first child B is placed on thefirst available free track closest to A, i.e., track 1. The block on which B is placed



Algorithm 2: Basic Placement AlgorithmAuxiliary Methods:Node GetNextNode()

/* returns one node at a time in ascending order */Track GetFirstFreeTrack()/* smallest free track */

Place(track t, LBN lbnFirst,NodeList L)/* place children nodes L starting from lbnFirst on track t */

LBN FindSemiSequential(LBN parent, int t)/* returns the LBN n on track t such that

access to t from parent is semi-sequential. */

Require: Tree T to be placed1: PlaceInTrack(GetFirstFreeTrack(),0,Root(T))2: while more nodes do3: n←(GetNextNode())4: t←(GetFirstFreeTrack())5: L← empty

6: L←(Add(Children(n)))7: lbnFirstChild← (FindSemiSequential(n.lbn, T))8: Place(t,lbnFirstChild, L)9: end while

is rotationally skewed by a quarter-rotation relative to A as a consequence of ourassumption. Accessing B after A would require only seeking to the next track. Theremaining children of node A, i.e. I, and N, are placed sequentially next to thefirst child B. The asterisked blocks in each track immediately before the first-childrepresent the rotational skew between a parent and its first-child. The remainingnodes are placed following a similar approach to complete the placement of the tree.

Algorithm 2 outlines the procedure for tree-structured placement. Notice thatthe leaf nodes of the tree T shown in Figure 3 are not numbered in the ordering andhence are not returned by getNextNode(), which is when the placement algorithmterminates.

3.2 Optimized Tree-structured Placement

The basic layout strategy, as is obvious in Figure 4, results in severe externalfragmentation of disk space (internal fragmentation within a disk block is discussedin Section 4), which also increases the average seek time of I/O operations. We nowdescribe an optimization of the basic tree-structured layout strategy that reducesexternal fragmentation as well as random seek times drastically.

The key idea in the optimized tree-structured placement is the use of non-freetracks for placing the children for a given parent node. The optimized placementstrategy is less restrictive than the basic tree-structured placement strategy in twospecific ways: (1) it allows placing children on a non-free track, and (2) it doesnot require the first-child to be placed at the rotationally-optimal block, but ratherallows placing the first-child anywhere within a rotationally-optimal track-region asdefined next.

We define a track-region as a contiguous list of Ntr disk-blocks along a track. Theblocks within a track-region, therefore, are also sequential in the logical addressspace (LBN space) of the disk. Given a parent node u and a target track t, we



define the rotationally-optimal track-region for u on track t as the track-region ofsize Ntr blocks starting from the block where the disk head lands when seeking totrack t starting from u. In Figure 5, two rotationally-optimal track-regions (Ntr=6)for parent node ‘S’ are marked using the # symbol. To place the children nodes fornode u, a set of candidate rotationally-optimal track-regions are chosen close to u,which can lie in either side of the parent track. The optimized placement algorithmchooses the track-region closest to u with sufficient free space to house the childrenof u. Other than this variation, the optimized tree-structured placement algorithmproceeds to place the tree similar to the basic placement algorithm.

In the above placement description, the choice of the rotationally-optimal track-region size (Ntr) is a critical factor. Increasing the track-region size gives theplacement algorithm more opportunity to reduce fragmentation and consequentlyreduce random-seek overhead between node accesses, but it also increases the av-erage rotational delay incurred during parent-to-child node-traversals. This is animportant trade-off to be considered when choosing Ntr. In our experiments, wechoose Ntr as a quarter of the track-size.

A

C

D

E

H

F G

B

I

N

KL

M

R

SJ

O

Q

P

##

#

#

#

#

##

#

#

#

#

Fig. 5. Optimized Strategy.

Figure 5 shows the layout of the tree in Figure 3 on a hard disk (platter) usingthe optimized strategy. Again, we assume that the platter rotates in the clockwisedirection. The assumptions of track skew are also the same as for the basic strategy.In the optimized placement, since a single track can contain the children of sev-eral nodes, the external fragmentation (shown in Section 6) is drastically reducedcompared to the basic tree-structured placement.

The PlaceInTrack method in Algorithm 3 outlines the logic for optimized tree-structured placement. Line 1 places the root node of the tree T on the outer-most track. Lines 2-7 place the children of the next node (which is the rootnode in the first iteration) on the rotationally-optimal track-region (returned byFindRotTrackRegion). The next node is returned by getNextNode(), which re-turns a non-leaf node of the XML tree based on the chosen ordering scheme. Theabove process is repeated until all the nodes are placed on the disk.



Algorithm 3: Optimized Placement AlgorithmAuxiliary Methods:Track GetTrack(LBN)

/* returns the track for LBN */LBN FreeTrackRegionStart(LBN, int, tracksToSkip)/* Given a parent LBN, its number of children, and the number of tracks to skip, returns

the LBN for the first child if all children can be placed in the candidate tracksrotationally-optimal track-region. Otherwise returns NULL. Candidate tracks are

the two tracks situated at parentTrack +/- tracksToSkip respectively. */

1: <Track,LBN> FindRotTrackRegion(LBN parent, int n)2: tracksToSkip ← 13: parentTrack ← GetTrack(parent)4: while true do5: if lbnFirstChild←FreeTrackRegionStart(parent,n,tracksToSkip) != NULL then6: return <GetTrack(lbnFirstChild),lbnFirstChild>

7: end if8: tracksToSkip++9: end while

Require: Tree T to be placed1: PlaceInTrack(getFirstFreeTrack(),0,root(tree))2: while more nodes do3: n←GetNextNode()4: L←empty5: L→add(children(n))6: <lbnFirstChild>←FindRotTrackRegion(n.lbn,L.size())7: Place(target,lbnFirstChild,L)8: end while

Notice that the leaf nodes of T are not numbered in the ordering and henceare not returned by getNextNode(). The findRotTrackRegion(LBN parent,int

nchildren) auxiliary method checks for availability of space in the rotationallyoptimal track-regions in tracks on either side of the parent’s track, starting fromthe closest track. It returns the LBN for placing the first-child of the parent

node. The remaining children are placed incrementally following the first child.The direction identifier specifies where the target track lies with respect to theparent. If the direction has a negative value, the target track is less than theparent track. Likewise, a positive value indicates that the target track is greaterthan the parent track.

3.3 Implementation Issues

In implementing the strategies presented above, several practical issues must beconsidered. First, the above placement scheme assumes that a single, contiguouspartition, large enough to accommodate the semi-structured data is available. Thisassumption is realistic for both file systems and database systems since they typ-ically allocate a large contiguous disk partition and can reserve a fraction of thisspace for storing semi-structured data.

Second, after a tree node is read from the disk drive, a non-negligible CPUthink time is typically required before the next I/O request is issued. We addressthis issue as follows. If the next request is for a sibling node (stored sequentiallyin our approach), then on-disk pre-fetching mechanisms ensure that this node is



pre-fetched into the on-disk cache. However, if the next request is for a childnode (stored semi-sequentially), then during computation time, the disk wouldhave already rotated by an amount proportional to the CPU think time and henceno semi-sequential access would be possible. To address this, we skew the first childby an additional rotational delay equivalent to 95th percentile of a sample from thethink time distribution. This ensures that in most cases, the semi-sequential natureof child node accesses will be preserved.

Third, the proposed strategy would work well when processing a single queryat a time. However, if there are multiple queries issued concurrently by differentprocesses or users, then the resulting interleaving I/Os are likely to degrade sequen-tial or semi-sequential accesses to random ones. This problem is prominent evenin traditional relational database and filesystem accesses. Techniques at the diskscheduling layer such as anticipatory scheduling [Iyer and Druschel 2001], whichgroup together requests from a single process and minimize the effects of multipleinterleaved I/O request streams, address this issue well. We evaluate the impact ofquery parallelism (in Section 6) with anticipatory I/O scheduling to demonstratethe effectiveness of native layout strategies in the simulated environment.

Finally, existing storage interfaces are restrictive which makes it non-trivial toobtain profiling information or control data layout. While the need for more ex-pressive storage interfaces has been brought up repeatedly in the storage researchcommunity(e.g., [Ganger 2001; Keeton et al. 1998; Riedel et al. 1998]), for the time-being, we can circumvent this restriction by employing disk profiling and controltools. Profiled information includes: rotational time, seek time, track and cylinderskew times, sizes of read cache and write buffer along with pre-fetching and buffer-ing techniques, logical to physical block mappings, and access time prediction. Thisprofiled information enable fine-grained control for disk drives, tailored specificallyfor semi-structured data.

4. SUPERNODE TREES

So far, we assumed that each node in the semi-structured data tree occupies anentire disk block. This assumption, however, is not realistic; in practice, the treenodes are of variable size, ranging from a fraction of a disk block to multiple diskblocks.

In this section, we first lay the foundation for grouping nodes in a semi-structureddata tree T to form supernodes where each supernode occupies an entire disk block.Next, we describe how to organize the supernodes into a supernode tree structureTS . The placement strategies of Section 3 are then applied on the supernode treeinstead of the node tree.

4.1 Grouping Nodes into Supernodes

To reduce the internal fragmentation, it is desirable to group the maximum numberof nodes into a supernode. It is also important to group adjacent nodes of T inthe same supernode, so that navigating among these nodes requires only one diskaccess. If the size of a node is larger than the size of a disk block, it is stored using



multiple supernodes, which are then stored in consecutive disk blocks. 3

To elucidate the following grouping techniques, we assume that all nodes havethe same size, and one supernode can contain at most five nodes.

S

Q

N

J

M

O P

A

I

K L R SGF

C D E H

B

S

1

2

3

4S

S

(a) Sequential grouping

T

Q

N

J

M

O P

A

I

K L R SGF

C D E H

B

1

2 3T

T4

T5

T

(b) Tree-preserving group-ing

Q

N

J

M

O P

A

I

K L R SF

D E H

B

1

2

3 5

6

7

4

C

G

T1

T2T3

T4

(c) EKM grouping

Fig. 6. Grouping strategies for creating supernodes.

Sequential grouping. Nodes are added to a supernode starting from the rootnode using a depth-first (and left-to-right) traversal. The only difference is thata single node is not split nodes across disk blocks, unless the size of the node isgreater than the size of a disk block. Figure 6(a) illustrates this grouping strategyfor the tree presented earlier in Figure 3.

Tree-preserving grouping. The tree-preserving grouping proceeds as in thesequential grouping except it ensures that cycles of supernodes do not form in thegrouped tree. At each step, before adding a node v to a supernode S, the followingadditional conditions are checked:(i) the parent node of v is in S, or

(ii) the parent node of v is in the parent supernode of S.If any of these conditions hold, then we add v to S. If neither holds, then by addingv to S a cycle of supernodes in the original tree T would be created. To avoid that,we close S and add v to a new supernode. This strategy aims at preserving thetree-structure of the original tree T in the supernode tree. Figure 6(b) illustratesthis grouping strategy for the tree of Figure 3.

Enhanced Kundu Misra grouping. We also implement a grouping techniquedeveloped independently at the same time by Kanne and Moerkotte [Kanne andMoerkotte 2006] called the Enhanced Kundu Misra (EKM) grouping, an extensionto the original Kundu-Misra grouping algorithm [Kundu and Misra 1977]. TheEKM strategy operates in a bottom-up fashion and aims at reducing the numberof node groups while preserving the original tree structure, thereby increasing nav-igations between nodes within the same group. It operates by converting the n-ary

3An alternative strategy to avoid breaking the tree-structure of the rest nodes would be to store apointer to a Binary Large Object (BLOB) and use an object storage manager [Carey et al. 1994]to manage BLOBs.



tree into a binary tree representation, obtaining a layered partitioning that helps re-ducing the number of supernodes while preserving the connectedness. Figure 6(c)illustrates this grouping strategy for the tree of Figure 3.

4.2 Building Supernode Trees

The organization of the supernodes into a supernode tree, TS , determines the place-ment of the supernodes on the disk drive according to the algorithms presented inSection 3. Hence, it is desirable to preserve the tree-structure of T in TS. Thatis, if a parent-child pair of nodes in T is split to different supernodes, then it ispreferable to split it to two adjacent supernodes in TS . Based on the groupingstrategies described above, we consider four supernode tree organization strategies:1. The sequential supernode list, which corresponds to the default placementstrategy, uses sequential grouping to form supernodes. It is merely a linked-list ofsupernodes in the order in which the supernodes were formed. Figure 7(a) showsthe formation of this list.

2. The tree-preserving supernode tree, which corresponds to the tree-preserving4

tree-structured5 placement to be introduced in Section 6, uses the tree-preservinggrouping to form supernodes. The supernode tree is formed by adding edgesbetween two supernodes Si, Sj if there is an edge between two nodes vi ∈ Si, vj ∈Sj in T . Notice that due to the nature of tree-preserving grouping no cycles canoccur. Figure 7(b) shows the formation of this tree.3. The sequential supernode tree, which corresponds to the sequential tree-structuredplacement algorithm in Section 6, uses the sequential grouping to form supernodes.Then, the supernode tree is created by adding edges between pairs of supernodesSi, Sj if there is an edge between two nodes vi ∈ Si, vj ∈ Sj in T and adding theedge will not create a cycle. Figure 7(c) shows the formation of this tree.4. The EKM supernode tree builds a tree on the EKM supernodes. Again nocycles exist due to the nature of EKM grouping. Figure 7(d) shows the formationof this tree.

SS 2S 3S 41

(a)

1T

2T 4T

5T3T

(b)

SS

2 3S

4S

1

(c)

T

T T3 2 1

4

T

(d)

Fig. 7. Supernode Trees: (a) Sequential supernode list. (b) Tree-preserving supernodetree. (c) Sequential supernode tree. (d) EKM supernode tree.

4with respect to grouping5with respect to placement algorithm



5. THEORETICAL ANALYSIS

In this section, we present a quantitative model to analyze the access times for thedefault and the optimized tree-structured placement strategies. Table II summa-rizes the description of each parameter used in this analysis.

Table II. Parameter Description

Tdefault: Average access time in default placementTtree: Average access time in tree-structured placement

tseq : Average access time for sequential accesstrand: Average access time for random accesstsemi−seq : Average access time for semi-sequential access

a1: Access is from parent to first child

a2: Access is from a parent node to non-first childa3: Access is from a non-leaf node to its right siblinga4: Access is from a leaf node to its right sibling

a5: All other accesses (that is, P5 = (1− (P4

i=1 Pi))

Pi: Probability that access ai occurs; 1 ≤ i ≤ 5

tdefault(ai): Average time for ai in default placementttree(ai): Average time for ai in tree-structured placement

C: Number of Cylinders

Trot: Rotational Period

Tnt: Time taken to transfer one block of data

First we compute the random, sequential and semi-sequential access times. The average random access time trand, is a function ofthe average seek time and rotational delay and is given by:

trand = seekT ime (C

3) +

1

2Trot (1)

where seekT ime is a disk specific function computing the seek time given thenumber of tracks to seek [Ruemmler and Wilkes 1994] and is given by:

seekT ime (d) = α + β ·√

d; if d <C

3= γ + δ · d; otherwise (2)

where d is the seek distance in cylinders, C is the total cylinder count, and α, β, γand δ are disk specific parameters.

For the barracuda disk, chosen as the base disk configuration in the experiments(and also further described in Table VII), the rotational latency is given by Trot =8.33 ms and α = 1.83, β = 0.17, γ = 2.85 and δ = 0.0035. For an XML documentof size 50MB occupies 129188 blocks or 325 cylinders after grouping with the tree-preserving grouping strategy (Table IV). Thus, substituting these values in theabove Equation 1, the random access time for the area occupied by this documentis given by trand = 5.99 ms.

The average sequential access time tseq from one block to the next is a very smallvalue, approaching zero. Hence,

tseq = 0 (3)



For the tree-structured placement, the access between a parent and its first childis semi-sequential, and from a node to its right sibling is sequential. The averagetime for semi-sequential access tsemi−seq given by:

tsemi−seq(v) = seekT ime (s(v)) (4)

where s(v) is the number of tracks to be seeked during a semi-sequential access.When T is a complete tree with height d and degree f , the average s(v) is givenby:

s(v) =fd−2(d − 2 − f/(1 − f)) + 2 + f/(1 − f)

2n′(5)

where n′ is the number of internal nodes given by n′ = (1−fd−1)(1−f)

To understand this equation, lets assume that the root is at depth 1 and theleaves at depth d. If there are two edges u1−v1 and u2−v2 where u1 and u2 are onthe same level and v1 and v2 are their lth respectively, then DFO(v1)−DFO(u1) =DFO(v2)−DFO(u2), Thus, the distance in tracks from v1 to its child u1 and fromv2 to u2 are the same. In the above relation, DFO(x) is the corresponding numberin the DFO ordering. The numbers above the internal nodes in the tree shown inFigure 3 illustrate the DFO ordering.

To calculate the average s(v) for the nodes v of level k + 1, we need to find thesize of the subtree rooted at v which is

1 + f + · · · + fd−k−1 =(1 − fd−k)

(1 − f)(6)

The average of s(v) for the nodes v of level k + 1 is the average s(v) of any set ofsiblings at level k + 1. That is,

( f+(1−fd−k)(1−f)(1+···+(f−1)))

f=

( f+(1−fd−k)(1−f)(f−1)f/2 )

f=

(fd−k + 1)

2(7)

Hence, for level k it is (fd−k−1+1)2 .

For an average fanout of 10 and a depth of 5 in an XML tree, s(v) from Equation 5is 1.83. Thus, the seekT ime(s(v)) is α + β ·

√1.83 = 2.26.

Equation 4 assumes perfect semi-sequential time, which is achieved by the tree-structured algorithm (Algorithm 2). However, in the case of the optimized tree-structured algorithm (Algorithm 3), tsemi−seq(v) depends on the number of track-regions per-track, k. Hence,

tsemi−seq(v) = seekT ime (s(v)) +1

2kTrot (8)

Since the first-child is placed anywhere within a rotationally-optimal track-regionrather than rotationally optimal sector, accessing the first child may involve any-where between 0 to 1

kTrot rotational delay after the seek operation. This additionalrotational delay during the semi-sequential access is 1

2kTrot on an average. Whena track is divided in 8 track regions, k =8 and for the barracuda disk, s(v) is cal-culated above and is 1.83 ms. Substituting these values in Equation 8, the average



semi-sequential time is given by tsemi−seq(v) = 2.79 ms, a significant reduction of53.4 % from an average random access time of 5.99 ms.

Next, we discuss the time needed for each of the five basic access types of Table II.When the first child is accessed from its parent (a1), a sequential access occurs in thedefault placement, whereas a semi-sequential access occurs in the tree-structuredplacement. When a non-first child is read from its parent (a2), it is a randomaccess in the default placement, whereas for the tree-structured placement, it isthe sum of the semi-sequential time and the average sibling index (f/2, where f isthe tree fanout) times Tnt (time required to transfer data from one node). Whenthe access is from a non-leaf node to its right sibling (a3) it is a random accessin the default placement, and a sequential access in the tree-structured placement.When from a leaf-node we access its right sibling (a4), it is a sequential access ineither placement strategy. In all other cases (a5), such as when moving up the tree,for both placements a random access will be performed. Table III summarizes theaccess times in the default and the tree-structured storage for every ai.

Table III. Average access times in default and tree-structured placement for eachaccess type ai.

Access type ai Description tdefault(ai) ttree(ai)

a1 Parent to first child tseq tsemi−seq

a2 Parent to non-first child trand tsemi−seq + f

2(Tnt)

a3 Non-leaf node to right sibling trand tseq

a4 Leaf node to right sibling tseq tseq

a5 All other accesses trand trand

The average access times in default and tree-structured storage are computed byEquations 9 and 10 respectively.

Tdefault =

5∑

i=1

Pi · tdefault(ai) (9)

Ttree =

5∑

i=1

Pi · ttree(ai) (10)

Tree-structured placement is better when Ttree < Tdefault.While this is not realistic (and necessarily subjective to the query as demon-

strated extensively later in Table VI), if we did assume that a query exhibits all theaccess types shown in Table III, with each access type occurring equally frequently,the average I/O times for the default and the tree placement can be obtained bysubstituting their values in Equations 9 and 10 as:

Tdefault =1

5· tseq +

1

5· trand +

1

5· trand +

1

5· tseq +

1

5· trand

= 3.594 ms, and

Ttree =1

5· tsemi−seq +

1

5· (tsemi−seq +

f

2(Tnt)) +

1

5· tseq +

1

5· tseq +

1

5· trand

= 2.344 mswhere the transfer time Tnt = 0.03 ms.



6. EVALUATION CASE STUDY: XML

In this section, we experimentally evaluate the grouping and native layout strategiesfor placing the XML data on disk drives.

We used the DiskSim [Bucy et al. 2003] disk simulator for our evaluations, instru-menting it to provide the additional interface: <LBN>

findSemiSequential(LBN parent, int cyl, int track) which given a parent LBN,returns an LBN X on <cyl,track>, such that access from the parent LBN to X issemi-sequential. The optimized-tree placement in Algorithm 3 uses this interfaceto find semi-sequential LBA for subsequent nodes in the tree that has to be placedon the disk. The optimized tree-structured and the default placement algorithmswere implemented in C and integrated with the instrumented DiskSim code. Thegrouping algorithms were implemented as a separate module.

6.1 Data Set and Queries

We generated XML files (each file corresponds to an XML tree) of various sizesusing the XMark generator [Schmidt et al. 2002b] with different scaling factorsfrom f = 0.01 to f = 1.00, corresponding to file sizes ranging from 1MB to 100MB.The limit of 100MB for the maximum file size is due to the memory constraintsin currently available open-source XML parsing engine implementations. Theseengines create the navigation tree data structures for the entire tree in memoryduring parsing, while at the same time consuming as much memory as five timesthe original document size [Nicola and John 2003]. There is ongoing work onimproving memory efficiency of XML parsers [Farfan et al. 2007] which promise toaddress this shortcoming in the near future. Earlier in Table I, we presented thedocument sizes used by several popular benchmarks typically used to evaluate XMLquery optimizations, storage, indexing and so on. As mentioned earlier in Section 2,trivial solutions that load the entire document in memory are not practical forlarge (several gigabyte sized) XML documents. Although the XML documents weexperiment with are small relative to the size of the disk, these serve as examples toillustrate the relative effectiveness of native layout when compared to the existingapproaches. It should additionally be noted that the on-disk buffer is small (1-8MB)for the disks we use, substantially smaller relative to the size of the documents, andis not in any significant way capable of influencing the I/O access patterns apartfrom on-disk readahead.

We implemented the three grouping strategies - sequential, tree-preserving, andEKM - described in Section 4, computing and storing the information about thesupernode that would contain each XML node. We also implemented extensions tothe DiskSim disk simulator [Bucy et al. 2003] that allowed us to simulate the nativelayout strategy described in Section 3. We then used the supernode information tostore them on disks simulated by DiskSim.

Table IV provides information about the XML trees used and the correspondingsupernode trees formed. The number of supernodes in the sequential grouping isthe lowest since it groups the nodes to form supernodes without any restrictions.EKM does a bottom-up grouping of the tree and reduces the number of resultingsupernodes by reducing the problem of finding supernodes for arbitrary trees to thesimpler problem of finding supernodes for flat trees (trees in which all nodes but



Table IV. XML Tree and Supernode Tree Parameters

XMarkTree

#NodesAvg Bytes # Supernodes Avg Bytes/Supernode

(KB) per node TP Seq. EKM TP Seq. EKM0.01 1667 17132 25.21 2576 2119 2148 343.8 418 412.30.05 8270 59641 25.8 12834 10625 10703 373.2 450.8 447.50.1 16765 167865 25.85 25991 21435 21628 345.3 418.7 414.90.5 83726 832911 26.09 129188 106592 114775 345.3 418.5 414.61 168755 1666315 26.07 259575 214326 216140 345.3 418.2 414.7

Table V. XPath queries for the deep-focused (D) and the non deep-focused (N) classes.

# Query # QueryD1 /site/closed auctions/closed auction/ N1 /site/open auctions/open auction

annotation/description/parlist/listitem/text/keyword

D2 /site/people/person/watches N2 /site/closed auctionsD3 /site/open auctions/open auction/ N3 /site/regions/australia

annotation/description/text/keywordD4 /site/people/person/address/country N4 /site/closed auctions/closed auctionD5 /site/regions/australia/item/ N5 /site/regions/ ∗ /item

description/text/emphD6 /site/people/person/ ∗ /business N6 /site/ ∗ /australiaD7 /site/closed auctions/closed auction/ ∗ / N7 /site/open auctions/open auction

description [@id =′ open auction0′]/bidderD8 /site/regions/ ∗ /item/description/text N8 /site/regions/asia/item

[@id =′ item4′ ]/mailbox/mail/from

D9 /site/closed auctions//itemref N9 /site/open auctions/open auction[@id = ”open auction0”]//keyword

the root are leaves) [Kanne and Moerkotte 2006]. Tree-preserving grouping avoidscycles by placing restrictions on the nodes being added to the supernode. This inturn reduces the number of nodes per supernode and subsequently increases thenumber of supernodes. The average nodes/supernode is six for the tree-preservinggrouping and is 8 for Sequential and EKM grouping.

For the query workload, we adopted performance-sensitive queries from the XPath-Mark benchmark [Franceschet 2004], but omitted the ones that check for featuressupported by XPath (e.g., Q18: /comment()). To compute reliable results we addedmore queries with similar properties of depth, number of conditions and selectivity.The query workload is summarized in Table V.

To contrast the relative advantages of using our native strategies with those ofthe default sequential layout, we classify XPath queries into two categories: deep-focused queries and non deep-focused queries. A subset of each class is shown inTable V. The former class describes the special class of XPath queries that navigateentire subtrees of the tree (queries D1, . . . , D9 in Table V). The latter class, nondeep-focused queries N1, . . . , N9 in Table V, represents all queries that do not belongto the former class. As we shall demonstrate, the default layout primarily addressesthe class of deep-focused queries and is sub-optimal for all other queries. Notice thatonly the supernode-granularity navigation matters for overall I/O performance, andnot the node-granularity navigation. Hence, queries like D2, which do not access



1

10

100

1000

10000

100000

1e+06

D1 D2 D3 D4 D5 D6 D7 D8 D9

Total

I/O T

ime (

ms)

Query

DefaultTP-TS

Seq-TSEKM-TS

(a) Deep-focused queries

1

10

100

1000

10000

100000

1e+06

N1 N2 N3 N4 N5 N6 N7 N8 N9

Total

I/O T

ime (

ms)

Query

DefaultTP-TS

Seq-TSEKM-TS

(b) Non-deep-focused queries

Fig. 8. Total I/O times in logarithmic scale for various placement strate-gies.

leaf nodes, are included in the first category since they access supernode leaves; thewatches subtree is very small and fits in less than one supernode.



0

0.2

0.4

0.6

0.8

1

1.2

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Nor

mal

ized

Tot

al I/

O T

ime

SeekRotationTransfer

D9D8D7D6D5D4D3D2D1

Disk(a) Deep-focused queries

0

0.2

0.4

0.6

0.8

1

1.2

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Nor

mal

ized

Tot

al I/

O T

ime


N9N8N7N6N5N4N3N2N1

Disk(b) Non-deep-focused queries

Fig. 9. Normalized total I/O times for various placement strategies.

6.2 Tree Navigation Performance

We conducted experiments that compare the I/O times for answering XML queriesfor four different layout strategies, corresponding to the supernode tree organiza-tions of Section 4: default (Section 2.2), tree-preserving tree-structured (TP-TS),sequential tree-structured (Seq-TS), and EKM tree-structured (EKM-TS) layoutstrategy.

To consider caching effects in our experiments, we assumed that all nodes alongthe path from the root to a single leaf node would be cached in main memory,either in the operating system VFS or a custom application level cache. This is areasonable assumption for XML trees, which are typically short even when their



Table VI. Navigational patterns for the two XPath query classes for f = 0.5. ai’s aredefined in Table II.

Default PlacementQuery a1 a2 a3 a4 a5 Query a1 a2 a3 a4 a5

D1 9046 0 0 0 1982 N1 1098 0 0 0 4775D2 7211 0 0 0 55 N2 0 0 0 0 5D3 12744 0 0 0 1895 N3 0 0 0 0 10D4 7211 0 0 0 55 N4 1387 0 0 0 3053D5 1823 0 0 0 759 N5 1322 0 0 0 9323D6 7315 0 0 0 4 N6 9324 0 0 0 8418D7 2765 0 0 0 2814 N7 1098 0 0 0 4775D8 11937 0 0 0 9654 N8 121 0 0 0 870D9 16166 0 0 0 5 N9 1098 0 0 0 4775

TP-TS PlacementQuery a1 a2 a3 a4 a5 Query a1 a2 a3 a4 a5


Seq-TS PlacementQuery a1 a2 a3 a4 a5 Query a1 a2 a3 a4 a5


EKM-TS PlacementQuery a1 a2 a3 a4 a5 Query a1 a2 a3 a4 a5


total size is large, due to large fan-out. Consequently, we ignore repeated accessesto nodes (such as parent, ancestor nodes) during the depth first traversal of theXML tree. Such caching reduces the number of random accesses equally in allthree placement strategies, since the navigation of nodes for answering a query isexactly the same regardless of the layout strategy.

6.2.1 Total I/O time. Figure 8 shows (in logarithmic scale) the I/O times foreach query, for the two classes of queries, deep-focused (Di) and non deep-focused(Ni), for an XMark file with scaling factor f = 0.5. We executed five simulationruns for each column shown in the graph. For the first run, the start LBA forthe placement of the root node was 0. For all the subsequent runs, it varied withincrements of 250 (> track size). Thus, the start LBA was varied over the range0−1250. The confidence interval, for a confidence level of 95%, for all the five runs



was found to be < ± 10.96. The results shown in the graph are for the start LBA0.

For the deep-focused class of queries, the default placement strategy performsconsistently better than the others, since it can retrieve entire subtrees more ef-ficiently. For the non-deep-focused query class, the performance of the defaultplacement strategy is consistently worse than the tree-structured variants (TP-TS,Seq-TS, and EKM-TS). For this query-class, a large number of accesses are non-sequential for the default placement, since complete sub-tree accesses are few.

Figure 9 shows the relative performance with the normalized total I/O timeto reduce the impact of the large variance across queries. Each value is scaledrelative to the maximum value for the experiment. To better demonstrate therelative distribution of seek, rotational delay, and transfer time components, thetotal normalized I/O time is further split to show these I/O access time components.It can be seen that the average rotational delays for the tree-structured placementstrategies (in the case of non-deep-focused queries) are substantially lower relativeto the default strategy. However, this is not the case for the deep-focused classwhere the default strategy outperforms in all respects.

To better understand and explain the graphs of Figure 8 and Figure 9, we countedthe different types of accesses in the supernode tree (each access translates to a diskI/O operation) for answering the XPath queries for both the deep-focused and nondeep-focused classes. Table VI shows the numbers of supernodes accesses for the fivebasic types of tree accesses, a1 through a5, defined in Table III. As an example,observe that for the TP-TS placement, Query D1 requires 4438 a1 accesses, theparent-to-first-child type accesses.

We can make some general observations from Table VI. First, the default place-ment causes all the accesses to be either of type a1 or a5, since only parent-to-first-child sequential accesses are possible for this layout. Second, the deep-focusedqueries are dominated by a1 and a5 type accesses, while the non-deep-focusedqueries are dominated by a3 and a4 accesses (except in the case of default place-ment). This enables the non-deep-focused queries to exploit native layout, sinceall the accesses to siblings are sequential, as opposed to the large number of ran-dom accesses the deep-focused queries require. Observe further that the EKM andTP-TS placement strategies increase the number of accesses from parent to non-first child, thus utilizing the semi-sequential and sequential access optimization toa larger extent. For the deep-focused queries, on the other hand, the default place-ment performs the best both because the number of sequential accesses for thisplacement is the highest and number of random accesses is lowest (in most cases)among all placement techniques.

In Figure 9 (b), we see a somewhat unexpected outcome that the seek timesreduce for queries N2 and N3 for TP-TS, Seq-TS and EKM placement. An answercan be found in the access patterns of these queries (Table VI). For N2 and N3,all accesses for the default placement are of type a5, which are random accesses,where as for the TP-TS and EKM placement, they are either semi-sequential orsequential accesses, leading to the observed difference in seek overhead. Further,the Seq-TS has a slightly lower performance relative to these two because of theincrease in the number of random accesses for this placement. Note that although



the number of random accesses in Seq-TS is relatively higher, it is still lower thanthe default placement and hence it performs better than the default placement.

The above discussion serves to reinforce the arguments we made earlier whendiscussing Figure 8. In summary, the EKM-TS placement strategy performs betteroverall due to its lower internal fragmentation and tree-structure preservation prop-erty; it results in I/O times which are 3X-127X better than the default strategy.Between the remaining strategies, TP-TS performs better on an average, since itbetter preserves the original tree-structure.

6.2.2 Sensitivity to drive characteristics. To evaluate the effect of drive char-acteristics, we conducted a sensitivity study of I/O access time for representativedisk-drive models. The drive models chosen, shown in Table VII, were the SeagateBarracuda, Seagate Cheetah 9LP, Seagate Cheetah 4LP, and the HP C3323A asrepresentative of four performance classes of disk drives: base, fast rotating andfast seeking, fast rotating, and slow rotating respectively. A disk block is of size 512bytes.

Table VII. Characteristics of experimented disk drives.

Disk Disk Size RPM Stroke Transfer Track Size Cylindersmodel type [GB] [ms] [MBps] [sectors]

Barracuda Base 2 7200 16.679 10-15 119-186 5172Cheetah 9LP Fast disk 9.1 10045 10.627 19-28.9 167-254 6962Cheetah 4LP Fast rotate 4.5 10033 16.107 15-22.1 131-195 6581HP C3323A Slow rotate 1 5400 18.11 4.0-6.6 72-120 2982

Figure 10 shows the average (across queries in a query-class) total I/O times (inlogarithmic scale) for the two query classes for an XMark file with f = 0.5 withthe various hard disk models. For the special class of deep-focused queries (Fig-ure 10(a)), the default placement strategy performs better than the other strate-gies benefiting from optimized sub-tree retrievals. However, for all other queries(Figure 10(b)), the tree-structured placement strategies perform better for all diskmodels, offering as much as 7X-34X reduction in average I/O time for answeringqueries. This underscores the importance of native layout strategies for XML data.

We break down the gains further in Figure 11 into the relative reduction in seekand rotational delay components for each of the drives by normalizing the I/O timesat each disk drive using the maximum value as reference.. Notice for the non-deep-focused query class (Figure 11(b)), the average rotational-delays are substantiallyreduced relative to the default layout.

6.2.3 Effect of Query Interleaving. One concern with a native layout targetedto a optimize a specific access pattern is the impact of multi-processing in thesystem. For instance, a server is likely to execute multiple XPath queries simul-taneously; optimizing individual query executions may not necessary translate tooverall performance improvement when the corresponding I/O request sequencesare interleaved. As elaborated in Section 3, this issue in its more general form (i.e.,



1

10

100

1000

10000

100000

1e+06

Disk1 Disk2 Disk3 Disk4

Aver

age

Tota

l I/

O T

ime

Disk

DefaultTP-TS

Seq-TSEKM-TS


1

10

100

1000

10000

100000

1e+06

Disk1 Disk2 Disk3 Disk4

Aver

age

Tota

l I/

O T

ime

Disk

DefaultTP-TS

Seq-TSEKM-TS


Fig. 10. Sensitivity of query I/O times to changing disk drive characteristics (loga-rithmic scale).

multi-process blocking I/O performance) has been addressed earlier with anticipa-tory I/O scheduling [Iyer and Druschel 2001]. Consequently, we expect that XMLservers would be configured with I/O schedulers that include an anticipation core.

To evaluate the performance of our grouping and placement techniques undermultiple simultaneous XPath queries, we interleaved a subset of deep-focused andnon-deep-focused queries stated in Table V. The interleaved queries belonged to



0

0.2

0.4

0.6

0.8

1

1.2

1.4

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Nor

mal

ized

Ave

rage

Tot

al T

ime

Disk


Disk 4Disk 3Disk 2Disk 1


0

0.2

0.4

0.6

0.8

1

1.2

1.4

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Default

TP-TS

Seq-TS

EKM-TS

Nor

mal

ized

Ave

rage

Tot

al T

ime

Disk


Disk 4Disk 3Disk 2Disk 1


Fig. 11. Sensitivity of seek and rotational delay components of I/O access times tochanging disk drive characteristics.

either the disjoint set of queries which accessed disparate portions of the tree orintersecting queries whose access paths overlapped. The ordering of the I/Os afterinterleaving were based on anticipatory scheduling. We simulate the behavior ofthe anticipatory I/O scheduler assuming that each query is serviced within anindependent thread and issues synchronous I/O requests. The behavior of the non-work-conserving anticipatory scheduler would result in optimizing the schedule ofsuccessive I/O operations resulting from the same query, in spite of them beingissued synchronously, as long as other queries in the system access disjoint portionsof the XML tree. When there is an overlap of subtrees between two queries, theirI/Os must interleave.

For the choice of queries, we selected both disjoint queries, which traverse differ-ent subtrees of the document, as well as intersecting queries, that access commonsubtrees, which navigate common sub-trees of the document. Table VIII shows theselected queries that were interleaved in each of these categories, where δi refers todisjoint queries and πi represents intersecting queries.

Figure 12 shows the total I/O time (in logarithmic scale) for the execution ofinterleaved deep-focused and non-deep-focused XPath queries. The results for thedeep-focused queries from Figure 12 (a), show that like in single query execution,



Table VIII. Query Interleaving for Multi-User Simulations.

Disjoint Deep-focused Non-deep-focusedQueries Queries Queries

δ1 D1 + D4 N1 + N4

δ2 D4 + D8 N4 + N8

δ3 D5 + D7 N5 + N7

δ4 D1 + D4 + D5 N1 + N4 + N5

δ5 D4 + D5 + D7 N4 + N5 + N7

δ6 D4 + D5 + D9 N4 + N5 + N9

Intersecting Deep-focused Non-deep-focusedQueries Queries Queries

π1 D1 + D7 N1 + N6

π2 D2 + D4 N5 + N6

π3 D5 + D8 N7 + N9

π4 D4 + D6 N1 + N6 + N7

π5 D1 + D7 + D9 N6 + N7 + N9

π6 D2 + D4 + D6 N5 + N6 + N8

the default strategy performs better for multiple interleaved queries than the otherstrategies.

Similarly, the behavior with the the non-deep-focused interleaved queries mostlymimic their single query counterparts. The native layout strategies provide muchbetter execution times for both the disjoint and intersecting queries, as shownin Figure 12 (b). Moreover, the EKM-TS performs better the most consistentlyacross the interleaved query executions. The breadth-first grouping approach ofthis placement strategy causes the I/Os corresponding to the upper levels of theXML tree to be read in parallel. For lower tree levels, the anticipatory schedulerwhich ensures that the I/O sequences generated by the individual query threads aregrouped successfully. Finally, the default placement performs consistently worse forthe disjoint queries, since the I/O sequences generated by individual query threadsare executed almost sequentially.

6.3 Fragmentation

We now measure the internal and external fragmentation incurred by the groupingand placement algorithms respectively.

Internal Fragmentation: Figure 13 (a) shows the internal fragmentation of diskblock space with the three grouping algorithms, sequential, tree-preserving, andEKM. As expected, the sequential grouping algorithm has little internal fragmen-tation as it can freely add nodes to a supernode as long as adding the next nodedoes not violate the block-size restriction. Supernodes are not occupied completelyif its the remaining space is smaller than the size of the next XML node. The tree-preserving grouping places further restrictions on grouping for preserving the XMLtree-structure in supernodes and incurs additional internal fragmentation (as muchas 55%). We argue that considering the fact that current disk drives are boundmore by I/O access time than by I/O capacity, trading capacity for improving ac-cess is acceptable. The internal fragmentation with EKM is very close to that for



1

10

100

1000

10000

100000

1e+06

δ1 δ2 δ3 δ4 δ5 δ6 π1 π2 π3 π4 π5 π6

Total

I/O T

ime (

ms)

Query

DefaultTP-TS

Seq-TSEKM-TS


1

10

100

1000

10000

100000

1e+06

δ1 δ2 δ3 δ4 δ5 δ6 π1 π2 π3 π4 π5 π6

Total

I/O T

ime (

ms)

Query

DefaultTP-TS

Seq-TSEKM-TS


Fig. 12. Total I/O times in logarithmic scale for interleaved XPathqueries.

sequential grouping. The EKM algorithm has the flexibility that allows selectingany of a node’s many subtrees as partition, thereby obtaining a more optimal resultfor this procedure. Our tree-preserving grouping algorithms lack this flexibility, andcan only add the next node to the current supernode in an in-order fashion.External Fragmentation: Figure 13 (b) shows the external fragmentation re-



0

20

40

60

80

100

0.01 0.05 0.1 0.5 1.0

Inte

rnal

Fra

gmen

tatio

n (%

)

XMARK Scaling Factor

SequentialTree-Preserving

EKM

(a) Internal fragmentation

0

20

40

60

80

100

0.01 0.05 0.1 0.5 1.0

Exte

rnal

Fra

gmen

tatio

n (%

)

XMARK Scaling Factor

DefaultTP-TS

Seq-TSEKM

(b) External fragmentation

Fig. 13. Internal and External Fragmentation.

sults for the data placement strategies. The default strategy incurs zero externalfragmentation as it places the supernode list sequentially on the disk. TP-TS andSeq-TS incur external fragmentation of less than 28%, while that of the EKM-TSis higher at around 32%. However, we once again contend that these numbers areacceptable, following the arguments mentioned above. EKM-TS incurs the highestexternal fragmentation, because in EKM-TS, the fanout of nodes is less in the toplevels (closest to root) of the tree and is higher in the lower levels, unlike the otherstrategies. If the fanout of a tree is higher at a greater depth, it is more difficult tofind contiguous free space to place all the children on the partially occupied tracks



using the optimized placement strategy. Consequently the children are placed onnew tracks, thereby increasing the external fragmentation. Furthermore, for a na-tive storage solution that is well integrated into the existing file or database system,it is relatively easy to utilize fragmented free space.

7. RELATED WORK

Storage of semi-structured data has received attention in the last few years becauseof its growing popularity. Most work has focused on storing semi-structured data inrelational DBMSs or in flat files with indexes. The former approach (e.g.,[Barbosaet al. 2001; Du et al. ; Shanmugasundaram et al. ; Nekrestyanov et al. 2000; Deutschet al. 1999; McHugh et al. 1997]) has been the most popular due to the success andmaturity of the relational DBMSs. The latter approach (e.g., [Kaushik et al. 2002;Li and Moon 2001]) is based on storing the data as a flat file and building separateindexes on top. These strategies do not use native layout of semi-structured dataand are limited to the generic optimization strategies built into relational databasesand file systems.

The problem of native storage of semi-structured data has been addressed inNatix [Kanne and Moerkotte 1999; Kanne et al. 2005] and in System RX [Beyeret al. 2005], where the tree-structured data is split into pages and each page is storedin a disk block, thereby reducing the number of read accesses while traversing thetree. OrientStore [Meng et al. 2003] uses schema information to make a storage planfor the semi-structured data. The above studies however view a disk drive as a listof pages and do not take into account the physical characteristics of its operationwhereas we investigate how to exploit detailed information about the disk drive anduse this information to minimize overheads such as seek-time and rotational-delay.

Given the restrictive block IO interface, the clear case for a more expressiveinterface has been made before [Ganger 2001]. Systems such as [Gibson et al. ;Huston et al. 2004; Sivathanu et al. 2003] use intelligence from upper layers ofthe storage stack inside storage devices to improve overall IO performance. Ourwork, if deployed, can use such systems, to incorporate storage techniques for semi-structured data into disk firmware.

Recent work by [Schlosser et al. 2005] uses the idea of semi-sequential access forefficient storage of multi-dimensional data. This work is significantly different fromour work in that unlike semi-structured data, multi-dimensional data is structuredwith access patterns along data dimensions and can afford efficient layout basedon fixed attribute cardinality. Also, with semi-structured data, grouping multipledata elements to be stored on a disk block is non-trivial due to the variable size ofthe data elements.

Atropos [Schindler et al. 2004] exploits the physical properties of disk drives anduses semi-sequential accesses to store relational databases. Our work targets XMLdata that has a tree structure, quite different from the relational tables. We alsoshow that a naive application of the semi-sequential access paradigm to XML treestructures leads to large seek times and severe space fragmentation. Our optimizedlayout strategy reduces such overhead significantly. To the best of our knowledge,there is no existing work tackling the problem of laying out XML data, accountingfor low-level hard drive storage and operation semantics.



8. CONCLUSIONS

In this paper, we have taken a first step towards building native storage systems forsemi-structured data, a problem which has been largely unexplored. We presentedon-disk data layout techniques for semi-structured data that explicitly account forthe structural mismatch between the semi-structured data and disk drives andreduce disk access overhead. These layout techniques are based on node-groupingalgorithms for semi-structured data that reduce the number of disk I/O operationsrequired when accessing the data. We have suggested directions for addressing thechallenges that would arise in integrating the proposed layout techniques in existingstorage systems.

8.1 Summary of Experimental Findings and Lessons Learned

We conducted an evaluation of the native layout techniques using XML as a case-study. All experiments were performed on XPathMark benchmark queries with aninstrumented DiskSim simulator. Our experiments revealed that:

—For the specific class of deep-focused queries, which result in access patterns re-trieving entire sub-trees, the existing file system layout mechanism (i.e., sequen-tial layout of the tree in depth-first-order) offers significantly better performancethan native layout (5X-54X across the query set). For such queries, we believethat sequential layout is the right choice.

—For all other query classes, which we group as non-deep-focused, native layouttaking into account tree navigation primitives, offers as much as 3X-127X per-formance improvement across the range of XPathMark queries that we exper-imented with, representing a large improvement. A sensitivity study across arange of disk models, representing drives of varying performance, suggest thataverage I/O performance improvement across the non-deep-focused query set of7X-34X.

—Of the various native layout techniques we considered, the EKM-TS providedconsistently better performance, barring a few cases. The above findings werelargely preserved when we experimented with multiple simultaneous query ex-ecutions with the anticipatory I/O scheduler. This scheduler naturally carriesforward the benefits of native layout into the I/O schedule.

—Native layout strategies, however, can result in substantial fragmentation of diskspace. Our initial estimates reveal total fragmentation (internal+external) of asmuch as 50% for the best-performing EKM-TS layout technique. This fragmentedspace can be reclaimed with clever file system or database system implementa-tions to store non semi-structured data. Even if that were not feasible, we believean additional 50% of space overhead for several magnitudes of I/O bandwidthincrease could be acceptable in many settings.

Our findings in this study serve to more closely examine and evaluate layouttechniques based on the nature and distribution of queries (i.e., access patterns).Further, based on our findings in this study, it can be inferred that a single layouttechnique is unlikely to be optimal for navigating semi-structured data; the opti-mality of any layout technique closely depends on the nature of the workload. Aprudent choice of the underlying data layout strategy can drastically improve I/O



access times if knowledge of the access patterns (e.g., query workload) is availablebeforehand.

REFERENCES

Abiteboul, S., Agrawal, R., Bernstein, P., Carey, M., Ceri, S., Croft, B., DeWitt, D.,Franklin, M., Molina, H. G., Gawlick, D., Gray, J., Haas, L., Halevy, A., Hellerstein,

J., Ioannidis, Y., Kersten, M., Pazzani, M., Lesk, M., Maier, D., Naughton, J., Schek,

H., Sellis, T., Silberschatz, A., Stonebraker, M., Snodgrass, R., Ullman, J., Weikum,

G., Widom, J., and Zdonik, S. 2005. The lowell database research self-assessment. Commun.

ACM 48, 5, 111–118.

Afanasiev, L., Manolescu, I., and Michiels, P. 2005. Member: A micro-benchmark repositoryfor xquery. In Database and XML Technologies, Third International XML Database Sympo-sium, XSym 2005, Trondheim, Norway, August 28-29, 2005, Proceedings, S. Bressan, S. Ceri,E. Hunt, Z. G. Ives, Z. Bellahsene, M. Rys, and R. Unland, Eds. Lecture Notes in ComputerScience, vol. 3671. Springer, 144–161.

Afanasiev, L. and Marx, M. 2006. An analysis of the current xquery benchmarks. In ExpDB.9–20.

Altschul, S. F., Gish, W., Miller, W., Myers, E. W., and Lipman, D. J. 1990. Basic localalignment search tool. J Mol Biol 215, 3 (October), 403–410.

Barbosa, D., Barta, A., Mendelzon, A. O., Mihaila, G. A., Rizzolo, F., and Rodriguez-

Guianolli, P. 2001. Tox - the toronto XML engine. In Workshop on Information Integrationon the Web. 66–73.

Bedathur, S. and Haritsa, J. 2006. Search-optimized suffix-tree storage for biological applica-tions. In 12th IEEE International Conference on High Performance Computing (HiPC), D. A.Bader, M. Parashar, S. Varadarajan, and V. K. Prasanna, Eds. Lecture Notes in ComputerScience, vol. 3769. IEEE, Springer, Goa, India, 29–39.

Beyer, K., Cochrane, R. J., Josifovski, V., Kleewein, J., Lapis, G., Lohman, G., Lyle, B.,Ozcan, F., Pirahesh, H., Seemann, N., Truong, T., der Linden, B. V., Vickery, B., and

Zhang, C. 2005. System rx: One part relational, one part xml. In SIGMOD.

Bhadkamkar, M., Farfan, F., Hristidis, V., and Rangaswami, R. 2006. Ef-ficient Native Storage for Semi-structured Data (extended paper version). Inhttp://www.cis.fiu.edu/SSS/NativeXMLextended.pdf.

Bohannon, P., Freire, J., Roy, P., and Simeon, J. 2002. From XML Schema to Relations: ACost-based Approach to XML Storage. ICDE .

Bohme, T. and Rahm, E. 2001. Xmach-1: A benchmark for xml data management. In Daten-banksysteme in Buro, Technik und Wissenschaft (BTW), 9. GI-Fachtagung,. Springer-Verlag,London, UK, 264–273.

Bohme, T. and Rahm, E. 2003. Multi-user evaluation of xml data management systems withxmach-1. In Proceedings of the VLDB 2002 Workshop EEXTT and CAiSE 2002 WorkshopDTWeb on Efficiency and Effectiveness of XML Tools and Techniques and Data Integrationover the Web-Revised Papers. Springer-Verlag, London, UK, 148–158.

Bressan, S., Dobbie, G., Lacroix, Z., Lee, M. L., Li, Y. G., Nambiar, U., and Wadhwa, B.

XOO7: Applying OO7 benchmark to XML query processing tool. 167–174.

Bucy, J., Ganger, G., and Contributors. 2003. The DiskSim Simulation Environment Version3.0 Reference Manual. Carnegie Mellon University Technical Report CMU-CS-03-102 .

Carey, M., DeWitt, D., Franklin, M., Hall, N., McAuliffe, M., Naughton, J., Schuh, D.,Solomon, M., Tan, C. K., Tsatalos, O., White, S., and Zwilling, M. 1994. Shoring upPersistent Applications. In ACM SIGMOD.

CDA. 2007. HL7 Clinical Document Architecture, Release 2.0. Inhttp://lists.hl7.org/read/attachment/61225/1/CDA-doc 20version.pdf. 2007.

Delcher, A., Kasif, S., Fleischmann, R., Peterson, J., White, O., and Salzberg, S. 1999.Alignment of Whole Genomes. Nucleic Acids Research 27, 11, 2369–2376.

Deutsch, A., Fernandez, M. F., and Suciu, D. 1999. Storing Semistructured Data withSTORED. ACM SIGMOD .



Dimitrijevic, Z., Rangaswami, R., Chang, E., Watson, D., and Acharya, A. 2004. Diskbench:

User-level Disk Feature Extraction Tool. UCSB Technical Report TR-2004-18 .

Dolin, Alschuler, Boyer, Beebe, Behlen, Biron, and Shvo, S. 2006. HL7 Clinical DocumentArchitecture Release 2. J Am Med Inform Assoc. 13, 1 (Jan-Feb).

Du, F., Amer-Yahia, S., and Freire, J. ShreX: Managing XML Documents in RelationalDatabases.

Farfan, F., Hristidis, V., and Rangaswami, R. 2007. Beyond lazy xml parsing. In Proceedingsof International Conference on Database and Expert Systems Applications (DEXA).

Finkelstein, A., Jacobs, C. E., and Salesin, D. H. 1996. Multiresolution Video. Proceedingsof SIGGRAPH , 281–290.

Franceschet, M. 2004. XPathMark: An XPath Benchmark For XMark. University of Amster-dam Technical Report PP-2004-04 .

Franceschet, M. 2005. XPathMark: An XPath Benchmark for the XMark Generated Data.

Galax. 2007. Galax. http://www.galaxquery.org .

Ganger, G. R. 2001. Blurring the Line Between OSes and Storage Devices. Carnegie MellonUniversity Technical Report CMU-CS-01-166 .

Gibson, G. A., Nagle, D. F., Amiri, K., Butler, J., Chang, F. W., Gobioff, H., Hardin,

C., Riedel, E., Rochberg, D., and Zelenka, J. A Cost-Effective, High-Bandwidth StorageArchitecture. Proceedings of the ACM ASPLOS .

GML. 2008. Geography markup language. http://opengis.net/gml/ .

Gottlob, G., Koch, C., and Pichler, R. 2002. Efficient Algorithms for Processing XPathQueries. In VLDB.

HL7. 2008. Health level seven xml. http://www.hl7.org/special/Committees/xml/xml.htm.

Huston, L., Sukthankar, R., Wickremesinghe, R., Satyanarayanan, M., Ganger, G. R.,Riedel, E., and Ailamaki, A. 2004. Diamond: A Storage Architecture for Early Discard inInteractive Search. Proceedings of the USENIX Conference on File and Storage Technologies.

Iyer, S. and Druschel, P. 2001. Anticipatory scheduling: A disk scheduling framework to over-come deceptive idleness in synchronous i/o. In Symposium on Operating Systems Principles.117–130.

Jagadish, H. V., Al-Khalifa, S., Chapman, A., Lakshmanan, L. V. S., Nierman, A., Pa-

parizos, S., Patel, J. M., Srivastava, D., Wiwatwattana, N., Wu, Y., and Yu, C. 2002.TIMBER: A Native XML Database. The VLDB Journal 11, 4, 274–291.

Kanne, C. and Moerkotte, G. 1999. Efficient Storage of XML Data . Universitaet MannheimTechnical Report .

Kanne, C.-C., Brantner, M., and Moerkotte, G. 2005. Cost-Sensitive Reordering of Naviga-tional Primitives. SIGMOD .

Kanne, C.-C. and Moerkotte, G. 2006. A Linear Time Algorithm for Optimal Tree SiblingPartitioning and Approximation Algorithms in Natix. In VLDB.

Kaushik, R., Bohannon, P., Naughton, J. F., and Korth, H. F. 2002. Covering Indexes forBranching Path Queries. SIGMOD .

Keeton, K., Patterson, D. A., and Hellerstein, J. M. 1998. A Case for Intelligent Disks(IDISKS). SIGMOD Record 27, 3 (September), 42–52.

Kundu, S. and Misra, J. 1977. A Linear Tree Partition Algorithm. In SIAM J. Comput.6(1):151–154.

Li, Q. and Moon, B. 2001. Indexing and Querying XML Data for Regular Path Expressions.VLDB Journal .

Manolescu, I., Miachon, C., and Michiels, P. 2006. Towards micro-benchmarking xquery. InExpDB. 28–39.

McHugh, J., Abiteboul, S., Goldman, R., Quass, D., and Widom, J. 1997. Lore: A databasemanagement system for semistructured data. SIGMOD Record 26, 3, 54–66.

Meng, X., Luo, D., Lee, M.-L., and An, J. 2003. Orientstore: A schema based native xmlstorage system. In VLDB. 1057–1060.



Mergen, S. L. S. and Heuser, C. A. 2004. Matching of XML Schemas and Relational Schemas.

In SBBD.

MML. 2008. Medical Markup Language. http://www.ncbi.nlm.nih.gov/ .

Nambiar, U., Lacroix, Z., Bressan, S., Lee, M., and Li, Y. 2001. Xml benchmarks put to thetest.

Nekrestyanov, I., Novikov, B., and Pavlova, E. 2000. An analysis of alternative methods forstoring semistructured data in relations. In ADBIS-DASFAA. 354–361.

Nicola, M. and John, J. 2003. Xml parsing: A threat to database performance. In Proceedingsof the ACM International Conference on Information and Knowledge Management (CIKM).175–178.

Nicola, M., Kogan, I., and Schiefer, B. 2007. An xml transaction processing benchmark. InSIGMOD ’07: Proceedings of the 2007 ACM SIGMOD international conference on Manage-ment of data. ACM, New York, NY, USA, 937–948.

Noga, M. L., Schott, S., and Lowe, W. 2002. Lazy xml processing. In Proceedings of the ACMSymposium on Document Engineering. 88–94.

ODS. 2008. Open Document Specification v1.0. http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf .

OOX. 2008. Openoffice xml file format v1.0.

Papakonstantinou, Y., Garcia-Molina, H., and Widom, J. 1995. Object Exchange AcrossHeterogeneous Information Sources. In ICDE ’95: Proceedings of the Eleventh InternationalConference on Data Engineering.

Ramanath, M., Freire, J., Haritsa, J., and Roy, P. Searching for efficient XML to relationalmappings.

Riedel, E., Gibson, G., and Faloutsos, C. 1998. Active Storage For Large-Scale Data Miningand Multimedia. Proceedings of the VLDB .

Rokhsar, D. 2007. Computational Analysis of Genomic Sequence Data.http://www.nersc.gov/news/annual reports/annrep01/sh BER 06.html .

Ruemmler, C. and Wilkes, J. 1994. An introduction to disk drive modeling. Computer 27, 3,17–28.

Runapongsa, K., Patel, J., Jagadish, H., Chen, Y., and Al-Khalifa, S. 2003. The michiganbenchmark: Towards xml query performance diagnostics.

Schindler, J., Schlosser, S. W., Shao, M., Ailamaki, A., and Ganger, G. R. 2004. Atropos:A Disk Array Volume Manager for Orchestrated Use of Disks. Proceedings of the USENIXConference on File and Storage Technologies.

Schlosser, S. W., Schindler, J., Papadomanolakis, S., Shao, M., Ailamaki, A., Faloutsos,

C., and Ganger, G. R. 2005. On Multidimensional Data and Modern Disks. Proceedings ofthe 4th USENIX Conference on File and Storage Technology .

Schmidt, A., Waas, F., Kersten, M., Carey, M., Manolescu, I., and Busse, R. 2002a. Xmark:A benchmark for xml data management.

Schmidt, A., Waas, F., Kersten, M. L., Carey, M. J., Manolescu, I., and Busse, R. 2002b.XMark: A Benchmark for XML Data Management. VLDB .

Shanmugasundaram, J., Tufte, K., Zhang, C., He, G., DeWitt, D. J., and Naughton, J. F.

Relational Databases for Querying XML Documents: Limitations and Opportunities. In VLDB1999.

Sivathanu, M., Prabhakaran, V., Popovici, F. I., Denehy, T. E., Arpaci-Dusseau, A. C., and

Arpaci-Dusseau, R. H. 2003. Semantically-Smart Disk Systems. Proceedings of the USENIXSymposium on File and Storage Technologies, 73–88.

SVG. 2008. Scalable vector graphics. http://www.w3.org/Graphics/SVG/ .

Talagala, N., Arpaci-Dusseau, R. H., and Patterson, D. 1999. Microbenchmark-based Ex-traction of Local and Global Disk Characteristics. UC Berkeley Technical Report .

Worthington, B., Ganger, G., Patt, Y., and Wilkes, J. 1995. Online Extraction of SCSIDisk Drive Parameters. Proceedings of ACM Sigmetrics Conference, 146–156.

Xalan. 2007. Xalan-Java. http://xml.apache.org/xalan-j .



XPath. 2007. XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath.

XT. 2007. XT. http://www.blnz.com/xt/index.html .

Yao, B. B., Ozsu, M. T., and Keenleyside, J. 2003. Xbench - a family of benchmarks forxml dbmss. In Proceedings of the VLDB 2002 Workshop EEXTT and CAiSE 2002 WorkshopDTWeb on Efficiency and Effectiveness of XML Tools and Techniques and Data Integrationover the Web-Revised Papers. Springer-Verlag, London, UK, 162–164.


Storing Semi-structured Data on Disk Drives 1mbhadkam/Medha-semi-structured.pdf2 · Medha Bhadkamkar...

Documents

Transcript of Storing Semi-structured Data on Disk Drives 1mbhadkam/Medha-semi-structured.pdf2 · Medha Bhadkamkar...