Staircase Join: Teach a Relational DBMS to Watch its (Axis) Steps

Transcription

1 Stairase Join: Teah a Relational DBMS to Wath its (Axis) Steps Torsten Grust Maurie van Keulen Jens Teubner University of Konstanz Department of Computer and Information Siene P.O. Box D 88, Konstanz, Germany {grust,teubner}@inf.uni-konstanz.de University of Twente Faulty of EEMCS P.O. Box 27, 7500 AE Enshede, The Netherlands m.vankeulen@utwente.nl Abstrat Relational query proessors derive muh of their effetiveness from the awareness of speifi table properties like sort order, size, or absene of dupliate tuples. This text applies (and adapts) this suessful priniple to database-supported XML and XPath proessing: the relational system is made tree aware, i.e., tree properties like subtree size, intersetion of paths, inlusion or disjointness of subtrees are made expliit. We propose a loal hange to the database kernel, the stairase join, whih enapsulates the neessary tree knowledge needed to improve XPath performane. Stairase join operates on an XML enoding whih makes this knowledge available at the ost of simple integer operations (e.g., +, ). We finally report on quite promising experiments with a stairase join enhaned main-memory database kernel. Introdution Relational database management systems (RDBMSs) have repeatedly shown how versatile the relational data model an be. RDBMSs are suessfully used to host types of data whih have formerly not been antiipated to live inside relational databases, e.g., non-first normal form (NF 2, nested) tables, omplex objets, and spatio-temporal data. Permission to opy without fee all or part of this material is granted provided that the opies are not made or distributed for diret ommerial advantage, the VLDB opyright notie and the title of the publiation and its date appear, and notie is given that opying is by permission of the Very Large Data Base Endowment. To opy otherwise, or to republish, requires a fee and/or speial permission from the Endowment. Proeedings of the 29th VLDB Conferene, Berlin, Germany, 2003 This paper ontributes a building blok, the stairase join, that an help relational tehnology to also embrae the tree data type. We ultimately strive for effiient database support for XML data storage and XPath path queries [2]. The work s key observation is that the RDBMS s effiieny an be signifiantly improved with an inreasing level of awareness of the speifi properties of the tree data type. A now quite substantial body of researh work has proposed a number of tree mappings to enode treeshaped data, espeially XML douments, using relations [5, 8,, 6, 7]. These enodings are designed suh that tree-speifis, like the anestor/desendant relationship of two tree nodes, an be reovered by a relational query. This level of tree awareness is suffiient to devise effiient relational implementations of the XPath anestor, parent, hild, and desendant axes. In reent former work, we presented an enoding of XML data, the XPath aelerator [8], whih added real XPath awareness in the sense that all 3 XPath axes ould be supported effiiently. In a nutshell, the XPath aelerator uses the preorder and order ranks of doument nodes to map nodes onto a two-dimensional plane. The evaluation of XPath axis steps then boils down to proess region queries in this pre/ plane. This work is orthogonal in that we build upon the simple XPath aelerator struture exatly as it was desribed in [8], and shift fous to exploit additional properties of the pre/ plane whih help to signifiantly speed up XPath query evaluation. These formerly unexplored properties exlusively derive from the fat that we enode tree-shaped data. Thus, we inrease the level of tree awareness one more. Pure SQL queries are apable of exploiting some of these properties but not all. The gist of this paper thus is the stairase join proposal, a join operator arefully tuned to exploit and enapsulate all tree knowledge present in the pre/ plane. With the stairase join

2 a b e d f i g h j a b e d f i g h j a b e d f i g h j a b e d f i g h j (a) (b) () (d) Figure : XPath axes indue doument regions: shaded nodes are reahable from ontext node f via a step along the (a) preeding, (b) desendant, () anestor, (d) following axes. Leaf nodes denote either empty XML elements, attributes, text, omment, or proessing instrution nodes; inner nodes represent non-empty elements. added to the RDBMS s kernel, SQL again suffies to make full use of the tree awareness now present. The paper proeeds as follows. Setion 2 briefly reviews the ore details of the XPath aelerator idea and the limitations an RDBMS faes if its SQL proessor is not taught about advaned tree properties. Setion 3 introdues the stairase join and disusses the tree-aware optimizations built into the join operator. The pre/ plane makes it partiularly easy to extrat ertain tree properties. This leads to algorithms whih use only a few CPU yles per XML doument node. We disuss the impliations for the implementation of stairase join, espeially in the ontext of the relational main-memory DBMS Monet in Setion 4. The setion loses with a performane assessment of the ideas developed so far. Setion 5 reviews related researh before we onlude in Setion 6. 2 The XPath Aelerator The XPath aelerator [8] is a relational XML doument enoding. Here, relational is meant in the sense of [0]: the enoded doument () is represented as a relational table, (2) an and should be indexed using index strutures native to the RDBMS (preferably B-trees, see below), and (3) may be queried using a relational language, namely SQL. The enoding has been designed with a lose eye on the XPath axes semantis: for eah node of a given XML doument, the four axes preeding, desendant, anestor, and following partition the doument into four disjoint regions. Figure depits the doument regions for a 0-node XML instane as seen from ontext node f. The XPath expression f/preeding::node() abbreviated as f/preeding from now on yields the node sequene (b,, d). Note that the ontext node plus the nodes in the four regions over all doument nodes. The XPath aelerator makes use of this observation: the nodes of a doument are enoded suh that the region notion is maintained. The evaluation of an XPath step along those four axes then amounts to retrieving the nodes ontained in the region assoiated with that axis. All further XPath axes determine easily haraterizable super- or subsets of these regions (e.g., anestor-or-self) or are supported by standard RDBMS join algorithms (e.g., hild, parent) [8]. The fous of this paper will, therefore, be on the four partitioning axes. The atual enoding maps eah node v to its preorder and order traversal rank in the doument tree: v pre(v), (v). Figure 2 shows the two-dimensional pre/ plane that results from enoding the sample XML instane of Figure. Like the original doument tree, the pre/ plane is partitioned into four, now retangular, regions whih haraterize the XPath preeding, desendant, anestor, and following axes, e.g., the nodes f/preeding = (b,, d) are loated in the lower left region with respet to ontext node f. Note that this haraterization of doument regions applies to all nodes in the plane. For example, the upper left region with respet to g hosts the nodes g/anestor = (a, e, f). This means that we an pik any node v and use its loation in the plane to evaluate an XPath step, i.e., make v the ontext node. This turns out to be an important feature when it omes to the implementation of, e.g., XQuery [3], where expressions ompute arbitrary ontext nodes and then traverse from there. Exatly this usage senario led to the development of the present ideas: the XPath aelerator serves as the bak-end of the Pathfinder XQuery ompiler runtime urrently under development at the University of Konstanz. We refer to [8] for a more detailed explanation of the XPath aelerator idea. In what follows we assume that a database stores a single (large) doument. Our disussion readily arries over to multidoument databases (e.g., by introdution of doument identifiers or a new virtual root node under whih several douments may be gathered.)

