PRSP: A Plugin-based Framework for RDF Stream Processing

TL;DR

PRSP is a plugin-based framework that enables efficient distributed RDF stream processing and evaluation of SPARQL engines' performance and correctness in handling dynamic RDF data.

Contribution

It introduces PRSP, a novel plugin-based framework that simplifies integration and evaluation of SPARQL engines for RDF stream processing in distributed environments.

Findings

PRSP maintains high performance of SPARQL engines in RDF stream processing.

PRSP enables unified evaluation of engine correctness and performance.

Experimental results on YABench validate PRSP's effectiveness.

Abstract

In this paper, we propose a plugin-based framework for RDF stream processing named PRSP. Within this framework, we can employ SPARQL query engines to process C-SPARQL queries with maintaining the high performance of those engines in a simple way. Taking advantage of PRSP, we can process large-scale RDF streams in a distributed context via distributed SPARQL engines. Besides, we can evaluate the performance and correctness of existing SPARQL query engines in handling RDF streams in a united way, which amends the evaluation of them ranging from static RDF (i.e., RDF graph) to dynamic RDF (i.e., RDF stream). Finally, within PRSP, we experimently evaluate the correctness and the performance on YABench. The experiments show that PRSP can still maintain the high performance of those engines in RDF stream processing although there are some slight differences among them.

Tables

Table 1. Table 1: Precision/Recall results

		Jena	RDF3X	gStore	gStoreD	TriAD
Precision	s=100	99%	93%	100%	100%	97%
	s=300	97%	94%	100%	100%	93%
	s=500	85%	88%	100%	100%	100%
Recall	s=100	95%	89%	75%	72%	95%
	s=300	94%	91%	88%	76%	92%
	s=500	92%	79%	77%	63%	91%

Equations

$$(⟨S_i,P_i,O_i⟩,T)$$

$$[[Q{]]}_{(S,t)}=[[Q_{\mathrm{SPARQL}}{]]}_{\text{Window}(S,t)}.$$

Full text

††conference: AOSD’12 Hasso-Plattner Institut Potsdam, Germany,March 25–30, 2012††conference: XXX XXX††terms: Theory

{CCSXML}

<ccs2012> <concept> <concept_id>10002951.10002952.10003190.10003192</concept_id> <concept_desc>Information systems Database query processing</concept_desc> <concept_significance>500</concept_significance> </concept> <concept> <concept_id>10002951.10002952.10003197.10010825</concept_id> <concept_desc>Information systems Query languages for non-relational engines</concept_desc> <concept_significance>500</concept_significance> </concept> </ccs2012>

\printccsdesc

1 Introduction

RDF stream, as a new type of dataset, can model real-time and continuous information in a wide range of applications, e.g. environmental monitoring, Smart City and so on. But data stream is unbounded sequences of time-varying data element and difficult to store.

What is more, there is a few RSP[1] (RDF Stream Processing) systems, such as C-SPARQL[2] and EP-SPARQL[3] implemented for supporting RDF stream due to its complicacy in processing. On the other hand, there are many popular and efficient SRARQL query engines supporting only static RDF graphs, such as the centralized engines, Jena[4], RDF-3X and gStore, and distributed systems, TriAD, gStoreD[5] and so on. How to employ those SRARQL query engines to evaluate continuous queries becomes an interesting problem.

In this paper, we provide a plugin-based framework for RDF stream processing named PRSP, which makes it possible to use the high-performance RDF engines that’s valid only for RDF graphs, to process RDF streams. Moreover, within this framework, we can employ any RDF query engine to process RDF streams in a convenient way and compare their performance under a unified framework namely PRSP. And users can choose the favourable systems based on their all kinds of requirements. For example, they have the need to handle large-scale RDF graphs, thus distributed engines are the best choice.

2 Preliminaries

RDF stream An RDF stream is defined as ordered sequences of pairs, each pair being made of an RDF triple and a timestamp $T$:

[TABLE]

C-SPARQL query The continuous query is divided into three parts: $R_{\text{\text{query}}}$, $S(t)$, $Q_{\mathop{\mathrm{SPARQL}}}$, and it is formally defined as follows:                   $Q=[R_{\text{\text{query}}},S(t),Q_{\mathop{\mathrm{SPARQL}}}]$

• •

$R_{\text{\text{query}}}$ indicates the registered query from users which is waiting to be addressed.

• •

$S(t)$ is the RDF stream registered by the RSP systems, which defines the window size and step size.

• •

