PAXQuery: Efficient Parallel Processing of Complex XQuery Jesús Camacho-Rodríguez, Dario Colazzo, Ioana Manolescu
To cite this version:
Jesús Camacho-Rodríguez, Dario Colazzo, Ioana Manolescu. PAXQuery: Efficient Parallel Processing of Complex XQuery. BDA’2014: 30e journées Bases de Données Avancées, Oct 2014, Grenoble- Autrans, France. hal-01086809
HAL Id: hal-01086809 https://hal.archives-ouvertes.fr/hal-01086809 Submitted on 25 Nov 2014
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 1 PAXQuery: Efficient Parallel Processing of Complex XQuery Jesus´ Camacho-Rodr´ıguez, Dario Colazzo, and Ioana Manolescu
Abstract—Increasing volumes of data are being produced and exchanged over the Web, in particular in tree-structured formats such as XML or JSON. This leads to a need of highly scalable algorithms and tools for processing such data, capable to take advantage of massively parallel processing platforms. This work considers the problem of efficiently parallelizing the execution of complex nested data processing, expressed in XQuery. We provide novel algorithms showing how to translate such queries into PACT, a recent framework generalizing MapReduce in particular by supporting many-input tasks. We present the first formal translation of complex XQuery algebraic expressions into PACT plans, and demonstrate experimentally the efficiency and scalability of our approach.
Index Terms—XQuery processing, XQuery parallelization, XML data management. ✦
1 INTRODUCTION In this work, we are interested in the implicit parallelization To scale data processing up to very large data volumes, of XQuery [40], the W3C’s standard query language for XML platforms are increasingly relying on implicit parallel frame- data. The language has been recently enhanced with features works [8], [19], [48]. The main advantage of using such geared towards XML analytics [21], such as explicit group- frameworks is that processing is distributed across many ing. Given a very large collection of documents, evaluating sites without the application having to explicitly handle data an XQuery query that navigates over these documents and fragmentation, fragment placement etc. also joins results from different documents raises performance By far the most widely adopted framework, MapRe- challenges, which may be addressed by parallelism. In contrast duce [19] features a very simple processing model consisting with prior work [12], [18], [27], we are interested in implicit of two operations, Map which distributes processing over sets parallelism, which does not require the application (or the of (key, value) pairs, and Reduce which processes the sets of user) to partition the XML input nor the query across many results computed by Map for each distinct key. However, the nodes. simplicity of this processing model makes complex compu- The contributions of this work are the following: tations hard to express. Therefore, high-level data analytics languages such as Pig [36], Hive [45] or Jaql [11], that 1) We present a novel methodology for massively parallel are translated (compiled) into MapReduce programs, have evaluation of XQuery, based on PACT and previous emerged. Still, complex processing translates to large and com- research in algebraic XQuery optimization. plex MapReduce programs, which may miss parallelization 2) We provide a translation algorithm from the algebraic opportunities and thus execute inefficiently. operators required by a large powerful fragment of Recently, more powerful abstractions for implicitly parallel XQuery into operators of the PACT parallel frame- data processing have emerged, such as the Resilient Dis- work. This enables parallel XQuery evaluation without tributed Datasets [48] or Parallelization Contracts [8] (PACT, requiring data or query partitioning effort from the in short). In particular, PACT generalizes MapReduce by application. (i) manipulating records with any number of fields, instead Toward this goal, we first translate XML data instances of (key, value) pairs, (ii) enabling the definition of custom (trees with identity) into PACT nested records, to ensure parallel operators by means of second-order functions, and XML query results are returned after the PACT manip- (iii) allowing one parallel operator to receive as input the ulations of nested records. outputs of several other such operators. The PACT model Second, we bridge the gap between the XQuery algebra, lies at the core of the Stratosphere platform [44], which can and in particular, many flavors of joins [20], [31], [32] read data from and write data to the Hadoop Distributed File going beyond simple conjunctive equality joins, and System (HDFS) [3]. PACT operators which (like MapReduce) are fundamen- tally designed around the equality of key values in their • Jesus´ Camacho-Rodr´ıguez and Ioana Manolescu are with Inria and Uni- inputs. versite´ Paris-Sud. Batimentˆ 650 (PCRI), 91405 Orsay Cedex, France. Our translation of complex joins into PACT is of interest E-mail: jesus.camacho [email protected], [email protected]. beyond the XQuery context, as it may enable compiling • Dario Colazzo is with Universite´ Paris-Dauphine. Place du Marchal de Lattre de Tassigny, 75775 Paris Cedex, France. other high-level languages [11], [36], [45] into PACT to E-mail: [email protected]. take advantage of its efficiency. 3) We fully implemented our translation technique into our 2
xmlwrite In contrast, given this query, PAXQuery generates in a fully automated fashion the PACT program shown in Figure 1. We reduce(post) outline here its functioning while on purpose omitting details, which will be introduced later on. The xmlscan(‘people’) cogroup($i=$b) cogroup($i=$s) and xmlscan(‘closed auctions’) operators scan (in parallel) the respective collections and transform each document into a
map(navigation1) map(navigation2) record. Next, the map operators navigate in parallel within the records thus obtained, following the query’s XPath expres- sions, and bind the query variables. The next operators in the xmlscan ‘people’ xmlscan ‘closed auctions’ ( ) ( ) PACT plan (cogroup) go beyond MapReduce. In a nutshell, Fig. 1. Outline of the PACT program generated by PAX- a cogroup can be seen as a reduce operator on multiple Query for the XQuery in Example 1. inputs: it groups together records from all inputs sharing the same key value, and then it applies a user-defined function on PAXQuery platform. We present experiments demon- each group. In this example, the functions are actually quite strating that our translation approach (i) effectively complex (we explain them in Section 5). The difficulty they parallelizes XQuery evaluation taking advantage of the have to solve is to correctly express (i) the disjunction in the PACT framework, and (ii) scales well beyond alternative where clause of the query, and (ii) the outerjoin semantics approaches for implicitly parallel XQuery evaluation, in frequent in XQuery: in this example, a
let $ic := collection( ‘items ’) Operator Annotations Q1 let $i := $ic/site/regions//item Parallelization Compiler hints return count($i) Data Data contract let $ic := collection( ‘items ’) User function (UF) for $i in $ic/site/regions//item Q let $l := $i/location/text() Fig. 3. PACT operator outline. 2 group by $l return
fields fi1 ,fi2 ,...,fik . We denote by r[i] and r.key the field i records that share the same key. Given a bag of input and the key of record r, respectively. A ⊥-record is a record records I1: whose fields consist of null (⊥) values. Finally, R denotes the crd(I1)= {s = {{r1,r2,...,rm}} | r1,r2,...,rm ∈ I1 infinite domain of records. and r1.key = r2.key = ... = rm.key and ′ ′ Path indexes are needed to describe navigation through 6∃r ∈ I \ s such that (r .key = r1.key)} records. A path index pi obeys the grammar pi := j.pi | ǫ, • Cross builds the cartesian product of two inputs. with j ≥ 0. Navigation through r along a path index j.pi first • Match builds all pairs of records from its two inputs, selects r[j]. If pi is empty (ǫ), then we are at the target field. which share the same key. Thus, given I1,I2 ⊂R: 4
XQuery Data position within another. In particular, nested queries challenge XQuery Model (XDM) the optimizer, as straightforward translation into nested plans leads to very poor performance. For instance, in Figure 2, Q3 contains a nested subquery for $t ... return $t (shown XML algebra Extended XQuery indented in the figure); let us call it Q4 and write Q3 = e(Q4). expression Data Model (EXDM) A na¨ıve algebraic expression of such a query would evaluate Q4 once per result of e in order to compute Q3 results, which is typically inefficient. PACT plan PACT Data Model Efficient optimization techniques translate nested XQuery into unnested plans relying on joining and grouping [20], [31], [32]. Thus, a smarter method to represent such query is to connect the sub-plans of Q4 and e with a join in the plan of Stratosphere XQuery XML Q ; the join condition in this example is $b=$i. Depending system results 3 documents on the query shape, such decorrelating joins may be nested and/or outer. Fig. 4. Translation process overview. Our goal is to complement existing engines, which translate
cmt(I1,I2)= {{(r1,r2) | r1 ∈ I1,r2 ∈ I2 and from XQuery to an internal algebra, by an efficient compilation r1.key = r2.key}} of this algebra into an implicit parallel framework such as • CoGroup can be seen as a “Reduce on two inputs”; it PACT. This enables plugging a highly parallel back-end to an groups the records from both inputs, sharing the same XQuery engine to improve its scalability. Accordingly, we aim key value. Formally, given I1,I2 ⊂R: to adapt to any XML query algebra satisfying the following ccg(I1,I2)= {s = {{r11,...,r1m,r21,...,r2j}} | two assumptions: r11,...,r1m ∈ I1 and r21,...,r2j ∈ I2 • The algebra is tuple-oriented (potentially using nested and ∀r, r′ ∈ s : r.key = r′.key tuples). ′′ and 6∃r ∈ (I1 ∪ I2) \ s • The algebra is rich enough to support decorrelated ′′ such that r .key = r11.key} (unnested) plans even for nested XQuery; in particular we consider that the query plan has been unnested before 4 OUTLINE we start translating it into PACT. Our approach for implicit parallel XQuery evaluation is to Three observations are in order here. translate XQuery into PACT plans as depicted in Figure 4. First, to express complex queries without nesting, the al- The central vertical stack traces the query translation steps gebra may include any type of joins (conjunctive/disjunctive, from the top to the bottom, while at the right of each step we value or identity-based, possibly nested, possibly outer), as show the data models manipulated by that step. well as grouping; accordingly, we must be able to translate all First, the XQuery query is represented as an algebraic such operators into PACT. expression, on which multiple optimizations can be applied. Second, a tuple-based algebra for XQuery provides border XQuery translation into different algebra formalisms and the operators for (i) creating tuples from XML trees, in leaf subsequent optimization of resulting expressions have been operators of the algebraic plan; (ii) constructing XML trees extensively studied [9], [14], [39], [49]. In Section 4.1, we out of tuples, at the top of the algebraic plan, so that XML characterize the class of XML algebras over which our trans- results can be returned. lation technique can be applied, while we present the nested- Finally, we require no optimization but unnesting [32] to tuple data model and algebra used by our work in Section 4.2. be applied on the XML algebraic plan before translating it to Second, the XQuery logical expression is translated into a PACT; however, any optimization may be applied before (and PACT plan; we explain this step in detail in Section 5. orthogonal to) our translation. Finally, the Stratosphere platform receives the PACT plan, optimizes it, and turns it into a data flow that is evaluated in 4.2 Algebra and data model parallel; these steps are explained in [8]. In the sequel, we present our work based on the algebra in [31]. We describe the nested tuple data model manipulated by this 4.1 Assumptions on the XQuery algebra algebra, then present its operators. Numerous logical algebras have been proposed for Nested tuples data model for XML. The data model extends XQuery [9], [20], [31], [39]. While the language has a the W3C’s XPath/XQuery data model with nested tuples to functional flavor, most algebras decompose the processing of facilitate describing algebraic operations. a query into operators, such as: navigation (or tree pattern Formally, a tuple t is a list of variable-value pairs: matching), which given a path (or tree pattern) query, extracts (($V 1,v1), ($V 2,v2),..., ($V k,vk)) from a document tuples of nodes matching it; selection; where the variable names $V i are all distinct, and each value projection; join etc. vi is either (i) an item, which can be an XML node, atomic A significant source of XQuery complexity comes from value or ⊥, or (ii) a homogeneous collection of tuples (see nesting: an XQuery expression can be nested in almost any below). 5
e matched in a single pass over the input [16]. In the spirit of 1 $pc:* e2 $cc:* generalized tree patterns [17], annotated tree patterns [37], site $c: closed auction or XML access modules [5], we assume a navigation (nav) people n: $u operator parameterized by an extended tree pattern (ETP) buyer seller $a: itemref $p: person supporting multiple returning nodes, child and descendant n: $t $b: @person $s: @person axis, and nested and optional edges. $i: @id $n: name constr L Consider the ETP e1 in Figure 5. The node labeled $n:name
S5:=($pc, $p, $i, $t{$n}, is (i) optional and (ii) nested with respect to its parent node $r{$cc, $c, $b, $s, $u{$a}}) $p:person, since by XQuery semantics: (i) if a given $p lacks l a name, it will still contribute to the query result; (ii) if a nojoin$i=$b∨$i=$s S2:=($pc, $p, $i, $t{$n}) given $p has several names, let binds them all into a single S4:=($cc, $c, $b, $s, $u{$a})
nav e1 nav e2 node collection. The operator nav e1 concatenates each tuple
S1:=($pc) S3:=($cc) successively with all @id attributes (variable $i) and name scan(‘people’) scan(‘closed auctions’) elements (variable $n) resulting from the embeddings of e1 in the value bound to $pc. Observe that variable $n is nested Fig. 5. Sample logical plan for the query in Example 1. into variable $t, which did not appear in the original query; Three flavours of collections are considered, namely: lists, in fact, $t is created by the XQuery to algebra translation to hold the nested collection with values bound to $n. The bags and sets, denoted as (t1,t2,...,tn), {{t1,t2,...,tn}}, operator nav e2 is generated in a similar fashion. Therefore, in and {t1,t2,...,tn}, respectively. Tuple schemas are needed for our discussion. The schema the previous query, ETPs e1 and e2 correspond to the following fragment: S of a tuple t is a set of pairs {($V 1,S1),..., ($V n,Sn)} where each Si is the schema of the value of the variable $V i. for $p in $pc/site/people/person, $i in $p/@id We use val to denote the type of (any) atomic value, and let $n := $p/name node to denote an XML node type. Further, a collection of let $r := for $c in $cc//closed_auction, values has the schema C{S} where C is list, bag, or set, $b in $c/buyer/@person, depending on the kind of collection, and S is the schema of $s in $c/seller/@person all values in the collection i.e., only homogeneous collections let $a := $c/itemref are considered. The concatenation of two tuples t1 and t2 is denoted by Above the nav operators in Figure 5, we find a nested join l t1+t2. (nojoinρ) on a disjunctive predicate ρ, which selects those Algebraic representation of XQuery. In the following, we people that appear as buyers or sellers in an auction. introduce the translation process and the main operators by Finally, the XML construction (constr L) is the border example. A methodology for translating our XQuery dialect operator responsible for transforming a collection of tuples into the algebra we consider was described in [6], and de- to XML forests [23], [43]. The information on how to build tailed through examples in [30]. The complete list of algebra the XML forest is specified by a list L of construction tree operators and their semantics can be found in Appendix B. patterns (CTPs in short), attached to the constr operator. For Example 1 (continuation). The algebraic plan corresponding each tuple in its input, constr L builds one XML tree for each to the XQuery introduced in Section 2 is shown in Figure 5. CTP in L [31]. In our example, L contains a single CTP that For simplicity, we omit the variable types in the operators generates for each tuple an XML tree consisting of elements schema and only show the variable names. We discuss the of the form
TABLE 1 vi → ri i =1 ...n Auxiliary functions details. (TUPLE) (($V 1,v1),... ($V ,v )) → r1+ ... +r n n n Signature Description v ::node Given the variable paths V bound to XML (XMLNODE) id nodes according to S, returns the index v → ( (v),v) S V F ; 7→id path positions F in S-records correspond- v ::val ing to the XML node IDs. (ATOMICVALUE) v → (v) Given a list of variable paths V bound to XML nodes, atomic values or collections, v C S v t1,t2,...,t :: { } ≡ [ m] S; V 7→v F according to S, returns the index path ti → ri i =1 ...m positions F of the values of those variables (COLLVALUE) v → ((r1,...,rm)) in S-records. S; V 7→id,v F “Union” of the two previous functions. Fig. 6. Data model translation rules. Given a list of CTPs L, returns the CTPs S; L 7→ L′ L′ where variables are replaced with cor- responding fields in S-records. 5 XML ALGEBRATO PACT Given an ETP e whose root is a variable Within the global approach depicted in Figure 4, this section S; e 7→ e′ in S, builds a new ETP e′ rooted with the describes our contribution: translating (i) from the Extended corresponding field position in S-records. ′ As above (replace ETPs with predicates). XQuery Data Model (or EXDM, in short) into the PACT Data S; ρ 7→ ρ Given a predicate ρ referencing variables Model (Section 5.1) and (ii) from algebraic expressions into ′ in tuples in S1 and S2, generates a new S1,S2 ρ ρ PACT plans (Section 5.2). The most complex technical issues ; 7→ predicate ρ′ referencing field positions in are raised by the latter. S1- and S2-records. XQuery algebraic plans are translated into PACT plans recursively, operator by operator; for each XQuery operator, the translation outputs one or several PACT operators for with two fields: the first one contains the XML ID, while which we need to choose (i) the parallelization contract the second is the text serialization of the XML tree rooted at (and possibly its corresponding key fields), and (ii) the user the node. In turn, rule (ATOMICVALUE) translates an XML function, which together determine the PACT behavior. The value. Finally, rule (COLLVALUE) translates a tuple collection hardest to translate are those algebraic operators whose input into a single-field record that contains the nested collection of cannot be fragmented based on conjunctive key equalities records corresponding to the tuples in the input. (e.g., disjunctive joins) . This is because all massively parallel operators in PACT are based on key equality comparisons [8]. Translation rules. As in [39], we use deduction rules to 5.2 Translating algebraic expressions to PACT specify our translation. In a nutshell, a deduction rule describes Rules for translating an algebraic expression into a PACT how the translation is performed when some conditions are plan are based on judgments of the form A⇒P , or: met over the input. Our rules rely on translation judgments, “A translates into a PACT plan P”. All rules are defined noted as J, Ji, and are of the form: recursively over the structure of their input A; for instance, ′ ′ cond J1 ... Jn the translation of A = sel ρ(A ) relies on the PACT plan P J resulting from the translation of the smaller expression A′, stating that the translation J (conclusion) is recursively made and so on. in terms of translations J1 ... Jn (premises) when the The specific behavior of each rule is encoded in the choice (optional) condition cond holds. The translation judgments Ji of the parallelization contracts (and corresponding keys) and are optional; their absence denotes that the rule handles the the user functions, so this is what we comment on below. “fixpoint” (start of the recursive translation). Preliminaries. In the translation, we denote a PACT operator by its parallelization contract c, user function f and the list 5.1 Translating XML tuples into PACT records K of key field positions in the PACT input. In particular: K Rules for translating instances of EXDM into those of PACT • a unary PACT is of the form cf ; if K=∅, for simplicity rely on translation judgments of the form t → r , or: “the we omit it and use just cf . K1,K2 EXDM instance t translates into the PACT record r”. • a binary PACT is of the form cf , assuming that the The translation rules appear in Figure 6, where + denotes key of the left input records consists of the fields K1 and record concatenation. Rules produce records whose key fields that of the right input records of K2, respectively. are not set yet; as we will see in Section 5.2, the keys are To keep track of attribute position through the translation, filled in by the translation. we use a set of helper functions associating to variables Rule (TUPLE) produces a record from a tuple: it translates from S, the index positions of the corresponding fields in each tuple value, and then builds the output record r by the PACT records. These functions are outlined in Table 1; concatenating the results according to tuple order. we use the term S-records as a shortcut for records obtained There are three rules that can be triggered by rule (TUPLE). by translating tuples that conform to schema S. The helper First, rule (XMLNODE) translates an XML node into a record functions implementation details are quite straightforward. 7
a) constr L e A⇒P $pc:* ′ S3:=($o, $s{$pc, $p, $r{$n}}) SA; L 7→ L people (CONSTRUCTION) grp∅,{$o},$s constr L(A) ⇒ xmlwriteL′ (P) $p: person S2:=($pc, $p, $o, $r{$n}) n: $r nav e watches $n: name (SCAN) scan(f) ⇒ xmlscan(f) S1 pc :=($ ) watch scan ‘people’ Fig. 7. Border operators translation rules. ( ) $o: @open auction
b) K:=(#6) A⇒P mp ′ ′ ′ xmlscan(‘people’) nav(e ) rdgrp(K) xmlwriteL′ SA; e 7→ e f := nav(e ) (NAVIGATION) nav e(A) ⇒ mpf (P) Fig. 9. Logical expression (a) and corresponding PACT A⇒P plan (b) for the query in Example 2. ′ ′ SA; Gid 7→id Gid SA; Gv 7→v Gv ′ ′ ′ K := Gid + Gv f := grp(K) from the (possibly partial) embeddings of e in each input (GROUP-BY) grp rdK record. Gid ,Gv ,$r(A) ⇒ f (P) Rule (GROUP-BY) translates a group-by expression into A⇒P a PACT with a Reduce contract, as the records need to be SA; p 7→v pi f := flat(pi) (FLATTEN) partitioned by the value of their grouping fields. The fields flat mp p(A) ⇒ f (P) in K, which form the key used by the Reduce contract, are ′ ′ A⇒P obtained appending Gv to Gid . K is also handed to the grp ′ ′ SA; ρ 7→ ρ f := sel(ρ ) UF, which creates one record from each input collection of (SELECTION) records. The new record contains the values for each field in sel ρ(A) ⇒ mpf (P) K, and a new field which is the collection of the input records A⇒P ′ ′ themselves. SA; V 7→id,v V f := proj (V ) (PROJECTION) proj V (A) ⇒ mpf (P) Example 2. The following XQuery groups together the peo- ple that share interest in the same auctions: A⇒P let $pc := collection( ‘people ’) SA; p 7→v pi if p.length 6=1 for $p in $pc//people/person, $o $p/watches/watch/@open_auction then agg pi in f := n( ,a) U := mpf let $n := $p/name K else K := ∅ f := agg(pi,a) U := rdf group by $o (AGGREGATION) return
Rule (FLATTEN) translates a flatten expression into a Map 5.2.1 Border operators translation PACT, that applies the flattening UF flat on each input record Figure 7 outlines the translation of border operators. independently. The path pi to the nested collection is obtained Rule (CONSTRUCTION) translates the logical constr L op- from p using SA. erator into a data sink that uses our output function xmlwrite. Rule (SELECTION) produces a Map PACT that applies the For each input record from P, xmlwrite generates XML selection to each record produced by P. Selection is performed content using the list of construction patterns in L′ and writes by the sel UF, which uses the filtering condition ρ′ obtained the results to a file. from ρ and SA. Rule (SCAN) translates the logical operator scanf into a Rule (PROJECTION) translates a projection expression into data source built up by means of our input function xmlscan. a PACT using a Map contract. The positions V ′ of the fields For each XML document in f, xmlscan returns a single-field that should be kept by the projection are obtained from V record holding the content of the document. using the schema SA. The translation of (AGGREGATION) is interesting as it can 5.2.2 Unary operators translation use one PACT or another, depending on the path p to the Unary operators are translated by the rules in Figure 8. variable being aggregated. If the variable is contained in a Rule (NAVIGATION) uses an auxiliary judgment that trans- nested collection, i.e., p.length 6= 1, we produce a PACT with ′ lates the input ETP e into e using SA. Navigation is applied a Map contract; for each input record, the aggn UF executes over each record independently, and thus we use a PACT with the aggregation operation a over the field pointed by pi and a Map contract. The UF is nav, which generates new records outputs a record with the aggregation results. 8
a) e A1 ⇒P1 A2 ⇒P2 1 $pc:* e2 $cc:* f := concat site (CARTESIANPRODUCT) $c: closed auction 1 2 1 2 prod(A , A ) ⇒ crf (P , P ) people n: $u buyer $a: itemref $p: person $b: @person A1 ⇒P1 A2 ⇒P2 n: $t ′ SA1 ,SA2 ; ρ 7→ ρ $i: @id $n: name ′ ′ constr L ρ ⇀l K1 ρ ⇀r K2 f := concat (∧ JOIN= ) K1,K2 S5:=($pc, $p, $i, $t{$n}, $r{$cc, $c, $b, $u{$a}}) joinρ(A1, A2) ⇒ mtf (P1, P2) l nojoin$i=$b A1 ⇒P1 A2 ⇒P2 S2:=($pc, $p, $i, $t{$n}) S4:=($cc, $c, $b, $u{$a}) ′ SA1 ,SA2 ; ρ 7→ ρ nav e1 nav e2 ′ ′ ρ ⇀l K1 ρ ⇀r K2 f := oconcat l S1:=($pc) S3:=($cc) (LO ∧ JOIN= ) l K1,K2 scan(‘people’) scan(‘closed auctions’) ojoinρ(A1, A2) ⇒ cgf (P1, P2)
A1 ⇒P1 A2 ⇒P2 ′ b) xmlwriteL′ SA1 ,SA2 ; ρ 7→ ρ ′ ′ ρ ⇀l K1 ρ ⇀r K2 f := noconcat l (NLO ∧ JOIN= ) cgnoconcatl l K1,K2 nojoinρ(A1, A2) ⇒ cgf (P1, P2) K1:=(#6) K2:=(#6) mp ′ mp ′ Fig. 10. Cartesian product and conjunctive equi-join nav(e1) nav(e2) translation rules. xmlscan(‘people’) xmlscan(‘closed auctions’)
Otherwise, if the aggregation is executed on the complete Fig. 11. Logical expression (a) and corresponding PACT input collection, we use a Reduce contract wrapping the input plan (b) for the query in Example 3. in a single group. The agg UF creates an output record having (i) a field with a nested collection of all input records and (ii) a sharing the same key. Then, the oconcat UF that we describe field with the result of executing the aggregation a over the l next is applied over each group, to produce the expected result. field pointed by pi. Finally, rule (DUPLELIM) translates a duplicate elimination Definition 1 (oconcat l): The left outer concatenation UF, ′ ′ expression into a PACT with a Reduce contract. Each group oconcat l, of two record bags {{r1,...,rx}} and {{r1,...,ry}} handed to the UF holds the bag of records containing the same is defined as: values in the fields pointed by K; the duplicate elimination UF, • If y 6= 0, the cartesian product of the two bags. ′ ′ denoted by dupelim, outputs only one record from the group. • Otherwise, {{r1+ ⊥ ,...,rx+ ⊥ }} i.e., concatenate each left input record with a ⊥-record having the schema 5.2.3 Binary operators translation (structure) of the right records. ⋄ The rules are depicted in Figure 10; we assume that the inputs b.3) Nested left outer conjunctive equi-join. Similar to the A1 and A2 of the algebraic binary operator translate into the non-nested case, rule (NLO ∧ JOIN=) translates the nested PACT plans P1 and P2. left outer conjunctive equi-join into a CoGroup PACT whose a) Cartesian product. This operator requires the simple key is extracted from ρ′. However, we need a different UF in concatenation UF, taking as input a pair of records, and order to generate the desired right-hand side nested records, outputting their concatenation: concat(r1,r2)= r1+r2. and we define it below. Rule (CARTESIANPRODUCT) translates a cartesian product into a Cross PACT with a concat UF. Definition 2 (noconcat l): The nested left outer concate- b) Joins with conjunctive equality predicates. This family nation UF, noconcat l, of the bags {{r1,...,rx}} and ′ ′ comprises joins on equality predicates, which can be simple {{r1,...,ry}} is defined as: ′ ′ ′ ′ (natural) equi-joins, or outer joins (without loss of generality • If y 6= 0, {{r1+(r1,...,ry), ...,rx+(r1,...,ry)}} i.e., we focus on left outer joins). nest the right set as a new field concatenated to each b.1) Conjunctive equi-join. The conjunctive equi-join oper- record from the left. ′ ′ • Otherwise, {{r +(⊥ ),...,r +(⊥ )}} i.e., add to each ator is translated by rule (∧ JOIN=), as follows. First, the 1 x ′ left record a field with a list containing a ⊥-record predicate ρ over A1 and A2 translates into a predicate ρ conforming to the schema of the right records. ⋄ over records produced by P1 and P2. Then, the list of fields pointed by the left (⇀l), resp. right (⇀r) of the condition ′ Example 3. The following XQuery extracts the name of users ρ are extracted, and finally they are used as the keys of the and the items that they bought (if any): generated Match PACT. let $pc := collection( ‘people ’), b.2) Left outer conjunctive equi-join. In the rule (LO $cc := collection( ‘ closed auctions ’) for $p in $pc/site/people/person, $i in $p/@id ∧ JOIN=), the output PACT is a CoGroup whose keys are ′ let $n := $p/name taken from the fields of the translated join predicate ρ . The let $r := CoGroup contract groups the records produced by P1 and P2 for $c in $cc//closed_auction, 9
a) e1 $pc:* A1 ⇒P1 A2 ⇒P2 e2 $cc:* ′ ′ ′ ′ SA1 ,SA2 ; ρ 7→ ρ ρ ≡ ρ1 ∨ ... ∨ ρn site ′ ′ $c: closed auction ρk ⇀l K1k ρk ⇀r K2k people ′ buyer seller fk := pnjoin(ρ ,k−1) k =1 ...n K11,K21 K1n,K2n $p: person $b: @person $s: @person U := {mtf1 ,..., mtfn } (∨ JOIN= ) n: $r joinρ(A1, A2) ⇒ U(P1, P2) $i: @id $n: name constr L A1 ⇒P1 A2 ⇒P2 S5:=($pc, $p, $i, $r{$n}, $cc, $c, $b, $s) ′ ′ ′ ′ SA1 ,SA2 ; ρ 7→ ρ ρ ≡ ρ1 ∨ ... ∨ ρn ′ ′ join$i=$b∨$i=$s ρk ⇀l K1k ρk ⇀r K2k ′ S2:=($pc, $p, $i, $r{$n}) S4:=($cc, $c, $b, $s) fk := nopnjoinl(ρ ,k−1) k =1 ...n nav nav K11,K21 K1n,K2n e1 e2 U := {cgf1 ,..., cgfn } ′ S1:=($pc) S3:=($cc) SA1 K f := opost l∨ (LO JOIN= ) scan(‘people’) scan(‘closed auctions’) l K ∨ ojoinρ(A1, A2) ⇒ rdf ′ (U(P1, P2))
A1 ⇒P1 A2 ⇒P2 b) xmlwriteL′ ′ ′ ′ ′ K1 := (#6) SA1 ,SA2 ; ρ 7→ ρ ρ ≡ ρ1 ∨ ... ∨ ρn ′ ′ K2 := (#6) ′ ′ ρk ⇀l K1k ρk ⇀r K2k ′ mtpnjoin(ρ ,0) K′ mtpnjoin(ρ ,1) ′ K1 := (#6) K2 1 ′ ′ fk := nopnjoinl(ρ ,k−1) k =1 ...n K2 := (#8) K1 K2 K11,K21 K1n,K2n ′ mp ′ mp ′ U := {cgf1 ,..., cgfn } ρ := (#6=#6)∨ nav(e1) nav(e2) ′ (#6=#8) SA1 K f := nopost l∨ (NLO JOIN= ) l K ∨ nojoinρ(A1, A2) ⇒ rdf ′ (U(P1, P2)) xmlscan(‘people’) xmlscan(‘closed auctions’)
Fig. 12. Disjunctive equi-join translation rules. Fig. 13. Logical expression (a) and corresponding PACT plan (b) for the query in Example 4. $b in $c/buyer/@person let $a := $c/itemref where $i = $b Example 4. The following XQuery extracts the names of return $a users involved in at least one auction, either as buyers or return K1 := (#6) conjunction, a Reduce post-processing PACT groups all xmlwriteL′ K2 := (#6) resulting combinations having the same left hand-side ′ K1 := (#6) ′ rd record; if none of such combinations exists, the left K2 := (#8) nopost l∨ ′ hand-side record representing a group is concatenated ρ := #6=#6∨ K3 K3 #6=#8 cg ′ cg ′ to a (nested) -record conforming to the right input nopnjoinl(ρ ,0) nopnjoinl(ρ ,1) ⊥ K3 # , # , # := ( 1 3 5) ′ K2 K schema, and the resulting record is output; otherwise the 1 ′ K1 K output record(s) are generated from the combinations. 2 mp ′ mp ′ In the first step, we must evaluate in parallel the joins related nav(e1) nav(e2) ′ to predicates ρi. A PACT with a CoGroup contract is built ′ xmlscan(‘people’) xmlscan(‘closed auctions’) for each conjunctive predicate ρk. Each such PACT groups together all records that share the same value in the fields ′ Fig. 14. PACT plan corresponding to the logical expres- pointed by ρk, then applies the nopnjoinl UF (see below) on each group, with the goal of avoiding erroneous duplicates in sion in Figure 5. the result; the UF is more complex than pnjoin though, as # # # it has to handle the disjunction and the nesting. nopnjoinl is left-hand side record, i.e., K3 holds field positions 1, 3, 5, parameterized by k, as we will use it once for each conjunction which contain the XML node identifiers of $pc, $p, $i, respec- ′ tively. ⋄ ρk. Furthermore, nopnjoinl takes as input two bags of records and is defined as follows, along the lines of pnjoin. d) Joins on inequalities. Our XQuery subset also supports ′ ′ ′ ′ Definition 4 (nopnjoinl): Let ρ = ρ1 ∨ ρ2 ∨ ... ∨ ρn be a joins with inequality conditions. In this case, the translation ′ predicate where each ρi is conjunctive. Given two input bags uses Cross contracts. Further, just like for joins with disjunc- ′ ′ ′ {{r1,...,rx}} and {{r1,...,ry}}, the nopnjoinl(ρ ,k) UF is tive predicates, the non-nested and nested outer variants of defined as follows: the joins on inequalities require more than one PACT. The ′ corresponding translation rules can be found in Appendix D. • If the second input is empty (y = 0), return {{r1+(⊥ ′ Syntactically complex translation vs. performance Clearly, ),...,rx+(⊥ )}} i.e., concatenate every left input record with a field containing a nested list of one ⊥-record complex joins such as those considered in c) could be trans- conforming to the schema of the right input. lated into a single Cross PACT over the pairs of records as in d). However, this would be less efficient and scale poorly • Otherwise, for each left input record ri: (number of comparisons quadratic in the input size), as our 1) create an empty list ci; ′ ′ ′ ′ experiments will demonstrate. 2) for each rj,1≤j≤y, evaluate ρ1 ∨ ρ2 ∨ ... ∨ ρk over ′ ′ ri and rj, and add rj to ci if the result is false; 3) if ci is empty, then insert into ci a ⊥-record with 6 EXPERIMENTAL EVALUATION the schema of the right input; We implemented our PAXQuery translation approach in Java 4) output ri concatenated with a new field whose value 1.6, and relied on the Stratosphere platform [44] supporting is ci. ⋄ PACT. We first describe the experimental setup, and then present our results. The second PACT produced by the (LO ∨ JOIN ) and = Experimental setup. The experiments run in a cluster of 8 (NLO ∨ JOIN ) rules uses a Reduce contract, taking as input = nodes on an 1GB Ethernet. Each node has 2 × 2.93GHz Quad the outputs of all the CoGroup operators; its key consists of Core Xeon CPUs, 16GB RAM and two 600GB SATA hard the XML node identifiers in each left hand-side record (we disks and runs Linux CentOS 6.4. PAXQuery is built on top denote by the extraction of these fields from the schema). of Stratosphere 0.2.1; it stores the XML data in HDFS 1.1.2. This amounts to grouping together the records originated from XML data. We used XMark [42] data; to study queries joining the same left input record. several documents, we used the split option of the XMark Depending on the join flavor though, this last PACT uses a generator to create four collections of XML documents, each different UF. For the plain (non-nested) join (LO ∨ JOIN ), = containing a specific type of XMark subtrees: users (10% of we use the opost UF producing records with an unnested l∨ the dataset size), items (50%), open auctions (25%) and closed right side. For the nested join (NLO ∨ JOIN ), on the other = auctions (15%). We used datasets of up to 272GB as detailed hand, the nopost UF is used to produce nested records. Due l∨ below. to space constraints, we omit the definition of these UFs here All documents are simply stored in HDFS (which replicates and delegate their details to Appendix C. them three times), that is, we do not control the distribution/al- Example 1 (continuation). Our algorithms translate the al- location of documents over the nodes. gebraic expression shown in Figure 5 into the PACT plan XML queries. We used a subset of XMark queries from our depicted in Figure 14; observe that it is the same PACT plan XQuery fragment, and added queries with features supported that was shown in less detail in Figure 1. by our dialect but absent from the original XMark, e.g., Rule (NLO ∨ JOIN=) translates the nested left outer dis- joins on disjunctive predicates; all queries are detailed in junctive equi-join into (i) two PACTs with CoGroup contracts, Appendix E. one for each disjunction, and (ii) a PACT with a Reduce Table 2 outlines the queries: the collection(s) that each query contract that groups together records originating from the same carries over, the corresponding XML algebraic operators and 11 TABLE 2 TABLE 3 Query details. Query evaluation time (1 node, 34GB). Parallelization Evaluation time (seconds) Query Collections Algebra operators (#) Query contracts (#) BaseX Saxon-PE Qizx/open PAXQuery q1 users Navigation (1) Map (1) q1 206 145 90 72 q2 items Navigation (1) Map (1) q2 629 OOM OOM 125 q3 items Navigation (1) Map (1) q3 600 OOM OOM 120 q4 closed auct. Navigation (1) Map (1) q4 189 OOM 84 51 q5 closed auct. Navigation (1) Map (1) q5 183 125 183 51 q6 users Navigation (1) Map (1) q6 233 162 109 70 q7 closed auct. Navigation (1) Map (2) q7 181 111 88 54 Aggregation (2) Reduce (1) q8 599 OOM OOM 126 q8 items Navigation (1) Map (2) q9 TO OOM OOM 94 Aggregation (2) Reduce (1) q10 OOM OOM OOM 229 q9 users Navigation (2) Map (3) q11 TO TO TO 236 closed auct. Projection (1) Reduce (1) q12 TO OOM OOM 113 Group-by/aggregation (1) Match (1) q13 TO OOM OOM 424 Conj. equi-join (1) q14 OOM OOM OOM 331 q10 users Navigation (3) Map (5) items Projection (2) CoGroup (2) closed auct. NLO conj. equi-join (2) q1-q6 navigate in the input document according to a given q11 users Navigation (2) Map (3) navigation pattern of 5 to 14 nodes; each translates into a Map Projection (1) Reduce (1) PACT, thus their response time follows the size of the input. Dup. elim. (1) CoGroup (1) NLO conj. equi-join (1) These queries scale up well; we see a moderate overhead in q12 users Navigation (2) Map (3) Figure 15 as the data volume and number of nodes increases. closed auct. Projection (1) CoGroup (1) Queries q7 and q8 apply an aggregation over all the records NLO conj. equi-join/ generated by a navigation. For both queries, the navigation aggregation (1) generates nested records and the aggregation consists on two q13 users Navigation (2) Map (3) steps. The first step goes over the nested fields in each input closed auct. Projection (1) Reduce (2) NLO disj. equi-join (1) CoGroup (2) record, and thus it uses a Map contract. The second step is q14 users Navigation (2) Map (3) executed over the results of the first. Therefore, a Reduce open auct. Projection (1) Reduce (2) contract that groups together all records coming from the NLO inequi-join (1) Cross (1) previous operator is used. Since the running time is dominated by the Map PACTs which parallelize very well, q and q also 700! 1 node, 34 GB! 7 8 2 nodes, 68 GB! scale up well. 600! ! 4 nodes, 136 GB! Queries q -q involve conjunctive equi-joins over the col- 8 nodes, 272 GB! 9 12 500! lections. Query q13 executes a NLO disjunctive equi-join, 400! while q14 applies a NLO inequi-join. We notice a very good 300! scaleup for q9-q13, whose joins are translated in many PACTs (recall the rules in Figure 12). In contrast, q14, which translates 200! into a Cross PACT, scales noticeably less well. This validates Execution time(s) Execution 100! the interest of translating disjunctive equi-joins into many 0! PACTs (as our rules do), rather than into a single Cross, since, q1! q2! q3! q4! q5! q6! q7! q8! q9! q10!q11!q12!q13!q14! despite parallelization, it fundamentally does not scale. Fig. 15. PAXQuery scalability evaluation. 6.2 Comparison against other processors their numbers of occurrences, and the parallelization contracts used in the plan generated by our translation framework. To evaluate the performance of our processor against existing alternatives, we started by comparing it on a single node with Queries q9-q14 all involve value joins, which carry over thou- sands of documents arbitrarily distributed across the HDFS other popular centralized XQuery processors. The purpose nodes. is to validate our choice of an XML algebra as outlined in Section 4.2 as input to our translation, by demonstrating that single-site query evaluation based on such an algebra 6.1 PAXQuery scalability is efficient. For this, we compare our processor with BaseX Our first goal is to check that PAXQuery brings to XQuery 7.7 [7], Saxon-PE 9.4 [41] and Qizx/open 4.1 [38], on a dataset evaluation the desired benefits of implicit parallelism. For this, of 11000 XML documents (34GB). we fixed a set of queries, generated 11.000 documents (34GB) Table 3 shows the response times for each query and per node, and varied the number of nodes from 1 to 2, 4, 8 processor; the shortest time is shown in bold, while OOM respectively; the total dataset size increases accordingly in a stands for out of memory, and TO for timeout (above 2 hours). linear fashion, up to 272GB. In Table 3, we identify two query groups. First, q1-q8 do not Figure 15 shows the response times for each query. Queries feature joins; while the performance varies across systems, 12 TABLE 4 on the 8 nodes and 272GB; the shortest time is in bold. First, Query evaluation time (8 nodes, 272GB). we notice that BaseX runs 2 to 5 times faster on Stratosphere Evaluation time (seconds) than on Hadoop. This is due to Hadoop’s checkpoints (writing Query BaseX BaseX PAXQuery intermediary results to disk) while Stratosphere currently does Hadoop-MR Stratosphere-PACT not, trading reliability for speed. For queries without joins q1 465 66 70 (q -q ), PAXQuery is faster for most queries than BaseX on 189 1 8 q2 773 282 Hadoop or Stratosphere; this simply points out that our in- q3 762 243 172 house tree pattern matching operator (physical implementation q4 244 72 58 q5 237 72 57 of nav) is more efficient than the one of BaseX. Queries with q6 488 70 73 joins (q9-q14) fail in the competitor architecture again. The q7 245 74 62 reason is that intermediary join results grow too large and this q8 576 237 206 leads to an out-of-memory error. PAXQuery evaluates such 114 q9 OOM OOM queries well, based on its massively parallel (outer) joins. q10 OOM OOM 299 q11 OOM OOM 334 q12 OOM OOM 132 6.3 Conclusions of the experiments 456 q13 OOM OOM Our experiments demonstrate the efficiency of an XQuery q14 OOM OOM 683 processor built on top of PACT. First, our scalability evaluation has shown that the trans- only BaseX and PAXQuery are able to run all these queries. lation to PACT allows PAXQuery to parallelize every query PAXQuery outperforms other systems because, compiled in execution step with no effort required to partition, redistribute PACT, it is able to exploit the multicore architecture. data etc., and thus to scale out with the number of machines In the second group, queries q9-q14 join across the docu- in a cluster. The only case where scale-up was not so good ments. None of the competing XQuery processors completes is q14 where we used a Cross (cartesian product) to translate their evaluation, while PAXQuery executes them quite fast. For an inequality join; an orthogonal optimization here would be these, the usage of outer joins and multicore parallelization are to use a smarter dedicated join operator for such predicates, key to this good performance behavior. e.g. [35]. We next compare our system with other alternatives for Secondly, we have shown that PAXQuery outperforms com- implicitly parallel evaluation of XQuery. As explained in the petitor XQuery processors, whether centralized or distributed Introduction, no comparable system is available yet. Therefore, over Hadoop and Stratosphere. None of the competing proces- for our comparison, we picked the BaseX centralized system sors was able to evaluate any of our queries with joins across (the best performing in the experiment above) and used documents on the data volumes we considered, highlighting Hadoop-MapReduce on one hand, and Stratosphere-PACT on the need for efficient parallel platforms for evaluating such the other hand, to parallelize its execution. queries. We compare PAXQuery, relying on the XML algebra-to- PACT translation we described, with the following alternative 7 RELATED WORK architecture. We deployed BaseX on each node, and paral- Massively parallel XML query processing. In this area, lelized XQuery execution as follows: MRQL [22] proposes a simple SQL-like XML query language 1) Manually decompose each query into a set of leaf sub- implemented through a few operators directly compilable into queries performing just tree pattern navigation, followed MapReduce. Like our XQuery fragment, MRQL queries may by a recomposition subquery which applies (possibly be nested, however, its dialect does not allow expressing the nested, outer) joins over the results of the leaf sub- rich join flavours that we use. Further, the XML navigation queries; supported by MRQL is limited to XPath, in contrast to our 2) Parallelize the evaluation of the leaf subqueries through richer navigation based on tree patterns with multiple returning one Map over all the documents, followed by one nodes, and nested and optional edges. Reduce to union all the results. Moreover, if the recom- ChuQL [27] is an XQuery extension that exposes the position query is not empty, start a new MapReduce MapReduce framework to the developer in order to distribute job running the recomposition XQuery query over all computations among XQuery engines; this leaves the paral- the results thus obtained, in order to compute complete lelization work to the programmer, in contrast with our implic- query results. itly parallel approach which does not expose the underlying This alternative architecture is in-between ChuQL [27], parallelism at the query level. where the query writer explicitly controls the choice of Map HadoopXML [18] and the recent [12] process XML queries and Reduce keys, i.e., MapReduce is visible at the query in Hadoop clusters by explicitly fragmenting the input data level, and PAXQuery where parallelism is completely hidden. in a schema-driven, respectively, query-driven way, which In this architecture, q1-q8 translate to one Map and one is effective when querying one single huge document. In Reduce, whereas q9-q14 feature joins which translates into a contrast, we focus on the frequent situation when no single recomposition query and thus a second job. document is too large for one node, but there are many Table 4 shows the response times when running the query documents whose global size is high, and queries may both 13 navigate and join over them. Further, we do not require any [26] or focusing on the processing of specific join types such as partitioning work from the application level. multi-way joins [2], set-similarity joins [46], or θ-joins [35], After the wide acceptance of Hadoop, other parallel execu- appeared. PAXQuery is the first to translate a large family tion engines and programming abstractions conceived to run of joins (which can be used outside XQuery), into the more custom data intensive tasks over large data sets have been flexible PACT parallel framework. proposed: PACT [8], Dryad [25], Hyracks [15] or Spark [48]. Among these, the only effort at parallelizing XQuery is 8 CONCLUSIONANDFUTUREWORK the ongoing VXQuery project [4], translating XQuery into We have presented the PAXQuery approach for the im- the Algebricks algebra, which compiles into parallel plans plicit parallelization of XQuery, through the translation of executable by Hyracks. In contrast, PAXQuery translates into an XQuery algebraic plan into a PACT parallel plan. We an implicit parallel logical model such as PACT. Thus, our targeted a rich subset of XQuery 3.0 including recent additions algorithms do not need to address underlying parallelization such as explicit grouping, and demonstrated the efficiency and issues such as data redistribution between computation steps scalability of PAXQuery with experiments on collections of etc. which [15] explicitly mentions. hundreds of GBs. XQuery processing in centralized settings has been thor- For future work, we contemplate the integration of indexing oughly studied, in particular through algebras in [39], [20], techniques into PAXQuery to improve query evaluation time. [32], [31]. Our focus is on extending the benefits of implicit Further, we would like to explore reutilization of intermediary large-scale parallelism to a complex XML algebra, by formal- results in the PACT framework to enable efficient multiple- izing its translation into the implicitly parallel PACT paradigm. query processing. XML data management has also been studied from many other angles, e.g., on top of column stores [14], distributed REFERENCES with [28] or without [1] an explicit fragmentation specification, in P2P [29] etc. We focus on XQuery evaluation through the [1] S. Abiteboul, A. Bonifati, G. Cobena,´ I. Manolescu, and T. Milo, “Dynamic XML Documents with Distribution and Replication,” in massively parallel PACT framework, which leads to specific SIGMOD, 2003. translation difficulties we addressed. [2] F. N. Afrati and J. D. Ullman, “Optimizing joins in a map-reduce Parallelizable nested languages. Recently, many high-level environment,” in EDBT, 2010. [3] “Apache Hadoop,” http://hadoop.apache.org/. languages which translate into massively parallel frameworks [4] “Apache VXQuery,” http://incubator.apache.org/vxquery/. have been proposed; some of them work with nested data [5] A. Arion, V. Benzaken, and I. Manolescu, “XML Access Modules: and/or feature nesting in the language, thus somehow resemble Towards Physical Data Independence in XML Databases,” in XIME-P, 2005. XQuery. [6] A. Arion, V. Benzaken, I. Manolescu, Y. Papakonstantinou, and R. Vijay, Jaql [11] is a scripting language tailored to JSON data, “Algebra-Based identification of tree patterns in XQuery,” in FQAS, which translates into MapReduce programs; Meteor [24], also 2006. [7] “BaseX,” http://basex.org/products/xquery/. for JSON, translates into PACT. None of these languages [8] D. Battre,´ S. Ewen, F. Hueske, O. Kao, V. Markl, and D. Warneke, handles XQuery semantics exactly, since JSON does not “Nephele/PACTs: a programming model and execution framework for feature node identity; the languages are also more limited, web-scale analytical processing,” in SoCC, 2010. [9] C. Beeri and Y. Tzaban, “SAL: An Algebra for Semistructured Data and e.g., Jaql only supports equi-joins. XML,” in WebDB, 1999. The Asterix Query Language [10], or AQL in short, is based [10] A. Behm, V. R. Borkar, M. J. Carey, R. Grover, C. Li, N. Onose, R. Ver- on FLOWR expressions and resembles XQuery, but ignores nica, A. Deutsch, Y. Papakonstantinou, and V. J. Tsotras, “ASTERIX: Towards a Scalable, Semistructured Data Platform for Evolving-world node identity which is important in XQuery and which we Models,” Distributed and Parallel Databases, 2011. support. Like VXQuery, AQL queries are translated into Alge- [11] K. S. Beyer, V. Ercegovac, R. Gemulla, A. Balmin, M. Y. Eltabakh, bricks; recall that unlike our translation, its compilation to the C.-C. Kanne, F. Ozcan,¨ and E. J. Shekita, “Jaql: A Scripting Language for Large Scale Semistructured Data Analysis,” PVLDB, 2011. underlying Hyracks engine needs to deal with parallelization [12] N. Bidoit, D. Colazzo, N. Malla, F. Ulliana, M. Nole,` and C. Sartiani, related issues. “Processing XML queries and updates on map/reduce clusters (demo),” Finally, other higher level languages that support nested in EDBT, 2013. [13] S. Blanas, J. M. Patel, V. Ercegovac, J. Rao, E. J. Shekita, and Y. Tian, data models and translate into parallel processing paradigms “A Comparison of Join Algorithms for Log Processing in MapReduce,” include Pig [36] or Hive [45]. Our XQuery fragment is more in SIGMOD, 2010. expressive, in particular supporting more types of joins. In [14] P. Boncz, T. Grust, M. van Keulen, S. Manegold, J. Rittinger, and J. Teubner, “MonetDB/XQuery: a fast XQuery processor powered by addition, Pig only allows two levels of nesting in queries, a relational engine,” in SIGMOD, 2006. which is a limitation. In contrast, we translate XQuery into [15] V. R. Borkar, M. J. Carey, R. Grover, N. Onose, and R. Vernica, unnested algebraic plans with (possibly nested, possibly outer) “Hyracks: A flexible and extensible foundation for data-intensive com- puting,” in ICDE, 2011. joins and grouping which we parallelize, leading to efficient [16] Y. Chen, S. B. Davidson, and Y. Zheng, “An efficient XPath query execution even for (originally) nested queries. processor for XML streams,” in ICDE, 2006. Complex operations using implicit parallel models. The [17] Z. Chen, H. V. Jagadish, L. Lakshmanan, and S. Paparizos, “From Tree Patterns to Generalized Tree Patterns: On Efficient Evaluation of problem of evaluating complex operations through implicit XQuery,” in VLDB, 2003. parallelism is of independent interest. For instance, the ex- [18] H. Choi, K.-H. Lee, S.-H. Kim, Y.-J. Lee, and B. Moon, “HadoopXML: ecution of join operations using MapReduce has been studied A suite for parallel processing of massive XML data with multiple twig pattern queries (demo),” in ACM CIKM, 2012. extensively. Shortly after the first formal proposal to compute [19] J. Dean and S. Ghemawat, “MapReduce: Simplified Data Processing on equi-joins on MapReduce [47], other studies extending it [13], Large Clusters,” in OSDI, 2004. 14 Query ::= FLWRExpr [20] A. Deutsch, Y. Papakonstantinou, and Y. Xu, “The NEXT Logical FLWRExpr ::= Initial Middle* Return Framework for XQuery,” in VLDB, 2004. Initial ::= For | Let [21] A. Eisenberg, “XQuery 3.0 is nearing completion,” SIGMOD Record, Middle ::= Initial | Where | GroupBy vol. 42, no. 3, 2013. For ::= for ForBinding (, ForBinding)* [22] L. Fegaras, C. Li, U. Gupta, and J. Philip, “XML Query Optimization ForBinding ::= Var in PathExpr in Map-Reduce,” in WebDB, 2011. PathExpr ::= (distinct-values)? (collection(Uri) | doc(Uri) | [23] T. Fiebig and G. Moerkotte, “Algebraic XML Construction and its Var) Path Optimization in Natix,” World Wide Web, vol. 4, no. 3, 2001. Let ::= let LetBinding (, LetBinding)* [24] A. Heise, A. Rheinlander,¨ M. Leich, U. Leser, and F. Naumann, “ LetBinding ::= Var := (FLWRExpr | AggrExpr | PathExpr) Meteor/Sopremo: An Extensible Query Language and Operator Model AggrExpr ::= (count | avg | max | min | sum) Var ,” in BIGDATA, 2012. Where ::= where OrExpr [25] M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly, “Dryad: OrExpr ::= AndExpr (or AndExpr)* Distributed Data-Parallel Programs from Sequential Building Blocks,” AndExpr ::= BoolExpr (and BoolExpr)* in EuroSys, 2007. BoolExpr ::= (not)? (Pred | Contains | Empty) [26] D. Jiang, A. K. H. Tung, and G. Chen, “MAP-JOIN-REDUCE: Toward Pred ::= Var (ValCmp | NodeCmp)(Var | C) Scalable and Efficient Data Analysis on Large Clusters,” IEEE TKDE, Contains ::= contains (Var, C) 2011. Empty ::= empty (Var) [27] S. Khatchadourian, M. P. Consens, and J. Simeon,´ “Having a ChuQL at GroupBy ::= group by Var (, Var)* XML on the cloud,” in A. Mendelzon Int’l. Workshop, 2011. ¨ Return ::= return (EleConst | (AggrExpr | Var)+) [28] P. Kling, M. T. Ozsu, and K. Daudjee, “Generating Efficient Execution EleConst ::= A ::= constr L (Operator) Operator ::= Scan | UnaryOp | BinaryOp Algorithm 1: XML Construction Scan ::= scan Input : Collection of tuples T , list of CTPs L UnaryOp ::= (Navigation | Group-By | Flatten | Output: XML forest Selection | Projection | Aggregation | 1 f ← () DupElim) Operator 2 for t ∈ T do Navigation ::= nav e 3 for c ∈ L do Selection ::= sel ρ 4 r ← c.root; N ← children(r); fn ← () Projection ::= proj V Group-By ::= grp 5 for n ∈ N do Gid ,Gv ,$r 6 Flatten ::= flatp if n is not a leaf and n is labeled with a variable Aggregation ::= aggp,a,$r path p then ′ DupElim ::= dupelimV 7 T ← collection of tuples obtained by BinaryOp ::= (CartProd | Join | LeftOuterJoin | following p within t NestedLeftOuterJoin) Operator, Opera- 8 else tor ′ CartProd ::= prod 9 T ← T ′ Join ::= joinρ 10 L ← children(n) LeftOuterJoin ::= ojoinl ′ ′ ρ 11 f ← constr L′ (T ) l ′ NestedLeftOuterJoin ::= nojoinρ 12 append f to fn Fig. 17. XML algebraic plan grammar. 13 if r is not optional or any variable path pr labeling a leaf under r leads to a non-⊥ value within t then APPENDIX B 14 fr ← () XML ALGEBRA OPERATORS 15 if r is labeled with an element (resp. attribute) name l then This section provides details about algebraic operators used 16 fr ← new element/attribute labeled l by the algebra considered in this work. In the following, we 17 else denote by F the domain of XML forests, and we denote by 18 if r is a leaf labeled with variable path p then T the domain of tuples. 19 fr ← t|p 20 if fr is not () then B.1 Border operators 21 add fn as child of fr XML Construction (constr L). The input to the operator is 22 else a collection of tuples, and from each tuple an XML forest is 23 fr ← fn ∗ ∗ created: constr L : T → F . 24 append fr to f The information on how to build the XML forest is specified by a list L of construction tree patterns (CTPs in short), 25 output f; exit attached to the constr operator. For each tuple in its input, constr L builds one XML tree for each CTP in L [31]. Formally, Construction Tree Patterns are defined as follows. of tuples to build the construction results. Afterwards, XML Definition 5 (Construction Tree Pattern): A Construction content for the current node r and its children (if any) is Tree Pattern is a tree c = (V,E) such that each node n ∈ V created and appended to f iff (i) r is not the root of an optional is labeled with (i) a valid XML element or attribute name, or subtree, or (ii) r is the root of an optional subtree but following ′ ′ (ii) a variable path p, which is $V 1.p where p is in turn a any variable path pr labeling a leaf under r leads to a non-⊥ variable path. value within t (lines 13-24). If a node n is labeled with a variable path p, and a In Figure 18a, we show four CTPs c1,...,c4, while Fig- descendant ndesc of n is annotated with a variable path pdesc, ure 18b shows three nested tuples and the four different XML then p is a prefix of pdesc. forests produced out of these three tuples by the operator Finally, we depict an optional construction subtree in c with constr ci,1≤i≤4. Regardless of the construction pattern used, a dashed edge. ⋄ there are three trees in the forest, each built from one input tuple. The root of each tree is a newly created node labeled Without loss of generality, we will assume from now on person, as dictated by each of the four c s. Further, in each that in all CTPs, the paths are valid wrt the schema of tuples i tree of the forest built for c , the children of the person node in the input to the constr operator. 1 are deep copies1 of the forests found in the $N attribute, The semantics of constr for an input collection of tuples L respectively, in the nested $R.$Z and $R.$C attributes. Since T and a list of CTPs L is depicted in Algorithm 1. We use an in the third tuple the latter forests are empty, the third tree XML forest f, initially empty, to gather the resulting XML. in the forest of c only has a copy of n as child. Observe XML content is built out of each tuple t ∈ T during a top- 1 3 that the same happens for c , as the subtree rooted at address down, left-to right traversal of each CTP c ∈ L; constr is 2 is optional and thus it is only built if $R.$Z or $R.$C are called recursively following this order (lines 5-12). Observe not bound to ⊥. Finally, note that when the CTP c is used, that if an intermediary node in c is labeled with a variable path 4 p, p is followed to extract a nested collection of tuples within 1. Following standard XQuery semantics [40], whenever an input node t, which is in turn used as input for the subsequent constr needs to be output under a new parent, a deep copy of the input node is call (line 7). Thus, we can navigate over the nested collection used. 16 c c e e e c1 person c2 person 3 person 4 person 1 $I:* 2 $I:* e3 $I:* 4 $I:* person person person person $N $R.$Z $R.$C $N address $N address $N $R n: $R n: $R n: $R $N:name $C:city $N: name address $N: name address $N:name address $R.$Z $R.$C $R address $Z: zip $S: street $Z:zip $C:city $Z $C $Z $C (a) Sample ETPs. (a) Sample CTPs. $I person person person root n1 z1 c1 n2 z21 z22 c21 c22 n3 person person person e1 e2 e3 e4 c1 $N $R n1 address n2 address n3 $Z $C n1 z1 c1 z1 c1 z21 z22 c21 c22 c2 $I $N $R $I $N $R $I $N $S $I $N $R $C $Z $Z $C person person person z21 c21 n2 root n1 c1 root n1 z1 root n1 z1 c1 z22 c22 c3 n1 address n2 address n3 address n3 ⊥ ⊥ c21 z21 z21 c21 root n2 root n2 root n2 c4 z1 c1 z21 c21 z22 c22 c22 z22 z22 c22 person person person root n1 ⊥ root n3 ⊥ ⊥ n1 address n2 address address n3 address (b) Resulting tuples after applying ETPs to a given tuple. z1 c1 z21 c21 z22 c22 (b) Resulting XML forests after applying the CTPs to a collection Fig. 19. Sample ETPs and corresponding navigation of tuples. results. Fig. 18. Sample CTPs and corresponding XML construc- root, people tion results. p1, person p2, person p3, person n1, name a1, address n2, name a21, address a22, address n3, name a3, address the root node in each tree has as children (copies of) the $N nodes, as well as a newly created address node having the $Z “Martin” z1, zip c1, city “Bernard” z21, zip c21, city z22, zip c22, city “Dubois” and $C forests as children. “75” “Paris” “69” “Lyon” “75” “Paris” Scan (scan). The scan operator takes as input an XML forest Fig. 20. Sample XML tree. and creates a tuple out of each tree in the forest: scan : F → T ∗. The semantics of the scan operator whose input is an these edges may not be mapped, in which case the node takes XML forest f is the following: the ⊥ value. scan(f)= {{h($I,d.root)i| d ∈ f}} We denote by ϕ(e,d) all the embeddings from e to d. Then, we define the semantics of the navigation operator as: ′ ′ nav e(A)= S {{t + t | t ∈ ϕ(e,t.$I)}} B.2 Unary operators t∈A In other words, the navigation operator nav is parameterized Navigation (nav ). The operator is applied on a set of tuples e by a tree pattern e, whose root is labeled with a variable $I, and is parameterized by an extended tree pattern (ETP) [31]. that must appear in tuples returned by the input expression A. In the following we introduce ETPs formally. The nav operator concatenates t successively with all tuples Definition 6 (Extended Tree Pattern): An Extended Tree binding returned by ϕ(e,t.$I), for any tuple t returned by A. Pattern is a tree e =(V,E) where: The semantics of the operator are illustrated with four • The root r ∈ V is labeled with a variable $I. examples in Figure 19b. Given a tuple with a variable $I • Each non-root node n ∈ V are labeled with (i) an bound to the XML tree shown in Figure 20, the navigation element/attribute name and (ii) optionally, a variable $V . operator using e1 extracts the name and city nodes of each • Each e =(x,y) ∈ E is either a child edge from x to y, person; observe that the variable $C is nested in $R and denoted by a single line, or a descendant edge from x to that the person without any city node does not generate any y, denoted by a double line. Further, optional edges are bindings. Instead, the navigation operator using e4 generates depicted with dashed lines, and nested edges are labeled bindings from all person nodes, as the subtree rooted at the with n. ⋄ address node is optional. The navigation result for ETPs e2,e3 is extracted in the similar fashion. Figure 19a depicts some sample extended tree patterns. Group-By (grpGid ,Gv ,$r). The operator has three parameters: Given an ETP e and an XML tree d, an embedding generates the set of group-by-id variables Gid , the set of group-by-value the tuple that results from binding the root variable of e to variables Gv and the result variable $r. d and mapping the nodes of e to a collection of nodes in d. Let P (A,Gid ,Gv) be the set of tuple collections that results The variables of the binding tuples are ordered by the preorder from partitioning the tuples output by A, such that the tuples traversal sequence of e. Note that if e contains optional edges, in a collection have id-equal values for the variables of Gid a mapping may be partial: nodes connected to the pattern by and equal values for the variables of Gv. For each collection 17 p p p ∈ P (A,Gid ,Gv), let tid (respectively, tv) be the tuple for the variables of Gid and equal values for the variables of consisting of the Gid (respectively, Gv) variables together with Gv. Then, the semantics of the duplicate elimination operator their values in p. Then, the semantics of group-by operator is is defined as follows. defined as follows. dupelimV (A)= {t1 | {{t1,...,tn}} ∈ P (A, (),V )} p p grpGid ,Gv ,$r(A)= {{tid +tv+h($r, p)i| p ∈ P (A,G ,G )}} id v B.3 Binary operators Each tuple in the output of grp contains: the variables of G and G with their values, and a newly introduced The last family of operators are binary: they take in input id v two collections of tuples produced by the plans and variable $r, whose value is the group of input tuples whose A1 A2 respectively, and output a collection of tuples. We outline their Gid attributes are ID-equal, and whose Gv values are equal. Flatten (flat ). This operator unnests tuples in the collection semantics in the following. p Cartesian product (prod). referenced by p. The cartesian product is standard. In the following, we introduce the semantics when prod(A1, A2)= {{t1+t2 | t1 ∈A1,t2 ∈A2}} p.length = 1; the other cases can be easily worked out Join (joinρ). The join relies on a boolean join predicate using the same approach. For each input tuple t ∈ A, let ρ(t1,t2), and is defined as follows. ′ ′′ t (respectively, t ) be the tuple containing the variables joinρ(A1, A2)= {{t1+t2 | t1 ∈A1,t2 ∈A2 and preceding (respectively, succeeding) p in t. Further, let ti ρ(t1,t2) holds}} be each of tuples contained in the collection t|p. Then, we As stated previously, the join predicate is expressed in formalize the semantics of the operator as follows: disjunctive normal form (DNF). ′ p ′′ ′ ′′ l flat p(A)= {{t + ti + t | t + h(p,t|p)i + t ∈A Left outer join (ojoinρ). Given two streams of tuples pro- p l and ti ∈ t|p}} duced by A1, A2 and a DNF predicate ρ, ojoinρ(A1, A2) Selection (sel ρ). The selection operator is defined in the usual returns the pairs of tuples satisfying ρ, plus the tuples from way based on a boolean predicate ρ to be tested on a tuple t. the left input without a matching right tuple. Its semantics are Formally, a selection over a stream of tuples generated by A defined as follows: l is defined as: ojoinρ(A1, A2)={{t1+t2 | t1 ∈A1,t2 ∈A2 and ρ(t1,t2)}} sel ρ(A)= {{t | t ∈A and ρ(t) holds}} ∪ {{t1+ ⊥A2 | t1 ∈A1, 6∃t2 ∈A2 s.t. ρ(t1,t2)}} where ⊥A2 is a tuple having the schema of the tuples in A2 Projection (proj V ). The operator is defined by specifying a set and ⊥ values bound to its variables. As customary of left of variable names V = {$V 1, $V 2,..., $V k} that are present in the schema of the input tuples and should be retained in outer joins, the left tuples without a matching right tuple are the output tuples. More precisely: concatenated to ⊥A2 . Nested left outer join (nojoinl ). The operator semantics are proj (A)= {{h($V 1,v1), ($V 2,v2),..., ($V k,vk)i| t ∈A ρ V defined as: and ∀j ∈ {1..k}.$V j ∈ V and ($V j,vj) ∈ t}} l nojoinρ(A1, A2)= {{t1 + h($r, (t21,t22,...,t2n))i| Aggregation (aggp,a,$r). The operator has three parameters: the variable path p that references the variable over whose t1 ∈A1 and t21,t22,...,t2n ∈A2 bound values we will execute the aggregation, the aggregation and ∀k ∈ {1..n}, ρ(t1,t2k) holds }} ∪ operation a (recall that we support count, avg, max, min and {{t1 + h($r, ⊥A2 )i| t1 ∈A1, 6∃t2 ∈A2 sum), and the result variable $r. such that ρ(t1,t2) holds}} Let A(t,p,a) be the result of applying aggregation operation Thus, each tuple from the left input is paired with a new a on the values bound to variable path p in tuple t. nested variable $r, encapsulating all the matching tuples from If the path p refers to a variable in a immediate nested the right-hand input. If the left tuple does not have a matching collection, i.e. p.length = 2, the semantics of the aggregation right tuple, $r must contain a tuple ⊥A2 . operator are defined as follows. ′ APPENDIX C aggp,a,$r(A)= {{t + t | t ∈A and t′ = h($r, A(t,p,a))i}} DISJUNCTIVEEQUI-JOINSPOST-PROCESSING The semantics of the aggregation with more levels of The semantics of these UFs are introduced in the following. nesting, i.e. p.length > 2, is straightforward. Definition 7 (opost l∨): Consider an input bag of records Finally, if we want to aggregate over a non-nested variable {{r1,...,rx}}. Each record ri,1≤i≤x is separated in left and of the input tuples, i.e. p.length = 1, we proceed by nesting l r r right side, i.e. ri = ri+ri . Further, ri contains a single field them under a new variable to produce the correct aggregation with a nested collection of records Ri. We denote by opost l∨ result. Thus, the semantics is defined as follows. the post-processing UF which: agg (A)= {{agg ({t}) | t = h($N, (A))i}} p,a,$r p,a,$r • If all nested collections Ri,1≤i≤x contain only ⊥-records, Duplicate elimination (dupelim ). The operator is defined l ′ l V it outputs a single record r = ri+ ⊥ , where ri is the by specifying a set of variable names V that are present in the left side of any input record and ⊥′ is the ⊥-record schema of the input tuples and whose bound value should be conforming to the signature of the records in Ri. unique among the output tuples. • Otherwise, it flattens the nested collections Ri,1≤i≤x Recall P (A,Gid ,Gv) that partitions the tuples output by excluding ⊥-records, and returns the result. ⋄ A, such that the tuples in a collection have id-equal values 18 Definition 10 (ojoinl): Given two records r1,r2 and a A1 ⇒P1 A2 ⇒P2 ′ ′ ′ ′ predicate ρ , the ojoinl(ρ ) UF evaluates ρ over r1,r2, and: SA1 ,SA2 ; ρ 7→ ρ ′ f := pnjoin(ρ ) • If it evaluates to true, outputs r1+r2. (INEQUI-JOIN) • Otherwise, it outputs r + ⊥ , where ⊥ is the ⊥-record joinρ(A1, A2) ⇒ crf (P1, P2) 1 2 2 that conforms to the signature of r2. ⋄ A1 ⇒P1 A2 ⇒P2 ′ ′ SA1 ,SA2 ; ρ 7→ ρ f := ojoinl(ρ ) The last PACT resulting from both translation rules uses ′ SA1 K f := opost l a Reduce contract that groups together the records originated (LO INEQUI-JOIN) l K ojoinρ(A1, A2) ⇒ rdf ′ (crf (P1, P2)) from the same left hand-side record. In the plain variant, the UF is opost l that produces unnested records; otherwise, the A1 ⇒P1 A2 ⇒P2 ′ ′ PACT uses the nopost l UF. We introduce both UFs in the SA1 ,SA2 ; ρ 7→ ρ f := ojoinl(ρ ) ′ following. SA1 K f := nopost l (NLO INEQUI-JOIN) l K nojoinρ(A1, A2) ⇒ rdf ′ (crf (P1, P2)) Definition 11 (opost l): Consider an input bag of records {{r1,...,rx}}. Each record ri,1≤i≤x is separated in left and Fig. 21. Inequi-join translation rules. l r right side, i.e. ri = ri+ri . We denote by opost l the post- processing UF which: nopost Definition 8 ( l∨): Consider an input bag of records r • If ri,1≤i≤x are all ⊥-records, it outputs one of them. {{r1,...,rx}}. Each record ri,1≤i≤x is separated in left and r l r r • Otherwise, it returns every ri,1≤i≤x where r is not a right side, i.e. ri = r +r . Further, r contains a single field i i i i ⊥-record. ⋄ with a nested collection of records Ri. We denote by nopost l∨ the post-processing UF that outputs a single record r = rl+r′, i Definition 12 (nopost l): Consider an input bag of records where: {{r1,...,rx}}. Each record ri,1≤i≤x is separated in left and • l r If all nested collections Ri,1≤i≤x contain only ⊥-records, right side, i.e. ri = ri+ri . We denote by nopost l the post- ′ l ′ r contains a field with a nested collection with a ⊥- processing UF that outputs a single record r = ri+r , where: r ′ record conforming to the signature of the records in Ri. • If r are all ⊥-records, r contains a field with a ′ i,1≤i≤x • Otherwise, r contains a field with a nested collection nested collection with a ⊥-record that conforms to the with the records contained in Ri,1≤i≤x, excluding ⊥- r signature of ri . ′ records. ⋄ • Otherwise, r contains a field with a nested collection r with every ri,1≤i≤x that is not a ⊥-record. ⋄ APPENDIX D JOINSONINEQUALITIES Example 5. Consider the following XQuery that extracts the Our XQuery fragment also supports joins with inequality name of users and (if any) the items they bought that were conditions. In this case, the translation uses Cross contracts. valued more than their monthly incoming: Further, just like for joins with disjunctive predicates, the non- let $pc := collection( ‘people ’), $cc := collection( ‘ closed auctions ’) nested and nested outer variants of the inequi-join require more for $p in $pc/site/people/person than one PACT. We depict the corresponding translation rules let $n := $p/name let $r := in Figure 21. In the following, we explain the translation of for $c in $cc//closed_auction, $i in $p/@id, this flavor of joins. $b in $c/buyer/@person, $x in $p/profile/@income, 1) Inequi-join. Rule (INEQUI-JOIN) generates a PACT with $y in $c/price Cross let $a := $c/itemref a input contract. The predicate ρ is transformed into where $i = $b and $x < $y ′ ρ , which is equivalent but replaces the EXDM variables return $a by positions in the PACTs records. Then the pnjoin UF return a) e2 Query 5: Return the IDs of those auctions that have one or e1 $pc:* $cc:* more keywords in emphasis. site $c: closed auction let $cc := collection( ‘XMarkClosedAuctions ’) n: $t people for $a in buyer $y: price $a: itemref $cc/site/closed_auctions/closed_auction $p: person $k $a/annotation/description/parlist/ $b: @person for in listitem/parlist/listitem/text/emph/keyword/text() $i: @id profile let $s := $a/seller/@person $x: @income where not(empty($k)) e3 $p:* constr L return rdopost l return $c K1 Query 9: List the number of buyers per city of France. ′ crojoinl(ρ ) let $pc := collection( ‘XMarkPeople ’), $cc := collection( ‘XMarkClosedAuctions ’) mpnav e′ mpnav e′ ( 1) ( 2) for $p in $pc/site/people/person [address/country/text()= ‘France ’] let $a := $p/address/city/text() xmlscan(‘people’) xmlscan(‘closed auctions’) for $c in $cc/site/closed_auctions/closed_auction, $i in $p/@id, $b in $c/buyer/@person Fig. 22. Logical expression (a) and corresponding PACT where $i = $b plan (b) for the query in Example 5. group by $a return