Robust query processing for linked data fragments

Abstract

Linked Data Fragments (LDFs) refer to interfaces that allow for publishing and querying Knowledge Graphs on the Web. These interfaces primarily differ in their expressivity and allow for exploring different trade-offs when balancing the workload between clients and servers in decentralized SPARQL query processing. To devise efficient query plans, clients typically rely on heuristics that leverage the metadata provided by the LDF interface, since obtaining fine-grained statistics from remote sources is a challenging task. However, these heuristics are prone to potential estimation errors based on the metadata which can lead to inefficient query executions with a high number of requests, large amounts of data transferred, and, consequently, excessive execution times. In this work, we investigate robust query processing techniques for Linked Data Fragment clients to address these challenges. We first focus on robust plan selection by proposing CROP, a query plan optimizer that explores the cost and robustness of alternative query plans. Then, we address robust query execution by proposing a new class of adaptive operators: Polymorphic Join Operators. These operators adapt their join strategy in response to possible cardinality estimation errors. The results of our first experimental study show that CROP outperforms state-of-the-art clients by exploring alternative plans based on their cost and robustness. In our second experimental study, we investigate how different planning approaches can benefit from polymorphic join operators and find that they enable more efficient query execution in the majority of cases.

1. Introduction

Linked Open Data initiatives led to the publication of Knowledge Graphs covering a large variety of domains on the Web.1

¹

https://lod-cloud.net/

Linked Data Fragments (LDFs) refer to Web interfaces for publishing and querying such Knowledge Graphs [28]. In recent years, several LDF interfaces have been proposed which mainly differ in their expressivity and the metadata they provide [6,14,22,28]. For example, Triple Pattern Fragments (TPF) is a popular LDF interface that allows for querying Knowledge Graphs with high availability [28]. TPF servers provide a lightweight interface that supports triple pattern-based querying to reduce server-side costs and increase server availability. Given a triple pattern, the TPF server returns all matching triples split into pages as well as additional metadata on the estimated number of total matching triples and the page size. More expressive LDF interfaces allow for exploring different trade-offs in client- and server-side query processing. This led to the development of specific clients to support SPARQL query processing over these interfaces. A key challenge of such clients is devising efficient query plans that minimize the overall query execution time by reducing the data transferred and the number of requests submitted to the server. To this end, the clients commonly rely on the metadata of the LDF interfaces and implement heuristics to achieve efficient query processing [1,6,14,27,28]. However, a drawback of these heuristics is the fact that they fail to adapt to different classes of queries which can lead to extensive runtimes while producing many requests. This can be attributed to the following reasons. First, the clients often follow specific planning paradigms resulting in either left-deep or bushy query plans and do not explore alternative plans [1,27]. Second, due to the limited metadata of the LDF interfaces, the clients rely on basic cardinality estimations to determine the join order and to place physical operators. Finally, even though many clients process queries in an adaptive fashion with non-blocking operators and adapting the join order, they still adhere to the predefined join strategies during execution set by the planner.

In this work, we investigate robust query processing techniques for LDFs to address these limitations. Robust query processing comprises different techniques with the common goal to overcome inefficient query execution performance caused by query planning errors and unexpected adverse runtime conditions [29,32]. These approaches accept the fact that cost-models and cardinality estimation approaches can be inaccurate and aim to implement query processing techniques that are not highly affected by potential inaccuracies, planning errors, and unexpected runtime conditions. Our techniques aim to support robustness with respect to cardinality estimation errors at two points during query processing: (i) Query planning, by devising efficient query plans that consider both the cost and robustness of plans, and (ii) Query execution with intra-operator adaptivity, to switch the join strategies in response to wrongly placed physical join operators. Therefore, we focus on the following research question.

RQ 1.

How can we measure the robustness of query plans with respect to cardinality estimation errors?

With the first research question, we want to investigate a suitable measure to determine the robustness of query plans during query planning. Specifically, we want to study means to assess the robustness of a query plan in the presence of high-level metadata, that is commonly provided by LDF interfaces.

RQ 2.

How does incorporating robustness during query planning impact the efficiency of query plans?

The second research question focuses on the impact on query execution efficiency when incorporating robust query plan selection in the optimizer. With this question, we want to study the trade-off between selecting a robust alternative plan over the cheapest plan. To this end, we investigate how a feasible selection of alternative robust plans can be determined and under which conditions the selection of a robust plan is favorable.

RQ 3.

To what extent does adapting the join strategies during query execution support robust query processing?

Finally, we want to understand whether runtime adaptivity allows for overcoming inefficient query execution due to cardinality estimation errors. Since query planners rely on cardinality estimations for placing physical join operators, estimation errors may lead to the selection of sub-optimal operators. Therefore, we investigate whether adapting the join strategy of physical join operators in response to estimation errors increases the execution robustness.

In this work, we study these questions using the example of the Triple Pattern Fragment (TPF) interface due to the following reasons. First, the existing state-of-the-art clients for TPFs [1,27] follow different query planning paradigms to which we can compare the effectiveness of our approach. Second, other queryable LDF interfaces also support the evaluation of triple patterns as the atomic component of SPARQL. As a result, our approach can be extended and tailored to clients and servers of more expressive LDF interfaces. Lastly, the insights gained from our experimental study on TPFs provides a basis for future investigations on robust query processing for other LDFs.

Contributions This work is based on a previous paper of ours [16], which studies cost- and robustness-based query optimization (CROP) for Linked Data Fragments. We extend this work by refining our cost model to better generalize for other LDF interfaces. Moreover, we study the concept of robustness from the perspective of adaptive query processing for Linked Data Fragments. To this end, we propose a new class of operators that we call Polymorphic Join Operators. These operators aim to achieve robustness by adapting their join strategy during query execution in response to potential cardinality estimation errors. In summary, the novel contributions of this work are as follows:

1. a refined cost model, additional experimental results, and a more detailed evaluation of CROP,

2. new adaptive join operators: the Polymorphic Bind Join (PBJ) and Polymorphic Hash Join (PHJ),

3. results on the theoretical properties and correctness of the PBJ and the PHJ, and

4. an experimental evaluation of the PBJ and PHJ for different query planning approaches.

Structure of this paper The remainder of this paper is structured as follows. We present a motivating example in Section 2. In Section 3, we discuss related work. In Section 4, we present our cost model, robustness metric, and our query plan optimizer that combines cost and robustness. In Section 5, we present two adaptive join operators from a new class of Polymorphic Join Operators. We empirically evaluate the effectiveness of our query planning approach and the adaptive join operators in Section 6. Lastly, we summarize our contributions and point to future work in Section 7.

2. Motivating example

As a motivating example, consider the query in Listing 1 that obtains persons with “Stanford University” as their alma mater, the title of their thesis, and their doctoral advisor from the Triple Pattern Fragment (TPF) server for the English version of DBpedia2

²

http://fragments.dbpedia.org/2014/en

with a page size of 100. The number of estimated triples matching each triple pattern (count) provided as metadata from the TPF server is also indicated in Listing 1.

Listing 1.

Query to get persons with “Stanford University” as their alma mater, the title of their thesis and their doctoral advisor

Evaluating SPARQL queries over the TPF server requires the client to obtain efficient query plans that minimize the query execution time, the number of requests, and the amount of data transferred. Typically, clients implement a query planning heuristic that relies on the metadata provided by the TPF server. The sort heuristics implemented by comunica sorts the triple patterns according to the number of triples they match in ascending order and places Nested Loop Joins (NLJs) as the physical operators [27]. Evaluating the query over the TPF server using comunica-sparql3

³

https://github.com/comunica/comunica

requires the client to perform 813 requests to obtain the 29 results of the query. The corresponding physical query plan is shown in Fig. 1(a), where the number of requests is indicated on the edges. The client performs 4 requests to obtain the statistics (counts) on the triple patterns, and thereafter, it executes the plan with 809 requests, leading to a total of 813 requests. An alternative query planning heuristic is implemented in the network of Linked Data Eddies (nLDE)4

⁴

https://github.com/maribelacosta/nlde

which is another client for TPF servers. The query planning heuristic builds bushy plans around star-shaped subqueries and places Nested Loop Join or Symmetric Hash Join (SHJ) operators such that the estimated number of requests is minimized [1]. To this end, nLDE first performs 4 requests to obtain the count values of the triple patterns and thereafter, builds the bushy query plan as shown in Fig. 1(b). The execution of the query plans requires 71 requests, leading to a total of 75 requests. When inspecting the query in detail, we observe that neither comunica-sparql nor nLDE finds the query plan which minimizes the number of requests to be performed. The optimal plan is shown in Fig. 1(c) and it requires a total of 69 requests only: 4 requests to obtain the counts and 65 requests to execute the plan. The number of requests in the query plan can be reduced by sorting the triple patterns similar to comunica by ascending count values. Furthermore, placing the appropriate physical join operators according to the join cardinalities of the sub-plans minimizes the number of requests.

The example query showcases the challenge for heuristics to devise efficient query plans based only on the count statistic provided by the TPF servers. In the query, the subject-object join of triple patterns ${\mathit{tp}}_1$ and ${\mathit{tp}}_2$ yields 756 results. This can be difficult to estimate relying on the TPF metadata alone with $count\mathrm{(}{\mathit{tp}}_1\mathrm{)}=2$ and $count\mathrm{(}{\mathit{tp}}_2\mathrm{)}=86088$ . On the one hand, an optimistic heuristic assuming small join cardinalities (for example the minimum) can lead to sub-optimal query plans as the query plan in Fig. 1(a) shows. On the other hand, a more conservative cardinality estimation model that assume the higher join cardinalities, for example, the sum, may lead to overestimating cardinalities and to too conservative query plans. Consequently, accurate join cardinality estimations are crucial to obtain efficient query plans. However, they are challenging to compute in the absence of fine-grained statistics in client-side SPARQL query evaluation over remote data sources such as TPF servers. Therefore, when following the optimize-then-execute paradigm, a robust query planning approach may help to identify query plans that are less prone to cardinality estimation errors.

Fig. 1.

Three alternative query plans for the SPARQL query from Listing 1. Indicated on the edges are the number of requests to be performed according to the corresponding join operators: nested loop join (NLJ) and symmetric hash join (SHJ).

In addition, adaptive query processing strategies [10] allow to eradicate potential query planning errors by adapting the join processing during query plan execution. Take for example the query plan in Fig. 1(a) which requires a large number of requests by probing each individual tuple from $⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧$ in the inner relation ${\mathit{tp}}_3$ . An optimistic planner which assumes that $⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧$ produces few tuples would choose an NLJ operator in this case, even though obtaining all tuples from ${\mathit{tp}}_3$ to perform an SHJ merely requires 12 requests. Consequently, knowing that probing each tuple from $⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧$ requires at least one request using a NLJ, the NLJ is guaranteed to require more requests than the SHJ if $|⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧|\mathrm{>}12$ . Instead of continuing to follow a predefined join strategy, an adaptive client could decide to change the join strategies based on the information it obtains during query execution. In the example, the client could decide to switch to a SHJ after realizing that $|⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧|\mathrm{>}12$ , which would reduce the number of requests from 813 to just 82 requests. The number of requests are given by: 4 requests to obtain the count values, 10 requests for $⟦{\mathit{tp}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{tp}}_2⟧$ , 13 requests for probing tuples in ${\mathit{tp}}_3$ before switching, 12 requests for obtaining all tuples from ${\mathit{tp}}_3$ after switching, and 43 requests for probing the tuples in ${\mathit{tp}}_4$ .

Our motivating example illustrates how efficient client-side query processing over TPF server can be achieved by (i) obtaining efficient query plans that are less prone to cardinality estimation errors, and (ii) adapting the join strategy during query execution. In Section 4, we present our approaches for robust query planning that not only considers the best-case scenario but also an average-case scenario when determining an efficient query plan. Moreover, in Section 5, we present the concept of Polymorphic Join Operators which are able to adapt their join strategy during query execution.

3. Background and related work

Different cost models and adaptive techniques have been proposed in federated SPARQL query engines. Therefore, we first present related work on federated SPARQL query processing (§3.1). Thereafter, we present the planning techniques implemented by client-side query processing for Linked Data Fragments (§3.2). Finally, we present adaptive and robust query processing approaches from the area of relational databases which address estimation errors in query planning and query execution (§3.3).

3.1. Federated SPARQL query processing

A variety of cost models [9,12,23–25] and adaptive query processing approaches [2,20] have been proposed to employ efficient federated SPARQL query processing. DARQ [24] implements a cost model to reduce the amount of data transferred and the number of transmissions. The cost estimation functions for nested loop joins and bind joins rely on join cardinality estimations derived from statistical information from the service descriptions of the federation members. The optimizer uses Iterative Dynamic Programming (IDP) to obtain an efficient query plan. The federated engine SPLENDID [12] also implements a cost model to devise efficient plans. The cost model incorporates the network communication based on the estimated number of tuples to be transferred for either a bind or a hash join operator. Join cardinalities are estimated using precomputed indices based on VoID descriptions. The optimizer uses Dynamic Programming (DP) to find the cost-optimal plan. The cost model in SemaGrow [9] incorporates the costs for querying endpoints, transferring tuples, and processing them locally. The cardinality estimations for computing these costs rely on detailed statistics including the number of distinct subjects, predicates, and objects for a given triple pattern. The query plan optimizer uses DP to enumerate the space of possible join plans and prunes inferior plans. The cost function of Odyssey [23] is only based on the cardinalities of intermediate results to favor plans that produce fewer intermediate results. The cardinalities of intermediate results are estimated using characteristics sets statistics of the federation members, and DP is applied to enumerate alternative join orders for the subexpressions. CostFed’s [25] cost model also relies on detailed data summaries to estimate the cardinalities of subexpressions. The cost model is tailored to physical query plans with symmetric hash joins and bind joins. The optimizer follows a greedy-heuristic to incrementally build sub-plans with minimal cardinalities.

Federated SPARQL query processing approaches that focus on runtime adaptivity include ANAPSID [2] and ADERIS [20]. ANAPSID [2] is a federated SPARQL query engine that adapts to data availability and runtime conditions of endpoints to hide delays from users. The engine implements a query planner based on adaptive sampling and two non-blocking join operators that aim to produce query results even in the case that SPARQL endpoints get blocked. The ADERIS system [20] focuses on adaptive join ordering for federated SPARQL queries. The system relies on basic statistics (predicates per source) for an initial decomposition of the query. In contrast to a static query plan, ADERIS adapts the join order during query execution using a cost model that uses the cardinalities and selectivities determined during runtime.

Similar to our work, existing federated querying approaches [9,12,23–25] implement cost models for comparing alternative query plans. The cost models typically combine local processing and network communication cost and consider different join operators. However, they rely on fine-grained cardinality estimations that are based on detailed statistics about the data sources. Moreover, the optimizers are able to employ different plan enumeration approaches, such a DP, since typically the search space for federated plans is smaller as they work with subexpressions which are typically composed of several triple patterns and other operators. Similar to the Polymorphic Join Operators, ANAPSID [2] also focuses on intra-operator adaptivity but the join operators adapt to delayed or bursty data traffic rather than cardinality estimation errors. In contrast to our work, ADERIS [20] implements inter-operator adaptivity and the cost model relies on cardinality and selectivity statistics produced during the query execution.

3.2. Linked data fragments and clients

Linked Data Fragments (LDF) are interfaces for accessing and querying RDF graphs on the Web [28]. A central difference between these interfaces is their expressivity and the metadata they provide [15,17], resulting in different client-side query processing approaches for LDF interfaces. The original Triple Pattern Fragment (TPF) client [28] supports the evaluation of SPARQL queries over TPF servers and implements a heuristics to process the query which tries to minimize the number of requests. The TPF client implements non-blocking operators and the join order is given by sorting the triple patterns according to their cardinality. The triple pattern with the smallest estimated number of matches is evaluated and the resulting solution mappings are used to instantiate variables in the remaining triple patterns. This procedure is executed continuously during runtime until all triple patterns have been evaluated. Comunica [27] is a modular query engine that supports SPARQL query evaluation over heterogeneous interfaces including TPF servers. The client is embedded in the Comunica framework which aims to provide a research platform for SPARQL query evaluation to support the development of modular, web-based query engines. Comunica currently supports two heuristic-based configurations. The sort configuration sorts all triple patterns according to the metadata and joins them in that order similar to [28]. The smallest configuration does not sort the entire BGP but selects the triple pattern with the smallest estimated count on every recursive evaluation call. The network of Linked Data Eddies (nLDE) [1] is an adaptive client-side SPARQL query engine over TPF servers. The query optimizer in nLDE builds star-shaped groups (SSG) and joins the triple patterns by ascending cardinality. The optimizer places either symmetric hash join or nested loop join operators to minimize the expected number of requests that need to be performed. Furthermore, nLDE realizes adaptivity by adjusting the routing of result tuples during the query execution according to changing runtime conditions and data transfer rates.

More expressive LDF interfaces include brTPF and smart-KG. Bindings-restricted Triple Pattern Fragments (brTPF) [14] are an extension of the TPF interface that allows for evaluating a given triple pattern with a sequence of bindings to enable more efficient bind join strategies. Given a triple pattern and sequence of bindings, the brTPF server instantiates the variables of the triple pattern with the bindings and evaluates them over the RDF graph to return the matching triples. The authors propose a heuristic-based client that builds left-deep query plans which aims to reduce the number of requests and data transferred by leveraging bind joins. Smart-KG [6] is a hybrid shipping approach which aims to balance the load between clients and servers when evaluating SPARQL queries over remote sources. The smart-KG server extends the TPF interface by providing access to compressed partitions of the graph. These partitions are based on the concept of predicate families to support the evaluation of star-shaped subexpression over the partition at the client. The smart-KG client determines which subexpressions are evaluated locally over the shipped partitions and which triple patterns should be evaluated at the server.

