The W3C RDF Stream Processing (RSP) community has proposed a common model and a language for querying RDF streams. However, the current RSP systems significantly differ from each other in terms of performance. In this paper, we propose a unified interface for optimizing a continuous query in heterogeneous RSP systems. To enhance the performance of RSP, a unified interface decomposes a query, reassembles partial queries and assigns them to appropriate RSP systems. Experimental results show that the proposed approach performs better in terms of memory consumption and latency.
The importance of RDF Stream Processing (RSP) is magnified by the extension of
Linked Open Data (LOD) [
We propose a unified interface for processing a continuous query in three steps:
Firstly, we analyze a global query [
Query partitioning. To assign a query to a suitable RSP system that has better performance than the other RSP systems, we divide a global query into partial queries. As shown in Algorithm 1, by dividing a given global query, our method returns a set of partial queries that should be delivered to appropriate RSP systems. Specifically, the tree of a query plan is constructed using the semantics of a given query. Each node of the tree contains operators (e.g., window, join etc.), which perform respective roles. And, each node finds a stream corresponding to an operator as an input parameter. Since a partial query must include a given window operator and a stream, thus we repeatedly constitute a pair of a window and a stream. Then a set of partial queries is returned to be registered to the RSP systems.
Optimization. In this stage, partial queries are optimized based on the stream features to be allocated to appropriate RSP systems. Specifically, to check whether a partial query is suitable to be processed on a specific RSP system or not, we obtain a set of RSP systems, which support a certain operator. We also use the performance history (e.g. memory consumption) to select an RSP system that can process the partial query most efficiently in accordance with the execution time. The number of streams is not considered by this stage because the partial query generated in the stage of Query partitioning only has a single stream. Furthermore, we classify RSP systems into four classes for registering a partial query to an optimal RSP system in accordance with two factors: the initial memory consumption and the increasing rate of memory consumption. If all of the factors are high, the corresponding RSP system is not selected because the performance is always the worst. In contrast, the RSP system with the lower values is an ideal choice. Generally, if one of the factors is high, then the other one is low. Moreover, it is reasonable to register a partial query with short execution time to a system, which has the high increasing rate and the low initial cost of memory consumption. By using the classification, we determine the type of the systems with the optimal performance. We define a set of timestamps T , , … , , … , , where indicates the time when two RSP systems consume the same amount of memory. Therefore, we try to derive the optimal performance to assign a partial query to the selected RSP system based on .
Local system manager. This stage includes the query localization and the result integration. In the previous step, we determine how to distribute partial queries. To deal with the partial queries in the given RSP system, the proposed method supports the translation into the language form of the given RSP system. Note that, since the RSP systems may not require translation, the query localization is optional. And then, we distribute each partial query into an appropriate RSP system. Besides, to answer a global query, we integrate the graphs generated from partial queries into a graph. The integrated graph provides the answer to the global query. 3
To verify our approach, we evaluated the performance of the proposed unified interface
in comparison with C-SPARQL and CQELS by using multiple stream queries. The
performance was evaluated in terms of memory consumption and latency. The latency
indicates the time of delay until our method provides an answer after query execution.
Experimental Setting. Our experiments were conducted with Intel Core i7-4790k
4.0GHz CPU, 8 GB RAM, 250 GB SSD, Windows 10 OS and Eclipse for Java. Also
we used the real time cities dataset provided by CityBench [
We measured the performance using queries consisting of five streams according to the execution time of streams as shown in Fig. 4 and Fig. 5. A unified interface required the increased memory consumption during the initial one minute. It is due to that a unified interface needs the processing steps of query writing and query registering. After some time, the experimental results were optimized in other parts, respectively. The proposed method was better than C-SPARQL as much as 80% in terms of memory consumption. Also, the proposed method was better than CQELS as much as 60% in terms of latency. This is because a partial query was assigned to an optimal RSP system.
In conclusion, the conventional RSP systems have to trade-off between memory consumption and latency. The proposed method showed stable performance between the memory consumption and the latency without being biased to one side.
This work was supported by the ICT R&D program of MSIP/IITP, Republic of Korea. [B0101-16-1276, Access Network Control Techniques for Various IoT Services]