ANAPSID: An Adaptive Query Processing Engine for SPARQL Endpoints
ANAPSID: An Adaptive Query Processing Engine for SPARQL Endpoints | |
---|---|
ANAPSID: An Adaptive Query Processing Engine for SPARQL Endpoints
| |
Bibliographical Metadata | |
Authors: | Maribel Acosta, Maria-Esther Vidal, Tomas Lampo, Julio Castillo |
Content Metadata | |
Problem: | SPARQL Query Federation
Query Execution Source SelectionProperty "Has problem" (as page type) with input value "SPARQL Query Federation
Query Execution Source Selection" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. |
Approach: | Querying Distributed RDF Data Sources |
Implementation: | Linux |
Contents
Abstract
[[has abstract:=Following the design rules of Linked Data, the number of available SPARQL endpoints that support remote query processing is quickly growing; however, because of the lack of adaptivity, query executions may frequently be unsuccessful. First, fixed plans identified following the traditional optimize-then execute paradigm, may timeout as a consequence of endpoint availability. Second, because blocking operators are...[read more],]]
Conclusion
{{{Conclusion}}}
Future work
{{{Future work}}}
Approach
Positive Aspects: {{{PositiveAspects}}}
Negative Aspects: {{{NegativeAspects}}}
Limitations: {{{Limitations}}}
Challenges: {{{Challenges}}}
Proposes Algorithm: {{{ProposesAlgorithm}}}
Methodology: {{{Methodology}}}
Requirements: {{{Requirements}}}
Limitations: {{{Limitations}}}
Implementations
Download-page: {{{Download-page}}}
Access API: {{{API}}}
Information Representation: {{{InfoRepresentation}}}
Data Catalogue: {{{Catalogue}}}
Runs on OS: {{{OS}}}
Vendor: {{{vendor}}}
Uses Framework: {{{Framework}}}
Has Documentation URL: {{{DocumentationURL}}}
Programming Language: {{{ProgLang}}}
Version: {{{Version}}}
Platform: {{{Platform}}}
Toolbox: {{{Toolbox}}}
GUI: {{{GUI}}}
Research Problem
Subproblem of: {{{Subproblem}}}
RelatedProblem: {{{RelatedProblem}}}
Motivation: {{{Motivation}}}
Evaluation
Experiment Setup: {{{ExperimentSetup}}}
Evaluation Method : {{{EvaluationMethod}}}
Hypothesis: {{{Hypothesis}}}
Description: {{{Description}}}
Dimensions: {{{Dimensions}}}
Benchmark used: {{{Benchmark}}}
Results: {{{Results}}}
Abstract
Following the design rules of Linked Data, the number of available SPARQL endpoints that support remote query processing is quickly growing; however, because of the lack of adaptivity, query executions may frequently be unsuccessful. First, fixed plans identified following the traditional optimize-then execute paradigm, may timeout as a consequence of endpoint availability. Second, because blocking operators are usually implemented, endpoint query engines are not able to incrementally produce results, and may become blocked if data sources stop sending data. We present ANAPSID, an adaptive query engine for SPARQL endpoints that adapts query execution schedulers to data availability and run-time conditions. ANAPSID provides physical SPARQL operators that detect when a source becomes blocked or data traÆc is bursty, and opportunistically, the operators produce results as quickly as data arrives from the sources. Additionally, ANAPSID operators implement main memory replacement policies to move previously computed matches to secondary memory avoiding duplicates. We compared ANAPSID performance with respect to RDF stores and endpoints, and observed that ANAPSID speeds up execution time, in some cases, in more than one order of magnitude.
Conclusion
We have defined ANAPSID, an adaptive query processing engine for RDF Linked Data accessible through SPARQL endpoints. ANAPSID provides a set of physical operators and an execution engine able to adapt the query execution to the availability of the endpoints and to hide delays from users. Reported experimental results suggest that our proposed techniques reduce execution times and are able to produce answers when other engines fail. Also, depending on the selectivity of the join operator and the data transfer delays, ANAPSID operators may overcome state-of-the-art Symmetric Hash Join operators. In the future we plan to extend ANAPSID with more powerful and lightweight operators like Eddy and MJoin, which are able to route received responses through different operators, and adapt the execution to unpredictable delays by changing the order in which each data item is routed.