Finally, SaGe [22] is a query engine that supports Web preemption by combining a preemptable server and a corresponding smart client. The server supports the fragment of SPARQL which can be evaluated in a preemptable fashion. The client decomposes a query such that the resulting subexpressions can be answered by the server and it also handles the preemptable execution of the query. As a result, the evaluation of the subexpressions is carried out at the server using a heuristic-based query planner that builds left-deep plans with index loop joins.

Different from the existing LDF clients, our query planner relies on a cost model, a robustness measure, and IDP to devise efficient query plans. Specifically, we focus on the TPF interface to showcase the effectiveness of our approach, however, it can be extended to support additional LDF interfaces. For instance, by extending the probe function in our cost-model to also support brTPF with several bindings per request. In addition, more expressive LDF interfaces and their clients may also benefit from our robustness measure. For example, to devise efficient and robust query plans in the smart-KG client or the SaGe server. While existing clients implement adaptivity during runtime [1,27,28], in contrast to the Polymorphic Join Operators, these adaptive approaches do not adjust the join strategy in response to estimation errors but focus on changing the join order and tuple routing during execution.

3.3. Robust query processing in relational databases

In the realm of relational databases, various approaches address uncertainties in the statistics and parameters used in cost models. Wiener et al. [29] consider different types of robustness including (i) query optimizer robustness as the ability of the optimizer to choose good plans under unexpected conditions, and (ii) query execution robustness as the efficient execution of a given plan under different runtime conditions. Yin et al. [32] focus on the former by investigating robust query optimization methods which are robust with respect to estimation errors. Their classification of such methods includes Robust Plan Selection, which comprises approaches that select a “robust” plan which is less sensitive to estimation errors over the “optimal” plan. These approaches, for example, use probability density functions for cardinality estimations instead of single-point values [7] or define cardinality estimation intervals where the size of the intervals indicate the uncertainty of the optimizer [8]. Wolf et al. [30] propose cardinality-based and selectivity-based robustness metrics for query plans. The core idea is computing the cost of a query plan as a function of the cardinality and selectivity estimations at all edges in the plan. The robustness metrics are computed based on the slope and area under the resulting cost function.

The CROP query planner can be considered a Robust Plan Selection approach. In contrast to [7] and [8], CROP has to rely on coarse grained statistics that do not allow for computing selectivity or cardinality estimation probabilities. Similar to [30], our measure computes the robustness of query plans and selects a robust plan from a selection of the cheapest plans.

Besides robust query planning, a variety of adaptive query processing approaches [10,13] have been proposed to support query execution robustness. Similar to our work, operator replacement considers approaches, where physical operators can be replaced with a logically equivalent operator at runtime [13]. Operator replacement typically occurs due to mid-query re-optimization [10]. For example, progressive query optimization (POP) [21] adapts to cardinality estimation errors by re-optimizing the query plans potentially leading to operator replacement. To this end, POP determines validity ranges of sub-plan cardinalities that trigger query plan re-optimization if the actual cardinalities violate these ranges. Materialized views and corresponding checkpoints allow the re-optimized query plans to reuse intermediate results.

Fig. 2.

Overview of CROP.

Similarly, Rio [8] adapts to cardinality estimation errors by (i) considering the robustness of query plans during query optimization based on bounding-boxes for estimations, and (ii) creating switchable plans during the optimization phase that can be used as alternatives plans in response to estimation errors at runtime.

The proposed Polymorphic Join Operators can be considered as dynamic operator replacement. However, in contrast to [21] and [8], the Polymorphic Join Operators do not require a re-optimization of the query plan or precomputed switchable plans. Moreover, the Polymorphic Join Operators independently decide whether they adapt their join strategy solely based on runtime conditions without detailed statistics for validity ranges or bounding-boxes. This makes our proposed solution suitable for query execution over LDFs, where the engine has access only to coarse-grained statistics.

4. Robust query planning

We present CROP, a cost- and robustness-based query plan optimizer to devise efficient plans for SPARQL queries over Linked Data Fragment (LDF) servers. An overview of the approach is provided it Fig. 2. Given a SPARQL query, the query plan optimizer determines a set of alternative query plans. The efficiency and robustness of these plans are estimated by our cost model and robustness measure. Finally, the optimizer selects a query that yields an appropriate trade-off of both cost and robustness. In the following, we start by introducing the preliminaries and thereafter, present the cost model (§4.2), robustness measure (§4.3), and query planner (§4.4) in detail.

4.1. Preliminaries

The foundation of this work is the Resource Description Framework (RDF). Consider the three pairwise disjoint sets of Internationalized Resource Identifiers (IRIs) I, blank nodes B, or literals L. An RDF term is an element in $\mathit{I}\cup \mathit{B}\cup \mathit{L}$ and an RDF triple is a 3-tuple of RDF terms: $\mathit{t}=\mathrm{(}\mathit{s}\mathrm{,}\mathit{p}\mathrm{,}\mathit{o}\mathrm{)}\in \mathrm{(}\mathit{I}\cup \mathit{B}\mathrm{)}\times \mathit{I}\times \mathrm{(}\mathit{I}\cup \mathit{B}\cup \mathit{L}\mathrm{)}$ , with s the subject, p the predicate, and o the object of the triple. A finite set of RDF triples is called an RDF graph G and the universe of RDF graphs is denoted by $\mathcal{G}$ . SPARQL is the recommended query language for RDF which allows to construct queries by replacing RDF terms with variables. Following the notation introduced by Schmidt et al. [26], let V be the set of variables disjoint from I, B, and L.

Definition 4.1 (SPARQL Expression [26]).

A SPARQL expression is an expression that is recursively defined as follows.

A triple pattern $\mathit{tp}\in \mathrm{(}\mathit{I}\cup \mathit{V}\mathrm{)}\times \mathrm{(}\mathit{I}\cup \mathit{V}\mathrm{)}\times \mathrm{(}\mathit{I}\cup \mathit{L}\cup \mathit{V}\mathrm{)}$ is a SPARQL expression.

If ${\mathit{P}}_1$ and ${\mathit{P}}_2$ are expressions and R is a SPARQL filter condition, then the expressions ${\mathit{P}}_1\mathrm{\text{F}}\mathrm{\text{ILTER}}\mathit{R}$ , $\mathrm{(}{\mathit{P}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{P}}_2\mathrm{)}$ , $\mathrm{(}{\mathit{P}}_1\mathrm{\text{U}}\mathrm{\text{NION}}{\mathit{P}}_2\mathrm{)}$ and $\mathrm{(}{\mathit{P}}_1\mathrm{\text{O}}\mathrm{\text{PT}}{\mathit{P}}_2\mathrm{)}$ are SPARQL expressions.

Furthermore, we denote the universe of SPARQL expression as $\mathcal{P}$ . A basic graph pattern (BGP) P is either a triple pattern or an expression of the form $\mathit{P}=\mathrm{(}{\mathit{P}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{P}}_2\mathrm{)}$ , where ${\mathit{P}}_1$ and ${\mathit{P}}_2$ are either a conjunctive expression (And) or a triple pattern. By ${⟦\mathit{P}⟧}_{\mathit{G}}$ , we denote the evaluation of a SPARQL expression P over an RDF graph G. We denote the number of triple patterns in a BGP P by $|\mathit{P}|$ . We assume set semantics for SPARQL as defined by Schmidt et al [26] and thus, the evaluation of an expression yields a set of solution mappings $\mathrm{\Omega }=\{{\mathit{\mu }}_1\mathrm{,}\dots \mathrm{,}{\mathit{\mu }}_{\mathit{n}}\}$ , where a solution mapping is a partial function $\mathit{\mu }:\mathit{V}\to \mathit{IBL}$ , mapping variables to RDF terms. The set of variables for which μ is defined is called the domain of a solution mapping $dom\mathrm{(}\mathit{\mu }\mathrm{)}\subset \mathit{V}$ . Moreover, we define a function $vars:\mathcal{P}\to \mathit{V}$ that maps an expression to the set of variables in the expression. Finally, given a BGP P and a solution mapping μ, we denote $\mathit{\mu }\mathrm{(}\mathit{P}\mathrm{)}$ replacing all variables $?\mathit{x}\in dom\mathrm{(}\mathit{\mu }\mathrm{)}\cap vars\mathrm{(}\mathit{P}\mathrm{)}$ in P by $\mathit{\mu }\mathrm{(}?\mathit{x}\mathrm{)}$ .

In the remainder of this work, we focus on query plans for BGPs to be evaluated over Linked Data Fragment (LDF) servers. An LDF server is a Web interface to access and query RDF graphs. We identify an LDF server by its IRI $\mathit{c}\in \mathit{I}$ . Similar to [5] and [17], we defined a function $ep:\mathit{I}\to \mathcal{G}$ that maps the IRI of an LDF server to the (default) graph available at the server. Moreover, we denote the type of interface of an LDF server $int\mathrm{(}\mathit{c}\mathrm{)}$ .

Example 4.1.

The TPF server for DBpedia of our motivating example can be defined as

${\mathit{c}}_{\mathrm{DBpedia}}=$ <http://fragments.dbpedia.org/2014/en>,

$ep\mathrm{(}{\mathit{c}}_{\mathrm{DBpedia}}\mathrm{)}={\mathit{G}}_{\mathrm{DBpedia}}$ , and

$int\mathrm{(}{\mathit{c}}_{\mathrm{DBpedia}}\mathrm{)}=\mathrm{\text{T}}\mathrm{\text{PF}}$ .

The central components of query plans for evaluating BGPs over LDF servers are its access operators. An access operator evaluates a SPARQL expression over a given LDF server by performing the necessary HTTP requests to obtain all solution mappings according to the interface.

Definition 4.2 (Access Operator).

An access operator is a tuple $\mathit{A}=\mathrm{(}\mathit{SE}\mathrm{,}\mathit{c}\mathrm{)}$ with $\mathit{SE}\in \mathcal{P}$ a SPARQL expression and c the IRI of an LDF server.

A join query plan defines the join order, the physical join operators, and the access operator for evaluating a BGP P in a tree structure.5

⁵

We only consider binary join operators, resulting in a binary tree.

Definition 4.3 (Join Query Plan).

A join query plan T is a binary tree, where the leaves $\mathcal{A}\mathrm{(}\mathit{T}\mathrm{)}=\{{\mathit{A}}_1\mathrm{,}\dots \mathrm{,}{\mathit{A}}_{\mathit{n}}\}$ of the tree are access operators and the internal nodes are physical join operators.

For query plan T, we denote the number of leaves as $|\mathit{T}|=|\mathcal{A}\mathrm{(}\mathit{T}\mathrm{)}|$ . The number of join operations is then given as $|\mathit{T}|-1$ . The longest path from the root of a (sub) query plan T to any access operator is denoted as $height\mathrm{(}\mathit{T}\mathrm{)}$ and for an access operator A, we have $height\mathrm{(}\mathit{A}\mathrm{)}=0$ . Moreover, the estimated number of solution mappings obtained by evaluating T is denoted $card\mathrm{(}\mathit{T}\mathrm{)}$ . Note that we distinguish algebraic join operators () and physical join operators (⋈). In addition, we indicate the join algorithm of a physical join operator by its subscript. For example, a bind join operator is denoted by ${\bowtie }_{\mathsf{\text{BJ}}}$ . In this work, we consider a physical join operator to be correct, if it adheres to the set semantics defined in [26].

Definition 4.4 (Evaluation of a Join Query Plan).

Given a query plan T, the evaluation of T is defined as

Furthermore, we define a function $expr\mathrm{(}\mathit{T}\mathrm{)}$ that maps a query plan T to its algebraic structure. This function traverses the tree structure of the query plan and replaces the access operators by their algebra expression and physical operators by the corresponding algebra operators as defined in Definition 4.4. Hence, $expr\mathrm{(}\mathit{T}\mathrm{)}$ allows us to compare different plans and to determine whether they are algebraically equivalent.

Proposition 4.1.

Given an LDF interface c for RDF graph G with $ep\mathrm{(}\mathit{c}\mathrm{)}=\mathit{G}$ and a BGP P. The evaluation of a join query plan T for P is correct, that is, $$\begin{array}{c}eval{\mathrm{(}\mathit{T}\mathrm{)}=⟦\mathit{P}⟧}_{\mathit{G}}\mathrm{,}\end{array}$$ if $expr\mathrm{(}\mathit{T}\mathrm{)}$ is algebraically equivalent to P, all physical operators in T are correct, and ${\mathit{c}}_{\mathit{i}}=\mathit{c}\forall \mathrm{(}{\mathit{SE}}_{\mathit{i}}\mathrm{,}{\mathit{c}}_{\mathit{i}}\mathrm{)}\in \mathcal{A}\mathrm{(}\mathit{T}\mathrm{)}$ .

The proposition follows from the algebraic equivalences defined by Schmidt et al. [26] and the fact that all expressions are evaluated over the same graph $ep\mathrm{(}\mathit{c}\mathrm{)}$ . Finally, $\mathit{T}\mathrm{(}\mathit{P}\mathrm{)}$ denotes a query plan for a SPARQL expression P, that is $expr\mathrm{(}\mathit{T}\mathrm{)}=\mathit{P}$ .

4.2. Cost model

We now present our cost model to estimate the cost of evaluating a query plan for a basic graph pattern over an LDF server. In principle, the cost for evaluating a query plan in a decentralized scenario are determined by (i) the server cost for processing the requests (i.e., evaluating the expression) on the server, (ii) the network cost for transporting requests and responses over the network, and (iii) the client cost, for processing the tuples of the response. Specifically, determining the server and network costs is challenging in practice since they are influenced by a large number of factors, such as the server load or potential network delays. Therefore, we use the number of requests that need to be performed by an access operator as a proxy for server and network costs. Consequently, for the sake of comparability of the individual requests of the access operator and because any LDF interface (except data dumps) allows for evaluating triple patterns, we assume the subexpressions in the access operators to be triple patterns, i.e., ${\mathit{SE}}_{\mathit{i}}={\mathit{tp}}_{\mathit{i}}$ , $\forall \mathrm{(}{\mathit{SE}}_{\mathit{i}}\mathrm{,}\mathit{c}\mathrm{)}\in \mathcal{A}\mathrm{(}\mathit{T}\mathrm{)}$ . Moreover, we only consider query plans which are evaluated over a single LDF server c. The number of requests that an access operator needs to perform depends on the specific LDF server. For example, TPF servers require several requests when the number of resulting tuples exceeds the page size of the server, while (in principle) a single request suffices when accessing SPARQL endpoints. Furthermore, other LDF servers, such as brTPF servers, may require fewer requests than TPF servers when probing tuples for a triple pattern because they support probing multiple bindings [14].

In the following, we focus on the request cost for access operators for TPF servers and for the physical join operators Bind Join (BJ) and symmetric Hash Join (HJ). Given a query plan T for a conjunctive query the cost of evaluating T over LDF server c is computed as $$\begin{array}{c}cost\mathrm{(}\mathit{T}\mathrm{)}=\left\{\begin{array}{cc}0\hfill & \text{if }\mathit{T}\text{ is a leaf }{\mathit{A}}_{\mathit{i}}\mathrm{,}\hfill \\ cost\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}+cost\mathrm{(}{\mathit{T}}_1\mathrm{)}+cost\mathrm{(}{\mathit{T}}_2\mathrm{)}\hfill & \text{if }\mathit{T}={\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{,}\hfill \end{array}\right.\end{array}$$ where $cost\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}$ is the cost of joining the solution mappings from sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ at the client using the physical join operator ⋈. Note that the cost for a leaf is 0 as its cost is accounted for as part of the join cost $cost\mathrm{(}{\mathit{T}}_{\mathit{i}}\bowtie {\mathit{T}}_{\mathit{j}}\mathrm{)}$ . In our model, the cost of joining two sub-plans is comprised of two aspects: (i) request cost, as the cost for submitting HTTP requests to the server if necessary; and (ii) processing cost, the client’s cost for processing the tuples that it receives from the server. Hence, the cost of joining sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ using the join operator ⋈ is given by: $$\begin{array}{c}cost\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}=\mathit{\varphi }·proc\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}+req\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}\end{array}$$ where proc are the processing cost, req the request cost, and $\mathit{\varphi }\in [0\mathrm{,}\infty \mathrm{)}$ a weighting factor.

4.2.1. Processing cost

The processing costs account for the effort of handling the tuples at the client once they have been received from the server. For instance, this includes parsing the tuples into the corresponding data structures and potentially inserting them into hash tables in the join operators. The first parameter of the cost model $\mathit{\varphi }\in [0\mathrm{,}\infty \mathrm{)}$ allows for weighting the local processing cost with respect to the request cost. For instance, $\mathit{\varphi }=1$ indicates that processing a single tuple at the client is equally expensive as one HTTP request. The impact of processing cost and request cost on the query execution time depends on the scenario in which the LDF server and client are deployed. In a local scenario, where network latency and the load on the LDF server are low, the impact of the processing cost on the execution time might be higher than in a scenario with high network latency, where the time for submitting requests has a larger share on the execution time. The processing cost depends on the physical join operator ⋈ and we distinguish two cases: $$\begin{array}{c}proc\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}=\left\{\begin{array}{cc}card\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}\hfill & \text{if }\bowtie ={\bowtie }_{\mathsf{\text{HJ}}}\mathrm{,}\hfill \\ card\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}+card\mathrm{(}{\mathit{T}}_2\mathrm{)}\hfill & \text{if }\bowtie ={\bowtie }_{\mathsf{\text{BJ}}}.\hfill \end{array}\right.\end{array}$$