$Q_{\mathop{\mathrm{SPARQL}}}$ is a standard RDF query language, i.e., SPARQL.

Proposition 1

Let $Q$ be a C-SPARQL query. For any RDF stream $S$ and any present time $t$, the following holds:

[TABLE]

Proposition 1 ensures that the evaluation problem of C-SPARQL queries over RDF streams can be equivalent to the evaluation problem of SPARQL queries over RDF graphs. Moreover, Proposition 1 can show that the evaluation problem of C-SPARQL has the same computational complexity as SPARQL [2].

Consider the following query, a simple example from C-SPARQL. Line 1 matching the $R_{\text{query}}$, tells the RSP system to register the continuous query of TestQuery. $S(t)$, that is the following list of line 3, indicates that streams with a sliding window of 5 seconds that slides every 5 seconds, is the stream data waiting to be processed. And $Q_{sparql}$, displayed in both line 2 and line 4, is the query language for RDF.

1. REGISTER QUERY TestQuery AS

2. SELECT ?obs

3. FROM STREAM streams [ RANGE 5s   STEP 5s ]

4. WHERE { ?obs observedProperty AirTemperature. }

3 The architecture of PRSP

PRSP is an extension of SPARQL for querying both RDF graphs and RDF streams shown in Figure1. Both continuous query and RDF streams as the input of PRSP are transformed by the plugin Query Rewriting and Data Transformer in PRSP, respectively. After that, the output from the former plugins as the input of SPARQL API, the results are produced by one of SPARQL engines.

And the right box consists of any SPARQL query engine which is used as a black box for evaluating RDF graphs. Its architecture contains three types of plugin: Data Transformer, Query Rewriting, and a SPARQL API connecting with the former two plugins.

Query Rewriting

Continuous queries as the input of query rewriting mode, apply transformation methods in order to generate two types of queries, namely, SPARQL query and window operator, which can be addressed in one of SPARQL engine and Data Transformer module, respectively. After rewritting $Q$, we can obtain $Q_{\mathop{\mathrm{SPARQL}}}$.

Data Transformer

The data transformer module manages RDF streams specified in the query via Esper or another DSMS. And it transforms RDF streams into RDF graphs based on the window size and step size set by window operator. After tranforming $S$ w.r.t. $t$, we can obtain $\text{Windows}(S,t)$.

SPARQL API

PRSP defines a unified interface for RDF engines, which makes it possible and easy for SPARQL engines to process RDF streams. In the current version of PRSP, we have extended PRSP by including a few centralized engines, such as Jena, gStore, and RDF-3X, and two distributed engines, i.e., gStoreD and TriAD.

4 Experiments and Evaluations

Experiments

All centralized experiments were carried out on a machine running Linux, which has 4 CPUs with 6 cores and 64GB memory, and 5 machines with the same performance for distributed experiments. For evaluation, we utilized YABench RSP benchmark[6], which uses a real world dataset about water temperature. In our experiments, we performed sliding windows with a window size and a step size of 5 seconds, respectively. Considering that some engines can not support complex queries, the experiments used two BGP queries, $Q1$ and $Q1^{\prime}$. $Q1$ is a BGP query with four forms($Q1$) from YABench, and $Q1^{\prime}$ is the rewriting of $Q1$ with three triples. Since RDF-3X did not work when the the amount of stream data to 42.000 triples (i.e.,$s=500$), we chose five load scenario (i.e., $s=100/200/300/400/500$ $sensors$).

Evaluations

The performance of each engine under the five different input loads for windows is shown in Fig. 2. When the load ranges from $s=100$ to $s=500$, the query response time is with varying degrees of increase except for gStoreD. Fig. 3 shows the time of three processes, including data load time ($LT$), query response time($RT$), and engine execution time ($ET$) under $s=300$ obtained from query $Q1^{\prime}$. $LT$ from RDF3X, gStore, and gStoreD occupies a large part of $ET$, resulting in their lower efficiency for processing RDF streams. Table 1 illustrates the results of precision and recall from the experiments under three load scenarios (i.e., $s=100/300/500$) in PRSP. Along with more input load for windows, most of them enjoy lower recalls with high accuracy.

5 Conclusions

In this paper, we present PRSP, as a plugin adaptable for SPARQL engines, to process RDF streams, which makes it feasible to employ various engines to process large-scale RDF streams. In the future, we will optimize PRSP further to improve its performance and correctness. This work is supported by the National Key Research and Development Program of China (2016YFB1000603) and the National Natural Science Foundation of China (61672377).