3 doument node a ontext node e i j 5 f g h d b pre pre a 0 9 b 2 0 d 3 2 e 4 8 f 5 5 g 6 3 h 7 4 i 8 7 j 9 6 Figure 2: Pre/ plane and the orrespoding node enoding table do for the XML doument of Figure. Dashed and dotted lines indiate the doument regions as seen from ontext nodes f ( ) and g ( ), respetively. SELECT DISTINCT v 2.pre 2 FROM do v,do v 2 3 WHERE v.pre > pre() 4 AND v.pre < v 2.pre 5 AND v. > () 6 AND v. > v 2. 8 ORDER BY v 2.pre unique pre ixsan pre do v 2 ixsan pre/ do v Figure 3: Query and assoiated plan. 2. SQL-based XPath Evaluation The pre/ plane enoding enables an RDBMS to translate XPath path expressions to pure SQL queries. The evaluation of an XPath path expression 2 like s /s 2 / /s n leads to a series of n region queries in the pre/ plane where the node sequene output by axis step s i is the ontext node sequene for the subsequent step s i+. (The ontext node sequene for step s is a singleton sequene (v) with v being an arbitrary node.) Note that the XPath semantis require the resulting node sequene to be dupliate free as well as being sorted in doument order [2]. In the pre/ plane of Figure 2, with initial ontext node sequene () and XPath path expression following::node()/desendant::node(), we get ()/following/desendant = (f, g, h, i, j). Let do denote the two-olumn table loaded with the pre/ node enodings (f. Figure 2), then we an systematially translate a path expression into an equivalent SQL query [8]. For the example above, we get the query in Figure 3. 2 The XPath aelerator supports further XPath features like prediates, node tests, et., as well [8]. An analysis of the atual query plan hosen by the optimizer IBM DB2 V7. in this ase shows that a relational database system an ope quite well with this type of query (Figure 3): the RDBMS maintains a B-tree using onatenated (pre, ) keys. The index is used to san the outer (left) do table in pre-sorted order. The atual region query evaluation happens in the inner join input: the prediates in lines 3 and 4 of the SQL query at as index san range delimiters while the prediates in lines 5 and 6 are suffiiently simple to be evaluated during the B-tree index san as well. The join is atually a left semijoin produing its output in pre-sorted order (whih mathes the request in line 8 for a result sorted in doument order). Atually, the query optimizer ould further delimit the index range san in the inner join input. This opportunity derives from the fat that in any tree and for any node v we an antiipate the size of the subtree below v: (v)/desendant = (v) pre(v) + level (v) }{{} h, () where level(v) denotes the length of the path from the root to v whih is obviously bound by h, the height of the overall doument tree. 3 With this tree knowledge available to the RDBMS, the optimizer ould delimit the desendant range san [8] and insert an additional prediate into the initial SQL query: 7 AND v 2.pre v. + h AND v 2. v.pre + h. The inner index range san for the desendant step is now delimited by the atual size of the ontext nodes subtrees and independent of the doument size. In [8] we observed a query speed-up of up to three orders of magnitude. We will see in the sequel that awareness of fats like Equation () an lead to more signifiant improvements in XPath performane. Notie that the unique operator in the plan of Figure 3 is indeed required sine, in general, the join will generate dupliate nodes (see Setion 3.). The generation of dupliates and thus the rather ostly unique operator, however, ould be avoided altogether if the join operator would be informed about the fat that the do table enodes a tree struture. For similar reasons, we furthermore ould improve on the ixsans: sine the node distribution in pre/ plane is not arbitrary, we an atually skip signifiant portions and guide the sans to touh only those nodes whih onstitute the atual result (modulo a small misestimation). 3 The system omputes h at doument loading time. For typial real-world XML instanes we found h 0.

4 This and further knowledge is present in pre/ enodings although not aessible to the query optimizer unless it an be made expliit at the SQL level (as it is the ase with the additional range prediate in line 7 above). 3 The Stairase Join Making the query optimizer of an RDBMS more tree aware would allow it to improve its query plans onerning XPath evaluation. However, inorporating knowledge of the pre/ plane should, ideally, not lutter the entire query optimizer with XML-speifi adaptations. As explained in the introdution, we propose a speial join operator, the stairase join, that exploits and enapsulates all tree knowledge present in the pre/ plane. It behaves to the query optimizer in many ways as an ordinary join, for example, by admitting seletion pushdown. In this setion, we will desribe the stairase join and the tree-aware optimizations it enapsulates. Before we proeed, a note on attributes. Exept for the attribute axis itself, no axis produes attribute nodes. We use a speial enoding for attribute nodes, whih allow them to be filtered out if needed. We disregard attributes in our explanations, however, beause it would lutter them unneessarily. Given numbers and experimental results obviously inlude attribute handling. Whenever the effets of attribute handling are observable, we indiate this via footnotes. 3. Pruning The evaluation of an axis step for a ertain ontext node boils down to seleting all doument nodes in the orresponding region. In XPath, however, an axis step is generally evaluated on an entire sequene of ontext nodes [2]. This leads to dupliation of work if the pre/ plane regions assoiated with the step are a b e d f i g h j (a) a b e d f i g h j Figure 4: (a) Intersetion and inlusion of the anestor-or-self paths of a ontext node sequene. (b) The pruned ontext node sequene overs the same anestor-or-self region and produes less dupliates (3 rather than ). (b) doument node ontext node (a) desendant axis () following axis pre pre (b) anestor axis doument node ontext node (d) preeding axis Figure 5: Overlapping regions (ontext nodes i ). pre pre independently evaluated for eah ontext node. Figure 4 (a) depits the situation if we are about to evaluate an anestor-or-self step for ontext sequene (d, e, f, h, i, j). The darker the path s shade, the more often are its nodes produed in the resulting node sequene whih ultimately leads to the need for dupliate removal operator unique in the query plan of Figure 3 to meet the XPath semantis. Obviously, we ould remove nodes e, f, i whih are loated along a path from some other ontext node up to the root from the ontext node sequene without any effet on the final result (a, d, e, f, h, i, j) (Figure 4 (b)). Suh opportunities for the simplifiation of the ontext node sequene arise for all axes. Figure 5 depits the situation in the pre/ plane as this is the RDBMS s view of the problem (these planes show the enoding of a slightly larger XML doument instane). For eah axis, the ontext nodes establish a different boundary enlosing a different area. Result nodes an be found in the shaded areas. In general, regions determined by ontext nodes an inlude one another or partially overlap (dark areas). Nodes in these areas generate dupliates. The removal of nodes e, f, i earlier is a ase of inlusion. Inlusion an be dealt with by removing the overed nodes from the ontext: for example, 2, 4 for (a) desendant and 3, 4 for () following axis.

5 doument node ontext node 3 2 pre Figure 6: Pruning produes a proper stairase. The proess of identifying the ontext nodes at the over s boundary is referred to as pruning and is easily implemented for a pre/ enoded ontext node sequene. Algorithm gives the pruning proedure for the desendant axis (anestor pruning funtions analogously). pruneontext_des (ontext : table (pre,)) begin result new table (pre, ); prev 0; foreah in ontext do if. > prev then append to result; prev.; return result; end Algorithm : Context pruning for desendant axis, table ontext is assumed to be pre-sorted. After pruning for the desendant or anestor axis, all remaining ontext nodes relate to eah other on the preeding/following axis as illustrated for desendant in Figure 6. The ontext establishes a boundary in the pre/ plane that resembles a stairase. Observe in Figure 6 that the three darker subregions do not ontain any nodes. This is no oinidene. Any two nodes a, b partition the pre/ plane into nine regions R through Z (see Figure 7). There are two ases to be distinguished regarding how both nodes relate to eah other: (a) on anestor/desendant axis or (b) on preeding/following axis. In (a), regions S, U are neessarily empty beause an anestor of b annot preede (region U) or follow a (region S) if b is a desendant of a. Similarly, region Z in (b) is empty, beause a, b annot have ommon desendants if b follows a. The empty regions in Figure 6 orrespond to suh Z regions. An RDBMS that is tree-aware enough to know about pruning and empty regions, ould use R U X S T a V W b Y Z pre (a) Nodes a and b relate to eah other on the anestor/ desendant axis. R U X S V a Y T b W Z pre (b) Nodes a and b relate to eah other on the preeding/ following axis. Figure 7: Empty regions in the pre/ plane. this knowledge to further delimit index range sans and thus exlude the darker regions. A similar empty region analysis an be done for all XPath axes. The onsequenes for the preeding and following axes are more profound. After pruning for, e.g., the following axis, the remaining ontext nodes relate to eah other on the anestor/desendant axis. In Figure 7 (a), we see that for any two remaining ontext nodes a and b, (a, b)/following = S T W. Sine region S is empty, (a, b)/following = T W = (b)/following. Consequently, we an prune a from the ontext (a, b) without affeting the result. If this reasoning is followed through, it turns out that all ontext nodes an be pruned exept the one with the maximum preorder rank in ase of preeding and the minimum order rank in ase of following. For these two axes the ontext is redued to a singleton sequene suh that the stairase join degenerates to a single region query. We will therefore fous on the anestor and desendant axes in the following. 3.2 Basi Stairase Join Algorithm While pruning leads to a signifiant redution of dupliate work, Figure 4 (b) exemplifies that dupliates still remain due to interseting anestor-or-self paths originating in different ontext nodes. A muh better approah results if we separate the paths in the doument tree and evaluate the axis step for eah ontext node in its own partition (Figure 8 (a)). Suh a separation of the doument tree is easily derived from the stairase indued by the ontext node sequene in the pre/ plane (Figure 8 (b)): eah of the partitions [p 0, p ), [p, p 2 ), and [p 2, p 3 ) define a region of the plane ontaining all nodes needed to ompute the axis step result for ontext nodes d, h, and j, respetively. Note that pruning redues the number of these partitions. (Although a review of the details is outside the sope of this text, it should be obvious

6 a a e i b e j d f i f g h g h d j b pre p p 2 p 3 p 0 p p 2 p 3 p 0 (a) Figure 8: The partitions [p 0, p ), [p, p 2 ), [p 2, p 3 ) of the anestor stairase separate the anestor-or-self paths in the doument tree. that the partitioned pre/ plane naturally leads to a parallel XPath exeution strategy.) The basi approah to evaluating a stairase join between a doument and a ontext node sequene thus is to sequentially san the pre/ plane one from left to right seleting those nodes in the urrent partition that lie within the boundary established by the ontext node sequene (see Algorithm 2). Sine the XPath aelerator maintains the nodes of the pre/ plane in the pre-sorted table do, stairase join effetively visits the tree in doument order. The nodes of the final result are, onsequently, enountered and written in doument order, too. The basi algorithm is perhaps most losely desribed as a merge join with a dynami range prediate. It is important to observe that do[i]. in the algorithm is not really a distint lookup for the reord with preorder rank i, sine the reord is enountered during a sequential san. The notation do[i], hene, just means the reord at hand. Note, furthermore, that the algorithm only works orretly on proper stairases, i.e., with an already pruned ontext. Although we presented pruning as a separate pre-proessing stage, stairase join is easily adapted to do pruning on-the-fly, thus saving a separate san over the ontext table. This basi algorithm has several important harateristis: () it sans the do and ontext tables sequentially, (2) it sans both tables only one for an entire ontext sequene, (3) it never delivers dupliate nodes, and (4) result nodes are produed in doument order, so no -proessing is needed to omply with XPath semantis. (b) stairasejoin_des (do : table (pre,), ontext : table (pre,)) begin result new table (pre, ); foreah suessive pair (, 2) in ontext do sanpartition (.pre +, 2.pre,.,<); last node in ontext; n last node in do; sanpartition (.pre +, n.pre,.,<); return result; end stairasejoin_an (do : table (pre,), ontext : table (pre,)) begin result new table (pre, ); first node in ontext; n first node in do; sanpartition (n.pre,.pre,.,>); foreah suessive pair (, 2) in ontext do sanpartition (.pre +, 2.pre, 2.,>); return result; end sanpartition (pre,pre 2,,θ) begin for i from pre to pre 2 do if do[i]. θ then append do[i] to result; end Algorithm 2: Stairase join algorithms (desendant and anestor axes). 3.3 More Tree-Aware Optimization: Skipping The empty region analysis explained in Setion 3. offers another kind of optimization, whih we refer to as skipping. Figure 9 illustrates this for the XPath axis step (, 2 )/desendant. The stairase join is evaluated by sanning the pre/ plane from left to right starting from ontext node. During the san of s partition, v is the first node enountered outside the desendant boundary and thus not part of the result. Note that no node beyond v in the urrent partition ontributes to result (the light grey area is empty). This is, again, a onsequene of the fat that we san the enoding of a tree data struture: node v is following in doument order so that both annot have ommon desendants, i.e., the empty region in Figure 9 is a region of type Z in Figure 7 (b). Stairase join uses this observation to terminate the urrent sanpartition early whih effetively means that the portion of the san between pre(v) and the suessive ontext node pre( 2 ) is skipped. The hange to the basi stairase join algorithm is minimal as only proedure sanpartition is af-

7 doument node ontext node 2 san v skip san pre Figure 9: Skipping tehnique for desendant axis. feted. Proedure stairasejoin_des is merely modified to invoke the new replaement proedure sanpartition_des shown as Algorithm 3. sanpartition_des (pre,pre 2,) begin for i from pre to pre 2 do ( ) if do[i]. < then append do[i] to result; else break; /* skip */ end Algorithm 3: Skipping for the desendant axis. The effetiveness of skipping is high. For eah node in the ontext, we either () hit a node to be opied into the result, or (2) enounter a node of type v whih leads to a skip. To produe the result, we thus never touh more than result + ontext nodes in the pre/ plane while the basi Algorithm 2 would san along the entire plane starting from the ontext node with minimum preorder rank. A similar, although slightly less effetive skipping tehnique an be applied to the anestor axis: if, inside the partition of ontext node, we enounter a node v outside the anestor boundary, we know that v as well as all desendants of v are in the preeding axis of and thus an be skipped. In suh a ase, Equation () provides us with a good estimate whih is maximally off by the doument height h of how many nodes we may skip during the sequential san, namely (v) pre(v). 4 Main-Memory RDBMS Implementation Considerations To assess the viability and the impat of the stairase join idea, we enhaned the kernel of the Monet RDBMS [4] to inorporate the new join operator. The main-memory RDBMS Monet has been hosen as the preferred implementation platform for the aforementioned Pathfinder projet. Additionally, Monet s base type and operator extensibility make the system a suitable experimentation platform. Adding stairase join to a main-memory RDBMS kernel allowed us to study CPU-related and ahe-related adaptations to the original join algorithms. It turns out that stairase join an be optimized well for in-memory operation. We lose this setion with a number of experiments to manifest the effiieny of stairase join. 4. Experimentation Platform We first desribe our experimentation platform, Monet, in order to have some onrete material for illustrative purposes. We then show that CPU-related and aherelated adaptations to the stairase join algorithm are possible. First off, Monet s bulk data type, the binary table (BAT ), is a good math for the two-olumn table do holding the pre/ doument enoding. BATs provide several useful features, like the speial olumn type void: virtual oid. A olumn of this type represents a ontiguous sequene of integers o, o+, o+2,... for whih only the offset o needs to be stored. This not only saves storage spae a doument oupies only about.5 its size in Monet using our storage struture it also allows many operations to be exeuted using positional lookups. For more details about the Monet RDBMS, we refer to [4]. In our experiments, we used a Dual Pentium 4 (Xeon) mahine running on 2.2 GHz, 2 GB mainmemory, a two-level ahe (levels L /L 2 ) of size 8 kb/52 kb, L /L 2 ahe line size 32 byte/28 byte, L /L 2 miss lateny 28 y/387 y = 2.7 ns/76 ns (measured with Calibrator [2]). Without loss of generality, we will use the harateristis of this mahine to illustrate mahine-dependent alulations. 4.2 CPU-related Adaptations The stairase join algorithm basially inludes two loops whih san the ontext and do BATs, respetively. The ontext sequene ordinarily ontains far less elements than the doument, so we onentrate on the inner loop sanpartition_des (Algorithm 3). It sequentially sans a given partition of the do BAT. Eah iteration ontains a omparison and a write to the result BAT (exept for the last iteration). The preorder ranks in table do form a ontiguous sequene. We use Monet s void olumn type and thus only store (and san) the order ranks of 4 byte eah. An L 2 ahe line, hene, ontains

8 pre = doument node ontext node h 2 v pre a a 2 opy san skip san pre = +h Figure 0: Estimation-based skipping (h = height of doument). 28/4 = 32 nodes. On this mahine, CPU work for one iteration in sanpartition_des is about 7 y. 4 For one ahe line, this is 7 y 32 = 544 y whih exeeds the L 2 miss lateny of 387 y. Therefore, Algorithm 3 is CPU-bound so we onentrate on reduing CPU work first. A major part of the CPU work onerns the order rank omparison in the line labeled ( ) in Algorithm 3. For a large part, we an take it out of the main loop as follows. Aording to Equation () on page 3, we an alulate a lower and upper bound for the number of desendants of a node v (0 level(v) h). These bounds establish two diagonals in the pre/ plane (see Figure 0). Take ontext node. Beause a preorder traversal of a tree enounters the desendants of diretly after itself has been visited, it is guaranteed that the first ( ) pre( ) nodes following in the pre/ plane are its desendants. Consequently, we an simply opy these nodes to result without heking their order ranks (opy phase; interval a in the figure). The upper bound tells us that there are at most h additional desendants, whih we an obtain using the original loop (san phase; interval a 2 in the figure). As before, we stop sanning at the first following node found and skip to the next ontext node. We all this tehnique estimation-based skipping, beause we estimate the number of desendants before we enter the tight opy loop. See Algorithm 4. The error of our estimation is maximally h. 5 Therefore, we have restrited order rank omparison to 4 This number has been omputed from the atual assembler instrution latenies of Pentium 4 [6]. 5 We have devised an alternative pre/order enoding that allows exat alulation of (v)/desendant for any node v. As this paper builds upon [8], we used the original enoding desribed there. sanpartition_des (pre,pre 2,) begin estimate min(pre 2, ); /* opy phase */ for i from pre to estimate do append do[i] to result; /* san phase */ for i from estimate + to pre 2 do if do[i]. < then append do[i] to result; else break; /* skip */ end Algorithm 4: Estimation-based skipping (desendant axis). at most h ontext nodes. The remaining nodes, at least result (h ontext ), are simply opied. A single node opy iteration takes about 5 yles. Proessing one L 2 ahe line now takes 5 y 32 = 60 y whih learly underuts L 2 miss lateny. The opy phase is therefore ahe-bound rather than CPUbound. Sine h is small (in the order of tens of nodes, insignifiant in multi-million node douments), the opy phase represents the bulk of the work. The low number of CPU yles is also due to the branh-predition friendliness of stairase join. The loops of both phases have a fixed end ondition and the if onditional always hooses the same (then) branh exept for the last iteration. The branhing behavior of the tight inner loops of stairase join is perfetly preditable suh that the signifiant penalties for instrution retirement are avoided [4]. We now shift our attention to the CPU ahe, as it turned out to be the bottlenek in the opy phase. 4.3 Cahe-related Adaptations The sequential san of the pre/ plane is mainmemory friendly sine CPU ahe lines are fully used. The sequential memory bandwidth of a mahine with two ahe levels an be alulated as follows [4]: LS L2 L L2 + LS L 2 LS L L L = 28 byte 28 byte 76 ns ns 32 byte = 55 MB/s (with LS C = ahe line size of ahe C; L C = ahe miss lateny for ahe C). Pentium 4 like other modern proessors, however, supports hardware prefething whih partially hides the memory and ahe lateny effets: after a startup

9 penalty when the CPU has reognized the purely sequential aess pattern of stairase join it will read two L 2 ahe lines (= 256 byte) ahead. The opy phase uses two data streams (Pentium 4 supports up to 8 independent streams): one load stream (do) and one store stream (result). The simple experiment of evaluating (root)/desendant an show that hardware prefething indeed improves performane of the stairase join. This partiular experiment onsists almost entirely of a opy phase (for query harateristis, see Table ). It showed a bandwidth of bytes read + bytes written exeution time ( do + ontext nodes sanned + result size) 4 byte = exeution time (50, 844, , 05, 22) 4 byte = 59 ms = 79.0 MB/s. Intel suggests [6] that further bandwidth improvement an be obtained by employing software prefething. Given the overall L + L 2 miss lateny, 28 y+387 y = 45 y, it is suggested to additionally put an expliit prefeth-instrution (prefethnta) in the algorithm to prefeth 3 ahe lines ahead. In ombination with extra loop unrolling (reduing loop overhead) and employing Duff s devie [7], the bandwidth was boosted to 805 MB/s. Although the numbers given here are speifi for our platform, we believe a stairase join implementation in another RDBMS may enounter similar onditions and may admit similar optimizations. 4.4 Experiments The stairase join enapsulates tree knowledge by applying the pruning and skipping tehniques desribed in Setions 3 and 4. In the remainder of this setion, we will assess the performane gain ahieved by employing these tehniques. The system used for the experiments is the one desribed in Setion 4.. To ensure the test runs to be reproduible, we used an easily aessible soure of XML douments, namely the XML generator XMLgen, developed for the XMark benhmark projet [5]. For a fixed DTD, this generator produes instanes of ontrollable size. We have used XML instanes of MB up to GB size ( doument nodes). All douments were of height. We hose two queries that generate substantial intermediary results (see Table ; sizes for other douments are proportionally smaller). Both queries use two axis steps: a desendant step from the root and a subsequent desendant or anestor step. A third, fourth, or Q: /desendant ::profile /desendant ::eduation 47,05, ,984,849,360 63,793 Q2: /desendant ::inrease /anestor ::bidder 47,05,22 597, ,93 597,777 Table : Number of nodes in intermediary results ( GB doument; 50,844,982 nodes) further step would behave muh like the seond axis step whih is why we restrited these experiments to two-step paths. Furthermore, we onentrate on desendant and anestor as explained earlier. The queries are evaluated as illustrated here for Q2: r = root(do) s = nametest(stairasejoin_des(do, r), "inrease") s 2 = nametest(stairasejoin_an(do, s ), "bidder") Experiment : Pruning, Avoiding Dupliates The naive way of evaluating an axis step for a ontext node sequene would be to evaluate the step for eah ontext node independently and onstrut the end result from these intermediary results (Setion 3.). One of the advantages of the basi algorithm given in Setion 3.2, is that it avoids the generation of any dupliates that the naive approah would produe. Figure (a) shows the number of result nodes that the anestor step in query Q2 (exluding the name test) would produe using the naive approah and the stairase join. In this experiment, the stairase join saves generation and subsequent removal of the about 75% dupliates. This number is no oinidene, beause the ontext sequene ontains inrease nodes, whih all appear on a path of length 4 up to the root, i.e., for all ontext nodes, level() = 4. A large number of pairs of these paths, however, interset at level 3 leading to a dupliate/node ratio of about 3 /4 (f. Figure 4). The fat that the stairase join algorithm sans doument and ontext tables sequentially and only one has, besides avoiding dupliates, other advantageous onsequenes: exeution times are linear with doument size (see Figure (b)). Moreover, a further effet of the aess pattern is that the result is immediately in doument order, so a ostly sorting phase is avoided. Experiment 2: Effetiveness of Skipping Figures () and (d) assess the effetiveness of the skipping and estimation-based skipping tehniques. The experiment ounts aessed nodes and exeution times for the stairase join in the seond axis step of 6 This number is smaller than the total number of nodes in the doument, sine the result of a desendant step does not ontain any attributes.

10 number of nodes dupliates avoided stairase join doument size [MB] time [ms] stairase join doument size [MB] number of nodes sanned no skipping skipping result size doument size [MB] (a) Avoiding dupliates (Q2) (b) Stairase join performane (Q2) () Effetiveness of skipping no skipping skipping skipping (estimated) IBM DB2 SQL stairase join sj (early nametest) IBM DB2 SQL stairase join sj (early nametest) time [ms] time [ms] time [ms] doument size [MB] doument size [MB] doument size [MB] (d) Effetiveness of skipping (e) Performane omparison (Q) (f) Performane omparison (Q2) Figure : Experimental results (diagrams use a log sale). query Q. Skipping redues the number of nodes aessed to at most result + ontext (see Setion 3.3). The logarithmi sale of () learly shows that the amount of nodes aessed for skipping that do not appear in the result remains limited. 7 The amount of nodes atually skipped (the differene between no skipping and skipping ) is signifiant: about 92 % of the nodes were skipped. This number obviously depends on the query, but the main point is that skipping makes the number of aessed nodes independent of the doument size. The redution in aessed nodes has its effet on exeution times. Under the same onditions (stairase join in seond axis step of query Q), exeution time 7 Beause of attribute filtering, the differene between skipping and result size is slightly larger than ontext. The statement we san at most ontext nodes too many holds nevertheless. is about ut in half ( no skipping vs. skipping for the larger doument sizes in (d)). Employing the ahe onsious implementation of estimation-based skipping (see Setions 4.2 and 4.3) gives an additional performane gain of about 20% ( skipping (estimated) ). Experiment 3: Comparison with IBM DB2 The fous of this paper is on the stairase join and its benefit for evaluating axis steps. Other aspets of XPath like name tests and prediates, have largely been left out of the disussion. For this reason, an axis step like s/anestor::n has up to now been treated as nametest(stairasejoin_an(do, s), n), i.e., first fully evaluate the anestor step for ontext sequene s, and then do a subsequent name test for tag name n. In the introdution, however, we already mentioned that the stairase join behaves to the query optimizer in

11 many ways as an ordinary join, for example, by admitting seletion pushdown. Observe that the result of the stairase join ontains a seletion of nodes from the do table. The subsequent name test is a seletion on tag name n. Pushing the name test through the stairase join, hene, means doing both seletions in opposite order. The tree properties used by the stairase join are entirely based on preorder and order ranks. Those properties remain valid for a subset of nodes. Therefore, stairasejoin_an(nametest(do, n), s) is a valid equivalent of the example. Note that, onsequently, the name test is performed on the entire doument, whih obviously makes sense for seletive name tests only. Figures (e) and (f) ompare exeution times for both queries with and without name test pushdown. In both queries, an exeution plan with name test pushdown shows to be faster by about a fator 3. Future researh on a ost model is intended to let the system intelligently deide for or against name test pushdown or similar rewrites. The experiment furthermore shows the exeution times of an implementation with limited tree awareness (on top of IBM DB2). Considering the performane inreases we have seen for avoiding dupliates, pruning, and skipping, we believe a onventional RDBMS an ahieve an inrease of similar magnitude by employing the stairase join whih is in line with the observations in [7]. Note that, although not expliitly shown in the query plan of Figure 3, IBM DB2 also performs an early name test (the B-tree index atually uses onatenated (pre,, tag name) keys). As a further note, being tree-unaware, an RDBMS query optimizer sometimes makes bad estimations and onsequently hooses bad query plans, whih happened for our query Q2 (this has been observed by others as well [6]): the atual exeution times shown are for the SQL query orresponding with the equivalent manual rewrite [3] of Q2, /desendant::bidder[desendant::inrease]. 5 More Related Researh Reall that the ore operation of stairase join resembles a self merge join of the pre-sorted do table with the join prediate dynamially hanged to trae the stairase boundary (f. Setion 3.2). In [7], the multi-prediate merge join (MPMGJN) was introdued with the speifi purpose to effiiently support interval ontainment prediates. While suh prediates allow to express the semantis of the XPath anestor and desendant axes, MPMGJN has been designed to exploit the hierarhial ontainment of intervals and thus laks further tree awareness: due to pruning and skipping, stairase join touhes and tests less nodes than MPMGJN. Nevertheless, we subsribe to the view expressed in [6, 7], that inreased awareness of data type properties will be ritial in turning RDBMSs into effiient XML proessors. Stairase join is a real self join in the sense that ontext nodes and doument nodes are tuples of the do enoding table. A single B+-tree built at doument loading time suffies to index both, arbitrary ontext sequenes and the doument. This is unlike the approahes desribed in [5] and [9], where a speial purpose index struture needs to be built over ontext and doument (referred to as anestor and desendant lists in [5, 9]) to support anestor or desendant step evaluation with skipping. Like stairase join, the algorithms of [5, 9] depend on the lists being sorted in doument order. The join operators of [5] are based on a modified B+-tree implementation that uses extra sibling pointers. The authors of [9] propose to build new index strutures, the XR-Trees, over ontext and doument. Stairase join derives all pruning and skipping information from the do table itself and it does so using simple integer arithmeti. We do not require the underlying RDBMS s B+-tree implementation to be altered. Furthermore, sine a single B+-tree instane indexes the ontext as well as the pre/ plane, it is likely that less index pages ompete for buffer slots during query evaluation. The oneptual simpliity of stairase join led to algorithms whih exhibit partiularly simple ontrol flow. Just like [4], we found this to be ritial to ahieve high effiieny, espeially in the main-memory RDBMS ontext. Highly preditable branhes in its inner loop and a stritly sequential aess pattern [] make stairase join CPU- and ahe-friendly. Finally, note that stairase join never touhes a node in tables ontext and do more than one (skipping, in fat, helps to avoid touhing a signifiant number of nodes at all). This is in ontrast to, e.g., the EE/EA join algorithms of [] whih repeatedly iterate over ontext and doument in their inner loops. 6 Conlusions The stairase join operator desribed in this paper exploits the tree properties enoded in the pre/ plane to optimize database-supported XPath evaluation. Knowledge of tree properties like subtree size and inlusion/disjointness of subtrees is available in this enoding at the ost of simple integer operations. We have shown that inreased tree awareness an lead to signifiantly improved XPath performane. To avoid luttering the query optimizer with XML speifis, we propose to teah the RDBMS about tree

12 properties by means of a loal hange to its kernel: the addition of a single join operator, the stairase join, enapsulating all tree knowledge. The stairase join has been added to a main-memory RDBMS kernel. In this ontext, we ould demonstrate that stairase join an be optimized well for in-memory operation. Future Researh Ideally, we would like to experiment with a stairase join implementation in a ommerial disk-based RDBMS, if possible. Seondly, in our experiments, we used douments of up to GB. For even larger douments or large multi-doument databases, one evidently needs to apply fragmentation strategies. An interesting strategy is to fragment by tag name. First experiments are enouraging: the exeution time of Q ould be brought down from 345 ms to 39 ms. This strategy should probably be ombined with a partitioning-inspired one (see Setion 3.2) when tag name fragments beome too large. It should be obvious that fragmentation naturally leads to a parallel XPath exeution strategy. Further researh goes in the diretion of a ost model to be able to intelligently hoose between name/node test pushdown and related XPath rewriting laws. Aknowledgments The authors would like to thank the Monet people at CWI (Amsterdam, The Netherlands) for their support and most useful feedbak. Maurie van Keulen has been with the University of Konstanz as a DAAD IN- NOVATEC funded researh fellow. Referenes [] Anastassia Ailamaki, David J. DeWitt, and Mark D. Hill. Data Page Layouts for Relational Databases on Deep Memory Hierarhies. The VLDB Journal, (3), [2] Anders Berglund, Sott Boag, Don Chamberlin, Mary F. Fernandez, Mihael Kay, Jonathan Robie, and Jérôme Siméon. XML Path Language (XPath) 2.0. Tehnial Report W3C Working Draft, Version 2.0, World Wide Web Consortium, November http: // [3] Sott Boag, Don Chamberlin, Fernandez Mary F., Daniela Floresu, Jonathan Robie, and Jérôme Siméon. XQuery.0: An XML Query Language. Tehnial Report W3C Working Draft, World Wide Web Consortium, November TR/xquery. [4] Peter A. Bonz. Monet, a Next-Generation DBMS Kernel for Query-Intensive Appliations. PhD thesis, CWI Amsterdam, [5] Shu-Yao Chien, Zografoula Vagena, Donghui Zhang, Vassilis J. Tsotras, and Carlo Zaniolo. Effiient Strutural Joins on Indexed XML Douments. In Pro. of the 28th VLDB Conferene, pages , Hong Kong, China, August [6] Intel Corporation. Intel PentiumR and Intel XeonR Proessor Optimization Referene Manual, [7] Tom Duff. Netnews ing. jargonfile/d/duffsdevie.html, 984. [8] Torsten Grust. Aelerating XPath Loation Steps. In Pro. of the 2st ACM SIGMOD Conferene, pages 09 20, Madison, Wisonsin, USA, June ACM Press. [9] Haifeng Jiang, Hongjun Lu, Wei Wang, and Beng Chin Ooi. XR-Tree: Indexing XML Data for Effiient Strutural Joins. In Pro. of the 9th ICDE Conferene, Bangalore, India, Marh IEEE Computer Soiety. [0] Hans-Peter Kriegel, Maro Pötke, and Thomas Seidl. Managing Intervals Effiiently in Objet-Relational Databases. In Pro. of the 26th VLDB Conferene, pages , Cairo, Egypt, September [] Quanzhong Li and Bongki Moon. Indexing and Querying XML Data for Regular Path Expressions. In Pro. of the 27th VLDB Conferene, pages , Rome, Italy, September 200. [2] Stefan Manegold. Understanding, Modeling, and Improving Main-Memory Database Performane. PhD thesis, CWI Amsterdam, [3] Dan Olteanu, Holger Meuss, Tim Furhe, and François Bry. Symmetry in XPath. Tehnial Report PMS-FB , Institute of Computer Siene, University of Munih, Germany, Otober 200. [4] Kenneth A. Ross. Conjuntive Seletion Conditions in Main Memory. In Pro. of the 2st ACM Symposium on Priniples of Database Systems (PODS), pages 09 20, Madison, Wisonsin, June ACM Press. [5] Albreht Shmidt, Florian Waas, Martin Kersten, Mihael J. Carey, Ioana Manolesu, and Ralph Busse. XMark: A Benhmark for XML Data Management. In Pro. of the 28th VLDB Conferene, pages , Hong Kong, China, August [6] Igor Tatarinov, Stratis D. Viglas, Kevin Beyer, Jayavel Shanmugasundaram, Eugene Shekita, and Chun Zhang. Storing and Querying Ordered XML Using a Relational Database System. In Pro. of the 2st ACM Symposium on Priniples of Database Systems (PODS), Madison, Wisonsin, June ACM Press. [7] Chun Zhang, Jeffrey Naughton, David DeWitt, Qiong Luo, and Guy Lohman. On Supporting Containment Queries in Relational Database Management Systems. In Pro. of the 20th ACM SIGMOD Conferene, pages , Santa Barbara, California, May 200. ACM Press.