In both cases, the estimated tuples produced by the join $card\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}$ are considered. Including $card\mathrm{(}{\mathit{T}}_2\mathrm{)}$ in the processing cost for the BJ allows the optimizer to estimate the cost of alternative plans more accurately. For instance, if we assume the minimum as the cardinality estimation function and do not consider the cardinality of the inner relation, a plan $\mathrm{(}\mathit{A}{\bowtie }_{\mathsf{\text{BJ}}}\mathit{B}\mathrm{)}$ could be chosen over $\mathrm{(}\mathit{A}{\bowtie }_{\mathsf{\text{BJ}}}\mathit{C}\mathrm{)}$ even if B has a higher cost than C.

4.2.2. Request cost

In our cost model, we use the request cost as a proxy for the network cost and the server-side cost when evaluating an expression at the server. The request cost $req\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}$ for joining two sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ are determined by the join operator ⋈ and whether the sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ are access operators. In the following, we present how the request cost for the access operators as well as for a bind join and a symmetric hash join operators are computed in our cost model. In line with the evaluation of our approach, we will detail these cost functions for Triple Pattern Fragment servers. Nonetheless, the functions can be extended to support other LDF interfaces as well.

Access operator If a T is an access operator $\mathit{A}=\mathrm{(}\mathit{SE}\mathrm{,}\mathit{c}\mathrm{)}$ , the cost of its requests are given by the number of requests that need to be performed to obtain all solution mappings for the expression $\mathit{SE}$ at the LDF server c. Otherwise, if T is a sub-plan (i.e., $height\mathrm{(}\mathit{T}\mathrm{)}\mathrm{>}0$ ), no requests costs are associated with it. Specifically, we focus on access operators for a TPF server c ( $int\mathrm{(}\mathit{c}\mathrm{)}=$ TPF) where the expression $\mathit{SE}$ of the access operator is a triple pattern $\mathit{tp}$ . Therefore, the request cost for an access operator for a TPF server c with page size ${\mathit{p}}_{\mathit{c}}$ evaluating triple pattern $\mathit{tp}$ over $ep\mathrm{(}\mathit{c}\mathrm{)}$ is given as $$\begin{array}{}\text{(1)}& acc\mathrm{(}\mathit{T}\mathrm{)}=\left\{\begin{array}{cc}\lceil \frac{card\mathrm{(}\mathit{tp}\mathrm{,}\mathit{c}\mathrm{)}}{{\mathit{p}}_{\mathit{c}}}\rceil \hfill & \text{if }\mathit{T}=\mathit{A}=\mathrm{(}\mathit{t}\mathit{p}\mathrm{,}\mathit{c}\mathrm{)}\text{,}\hfill \\ 0\hfill & \text{otherwise.}\hfill \end{array}\right.\end{array}$$

Bind join The request costs of a Bind Join (BJ) are determined by the request cost for obtaining the tuples of the outer plan $acc\mathrm{(}{\mathit{T}}_1\mathrm{)}$ and the request cost for probing the instantiations in the inner plan ${\mathit{T}}_2$ : $probe\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}$ . Therefore, the request costs for the BJ are computed as $$\begin{array}{c}req\mathrm{(}{\mathit{T}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{T}}_2\mathrm{)}=acc\mathrm{(}{\mathit{T}}_1\mathrm{)}+\mathit{d}\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}·probe\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}\end{array}$$ where $probe\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}$ is the estimated number of requests for probing all tuples of $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ in the inner plan ${\mathit{T}}_2$ and $\mathit{d}\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}$ is a factor for discounting the probing cost, which we detail in Eq. (3). In the remainder of this work, we only focus on BJs where ${\mathit{T}}_2$ is an access operator for a triple pattern because it allows for more accurate request cost estimations. In case ${\mathit{T}}_1$ is leaf, i.e., an access operator ${\mathit{A}}_1=\mathrm{(}{\mathit{tp}}_1\mathrm{,}\mathit{c}\mathrm{)}$ , the number of requests to obtain the tuples from ${\mathit{T}}_1$ is given by $acc\mathrm{(}\mathrm{(}{\mathit{tp}}_1\mathrm{,}\mathit{c}\mathrm{)}\mathrm{)}$ from Eq. (1). Otherwise, there are no request cost associated with ${\mathit{T}}_1$ . In either case, the number of requests that need to be performed to probe the tuples from ${\mathit{T}}_1$ in ${\mathit{T}}_2$ needs to be considered. This number depends on the number of tuples in $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ , the number of tuples that are produced when probing each tuple, and the number of instantiations that can be probed at the server in a single request. For a TPF server c, the accurate number of requests for probing each tuple $\mathit{\mu }\in eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ in triple pattern $\mathit{tp}$ is given by $$\begin{array}{c}{\displaystyle \sum }_{\mathit{\mu }\in eval\mathrm{(}{\mathit{T}}_1\mathrm{)}}\lceil {\displaystyle \frac{⟦\mathit{\mu }{\mathrm{(}\mathit{tp}\mathrm{)}⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}}{{\mathit{p}}_{\mathit{c}}}}\rceil \end{array}$$

In practice, there are two major reasons why this cannot be computed accurately. First, the number of tuples in $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ needs to be estimated by a cardinality estimation function. Second, it is infeasible to determine how many tuples are produced by instantiating the individual solution mapping. Therefore, we use the estimated cardinality of ${\mathit{T}}_1$ as a lower bound and the estimated join cardinality divided by the page size ${\mathit{p}}_{\mathit{c}}$ as an upper bound. $$\begin{array}{}\text{(2)}& probe\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}=max\{card\mathrm{(}{\mathit{T}}_1\mathrm{)}\mathrm{,}\lceil {\displaystyle \frac{card\mathrm{(}{\mathit{T}}_1\bowtie {\mathit{T}}_2\mathrm{)}}{{\mathit{p}}_{\mathit{c}}}}\rceil \}.\end{array}$$

The minimum number of requests that need to be performed is given by the cardinality for ${\mathit{T}}_1$ , i.e. one request per binding. However, it might be the case that the join produces more results per binding than the page size, such that paginating is required to obtain all solutions for one binding in the inner relation. In this case, we use the estimated join cardinality and the page size to estimate the requests. Note that while we focus on Bind Join operators with a block size of 1, the probe function can be adapted for LDF servers that support bind join strategies with a block size  $\mathrm{>}1$ as well, such as brTPF servers [14].

The discounting factor for BJs is computed using the parameter $\mathit{\delta }\in [0\mathrm{,}\infty \mathrm{)}$ and the maximum height of the sub-plans as $$\begin{array}{}\text{(3)}& \mathit{d}\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}={\displaystyle \frac{1}{max\{1\mathrm{,}\mathit{\delta }·height\mathrm{(}{\mathit{T}}_1\mathrm{)}\mathrm{,}\mathit{\delta }·height\mathrm{(}{\mathit{T}}_2\mathrm{)}\}}}.\end{array}$$

The rationale for including a discount factor for the requests on the inner plan is twofold. First, since the join variables are bound by the terms obtained from the outer plan, the number of variables in the triple pattern is reduced which can reduce the cost per request. This was shown in an empirical study for TPF servers [18]. Second, for star-shaped queries, typically the number of tuples reduces with an increasing number of join operations and, therefore, the higher the BJ operator is placed in the query plan, the more likely it is that it needs to perform fewer requests in the inner plan than the estimated cardinality of the outer relation suggests. The discount factor $\mathit{d}\mathrm{(}{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\mathrm{)}$ allows for considering these aspects and its parameter δ allows for setting the magnitude of the discount factor. With $\mathit{\delta }=0$ , there is no discount and with an increasing δ value, placing BJs higher in the query plan becomes increasingly cheaper.

Symmetric hash join The request cost for the symmetric Hash Join (HJ) operator is computed based on the number of requests that need to be performed if either or both sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ are access operators. $$\begin{array}{c}req\mathrm{(}{\mathit{T}}_1{\bowtie }_{\mathsf{\text{HJ}}}{\mathit{T}}_2\mathrm{)}=acc\mathrm{(}{\mathit{T}}_1\mathrm{)}+acc\mathrm{(}{\mathit{T}}_2\mathrm{)}\end{array}$$

If both ${\mathit{T}}_1$ and ${\mathit{T}}_2$ are access operators, we sum up the corresponding number of requests according to the access operator. If just one sub-plan (e.g., ${\mathit{T}}_2$ ) is an access operator, we need to consider the number of requests for its access operator. Otherwise, when joining two sub-plans with $height\mathrm{(}{\mathit{T}}_1\mathrm{)}\mathrm{>}0$ and $height\mathrm{(}{\mathit{T}}_2\mathrm{)}\mathrm{>}0$ , there are no requests that need to be performed by the join operator.

Note that the number of requests for the HJ can be computed accurately if the true cardinalities of the expressions of the access operators are known. For example, the count metadata that provides (an estimation of) the number of triples matching a triple pattern allows for determining the number of requests accurately.

Cardinality estimation Central to our cost model are the expected number of intermediate results produced by the join operators as this number affects both the local processing and the request costs. Since we focus on query plans for BGPs, we determine the number of intermediate results by recursively applying a join cardinality estimation function to the query plan T. Given a query plan T, we estimate the cardinality as $$\begin{array}{}\text{(4)}& card\mathrm{(}\mathit{T}\mathrm{)}=\left\{\begin{array}{cc}{card}_{acc}\mathrm{(}\mathit{SE}\mathrm{,}\mathit{c}\mathrm{)}\hfill & \text{if }\mathit{T}=\mathit{A}=\mathrm{(}\mathit{S}\mathit{E}\mathrm{,}\mathit{c}\text{)}\mathrm{,}\hfill \\ min\{card\mathrm{(}{\mathit{T}}_1\mathrm{)}\mathrm{,}card\mathrm{(}{\mathit{T}}_2\mathrm{)}\}\hfill & \text{if }\mathit{T}={\mathit{T}}_1\bowtie {\mathit{T}}_2.\hfill \end{array}\right.\end{array}$$

To compute the cardinality estimation for an access operator $\mathit{A}=\mathrm{(}\mathit{SE}\mathrm{,}\mathit{c}\mathrm{)}$ depends on the expression $\mathit{SE}$ , the LDF server c, and the corresponding graph $ep\mathrm{(}\mathit{c}\mathrm{)}$ . In the case of TPF servers, we can leverage the “estimate of the cardinality” [28] provided in the metadata when requests a triple pattern which we denote by count. Therefore, we use ${card}_{acc}\mathrm{(}\mathit{tp}\mathrm{,}\mathit{c}\mathrm{)}=count\mathrm{(}\mathit{tp}\mathrm{)}$ . Furthermore, in our cost model, we choose the minimum as the cardinality estimation function for joining sub-plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ as an optimistic estimation.

After presenting our cost model, we will now present the concept of robustness for query plans in order to avoid always choosing the cheapest plan merely based on these optimistic cardinality estimations.

4.3. Query plan robustness

Query planning approaches benefit from accurate join cardinality estimations to determine a suitable join order and to properly place physical operators such that the execution time of the query plan is minimized. However, estimating the join cardinalities is a challenging task, especially in the case that only basic statistics about the data are available. Addressing this challenge, we propose a robustness measure in order to determine how strongly the costs of a query plan are affected by potential cardinality estimations errors. To this end, our robustness measure compares the best-case cost of a query plan to its average-case cost. The average-case cost of a query plan is computed by using different cardinality estimation functions in the cost model to cover alternative join cardinalities. The resulting cost for each estimation function and the same query plan can be aggregated to an average cost value. Thus, a robust query plan is a plan in which the best-case cost only slightly differs from the average-case cost.

Example 4.2.

Let us revisit the query plans from our motivating example in Section 2. As we focus on query plans with access operators for the same LDF server c, for the sake of readability, we omit the access operator in the following examples, i.e., $\mathrm{(}{\mathit{tp}}_{\mathit{i}}\mathrm{,}\mathit{c}\mathrm{)}={\mathit{tp}}_{\mathit{i}}$ . For the sake of simplicity, we only consider the sub-plan $\mathit{T}=\mathrm{(}\mathrm{(}{\mathit{tp}}_1\bowtie {\mathit{tp}}_2\mathrm{)}\bowtie {\mathit{tp}}_3\mathrm{)}$ , and focus on the request cost with $\mathit{\delta }=0$ . Let us consider the alternative query plans $$\begin{array}{l}{\mathit{T}}_1=\mathrm{(}\mathrm{(}{\mathit{tp}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_2\mathrm{)}{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_3\mathrm{)}\mathrm{,}\\ {\mathit{T}}_2=\mathrm{(}\mathrm{(}{\mathit{tp}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_2\mathrm{)}{\bowtie }_{\mathsf{\text{HJ}}}{\mathit{tp}}_3\mathrm{)}.\end{array}$$ For comparing the robustness of ${\mathit{T}}_1$ and ${\mathit{T}}_2$ , we not only use the optimistic cardinality estimation of the cost model (the minimum, cf. Eq. (4)) but also compute the cost using different, less optimistic cardinality estimation functions. For instance, we can also consider the maximum and mean as alternatives. The resulting cost values allow for deriving the average-case cost and thus the robustness of ${\mathit{T}}_1$ and ${\mathit{T}}_2$ . Depending on the cardinality estimation function, we obtain the following cost for the query plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ , see Table 1.

Table 1

Cost of query plans ${\mathit{T}}_1$ and ${\mathit{T}}_2$ for alternative cardinality estimations

	Cardinality Estimation Function
	minimum	mean	maximum
$cost\mathrm{(}{\mathit{T}}_1\mathrm{)}$	5	43 477	86 951
$cost\mathrm{(}{\mathit{T}}_2\mathrm{)}$	15	445	875

Query plan ${\mathit{T}}_1$ yield the lowest best-case cost when considering the minimum. However, we observe that the cost for query plan ${\mathit{T}}_2$ is not as strongly impacted by the alternative estimation functions. As a consequence, its average-case cost does not deviate as strongly from its best-case cost in comparison to ${\mathit{T}}_1$ and as a result, query plan ${\mathit{T}}_2$ is considered a more robust query plan.

Definition 4.5 (Cost ratio robustness measure).

Let T be a query plan, ${cost}^{\ast }\mathrm{(}\mathit{T}\mathrm{)}$ the best-case and $\overline{cost}\mathrm{(}\mathit{T}\mathrm{)}$ the average-case cost for T. The cost ratio robustness (crr) for T is defined as $$\begin{array}{c}crr\mathrm{(}\mathit{T}\mathrm{)}:={\displaystyle \frac{{cost}^{\ast }\mathrm{(}\mathit{T}\mathrm{)}}{\overline{cost}\mathrm{(}\mathit{T}\mathrm{)}}}.\end{array}$$

That is, the cost ratio robustness (crr) of a plan is the ratio between the cost in the best-case ${cost}^{\ast }$ and the cost in the average-case $\overline{cost}$ . A higher ratio indicates a more robust query plan because its expected average-case costs are not as strongly affected by changes in the cardinality estimations with respect to its best-case cost. Note that while we focus on query plans for basic graph patterns in this work, our robustness measure can be applied to query plans for other expressions as well.

We extend the definition of the cost function from Section 4.2 to capture the average-case cost of a query plan by including the cardinality estimation functions applied to each join operator. Let $\mathit{O}=\{{\mathit{o}}_1\mathrm{,}\dots \mathrm{,}{\mathit{o}}_{\mathit{n}-1}\}$ be the set of (binary) join operators for a query plan T ( $|\mathit{T}|=\mathit{n}$ ). Let $\mathit{E}=[{\mathit{e}}_1\mathrm{,}\dots \mathrm{,}{\mathit{e}}_{\mathit{n}-1}]$ be a vector of estimation functions with ${\mathit{e}}_{\mathit{i}}$ the cardinality estimation function applied at join operator ${\mathit{o}}_{\mathit{i}}$ . For the join operator ${\mathit{o}}_{\mathit{i}}$ , the cardinality estimation function ${\mathit{e}}_{\mathit{i}}:{\mathbb{N}}_0^2\to {\mathbb{N}}_0^{}$ maps the cardinalities of the sub-plans $\mathit{a}=card\mathrm{(}{\mathit{T}}_1\mathrm{)}$ and $\mathit{b}=card\mathrm{(}{\mathit{T}}_2\mathrm{)}$ to an estimated join cardinality value. In practice, the values of a cardinality estimation function are bound within zero and the cross-product of a and b: ${\mathit{e}}_{\mathit{i}}\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\in [0\mathrm{,}\mathit{a}·\mathit{b}]$ . We then denote the cost for a query plan T computed using the cardinality estimation functions given by E as ${cost}_{\mathit{E}}\mathrm{(}\mathit{T}\mathrm{)}$ .

Definition 4.6 (Best-case cost).

The best-case cost for a query plan T is defined as $$\begin{array}{c}{cost}^{\ast }\mathrm{(}\mathit{T}\mathrm{)}={cost}_{\mathit{E}}\mathrm{(}\mathit{T}\mathrm{)}\mathrm{,}\end{array}$$ with ${\mathit{e}}_{\mathit{i}}=\mathit{f}$ , $\forall {\mathit{e}}_{\mathit{i}}\in \mathit{E}$ and $\mathit{f}:\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\mapsto min\{\mathit{a}\mathrm{,}\mathit{b}\}$ .

In other words, at every join operator in the query plan, we use the minimum cardinality of the sub-plans to estimate the join cardinality. This is identical to the estimations used in our cost model. Note that while in principle the cardinality for very selective joins can even be lower than the minimum, it still provides an optimistic estimation for computing the best case cost. The computation of the average-case cost requires applying different combinations of such estimation functions at the join operators.

Definition 4.7 (Average-case cost).

Given a set of m estimation functions $\mathit{F}=\{{\mathit{f}}_1\mathrm{,}\dots \mathrm{,}{\mathit{f}}_{\mathit{m}}\}$ with $\mathit{f}:{\mathbb{N}}_0^2\to {\mathbb{N}}_0^{}$ , $\forall \mathit{f}\in \mathit{F}$ . The average-case cost for a query plan T is defined as the median of its cost when applying all potential combinations of estimation functions $\mathit{E}\in {\mathit{F}}^{\mathit{n}-1}$ for the operators of the query plan: $$\begin{array}{c}\overline{cost}\mathrm{(}\mathit{T}\mathrm{)}=median\{{cost}_{\mathit{E}}\mathrm{(}\mathit{T}\mathrm{)}\mid \forall \mathit{E}\in {\mathit{F}}^{\mathit{n}-1}\}.\end{array}$$

By applying a variety of cardinality estimation functions, different join selectivities can be reflected in the average-case cost. We empirically tested different sets of estimation functions in F and found that the following functions yield suitable estimations for computing the average-case cost: $\mathit{F}=\{{\mathit{f}}_1\mathrm{,}{\mathit{f}}_2\mathrm{,}{\mathit{f}}_3\mathrm{,}{\mathit{f}}_4\}$ with

1. $\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\mapsto min\{\mathit{a}\mathrm{,}\mathit{b}\}$ ,

2. $\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\mapsto max\{\mathit{a}\mathrm{/}\mathit{b}\mathrm{,}\mathit{b}\mathrm{/}\mathit{a}\}$ ,

3. $\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\mapsto max\{\mathit{a}\mathrm{,}\mathit{b}\}$ ,

4. $\mathrm{(}\mathit{a}\mathrm{,}\mathit{b}\mathrm{)}\mapsto \mathit{a}+\mathit{b}$ .

The rationale for selecting these functions is to capture different join selectivities based on the cardinality estimations of the sub-plans to be joined. The function ${\mathit{f}}_1$ captures high join selectivities (i.e., the join produces few solution mappings), while ${\mathit{f}}_2$ and ${\mathit{f}}_3$ capture medium and ${\mathit{f}}_4$ low join selectivities. Moreover, we observed that for subject-object (s-o) and object-object (o-o) joins, the cardinalities were more frequently misestimated with the optimistic cardinality estimation function, while for all other types of joins, such as in star-shaped groups, it provided adequate estimations. Similar observations about the challenge in estimating join cardinalities for s-o and o-o joins have been reported in other works as well [31]. Therefore, we only consider alternative cardinality estimation function ${\mathit{e}}_{\mathit{i}}$ for a join operator ${\mathit{o}}_{\mathit{i}}$ , if the join performed at ${\mathit{o}}_{\mathit{i}}$ is either of type s-o or o-o. Thus, for s-s joins, we estimate their cost using only the best-case cost estimation (Definition 4.6). For s-o and o-o join, the alternative cost estimation functions in F are used to compute the average case cost as defined in 4.7.

Example 4.3.

Let us consider the query plan alternative 1 from our motivating example (cf. Fig. 1). In this example, the join is a s-o join and all other joins are s-s joins. As a result, to compute the average case cost, the alternative estimation functions in F are applied to estimate . Based on these four alternative cardinality estimations, the minimum cardinality (cf. Eq. (4)) is used to estimate the cardinality of the remaining joins (as they are s-s joins). With these cardinality estimation alternatives, the cost of the query plan is computed which results in four different cost estimations. Finally, to obtain the average-case cost value, the median of those four cost estimations is computed.

4.4. Query plan optimizer

After presenting our cost model and robustness measure, we now present our optimizer that combines both aspects. Introducing the concept of robustness for query plans in addition to their cost yields two major questions: (i) in which cases should a more robust plan be chosen over the cheapest plan, and (ii) which alternative robust plan should be chosen instead of the cheapest plan? To this end, we propose a query plan optimizer that combines both aspects. Its parameters allow for defining the sensitivity of when a robust plan should be selected and also which alternative plan should be chosen over the cheapest plan. The query plan optimizer follows three main steps:

1. Obtain a selection of alternative query plans using Iterative Dynamic Programming (IDP).

2. Assess the robustness of the cheapest plan.

3. If the cheapest plan is not considered to be robust enough, find an alternative robust query plan.

Algorithm 1:

CROP query plan optimizer

The query plan optimizer is detailed in Algorithm 1. Given a BGP P, the query planner determines the best query plan ${\mathit{T}}^{\ast }$ for P. The input parameters are the block size $\mathit{k}\in [2\mathrm{,}\infty \mathrm{)}$ and the number of top $\mathit{t}\in \mathbb{N}$ cheapest plans for the IDP algorithm. Moreover, the planner relies on a robustness threshold $\mathit{\rho }\in [0\mathrm{,}1]$ and a cost threshold $\mathit{\gamma }\in [0\mathrm{,}1]$ . The first step is to obtain a selection of alternative query plans using IDP. We adapted the original “ ${\mathit{IDP}}_1-\mathit{standard}-\mathit{bestPlan}$ ” algorithm presented by Kossmann and Stocker [19] in the following way. Identical to the original algorithm, we only consider select-project-join queries, i.e. basic graph patterns, and each triple pattern ${\mathit{tp}}_{\mathit{i}}\in \mathit{P}$ is considered a relation in the algorithm. Given a subset of triple patterns $\mathit{S}\subset \mathit{P}$ , the original algorithm considers the single optimal plan for S according to the cost model in $optPlan\mathrm{(}\mathit{S}\mathrm{)}$ by applying the $\mathit{prunePlans}$ function to the potential candidate plans. However, as we do want to obtain alternative plans, we keep the top t cheapest plans for S in $optPlan\mathrm{(}\mathit{S}\mathrm{)}$ for $|\mathit{S}|\mathrm{>}2$ . When joining two triple patterns ( $|\mathit{S}|=2$ ), we always choose the physical join operator with the lowest cost. We follow this strategy for the following reasons. First, we expect accurate cost estimations for joining two triple patterns as the join estimation error impact is low in the base case. Second, by considering fewer alternatives that are likely to be discarded later in the algorithm, we can reduce the number of plans to be explored with IDP without loosing viable alternatives.

Example 4.4.

Consider the query for the motivating example and ${\mathit{S}}_1=\{{\mathit{tp}}_1\mathrm{,}{\mathit{tp}}_2\}$ . According to the cost model, the cheapest plan is $optPlan\mathrm{(}{\mathit{S}}_1\mathrm{)}=\{\mathrm{(}{\mathit{tp}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_2\mathrm{)}\}$ . As $|{\mathit{S}}_1|=2$ , we only consider this single cheapest sub-plan in the remaining iterations. However, for $|\mathit{S}|\mathrm{>}2$ we need to place at least two join operators where the cost of at least one join operator relies on the estimated cardinality of the other. Therefore, we want to keep alternative plans in the case that a robust alternative plan is required. For instance with ${\mathit{S}}_2=\{{\mathit{tp}}_1\mathrm{,}{\mathit{tp}}_2\mathrm{,}{\mathit{tp}}_3\}$ , the optimal plan according to the cost model is ${\mathit{T}}_1=\mathrm{(}\mathrm{(}{\mathit{tp}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_2\mathrm{)}{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_3\mathrm{)}$ . As shown in our motivating example, it turns out that the true optimal sub-plan for S is ${\mathit{T}}_2=\mathrm{(}\mathrm{(}{\mathit{tp}}_1{\bowtie }_{\mathsf{\text{BJ}}}{\mathit{tp}}_2\mathrm{)}{\bowtie }_{\mathsf{\text{HJ}}}{\mathit{tp}}_3\mathrm{)}$ . As a result, the algorithm does not prune all but a single plan, while keeping alternative plans for the case that a robust plan should be chosen. Combining the latter observations, we can set $optPlan\mathrm{(}{\mathit{S}}_2\mathrm{)}=\{{\mathit{T}}_1\mathrm{,}{\mathit{T}}_2\}$

Given the set of t candidate query plans $\mathcal{T}$ from the IDP, the overall cheapest plan ${\mathit{T}}^{\ast }$ is determined (Line 3). If the cheapest plan is considered robust enough according to its cost ratio robustness crr( ${\mathit{T}}^{\ast }$ ) and the robustness threshold ρ, it becomes the final plan and is returned (Line 11). However, if the plan is not robust enough with respect to ρ and there are alternative plans to choose from (Line 4), the query plan optimizer tries to obtain a more robust alternative plan. First, the planner considers the set of plans $\mathcal{R}$ which are above the robustness threshold as potential alternatives. If no such plans exist, it considers all alternative plans except the cheapest plan (Line 7). If the ratio of best-case cost of the cheapest plan ${\mathit{T}}^{\ast }$ to the best-case cost of the alternative plan ${\mathit{R}}^{\ast }$ is higher than the cost threshold γ, the alternative plan ${\mathit{R}}^{\ast }$ is selected as the final plan ${\mathit{T}}^{\ast }$ . For instance, for $\mathit{\rho }=0.1$ and $\mathit{\gamma }=0.2$ , a robust plan is chosen over the cheapest plan if (i) for the cheapest plan ${\mathit{T}}^{\ast }$ , the average-case cost $\overline{cost}\mathrm{(}{\mathit{T}}^{\ast }\mathrm{)}$ is 10 times higher than the best-case cost ${cost}^{\ast }\mathrm{(}{\mathit{T}}^{\ast }\mathrm{)}$ and (ii) for the alternative robust plan ${\mathit{R}}^{\ast }$ , the best-case cost ${cost}^{\ast }\mathrm{(}{\mathit{R}}^{\ast }\mathrm{)}$ is no more than 5 times ( $1\mathrm{/}\mathit{\gamma }$ ) higher than best-case cost of the cheapest plan ${cost}^{\ast }\mathrm{(}{\mathit{T}}^{\ast }\mathrm{)}$ . Hence, smaller robustness threshold values lead to selecting alternative plans when the cheapest plan is less robust, and smaller cost threshold values lead to less restriction on the alternative robust plan with respect to its cost. The combination of both parameters allows for exploring alternative robust plans (ρ) but does not require to choose them at any cost (γ) and therefore, the performance degradation risk [32] is limited. Finally, we investigate the time complexity of the proposed optimizer.

Theorem 4.1.

With the number top plans t and the set of estimation functions F constant, the time complexity of the query plan optimizer is for a BGP P with n triple patterns in the order of

$\mathcal{O}\mathrm{(}{2}^{\mathit{n}}\mathrm{)}$ , for $2⩽\mathit{k}\mathrm{<}\mathit{n}$ ,

$\mathcal{O}\mathrm{(}{3}^{\mathit{n}}\mathrm{)}$ , for $\mathit{k}=\mathit{n}$ .

Proof.

The time complexity of the query plan optimizer is given by the IDP algorithm and computing the average-case cost in the robustness computation. Kossmann and Stocker [19] provide the proofs for the former. For the latter, given $|\mathit{F}|=\mathit{m}$ different estimation functions and the top t query plans, the upper bound for the number of alternative cardinality estimations per query plan is $\mathit{t}·\mathit{m}·2^{\mathit{n}-1}$ . As t and m are considered constants, the time complexity of the robustness computation is in the order of $\mathcal{O}\mathrm{(}{2}^{\mathit{n}}\mathrm{)}$ . Combining these complexity results, we have:

For $\mathit{k}\mathrm{<}\mathit{n}$ , the time complexity of computing the robustness exceeds the time complexity of IDP, which is $\mathcal{O}\mathrm{(}{\mathit{n}}^2\mathrm{)}$ , for $\mathit{k}=2$ and $\mathcal{O}\mathrm{(}{\mathit{n}}^{\mathit{k}}\mathrm{)}$ , for $2\mathrm{<}\mathit{k}\mathrm{<}\mathit{n}$ . As a result, the time complexity is in the order of $\mathcal{O}\mathrm{(}{2}^{\mathit{n}}\mathrm{)}$ .

For $\mathit{k}=\mathit{n}$ , the time complexity of IDP exceeds the time complexity of the robustness computation and therefore, we have that the time complexity of the query plan optimizer is in the order of $\mathcal{O}\mathrm{(}{3}^{\mathit{n}}\mathrm{)}$ .

 □

5. A new class of adaptive join operators

We now present a new class of adaptive join operators which we call Polymorphic Join Operators. The goal of these operators is to improve the runtime efficiency by adapting the join strategy during the execution of a query plan. In particular, these operators adapt to potential join cardinality estimation errors of the planner to achieve an additional level of robustness during query execution.

A central task of the query planner is deciding on the appropriate physical join operators that maximize the query plan’s efficiency with respect to the runtime and number of requests. The efficiency depends on the join strategies implemented by the operators and the number of intermediate results they need to process. Based on join cardinalities estimations of the sub-plans, the query planner decides to place operators that implement different join strategies (e.g., bind join, hash join, etc). A client following the optimize-then-execute paradigm would then execute the resulting query plan. However, this approach does not allow for adapting to potential estimations errors of the planner which can lead to sub-optimal join strategies. Alternatively, the client could support intra-operator adaptivity aiming to support robust query execution. To this end, we propose two new operators in this class of adaptivity, namely a Polymorphic Bind Join and a Polymorphic Hash Join operator. For the sake of simplicity, we present the operators with a bindings block size equal to one, that is a single tuple is probed during the bind join phase. The operators can easily be extended to support larger block sizes for more expressive LDF interfaces.6

⁶

See for example [17], where the concept of polymorphism refers to adapting the block size according to the LDF interface while in this work it refers to adapting the join strategy.

5.1. Polymorphic bind join

The Polymorphic Bind Join (PBJ) is a physical join operator that can switch its join strategy during query execution from a bind join to a hash join strategy. We denote the PBJ by ${\bowtie }_{\mathsf{\text{PBJ}}}$ and given a query plan $\mathit{T}={\mathit{T}}_1\bowtie {\mathit{T}}_2$ , the PBJ can be placed when ${\mathit{T}}_2$ is an access operator in the query plan.

The PBJ operator is outlined in Algorithm 2. The operator receives a stream of tuples from the evaluation of the sub-plan ${\mathit{T}}_1$ as ${\mathrm{\Omega }}_1$ (Line 2). The end of the stream is indicated by an end-of-file (EOF) tuple. The operator receives and processes the tuples in an asynchronous, non-blocking fashion.7

⁷

In the pseudocode, we use the receive keyword to indicate asynchronicity: The operator determines whether the next tuple is available in the stream and if this is not the case, it continues its operation without executing the dependent steps.

In its first phase (Line 5 to 12), the operator follows a bind join strategy and produces the resulting tuples to its output (Line 7). The operator keeps track of the number of probed tuples $\mathit{cnt}$ , which is used to decide whether it should adapt its join strategy. The switch function in Line 9 determines whether the PBJ will switch from the bind join to the hash join strategy. The challenge in deciding whether the strategy should be switched is the fact that the operator does not certainly know the number of tuples that are still remaining from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ until the EOF is received. In our case, the operator assumes that a bind join strategy was chosen by the planner as it expected that the requests cost for probing all tuples in $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ would be lower than for a hash join operator. To this end, the operator determines whether to switch its join strategy according to the number of probed tuples ( $\mathit{cnt}$ ) and the access cost for ${\mathit{T}}_2$ if it was to switch to a hash join: $$\begin{array}{}\text{(5)}& {\mathtt{\text{switch}}}_{\mathsf{\text{PBJ}}}\mathrm{(}\mathit{cnt}\mathrm{,}{\mathit{T}}_2\mathrm{)}=\left\{\begin{array}{cc}\mathtt{\text{True}}\hfill & \mathit{cnt}\mathrm{>}\mathit{\lambda }·acc\mathrm{(}{\mathit{T}}_2\mathrm{)}\mathrm{,}\hfill \\ \mathtt{\text{False}}\hfill & \text{otherwise.}\hfill \end{array}\right.\end{array}$$

Adding the parameter $\mathit{\lambda }\in \mathrm{(}0\mathrm{,}\infty \mathrm{)}$ allows for setting the sensitivity of the operator. Lower λ values indicate a higher sensitivity as the operator would decide earlier to switch its join strategy. Furthermore, λ could be set according to the height of the operator in the plan.

In the case that the operator decides to switch its join strategy (Line 9), it terminates the loop of the bind join. Thereafter, the operator sets up two hash tables (Line 14 and 15) and starts evaluating ${\mathit{T}}_2$ and process the tuples from the resulting stream. In the second phase (Line 18 to 26), the operator implements a non-blocking, symmetric hash join. It produces the join tuples by inserting and probing the remaining tuples it receives from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ and all tuples from $eval\mathrm{(}{\mathit{T}}_2\mathrm{)}$ in the proper hash tables. The operator finishes after receiving the EOF from both inputs.

Algorithm 2:

Polymorphic bind join

Example 5.1.

Let us consider the query plan from our motivating example shown in Fig. 1(a) that is evaluated over the DBpedia TPF server with a page size of 100. We focus on the second join operator $\mathrm{(}{\mathit{tp}}_1\bowtie {\mathit{tp}}_2\mathrm{)}\bowtie \mathit{T}\mathrm{(}{\mathit{tp}}_3\mathrm{)}$ and assume the planner places PBJ operators with $\mathit{\lambda }=1$ . Following an optimistic cardinality estimation (e.g., the minimum) with $card\mathrm{(}{\mathit{tp}}_1\bowtie {\mathit{tp}}_2\mathrm{)}=2$ , the planner decides for a bind join strategy as probing the expected 2 tuples requires fewer requests than obtaining all tuples for ${\mathit{tp}}_3$ . The cardinality of ${\mathit{tp}}_3$ is given as $count\mathrm{(}{\mathit{tp}}_3\mathrm{)}=1187$ and thus, the request cost for the access operator in a hash join is $acc\mathrm{(}\mathit{T}\mathrm{(}{\mathit{tp}}_3\mathrm{)}\mathrm{)}=\lceil 1187\mathrm{/}100\rceil =12$ . However, the actual number of tuples produced by ${\mathit{tp}}_1\bowtie {\mathit{tp}}_2$ is 756. Hence, the PBJ switches its operation after probing 13 tuples ( $13\mathrm{>}1·12$ , Eq. (5)) to a hash join strategy. In this example, the PBJ adapts appropriately to the cardinality estimation error of the planner. Switching to the hash join operator requires less requests than probing the remaining $756-\mathrm{(}13+12\mathrm{)}=731$ tuples from ${\mathit{tp}}_1\bowtie {\mathit{tp}}_2$ . The adaptivity of the operator results in a smaller number of requests and therefore, reduces the overall query execution time.

Parameters for the PBJ The PBJ follows a simple heuristic-based decision rule to decide whether it should switch its join strategy. This is due to the fact that it cannot assess how many tuples in $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ are still remaining to be received. If the bind join strategy of the operator is sub-optimal with respect to the number of requests, the operator should switch to the hash join strategy after probing the first tuple. Since the operator cannot know whether this is the case, it follows the decision rule in ${\mathtt{\text{switch}}}_{\mathsf{\text{PBJ}}}$ to determine the number of tuples ( $\mathit{cnt}$ ) that it probes in the bind join phase, before switching to the hash join phase. There is a maximum value for $\mathit{cnt}$ for which switching to the hash join reduces the number of requests in comparison to not switching. We can split the tuples received from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ into two disjoint subsets ${\mathrm{\Omega }}_1={\mathrm{\Omega }}_1^{\mathrm{BJ}}\cup {\mathrm{\Omega }}_1^{\mathrm{HJ}}$ , with ${\mathrm{\Omega }}_1^{\mathrm{BJ}}$ the tuples that are received and probed during the bind join phase and ${\mathrm{\Omega }}_1^{\mathrm{HJ}}$ the tuples received during the hash join phase. The operator can reduce the number of requests if $\mathit{\lambda }·acc\mathrm{(}{\mathit{T}}_2\mathrm{)}$ is set such that the operator switches with $\mathit{cnt}=|{\mathrm{\Omega }}_1^{\mathrm{BJ}}|$ and $$\begin{array}{c}\underset{\text{Requests for hash join}}{\underbrace{\phantom{{\displaystyle \sum }_{\mathit{\mu }\in {\mathrm{\Omega }}_1^{\mathit{H}\mathit{J}}}}acc\mathrm{(}\mathrm{(}{\mathit{SE}}_2\mathrm{,}\mathit{c}\mathrm{)}\mathrm{)}}}\mathrm{<}\underset{\text{Requests for probing remaining tuples}}{\underbrace{{\displaystyle \sum }_{\mathit{\mu }\in {\mathrm{\Omega }}_1^{\mathrm{HJ}}}acc\mathrm{\left(}\mathrm{\right(}\mathit{\mu }\mathrm{(}{\mathit{SE}}_2\mathrm{)}\mathrm{,}\mathit{c}\mathrm{\left)}\mathrm{\right)}}}.\end{array}$$

In other words, the PBJ decides correctly if it switches to a hash join operation as long as the access requests for ${\mathit{T}}_2$ in the hash join are lower than probing the remaining tuples ${\mathrm{\Omega }}_1^{\mathrm{HJ}}$ in the bind join phase. This will be illustrated in the following example.

Example 5.2.

We consider the query plan from Fig. 1(a) with PBJ operators and focus on the second join operator $\mathit{T}=\mathrm{(}{\mathit{tp}}_1\bowtie {\mathit{tp}}_2\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}{\mathit{tp}}_3$ with ${\mathrm{\Omega }}_1=eval\mathrm{(}\mathrm{(}{\mathit{tp}}_1\bowtie {\mathit{tp}}_2\mathrm{)}\mathrm{)}$ . Assume that probing each tuple $\mathit{\mu }\in {\mathrm{\Omega }}_1$ requires a single request, and assume that the operator will switch its strategy at $\mathit{cnt}=13$ (i.e., $\mathit{\lambda }=1$ ). This leads to the following outcomes, depending on the actual cardinality of ${\mathrm{\Omega }}_1$ :

If $|{\mathrm{\Omega }}_1|\mathrm{<}13$ : The operator adapts correctly by not switching the join strategy; switching to a hash join would require at least the same number of requests.

If $|{\mathrm{\Omega }}_1|\in [13\mathrm{,}24]$ : The operator adapts incorrectly by switching to a hash join. With $\mathit{cnt}=13$ , the operator switches to the hash join which requires an additional 12 requests, which is more expensive than probing the at most 24 tuples.

If $|{\mathrm{\Omega }}_1|\mathrm{>}25$ : The operator adapts correctly by switching the join strategy. Switching at $\mathit{cnt}=13$ requires additional 12 requests in the hash join phase. The total number of requests $13+12$ is lower than probing all tuple from ${\mathrm{\Omega }}_1$ in the bind join phase.

In the motivating example $|{\mathrm{\Omega }}_1|=756$ and, therefore, the PBJ would make the right decision.

Correctness of the PBJ We show that the Polymorphic Bind Join operator produces correct solution mappings according to the SPARQL set semantics [26].

Theorem 5.1.

Given an RDF graph G, an LDF interface c with $ep\mathrm{(}\mathit{c}\mathrm{)}=\mathit{G}$ , a conjunctive SPARQL expression $\mathit{P}={\mathit{P}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{P}}_2$ . The Polymorphic Bind Join operators yields the correct set of solution mappings for a query plan $\mathit{T}=\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}$ , that is $$\begin{array}{c}{⟦\mathit{P}⟧}_{\mathit{G}}=eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\end{array}$$

The intuition of the operator’s correctness is as follows. If the operator does not switch its join strategy, it operates as a regular bind join operator producing correct results. In the case that it switches from the bind join strategy to the hash join strategy, there are still tuples from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ that have not been considered in the join. These remaining tuples will be processed in the hash join phase (Line 19) and inserted into the hash table ${\mathit{H}}_1$ . The remaining results of the join are produced in the hash join phase: (i) either when the tuples are probed in the hash table ${\mathit{H}}_2$ of $eval\mathrm{(}{\mathit{T}}_2\mathrm{)}$ (Line 22), or (ii) when the tuples from $eval\mathrm{(}{\mathit{T}}_2\mathrm{)}$ are probed against the tuples in ${\mathit{H}}_1$ (Line 26). In order to avoid spurious duplicates, the tuples of $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ that are probed during the bind join phase are not considered again in the hash join phase. The formal proof of Theorem 5.1 is presented in the following.

Proof.

We demonstrate the correctness of the operator ${\bowtie }_{\mathsf{\text{PBJ}}}$ by proving completeness and correctness. We prove these by contradiction in the following.

Completeness: We assume that the ${\bowtie }_{\mathsf{\text{PBJ}}}$ produces incomplete result sets: $$\begin{array}{c}eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}{\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\subset ⟦\mathit{P}⟧}_{\mathit{G}}\end{array}$$

Let us consider a solution mapping μ, such that ${\mathit{\mu }\in ⟦\mathit{P}⟧}_{\mathit{G}}$ and $\mathit{\mu }\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ . Without loss of generality, assume that $\mathit{\mu }={\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ , with ${\mathit{\mu }}_{\mathit{i}}^1\sim {\mathit{\mu }}_{\mathit{j}}^2$ , ${\mathit{\mu }}_{\mathit{i}}^1\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ and ${{\mathit{\mu }}_{\mathit{j}}^2\in ⟦{\mathit{P}}_2⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ . Assuming the evaluation of $\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}$ is correct by Proposition 4.1, we distinguish two sub-cases:

${\mathit{\mu }}_{\mathit{i}}^1$ is processed by the PBJ during the bind join phase (Line 5 to 12). The operator computes ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{x}}^2$ , $\forall {\mathit{\mu }}_{\mathit{x}}^2\in eval\mathrm{(}\mathrm{(}{\mathit{\mu }}_{\mathit{i}}^1\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{,}\mathit{c}\mathrm{)}\mathrm{)}$ (Line 7). By Definition 4.4, we have that ${\mathit{\mu }}_{\mathit{x}}^2\in ⟦{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ . Since the solution mappings in $⟦{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ correspond to the subset of solution mappings in ${⟦{\mathit{P}}_2⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ which are compatible with ${\mathit{\mu }}_{\mathit{i}}^1$ , μ must be produced by the PBJ.

${\mathit{\mu }}_{\mathit{i}}^1$ is processed by the PBJ during the hash join phase (Line 18 to 26). In this case, ${\mathit{\mu }}_{\mathit{i}}^1$ is inserted into the hash table ${\mathit{H}}_1$ and probed with all solution mappings in ${\mathit{H}}_2$ . If ${\mathit{\mu }}_{\mathit{j}}^2$ is in ${\mathit{H}}_2$ , then μ will be produced by the operator (Line 22). If ${\mathit{\mu }}_{\mathit{j}}^2$ is not yet in ${\mathit{H}}_2$ , it will be processed by the operator (Line 23) as part of $eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ and probed in ${\mathit{H}}_1$ (where ${\mathit{\mu }}_{\mathit{i}}^1$ has been inserted) and the solution mapping μ is produced.

In both cases, the solution mapping μ is produced by the PBJ. This contradicts the assumption that $\mathit{\mu }\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ .

Soundness: We assume that the ${\bowtie }_{\mathsf{\text{PBJ}}}$ produces unsound results: $$\begin{array}{c}eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}{\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\supset ⟦\mathit{P}⟧}_{\mathit{G}}\end{array}$$

To this end, we consider a solution mapping μ, such that $\mathit{\mu }\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PBJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ and ${\mathit{\mu }\notin ⟦\mathit{P}⟧}_{\mathit{G}}$ . Without loss of generality, assume that $\mathit{\mu }={\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ , with ${\mathit{\mu }}_{\mathit{i}}^1\sim {\mathit{\mu }}_{\mathit{j}}^2$ , ${\mathit{\mu }}_{\mathit{i}}^1\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ and ${\mathit{\mu }}_{\mathit{j}}^2\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ . Assuming the evaluation of $\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}$ is correct by Proposition 4.1, we have that ${{\mathit{\mu }}_{\mathit{i}}^1\in ⟦{\mathit{P}}_1⟧}_{\mathit{G}}$ . As a result, ${\mathit{\mu }}_{\mathit{j}}^2$ is the cause of the unsoundness of μ. Note that ${\mathit{\mu }}_{\mathit{j}}^2$ must be produced by an access operator for $\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}$ in either the bind join or the hash join phase. If ${\mathit{\mu }}_{\mathit{j}}^2$ is produced by the access operator during the bind join phase, we have by Definition 4.4 that ${\mathit{\mu }}_{\mathit{j}}^2\in ⟦{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{\mathit{G}}$ (Line 6). Which implies that ${{\mathit{\mu }}_{\mathit{j}}^2\in ⟦{\mathit{P}}_2⟧}_{\mathit{G}}$ , as $⟦{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{\mathit{G}}$ is the subset of solution mappings from ${⟦{\mathit{P}}_2⟧}_{\mathit{G}}$ that are compatible with ${\mathit{\mu }}_{\mathit{i}}^1$ . Then μ must belong to ${⟦\mathit{P}⟧}_{\mathit{G}}$ which contradicts the assumption. Otherwise, ${\mathit{\mu }}_{\mathit{j}}^2$ is produced during the hash join phase by $eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ (Line 16). By Definition 4.4 this means that ${{\mathit{\mu }}_{\mathit{j}}^2\in ⟦{\mathit{P}}_2⟧}_{\mathit{G}}$ . Then μ must belong to ${⟦\mathit{P}⟧}_{\mathit{G}}$ which contradicts the assumption.  □

5.2. Polymorphic hash join

We now introduce the Polymorphic Hash Join (PHJ), which is the complement of the PBJ. The PHJ enables adaptivity by switching its join strategy from a hash join to a bind join during query execution. We denote the PHJ by ${\bowtie }_{\mathsf{\text{PHJ}}}$ and it can be placed in a query plan $\mathit{T}={\mathit{T}}_1{\bowtie }_{\mathsf{\text{PHJ}}}{\mathit{T}}_2$ when ${\mathit{T}}_2$ is an access operator in the plan. The core idea of the operator is that it decides to switch the join strategy after receiving the last tuple from the sub-plan ${\mathit{T}}_1$ . At this point, the operator estimates whether probing all tuples received from ${\mathit{T}}_1$ would require fewer requests than continuing with the hash join by obtaining the remaining tuples from ${\mathit{T}}_2$ .

Algorithm 3:

Polymorphic hash join

The PHJ operator is outlined in Algorithm 3. In the first phase, the operator follows a non-blocking, symmetric hash join strategy as long as the operator receives tuples from ${\mathit{T}}_1$ (Line 9 to 23). During the hash join phase, the operator builds two hash tables ${\mathit{H}}_1$ and ${\mathit{H}}_2$ by inserting the tuples obtained from ${\mathit{T}}_1$ and ${\mathit{T}}_2$ . Tuples obtained from ${\mathit{T}}_1$ are then probed in ${\mathit{H}}_2$ and vice versa. Moreover, the operator keeps track of the set of solution mapping O that it produces (Line 14 and 22). As soon as the operator receives the EOF tuple from ${\mathit{T}}_1$ which indicates that all tuples from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ have been received and processed, the operator determines whether it is convenient to switch the join strategy. The decision to switch is determined by the switch function. The function determines the number of remaining requests with the hash join strategy and compares it to an estimation of the requests for probing all tuples received from ${\mathit{T}}_1$ using a bind join. The number of remaining hash join requests ${acc}_{\mathrm{\Delta }}$ is determined by the total number of requests for obtaining the tuples from ${\mathit{T}}_2$ and subtracting the number of requests which have already been performed. The operator then estimates whether instantiating all tuples received from ${\mathit{T}}_1$ and requesting the resulting expressions would require fewer requests than to continue with the hash join: $$\begin{array}{c}{\mathtt{\text{switch}}}_{\mathsf{\text{PHJ}}}\mathrm{(}{\mathit{cnt}}_1\mathrm{,}{\mathit{cnt}}_2\mathrm{,}\mathit{T}\mathrm{)}=\left\{\begin{array}{cc}\mathtt{\text{True}}\hfill & \mathit{\epsilon }·{\mathit{cnt}}_1\mathrm{<}{acc}_{\mathrm{\Delta }}\mathrm{(}{\mathit{cnt}}_2\mathrm{,}{\mathit{T}}_2\mathrm{)}\mathrm{,}\hfill \\ \mathtt{\text{False}}\hfill & \text{otherwise.}\hfill \end{array}\right.\end{array}$$

The parameter $\mathit{\epsilon }\in \mathrm{(}0\mathrm{,}\infty \mathrm{)}$ allows for weighting the bind join requests and we will show that we can guarantee that the PBJ minimizes the total number of requests during its execution if the parameter ε is set correctly. For a TPF server c with page size ${\mathit{p}}_{\mathit{c}}$ , the remaining number of hash join requests is determined as $$\begin{array}{c}{acc}_{\mathrm{\Delta }}\mathrm{(}{\mathit{cnt}}_2\mathrm{,}{\mathit{T}}_2\mathrm{)}=\underset{\text{Total requests for }{\mathit{T}}_2}{\underbrace{\phantom{{\displaystyle \frac{\mathit{c}\mathit{n}{\mathit{t}}_2}{{\mathit{p}}_{\mathit{c}}}}}acc\mathrm{(}{\mathit{T}}_2\mathrm{)}}}-\underset{\text{Performed requests}}{\underbrace{\lceil {\displaystyle \frac{{\mathit{cnt}}_2}{{\mathit{p}}_{\mathit{c}}}}\rceil }}.\end{array}$$

In the case that the PHJ decides to switch to the bind join, it terminates the hash join phase (Line 16). Thereafter, in the bind join phase, the operator probes all tuples from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ as they have been inserted in the hash table ${\mathit{H}}_1$ (Line 25 to 28). The operator does not know whether there are remaining tuples from $eval\mathrm{(}{\mathit{T}}_2\mathrm{)}$ that are compatible with a solution mapping from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ , which has not been inserted into ${\mathit{H}}_2$ during the hash join phase. Therefore, it probes all tuples obtained from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ in the inner plan ${\mathit{T}}_2$ (Line 26) during the bind join phase. Following set semantics, the operator does not produce duplicate tuples as it determines whether a tuple has been produced already (Line 27) before producing it.

Optimality condition for the PHJ For the PHJ there is an optimal parameter ${\mathit{\epsilon }}^{\ast }$ , for which the operator minimizes the total number of requests during its execution.

Proposition 5.1.

For a query plan $\mathit{T}={\mathit{T}}_1{\bowtie }_{\mathsf{\text{PHJ}}}{\mathit{T}}_2$ with ${\mathit{T}}_2={\mathit{A}}_2=\mathrm{(}{\mathit{SE}}_2\mathrm{,}\mathit{c}\mathrm{)}$ , the Polymorphic Hash Join operator minimizes the total number of request if the parameter ε is set to ${\mathit{\epsilon }}^{\ast }$ with $$\begin{array}{c}{\mathit{\epsilon }}^{\ast }={\displaystyle \frac{1}{|eval\mathrm{(}{\mathit{T}}_1\mathrm{)}|}}{\displaystyle \sum }_{\mathit{\mu }\in eval\mathrm{(}{\mathit{T}}_1\mathrm{)}}acc\mathrm{\left(}\mathrm{\right(}\mathit{\mu }\mathrm{(}{\mathit{SE}}_2\mathrm{)}\mathrm{,}\mathit{c}\mathrm{\left)}\mathrm{\right)}.\end{array}$$

In other words, if ${\mathit{\epsilon }}^{\ast }$ is equal to the average number of requests to be performed for probing a tuple from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ in ${\mathit{T}}_2$ , the switch function in the operator will evaluate to True only if switching requires fewer requests. The proposition follows from the following observations. First, we decide whether to change the strategy once we have received all tuples from the sub-plan ${\mathit{P}}_1$ and therefore, we have that ${\mathit{cnt}}_1=|eval\mathrm{(}{\mathit{T}}_1\mathrm{)}|$ and consequently, the left side in the decision rule of the switch function is $\mathit{\epsilon }·|eval\mathrm{(}{\mathit{T}}_1\mathrm{)}|$ . Therefore, the switch function evaluates to True with ${\mathit{\epsilon }}^{\ast }$ , if we have $$\begin{array}{c}\underset{\text{Bind join requests}}{\underbrace{{\displaystyle \sum }_{\mathit{\mu }\in eval\mathrm{(}{\mathit{T}}_1\mathrm{)}}acc\mathrm{(}\mathrm{(}\mathit{\mu }\mathrm{(}{\mathit{SE}}_2\mathrm{,}{\mathit{c}}_2\mathrm{)}\mathrm{)}}}\mathrm{<}\underset{\text{Remaining hash join requests}}{\underbrace{\phantom{{\displaystyle \sum }_{\mathit{\mu }\in \mathit{e}\mathit{v}\mathit{a}\mathit{l}\mathrm{(}{\mathit{T}}_1\mathrm{)}}\mathrm{)}}{acc}_{\mathrm{\Delta }}\mathrm{(}{\mathit{cnt}}_2\mathrm{,}{\mathit{T}}_2\mathrm{)}}}.\end{array}$$ The left expression is the sum of requests necessary when probing each individual solution mapping form $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ in the inner-plan ${\mathit{T}}_2$ . For each solution mapping μ, the number of requests is given according to the access request cost acc as defined in Equation (1). The right side of the expression, ${acc}_{\mathrm{\Delta }}\mathrm{(}{\mathit{cnt}}_2\mathrm{,}{\mathit{T}}_2\mathrm{)}$ , is the number of remaining requests to obtain all solution mappings ${\mathit{T}}_2$ according to the current hash join strategy. Consequently, if ε is set accurately to the average number of requests for probing a tuple in the bind join, the operator always chooses the request-minimizing strategy. In the case that $\mathit{\epsilon }\ne {\mathit{\epsilon }}^{\ast }$ , we cannot guarantee the minimum number of requests:

• The number of requests for probing all solution mappings is overestimated and the operator performs more requests by not switching to the bind join strategy.

• The number of requests for probing all solution mappings is underestimated and the operator switches to the bind join strategy, which ends up requiring more requests.

If we assume that all requests are equal in terms of response time, we have that $\mathit{\epsilon }⩾1$ because probing a solution mapping requires at least one request. However, different types of requests may yield different response times [18] and, therefore, values for ε below 1 may also be feasible. Determining ${\mathit{\epsilon }}^{\ast }$ requires knowing the number of requests for probing each solution mapping from ${\mathit{T}}_1$ which is unlikely to be known in practice. Nonetheless, when setting the parameter ε it should be still considered that (i) depending on the expression ${\mathit{SE}}_2$ , probing an instantiation of ${\mathit{SE}}_2$ may require several requests and (ii) a request for probing may require less time than a request of the hash join due to fewer intermediate results to be transferred.

Correctness of the PHJ We now show that the Polymorphic Hind Join operator produces correct solution mappings according to the SPARQL set semantics [26].

Theorem 5.2.

Given an RDF graph G, an LDF interface c with $ep\mathrm{(}\mathit{c}\mathrm{)}=\mathit{G}$ , a conjunctive SPARQL expression $\mathit{P}={\mathit{P}}_1\mathrm{\text{A}}\mathrm{\text{ND}}{\mathit{P}}_2$ . The Polymorphic Bind Join Operators yields the correct set of solution mappings for a query plan $\mathit{T}=\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}$ , that is $$\begin{array}{c}{⟦\mathit{P}⟧}_{\mathit{G}}=eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\end{array}$$

The intuition of the operator’s correctness is as follows. If the operator does not switch its join strategy, it operates as a regular hash join operator producing a correct result set. The operator considers switching from the hash join strategy to the bind join strategy when all tuples from $eval\mathrm{(}{\mathit{T}}_1\mathrm{)}$ have been received and inserted into ${\mathit{H}}_1$ (Line 16). The hash join strategy is executed only when there are tuples from $eval\mathrm{(}{\mathit{T}}_2\mathrm{)}$ that have not been received yet (Line 24). In this case, all tuples in ${\mathit{H}}_1$ are probed in ${\mathit{T}}_2$ in the bind join phase to produce all results of the join. To avoid spurious duplicates, the operator checks in the bind join phase if a result has been produced during the hash join phase (Line 27). The proof of Theorem 5.2 is as follows.

Proof.

We prove the correctness of the operator ${\bowtie }_{\mathsf{\text{PHJ}}}$ by showing completeness and soundness. We prove these by contradiction in the following.

Completeness: The first case is that the ${\bowtie }_{\mathsf{\text{PHJ}}}$ produces incomplete result sets. We assume that $$\begin{array}{c}eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}{\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\subset ⟦\mathit{P}⟧}_{\mathit{G}}\end{array}$$

Let us consider a solution mapping μ, such that ${\mathit{\mu }\in ⟦\mathit{P}⟧}_{\mathit{G}}$ and $\mathit{\mu }\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ . Without loss of generality, assume that $\mathit{\mu }={\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ , with ${\mathit{\mu }}_{\mathit{i}}^1\sim {\mathit{\mu }}_{\mathit{j}}^2$ , ${\mathit{\mu }}_{\mathit{i}}^1\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ and ${{\mathit{\mu }}_{\mathit{j}}^2\in ⟦{\mathit{P}}_2⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ . Assuming the evaluation of $\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}$ is correct by Proposition 4.1, we distinguish two sub-cases:

The operator does not switch the operation, i.e., $\mathtt{\text{switch}}\mathrm{(}{\mathit{cnt}}_1\mathrm{,}{\mathit{cnt}}_2\mathrm{,}\mathit{T}\mathrm{)}$ never evaluates to True. As a result, all solution mappings from ${⟦{\mathit{P}}_1⟧}_{\mathit{G}}$ and ${⟦{\mathit{P}}_2⟧}_{\mathit{G}}$ (Definition 4.4) are processed in the hash join phase (Line 9 to 23) and the operator finalizes once both $\mathtt{\text{EOF}}$ tuples have been received. In this case, ${\mathit{\mu }}_{\mathit{i}}^1$ is processed from $eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ (Line 10), inserted into the hash table ${\mathit{H}}_1$ , and probed with all solution mappings in ${\mathit{H}}_2$ . If ${\mathit{\mu }}_{\mathit{j}}^2$ is in ${\mathit{H}}_2$ , then μ will be produced by the operator (Line 15). If ${\mathit{\mu }}_{\mathit{j}}^2$ is not yet in ${\mathit{H}}_2$ , it will be processed by the operator as part of $eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ (Line 18) and probed in ${\mathit{H}}_1$ (where ${\mathit{\mu }}_{\mathit{i}}^1$ has already been inserted) and the solution mapping μ is produced.

The operator switches the operation to the bind join strategy. This can only be the case if all solution mappings from ${⟦{\mathit{P}}_1⟧}_{\mathit{G}}$ have been processed in the hash join phase (Line 16) and if not all tuples from $eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ have been processed yet: ${\mathit{\mu }}^{\prime }=\mathtt{\text{EOF}}$ and ${\mathit{\mu }}^{″}\ne \mathtt{\text{EOF}}$ . As a consequence, all solution mappings from ${⟦{\mathit{P}}_1⟧}_{\mathit{G}}$ have been inserted into ${\mathit{H}}_1$ and probed in ${\mathit{H}}_2$ . If ${\mathit{\mu }}_{\mathit{j}}^2$ was in ${\mathit{H}}_2$ when ${\mathit{\mu }}_{\mathit{i}}^1$ was probed in ${\mathit{H}}_2$ , then μ will be produced by the operator (Line 15). In addition, all solution mappings produced during the hash join phase are added to the set O (Line 14 and 22). In the bind join phase (Line 25 to Line 28), the operator processes all tuples in ${\mathit{H}}_1$ including ${\mathit{\mu }}_{\mathit{i}}^1$ and produces the solution mappings that it has not yet produced: ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{x}}^2$ , $\forall {\mathit{\mu }}_{\mathit{x}}^2\in eval\mathrm{(}\mathrm{(}{\mathit{\mu }}_{\mathit{i}}^1\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{,}\mathit{c}\mathrm{)}\mathrm{)}\wedge {\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{x}}^2\notin \mathit{O}$ . By Definition 4.4, we have that ${\mathit{\mu }}_{\mathit{x}}^2\in ⟦\mathrm{(}{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ and the solution mappings in $⟦{\mathit{\mu }}_{\mathit{i}}^1{\mathrm{(}{\mathit{P}}_2\mathrm{)}⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ correspond to the subset of solution mappings in ${⟦{\mathit{P}}_2⟧}_{ep\mathrm{(}\mathit{c}\mathrm{)}}$ which are compatible with ${\mathit{\mu }}_{\mathit{i}}^1$ . Since $\mathit{\mu }={\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ has not been produced yet, we have $\mathit{\mu }\notin \mathit{O}$ . As a result, μ must be produced by the PHJ.

In both cases, the solution mapping μ is produced by the PHJ. This contradicts the assumption that $\mathit{\mu }\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ .

Soundness: The second case is that the ${\bowtie }_{\mathsf{\text{PHJ}}}$ produces unsound results. We assume that $$\begin{array}{c}eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}{\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}\supset ⟦\mathit{P}⟧}_{\mathit{G}}\end{array}$$

This means there is a solution mapping μ, such that $\mathit{\mu }\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}{\bowtie }_{\mathsf{\text{PHJ}}}\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{)}$ and ${\mathit{\mu }\notin ⟦\mathit{P}⟧}_{\mathit{G}}$ . Without loss of generality, assume that $\mathit{\mu }={\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ , with ${\mathit{\mu }}_{\mathit{i}}^1\sim {\mathit{\mu }}_{\mathit{j}}^2$ , ${\mathit{\mu }}_{\mathit{i}}^1\in eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ and ${\mathit{\mu }}_{\mathit{j}}^2\notin eval\mathrm{(}\mathit{T}\mathrm{(}{\mathit{P}}_1\mathrm{)}\mathrm{)}$ . Since the operator processes the solution mappings in ${⟦{\mathit{P}}_1⟧}_{\mathit{G}}$ twice in the case that it switches its operation, there are two cases in which the PHJ might produce unsound results: (1) ${\mathit{\mu }}_{\mathit{j}}^2$ is the cause of unsoundness; or (2) μ is a spurious duplicate produced by the PHJ.

The first case is that ${\mathit{\mu }}_{\mathit{j}}^2$ is the cause of the unsoundness of μ. Note that ${\mathit{\mu }}_{\mathit{j}}^2$ must be produced by an access operator for $\mathit{T}\mathrm{(}{\mathit{P}}_2\mathrm{)}$ . The proof that ${\mathit{\mu }}_{\mathit{j}}^2$ is not produced by an access operator during both the hash and the bind join phase is analogous to the soundness proof of the PBJ for Theorem 5.1.

The second case is that μ is produced twice (i.e., a spurious duplicate) when the operator processes ${\mathit{\mu }}_{\mathit{i}}^1$ from ${\mathit{H}}_1$ a second time in the bind join phase. Furthermore, we assume that μ is produced during the hash join phase and a second time by the output of the operator in Line 28. In this case, we have that ${\mathit{\mu }}_{\mathit{i}}^1$ in ${\mathit{H}}_1$ and the operator obtains the solution mappings ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{x}}^2$ , $\forall {\mathit{\mu }}_{\mathit{x}}^2\in eval\mathrm{(}\mathrm{(}{\mathit{\mu }}_{\mathit{i}}^1\mathrm{(}{\mathit{P}}_2\mathrm{)}\mathrm{,}\mathit{c}\mathrm{)}\mathrm{)}$ (Line 26). We assume that ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ is in this set of solution mappings. If ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ has already been produced during the hash join phase, we have that ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2\in \mathit{O}$ (Line 14 and 22). As the operator does not produce solution mappings which are in O (Line 27), we have that ${\mathit{\mu }}_{\mathit{i}}^1\cup {\mathit{\mu }}_{\mathit{j}}^2$ is not produced a second time. As a result, μ is not produced twice, which contradicts the assumption.  □

5.3. Summary

We introduced a new class of adaptive join operators that are able to switch their join strategy during the execution of a query plan. In particular, we presented two instances from this class: the Polymorphic Bind Join (PBJ) and the Polymorphic Hash Join (PHJ). These operators allow for switching their join strategy from a bind join to a hash join and vice versa. While we presented PBJ and PHJ operators probe a single tuple in the bind join phase, both operators can easily be extended to handle several bindings per request (binding block size > 1). Moreover, the proposed operators can be further optimized by leveraging the query planner and the properties of the LDF interface. The query planner could determine the sensitivity of individual operators according to estimated cardinalities and probabilities of estimation errors. In addition, the operators could leverage the properties of the underlying LDF interface. For example, in the case that the solution mappings are sorted (e.g., for a TPF server with an HDT backend), the operators could use the order to reduce the number of requests after switching the join strategy. In addition, the PHJ could be extended in two ways. First, instead of keeping all produced tuples in the set O to avoid producing duplicate solution mappings, the operator could also check during the bind join phase, whether the tuples are in the hash table ${\mathit{H}}_2$ . If this is the case, they have been processed in the hash join phase already and the corresponding solution mapping has been produced.8

⁸

We choose to describe the operator with the set O to provide a more intuitive description and proof of correctness.

Second, the PHJ could track response times and estimate the number of requests for probing each tuple during its execution to properly set the ε parameter. In this work, we do not consider these optimizations in the implementation of the operators as we aim to evaluate the concept of switching the join strategy in a more general scenario and for a variety of query planning approaches.

6. Evaluation

In this experimental evaluation, we investigate the effectiveness of our two approaches for robust query processing over Linked Data Fragments. As previously mentioned, we evaluate the approaches using the example of Triple Pattern Fragment (TPF) servers. We investigate the effectiveness of the proposed query planning approach CROP and the impact of the adaptive join operators PBJ and PHJ on two different benchmarks with a fine-grained analysis of the results.

6.1. Experimental setup

Datasets and queries As the basis for our evaluation, we focus on two different datasets and corresponding benchmark queries that have also been used in previous evaluation for LDF clients [1,6,14,22,27,28]. First, we use a synthetic RDF graph and benchmark queries from the Waterloo SPARQL Diversity Test Suite (WatDiv) [4]. Specifically, we generated a dataset with scale factor = 100 and the corresponding default queries with query-count = 5 resulting in a total of 88 distinct queries from query categories, namely, 25 linear queries (L), 35 star queries (S), 25 snowflake-shaped queries (F) and 3 complex queries (C). The second benchmark is taken from the evaluation of nLDE9

⁹

https://people.aifb.kit.edu/mac/nlde/

and is based on the real-world RDF graph of DBpedia 2014 [1]. The benchmark consists of two subsets of queries. The first subset, Benchmark 1 (BM 1), consists of 20 non-selective queries composed of basic graph patterns with up to 14 triple patterns that produce a large number of intermediate results. The second subset, Benchmark 2 (BM 2), consists of 25 more selective queries from the domains Historical, Life Science, Movies, Music, and Sports. The number of queries per category as well as statistics on the number of answers and number of triple patterns for the queries of benchmarks is provided in Table 2. In addition, to showcase the benefits of combining the cost model with robustness in the query plan optimizer on different RDF graphs, we designed an additional test-set with 10 queries for 3 RDF graphs that include either a s-o and or an o-o join and 3-4 triple patterns. We used the RDF graphs DBpedia 2014, GeoNames 2012, and DBLP 2017 for which we obtained the HDT files from the RDF-HDT website.10

¹⁰

http://www.rdfhdt.org/datasets/

Table 2

Properties of the benchmark queries

		#	# Answers			# Triple Patterns
			min	max	median	min	max
WatDiv	C	3	2	417 029	20	6	10
	F	25	0	58	8	6	9
	L	25	0	239	47	2	3
	S	35	0	320	4	3	9
nLDE	BM 1	20	2	45 655 205	7131	4	14
	BM 2	25	2	1768	19	3	5

Implementation We implemented CROP11

¹¹

https://github.com/Lars-H/crop

on top of the nLDE client ⁴ , which is implemented in Python 2.7.13. We implemented our cost model, robustness measure, and query plan optimizer, such that the resulting physical query plans can be executed using nLDE. We used the default of 2 eddy operators and do not consider the routing adaptivity features of nLDE, that is, we select no routing policy for the execution. We deployed the TPF server with an HDT backend [11] using the Server.js v2.2.312

¹²

https://github.com/LinkedDataFragments/Server.js

implementation. We set the number of workers for the TPF server to 5. All experiments were executed on a Debian Jessie 64 bit machine with CPU: 2× Intel(R) Xeon(R) CPU E5-2670 2.60 GHz (16 physical cores), and 256 GB RAM. The queries were executed three times in all experiments. The timeout was set to 900 seconds for the experiments to set the parameters for CROP (δ, k, γ, and ρ). For all the remaining experiments, we set a runtime timeout of 600 seconds.

Evaluation metrics We consider the following query execution metrics:

• Runtime: Elapsed time in seconds spent by a query engine to complete the evaluation of a query measured in seconds. In the implementation of CROP, we distinguish between the optimization time spent by the query planner to obtain a query plan and the execution time to execute the plan.

• Number of Requests: Total number of requests submitted to the server during the query execution including query planning.

• Number of Answers: Total number of answers produced during query execution.

• Diefficiency: Continuous efficiency as the answers are produced over time [3].

We provide all results of our experimental study in our supplemental material on Zenodo.13

¹³

https://doi.org/10.5281/zenodo.4639843

Table 3

Cost-model: impact of the δ-parameter of the height discount factor for the Bind Join (BJ) on the query plan efficiency (runtime and requests), percentage of BJs and bushy plans. Best efficiency values are indicate in bold

δ	WatDiv				nLDE BM
	Runtime (s)	Requests	BJs	Bushy Plans	Runtime (s)	Requests	BJs	Bushy Plans
0	255.0	24 039	50%	2%	1300.75	24 702	34%	10%
1	267.01	30 133	61%	2%	588.74	24 743	39%	10%
2	224.6	30 708	66%	0%	330.99	27 184	44%	10%
3	222.15	29 907	72%	0%	221.27	36 154	54%	10%
4	221.26	29 587	74%	0%	182.86	36 497	59%	10%
5	236.55	32 933	74%	2%	196.83	40 082	67%	5%
6	215.22	32 659	73%	5%	200.95	42 587	71%	5%
7	211.72	32 651	74%	5%	202.02	42 586	71%	5%

6.2. Robust query planning

We start by evaluating the proposed cost model, robustness measure, and corresponding query planner. First, we focus on the height discount factor for the cost model and the block size k for the IDP algorithm. Second, we focus on the cost and robustness threshold values of the query planner. Finally, we compare the resulting parameterization for CROP to the state-of-the-art clients for TPF servers. In order to determine how well the parameter settings generalize, we randomly selected a subset of the queries from the benchmarks to set the parameters but compare our approach to the state of the art for all benchmark queries. From the 88 WatDiv Benchmark queries, we randomly selected 2 queries per subgroup (L1-L5, F1-F5, S1-S7, C), resulting in 36 queries total. For the nLDE benchmark, we randomly chose 10 queries from BM 1 and 2 queries per domain from BM 2, resulting in 20 queries total.

Cost model and IDP parameters We start by investigating how the parameter settings of the cost model affect the efficiency and structure of the query plans obtained by the planner. We begin with the parameter δ which determines the impact of the height discount factor (Eq. (3)). We consider the following settings: $\mathit{\delta }\in \{0\mathrm{,}1\mathrm{,}2\mathrm{,}3\mathrm{,}4\mathrm{,}5\mathrm{,}6\mathrm{,}7\}$ . As we only focus on local deployment in our evaluation, we do not investigate different processing cost parameters and set $\mathit{\varphi }=0.001$ . Optimizing the value for ϕ should be considered when in different deployment scenarios, where network delays have a stronger impact on the query execution cost. We disable robust plan selection by setting $\mathit{\rho }=0.00$ , set the default block size to $\mathit{k}=3$ , and select the top $\mathit{t}=5$ plans. Table 3 provides an overview of the query execution performance regarding the mean runtime and the mean number of requests for both benchmarks per run. In addition, to determine the impact of the parameter on the structural properties of the query plans, we report the percentage of Bind Joins (BJ) in the query plans and the percentage of bushy query plans.

Regarding the efficiency of the query plans, we observe that an increase in the δ values yields a reduction of query runtimes. In particular, the lowest runtime for the WatDiv benchmark are observed for $\mathit{\delta }=7$ and for the nlDE benchmark with $\mathit{\delta }=4$ . For the nLDE benchmark, the runtimes slightly increase with $\mathit{\delta }\mathrm{>}4$ . In contrast to the runtimes, the lowest number of requests in both benchmarks are observed without the height discount factor (i.e., $\mathit{\delta }=0$ ). Combining this observation with the percentage of BJ operators, the results show that (i) an increasing δ leads the query planner to place more BJs, (ii) more BJs yield a higher number of requests for probing the tuples, and (iii) the discrepancy between runtime and number of requests arises from the fact the requests from the BJ operator typically yield lower response times in comparison to HJ requests, as more variables are instantiated in the triple pattern which leads to fewer intermediate results that need to be transferred. While the request costs of the cost model do not distinguish the type of requests, the height discount factor allows for balancing this effect.

Even though we can observe a similar impact of the δ value on the percentage of BJs in the query plans, the shape of the query plans differs in the two benchmarks. When considering the percentage of bushy plans, we find that in the WatDiv benchmark fewer bushy plans are obtained and the best results in the nLDE benchmark are observed with a higher bushy plan ratio. These results show that, on the one hand, the δ parameter not only affects the type of join operators placed in the plan but also their shape. Based on the previous observations, we set $\mathit{\delta }=4$ as it yields an appropriate trade-off between runtime efficiency and the number of requests for both benchmarks.

Next, we focus on the parameterization of the IDP algorithm. Specifically, investigate how the block size k impacts both times for the planner to devise these plans (optimization time) and the efficiency of their execution (execution time and the number of requests). We set the number of top plans kept by the IDP to $\mathit{t}=5$ and set the height discount parameter $\mathit{\delta }=4$ as suggested by the previous results. We study the block sizes $\mathit{k}\in \{2\mathrm{,}3\mathrm{,}4\mathrm{,}5\mathrm{,}6\}$ . Figure 3(a) shows the median runtimes $\tilde{\mathit{r}}$ for all queries per block size k with the proportion of the optimization time indicated in blue. The runtimes are separated for small queries ( $|\mathit{P}|\mathrm{<}6$ ) and larger queries ( $|\mathit{P}|⩾6$ ). Furthermore, note that $\mathit{k}=min\{\mathit{k}\mathrm{,}|\mathit{P}|\}$ .

Fig. 3.

IDP: impact of the different block sizes in the IDP algorithm on the execution time, optimization time, and number of requests.

The results show that for small queries ( $|\mathit{P}|\mathrm{<}6$ ) the overall runtimes as well as the optimization time proportion, is similar regardless of the block size k. For larger queries ( $|\mathit{P}|⩾6$ ), the runtimes increase with higher k. This increase for larger queries is due to a larger proportion of optimization time to obtaining ideally better plans. At the same time, the benefit of investing the additional time and exploring alternative query plans is disproportionately low as the execution times only marginally decrease. Considering just the execution times, we find that the mean lowest execution times are obtained for Watdiv with $\mathit{k}=2$ ( $5.41\text{ s}$ ) with very similar results for the second-lowest with $\mathit{k}=4$ ( $5.79\text{ s}$ ). For the nLDE Benchmark, the lowest mean execution times are observed for $\mathit{k}=3$ ( $8.98\text{ s}$ ).

The optimization times (log-scale) with respect to the query size are shown in Fig. 3(b), where the block size is indicated in color. The results show the impact of the number of triple patterns in the query on the optimization time. Especially, for large block sizes $\mathit{k}\mathrm{>}4$ and queries with many triple patterns this trend is more apparent. For example, for query Q07 with 14 triple pattern, the optimization time is on average more than 100 times higher with $\mathit{k}=6$ ( $31.85\text{ s}$ ) than with block size $\mathit{k}=2$ ( $0.30\text{ s}$ ). This is due to the fact that the number of plans that need to be considered grows exponentially with k. The observed impact of the block size on the query optimization time is in line with the results reported by Kossmann and Stocker [19].

Finally, we look at the distribution of the number of requests for the different benchmark and block sizes as shown in Fig. 3(c). We can observe that for the WatDiv benchmark, the number of outliers increases, especially with $\mathit{k}\mathrm{>}4$ . For the nLDE benchmark, the number of requests can be slightly reduced for some queries with $\mathit{k}\mathrm{>}4$ . Based on all previous observations, we set k in a dynamic fashion with: $\mathit{k}=4$ if $|\mathit{P}|\mathrm{<}6$ and $\mathit{k}=2$ otherwise. As a result, the planner avoids disproportionate optimization times, especially for large queries, while still exploring the space of possible plans sufficiently to find efficient alternative query plans.

CROP query optimizer parameters The previous experiments focused on determining appropriate parameters for the cost model. We now focus on the parameters for the proposed query optimizer (cf. Algorithm 1), namely the robustness threshold ρ and the cost threshold γ. The robustness threshold ρ defines whether an alternative plan should be considered. The cost threshold γ limits the alternative plans to those which are not considered too expensive with respect to the cheapest plan. We tested all 25 combinations of $\mathit{\rho }\in \{0.05\mathrm{,}0.10\mathrm{,}0.15\mathrm{,}0.20\mathrm{,}0.25\}$ and $\mathit{\gamma }\in \{0.1\mathrm{,}0.3\mathrm{,}0.5\mathrm{,}0.7\mathrm{,}0.9\}$ . We executed the subset of 56 queries (36 WatDiv and 20 nLDE BM) for each combination three times. Table 4 shows the mean results per benchmark for all runs. The results include the query plan efficiency in terms of runtime and number of requests, as well as the number of queries for which a robust query plan was selected over the cheapest plan as $|{\mathit{R}}^{\ast }|$ . The best results are indicated in bold.

Table 4

Mean runtime, mean number of requests, and the number of robust plans ( $|{\mathit{R}}^{\ast }|$ ) selected by the query plan optimizer for both benchmarks. Best overall runtime and minimum number of requests per configuration and benchmark are indicated in bold

γ	$\mathit{\rho }=0.05$			$\mathit{\rho }=0.10$			$\mathit{\rho }=0.15$			$\mathit{\rho }=0.20$			$\mathit{\rho }=0.25$
	Runtime	Requests	$|{\mathit{R}}^{\ast }|$	Runtime	Requests	$|{\mathit{R}}^{\ast }|$	Runtime	Requests	$|{\mathit{R}}^{\ast }|$	Runtime	Requests	$|{\mathit{R}}^{\ast }|$	Runtime	Requests	$|{\mathit{R}}^{\ast }|$
WatDiv Benchmark
0.1	87.88	20 796	6	89.04	20 796	6	96.47	21 504	6	97.31	21 643	6	338.30	26 395	8
0.3	87.79	20 796	6	89.68	20 796	6	194.62	30 078	2	196.18	30 217	2	196.45	30 217	2
0.5	195.14	30 078	2	195.15	30 078	2	196.77	30 078	2	197.63	30 217	2	197.45	30 217	2
0.7	194.41	30 078	2	193.61	30 078	2	196.47	30 078	2	194.97	30 085	0	195.29	30 085	0
0.9	195.19	30 078	2	192.97	30 078	2	194.84	30 078	2	195.77	30 085	0	194.49	30 085	0
nLDE Benchmark
0.1	291.45	31 465	1	303.14	49 925	2	303.95	49 925	2	304.31	49 925	2	384.13	58 092	3
0.3	293.19	31 465	1	303.29	49 925	2	301.46	49 925	2	299.85	49 925	2	302.20	49 925	2
0.5	290.03	31 465	1	196.19	35 783	1	196.01	35 783	1	196.82	35 783	1	195.37	35 783	1
0.7	290.84	31 465	1	196.67	35 783	1	196.28	35 783	1	198.50	35 783	1	196.26	35 783	1
0.9	289.72	31 465	1	195.78	35 783	1	197.67	35 783	1	196.06	35 783	1	197.13	35 783	1

Fig. 4.

Custom testset: runtime, number of requests, number of answers, and query plan robustness for the 10 queries of the custom benchmark. Results compare CROP without robustness ( $\mathit{\rho }=0.00$ ) and with robustness ( $\mathit{\rho }=0.05$ ).

For the WatDiv benchmark, the results show that the best performing query plans are obtained for parameter values $\mathit{\rho }\in \{0.05\mathrm{,}0.10\}$ and $\mathit{\gamma }\in \{0.1\mathrm{,}0.3\}$ . While the mean runtimes slightly differ, the number of requests indicates that the same query plans are chosen by the planner. Moreover, in 6 out of the 36 queries an alternative robust plan is chosen. In contrast, for the nLDE Benchmark, the results show the best runtimes with $\mathit{\rho }\in [0.10\mathrm{,}0.25]$ and $\mathit{\gamma }\in [0.5\mathrm{,}0.9]$ . The query plans that minimize the number of requests are obtained with $\mathit{\rho }=0.05$ regardless of the cost threshold. The difference can be explained by the single query for which the robust query plan is chosen. The best runtimes are obtained in the case that the robust plan is selected for Q02 (Movies) and the minimum number of requests if the robust plan is selected for Q05 (BM 1). These results are in line with the previous observation regarding the height discount factor, i.e. minimizing the number of requests not always yields the best execution times. The results also show that for the nLDE benchmark, robust plans are selected less frequently than for the WatDiv benchmark. In both benchmarks with $\mathit{\gamma }=0.1$ , we observe the impact of an increasing robustness threshold as more alternative robust plans are chosen ( $|{\mathit{R}}^{\ast }|$ ). Furthermore, the results indicate the effectiveness of the cost threshold in limiting the selection of alternative plans. Combining the results from both benchmarks, we choose a trade-off setting for the parameters and set the cost threshold to $\mathit{\gamma }=0.3$ and the robustness threshold to $\mathit{\rho }=0.05$ in the following experiments.

Next, we study the effectiveness of our query planning approach in identifying efficient alternative robust plans using the 10 queries from our custom test-set. We keep the parameters from the previous experimental evaluations and compare the configuration of our planner with $\mathit{\rho }=0.00$ (the cheapest plan is always chosen) to the configuration that selects robust plans with $\mathit{\rho }=0.05$ (as suggested by the previous experiments). The results are shown in Fig. 4. It can be observed that for 7 queries (DBLP1-3, DBP1-3, GN2) the query planner obtains more efficient query plans when enabling the selection of a robust plan. For these queries, the runtime and the total number of requests are lower and, at the same time, the selected robust query plans produce the same number of answers or even more before reaching the timeout. Regarding the remaining queries, we find that for the query DBP4 the planner chooses the same query plan in both configurations as the cheapest plan is also considered to be robust enough (Fig. 4(d)). For the queries GN1 and GN3, the timeout is reached in all cases. Nonetheless, we can observe that the robust query plans produce more answers with the same number or fewer requests during their execution. The results indicate that CROP allows for devising efficient query plans even for queries where the cost model produces high cardinality estimation errors in the presence of o-o and s-o joins. The robustness values of the cheapest plans, as shown in Fig. 4(d), lead the query optimizer to choose more robust plans, which reduces the query execution times as well as the number of requests.

Comparison to the state of the art After the intrinsic evaluation of our approach and determining appropriate parameters for the query optimizer, we now compare CROP to state-of-the-art TPF clients. Specifically, we compare CROP to nLDE [1] and Comunica [27].

Table 5

Comparison to the state of the art

		$\overline{\mathit{r}}$	$\tilde{\mathit{r}}$	$\overline{req.}$	$\sum \mathit{ans}$ .	Timeout [%]
WatDiv	CROP	2.12	0.68	375	419 448	0
	nLDE	9.01	0.84	862	419 448	0
	Comunica	6.98	2.76	1572	419 448	0
nLDE BM	CROP	58.14	0.89	4520	2 969 457	6
	nLDE	77.15	0.77	3897	6 616 570	9
	Comunica	84.28	4.67	9234	423 904	10

In contrast to the previous experiments, we evaluate the clients using all queries from both benchmarks and set the timeout to 600 seconds. Table 5 summarizes the results, where the mean ( $\overline{\mathit{r}}$ ), median ( $\tilde{\mathit{r}}$ ) runtimes, mean number of requests ( $\overline{req.}$ ), total number of answers ( $\sum \mathit{ans}$ .), and the percentage of query executions timing out are listed. Moreover, the runtimes of all queries14

¹⁴

Results are aggregated per query group in WatDiv.

are shown in more detail in Fig. 5. In the following, we analyze the results within each benchmark.

Fig. 5.

Comparison to the state of the art: mean query runtimes of Comunica, nLDE, and CROP for the different benchmarks and query categories.

Considering the individual runtimes per query group of the WatdDiv benchmark (Fig. 5(a)), we observe that CROP, in general, exhibits very good performance in terms of runtime in the majority of the cases. Overall, CROP yields the lowest runtimes with the lowest number of requests (Table 5). Combining these observations, the results suggest that the query plans obtained by CROP find a balance between the left-deep plans (i.e., Comunica) and the bushy plans (i.e., nLDE) for the WatDiv benchmark. Finally, none of the clients reach the timeout and consequently, all clients produce complete answers.

Next, we focus on the nLDE Benchmark, for which the runtimes are detailed in Fig. 5(b) and Fig. 5(c). The runtime results for the nLDE Benchmark 1 reveal a similar performance of CROP as in the WatDiv benchmark. While CROP performs best in $35\mathrm{\%}$ of the queries, it also performs well in the remaining queries and is only outperformed by nLDE and Comunica for a single query (Q02). Similar results can be observed for the more selective queries in Benchmark 2, where CROP performs as least as well as the best competitor (nLDE) in the majority of the queries. The previous observation is also reflected in the aggregated results in Table 5. CROP has the lowest mean runtimes. However, nLDE slightly outperforms CROP regarding the median runtimes and the mean number of requests. Moreover, nLDE yields the highest number of answers. Note that, the absolute difference in answers is very high (~3.7M) which is due to the better performance of nLDE in query $\mathsf{\text{Q18}}$ which has a total of 45M answers. When considering the number of queries for which all answers are obtained, we find that nLDE obtains complete answers for $90\mathrm{\%}$ and CROP $93\mathrm{\%}$ of all queries. This is also due to the fact that CROP only reaches the timeout in $6\mathrm{\%}$ and nLDE in $9\mathrm{\%}$ of query executions. In contrast to the WatDiv benchmark, Comunica is outperformed by nLDE with the highest runtimes and number of requests while obtaining the fewest answers. These results suggest that the bushy query plans of the nLDE query planner are more efficient for the non-selective queries in the nLDE benchmark and out-perform the left-deep plans. Similar to the WatDiv benchmark, the results show that CROP still finds an effective trade-off between these planning paradigms and obtains efficient query plans in both benchmarks.

Summarizing the experimental study on our cost- and robustness-based query plan optimizer CROP, we examined how the parameters of the cost model and the planner impact the query plans and compared our approach to state-of-the-art TPF clients. The results show that the height discount factor and the block size of the IDP allow the query planner for obtaining query plans that find a balance of runtime, the number of requests, and optimization time. The cost and robustness thresholds enable the query planner to determine when and which alternative robust plan should be selected, in the case that the cheapest plan is not considered to be robust enough. Finally, comparing CROP to state-of-the-art TPF clients, we found that CROP outperforms the existing approaches in the majority of cases by exploring and devising appropriate query plans without following a fixed heuristic that either builds left-deep plans (Comunica) or bushy plans (nLDE).

6.3. Polymorphic join operators

We now evaluate the proposed Polymorphic Join operators and investigate how this novel intra-operator adaptivity affects the query plan executions.

Planning approaches In order to understand the effectiveness of the adaptive PBJ and PHJ, we determine their impact on a variety of query planning approaches. As a result, we are able to examine how different planning methods can benefit from the adaptive operators during the query plan execution. Specifically, we focus on three query planning approaches: a left-deep planner, the nLDE planner, and CROP. Similar to Comunica’s sort heuristics, the left-deep planner (LDP) obtains query plans by sorting the triple patterns by increasing count values and builds left-linear plans according to this join order. We consider three different variants of the planning approach, which differ in the join strategies they implement. LDP (HJ) supports hash joins only, LDP (BJ) supports bind joins only, and LDP (BJ + HJ) supports both hash and bind joins. The LDP (BJ + HJ) uses an optimistic join cardinality estimation function (the minimum) and places either a hash join or a bind join based on the resulting estimated number of requests.15

¹⁵

Similar to Lines 10–15 in Algorithm 1 of [1].

Additionally, we also use the nLDE planning approach that builds bushy-plans around star-shaped subqueries, and the CROP query planner with the parameter configuration from the previous experiments ( $\mathit{\delta }=4$ , dynamic k, $\mathit{\rho }=0.05$ , and $\mathit{\gamma }=0.3$ ). In accordance with the previous experiments, we executed all queries from both the WatDiv and nLDE benchmarks three times and set a timeout of 600 seconds. As the baseline, we executed each planning approach without the polymorphic join operators. In addition, (if applicable) we executed the planning approach with either the PBJ or the PHJ enabled as well as with both PBJ + PHJ enabled, resulting in a total of 16 configurations. For the PBJ, we set the λ parameter to $\mathit{\lambda }=1\mathrm{/}\sqrt{height\mathrm{(}{\mathit{T}}_1\mathrm{)}}$ . Furthermore, we set the parameter to $\mathit{\epsilon }=1$ in the PHJ.

Table 6

Overview of the polymorphic join operators for the different benchmarks and planning approaches. Listed are the mean ( $\overline{\mathit{r}}$ ) and median ( $\tilde{\mathit{r}}$ ) runtimes [s], the mean number of requests ( $\overline{\mathit{req}.}$ ) and the sum of answers ( $\sum \mathit{ans}$ .). Moreover, we indicate the percentage of PBJ and PHJ that switched their strategy during execution by ${\mathit{PBJ}}^{+}$ and ${\mathit{PHJ}}^{+}$ , respectively. Best performance values per planner are indicated in bold

		WatDiv						nLDE BM
		$\overline{\mathit{r}}$	$\tilde{\mathit{r}}$	$\overline{req.}$	$\sum \mathit{ans}$ .	${\mathit{PBJ}}^{+}$	${\mathit{PHJ}}^{+}$	$\overline{\mathit{r}}$	$\tilde{\mathit{r}}$	$\overline{req.}$	$\sum \mathit{ans}$ .	${\mathit{PBJ}}^{+}$	${\mathit{PHJ}}^{+}$
LDP (HJ)	Baseline	37.29	15.81	1961	375 163	0%	0%	176.46	22.77	2899	2 378 020	0%	0%
	PHJ	10.86	1.84	651	16 202	0%	41%	112.92	1.6	2615	2 291 301	0%	22%
LDP (BJ)	Baseline	12.91	2.95	1859	419 448	0%	0%	80.0	7.91	9561	1 389 673	0%	0%
	PBJ	2.19	0.78	298	419 448	33%	0%	87.75	1.56	2683	2 184 025	66%	0%
LDP (BJ + HJ)	Baseline	6.48	1.18	611	419 448	0%	0%	62.77	0.87	1478	2 369 838	0%	0%
	PBJ	3.95	1.07	395	419 448	6%	0%	85.1	0.88	1676	1 785 498	7%	0%
	PHJ	4.69	0.71	499	419 448	0%	16%	62.71	0.86	1477	2 404 440	0%	0%
	PBJ + PHJ	2.11	0.7	283	419 448	6%	16%	85.26	0.93	1675	2 421 653	7%	0%
nLDE	Baseline	9.01	0.84	862	419 448	0%	0%	77.15	0.77	3897	6 616 570	0%	0%
	PBJ	6.13	0.85	531	419 448	8%	0%	104.82	0.91	3521	6 272 811	31%	0%
	PHJ	8.47	0.86	828	419 448	0%	6%	76.91	0.74	3899	6 574 086	0%	0%
	PBJ + PHJ	5.61	0.85	497	419 448	8%	6%	104.81	0.84	3523	6 346 455	31%	0%
CROP	Baseline	2.12	0.68	375	419 448	0%	0%	58.14	0.89	4520	2 969 457	0%	0%
	PBJ	1.99	0.68	272	419 448	5%	0%	86.6	1.07	2381	1 985 203	45%	0%
	PHJ	2.09	0.64	373	419 448	0%	3%	58.09	0.87	4515	2 180 385	0%	0%
	PBJ + PHJ	1.97	0.65	270	419 448	5%	3%	86.54	1.09	2381	2 954 945	45%	0%

Experimental results An overview of the results for all planning approaches per benchmark is provided in Table 6. The table shows the query execution performance according to the mean runtimes, median runtimes, the mean number of requests, and the total answers produced by each approach. Additionally, the percentage of PBJ and PHJ operators that adapted their join strategy during query execution are shown as ${\mathit{PBJ}}^{+}$ and ${\mathit{PHJ}}^{+}$ , respectively. Regarding the WatDiv benchmark, the lowest mean runtimes and number of requests are observed when enabling both adaptive join operators (PBJ + PHJ) for all query planning approaches. Only for CROP, the median runtime is slightly lower with just the PHJ enabled. All query planning approaches, except for LDP (HJ), obtain all answers ( $\sum \mathit{ans}$ .). Intriguingly, LDP (HJ) obtains even fewer results with PHJ enabled. Taking a closer look at the results, we find that these differences are due to the complex query (C3) for which LDP (HJ) reaches the timeout in both configurations. For all other queries, LDP (HJ) obtains all answers without and with the PHJ enabled.

The percentage of operators that adapt their join strategy during query execution ( ${\mathit{PBJ}}^{+}$ and ${\mathit{PHJ}}^{+}$ ) differs for the different planning approaches. It can be observed that the less sophisticated planning approaches, such as the left-deep planner, benefit more from the adaptive join operators than nLDE and CROP. For example, in the query plans of the LDP (BJ + HJ), 6% of the PBJ and 16% of the PHJ operators switch their strategy during the execution, while for CROP only $5\mathrm{\%}$ of the PBJ and just $3\mathrm{\%}$ of the PHJ switch their strategy. Interestingly, for none of the cases where CROP selects a robust alternative query plan (i.e., ${\mathit{R}}^{\ast }$ ), the adaptive join operators adapt their strategy. This indicates that potential cardinality estimation errors that would impact the ideal join strategy were already mitigated by the robust query planner. Overall, the polymorphic join operators improve the runtime efficiency of the query plans for the WatDiv benchmark.

However, considering the results for the nLDE benchmark, the impact of the polymorphic join operators on the query execution differs. For all planning approaches, the results show that enabling the PBJ results in higher mean runtimes. At the same time, fewer answers are produced when enabling the PBJ and PHJ. The only exception is the LDP (BJ) query planner, where enabling the PBJ increases the mean runtime by ~8%, but reduces the median runtime by ~80% and the number of answers produced almost doubles. Comparing the behavior of the PHJ and PBJ for the planning approaches, we find that none of the PHJ operators switch their join strategy, except for the LDP (HJ) planner. As a consequence, the query plans and their execution of the baseline and PHJ configuration are the same and the slight differences in performance are due to runtime conditions (e.g., the exact timing in the execution when the timeout is reached). In summary, only the left-deep query planning approach with just PHJ and just the PBJ operators can benefit from the polymorphic join operators in the nLDE benchmark. For the other query planning approaches, the PBJ switches its strategy inappropriately increasing the query execution performance while the PHJ does not adapt its strategy at all. These results highlight the importance of investigating different benchmarks as the properties of the RDF graphs as well as the queries affect the effectiveness of the proposed operators. Understanding these differences allows to appropriately choose the operators according to the use case and to further improve their effectiveness in future work.

Fig. 6.

Example diefficiency plots with the polymorphic join operators (PBJ / PHJ) and the baseline without polymorphic operators in gray for different planning approaches. Indicated by the blue arrows are the points in the answer traces where the adaptivity impacts the diefficiency.

Next, we investigate the impact of the polymorphic join operators on the continuous production of answers by means of the diefficiency. To this end, we visualize the cumulative number of answers produced with respect to the query runtime for four example queries in Fig. 6. The first two queries (Fig. 6(a) and Fig. 6(b)) compare the baseline to the configuration with the PBJ enabled. For query C3 from the WatDiv benchmark and the LDP (BJ) planner, we can observe that after obtaining a few hundred tuples from the initial access operator of the query, the PBJ operators switch to the hash join strategy. Only the last PBJ in the query plan does not switch its strategy due to the large number of matching triples for the last triple pattern in the join order: $count\mathrm{(}\mathtt{\text{?v0 :friendOf ?v2}}\mathrm{)}=4479991$ . As a result, the adaptivity of the PBJ in the initial query execution phase allows for producing the answers continuously faster. However, as previously mentioned, the PBJ may also impede the query execution efficiency as shown for the CROP query plan for Q16 in Fig. 6(b). In this case, the PBJ operators also switch their join strategy improving the diefficiency at the beginning of the execution. Since the PBJ considers its height in the query, the PBJs located higher in the query plan tend to switch after already probing a larger number of tuples. In the query plan for Q16, the last join operator is more likely to switch its strategy even though it is producing answers efficiently in the bind join phase. In this case, switching is not the appropriate strategy as the diefficiency plot shows and the query plan ends up producing fewer answers following the hash join strategy. This is due to the fact that the query execution reaches the timeout. This example illustrates the challenge of determining a feasible approach for switching the join strategy in the PBJ operator.

The second two plots (Fig. 6(c) and Fig. 6(d)) compare the baseline to the configuration with the PHJ enabled. While we can observe the potentially detrimental effect of the PBJ in the case that it switches its join strategy too early, the PHJ yields consistent improvements in diefficiency. As shown for example for query S33 in Fig. 6(c) and query Q05 in Fig. 6(d), the PHJ adapts its join strategy appropriately in both cases. The adaptivity substantially improves the diefficiency and reduces the total number of requests of the query plan execution. Due to the higher selectivity of the first join operator in the query plan for S33, the PHJ switches its join strategy rather quickly, while in Q05 the operator switches later during the execution as more tuples are produced by the preceding joins.

Fig. 7.

Scatter plots of the runtimes (log-log scale) for all planners with and without adaptive join operators. Value above the diagonal indicate performance degradation with adaptivity and values below performance improvement.

As a summary, we compare the runtimes of all planners for each query with and without adaptivity in Fig. 7. Each dot represents the runtimes of a query with and without adaptivity for a specific planner. Dots below the diagonal line represent an improvement in the execution performance (lower runtime is better). Overall, for the combination of PBJ and PHJ (Fig. 7(a)), we observe that, for the majority of queries, the polymorphic join operators allow for improving the robustness of query plan execution by adapting their join strategy. For just the PBJ (Fig. 7(b)), we observe a few queries where the performance substantially degrades while the majority yield a performance improvement. As expected, for the PHJ (Fig. 7(c)), we see that the runtime of the majority of queries improves. Just a few queries are slightly above the diagonal line which is likely to be attributed to runtime conditions. Combining the theoretical properties and the empirical evaluation of the PHJ, our findings show that the opportunity of improving the query execution efficiency with PHJ outweighs the potential risk of performance degradation. For the PBJ, we find that (with the current parameters) in many cases there is a higher risk of performance degradation. Therefore, future work should further investigate and improve the PBJ operator and its parameterization to reduce this risk.

7. Conclusion

In this work, we investigated different robust query processing techniques for Linked Data Fragments. In particular, we proposed two approaches to overcome the challenges of join cardinality estimation errors to devise efficient query planning and execution.

Our first approach, a cost- and robustness-based query plan optimizer (CROP), devises plans that are robust with respect to cardinality estimation errors. We propose a cost model to estimate the cost of query plans that combines local processing and network costs. We assess the robustness of a query plan using the cost ratio robustness measure, which compares the query plan’s best-case cost to its average-case cost (RQ 1). While the best-case cost assumes optimistic cardinality estimations, the average-case cost accounts for potential estimation errors by incorporating alternative, less optimistic cardinality estimations. Our query planner combines the cost model and robustness measure to devise efficient query plans. The results of our experimental study provide the following insights regarding RQ 2: (1) Including the robustness measure improves the query plan efficiency for queries with s-o and o-o joins. (2) In the case that the cheapest plan is not robust enough, an alternative robust plan that is not too expensive should be chosen. (3) CROP overall outperforms state of the art TPF clients.

In our second approach, we focus on query execution robustness by adapting the operators to estimation errors. To this end, we propose a new class of adaptive join operators that are able to switch their join strategy at runtime. We propose a Polymorphic Bind Join (PBJ) and a Polymorphic Hash Join (PHJ), which are able to switch their join strategy from a bind to hash join and vice versa. Our theoretical analysis proves the correctness of both operators under set semantics. In our empirical evaluation, we investigate the impact of PBJ and PHJ on the query execution efficiency for different planning approaches. The results show that especially the left-deep query planning approaches benefit from the adaptivity of the operators. In addition, we find that the gains in robustness during query execution depend on the operator and query characteristics. Specifically, the PHJ consistently enables more robust query execution, while the PBJ yields better results for the more selective queries in the WatDiv benchmark (RQ 3).

Concluding, we found that robust query processing approaches for Linked Data Fragments enable more efficient query execution. Robust query planning approaches help to devise efficient query plans that are less prone to potential cardinality estimation errors. Adaptive join operators can enhance the robustness during query execution by reducing the impact of sub-optimal query planning decisions. Future work may continue in both directions. Our query planning approach should be extended and evaluated for additional LDF interfaces. Moreover, existing clients for LDF interfaces, such as Comunica or smart-KG, could benefit from implementing the cost model and the robustness measure. In the area of adaptive join operators, future work should investigate alternative switch rules for the polymorphic join operators, e.g., by considering information from the query planner similar to [8] and [21]. In addition, other types of polymorphic join operators should be studied. For instance, operators that are able to switch their strategies several times. Lastly, the operators can be extended to further leverage the properties of the LDF interfaces, such as sorted tuples or the support of several bindings in the expressions.