continuous self-updating query results over dynamic linked data

Continuously Self-Updating Query Results over Dynamic Linked Data

Ruben Taelman - @rubensworksiMinds - Ghent University

Dynamic Linked DataE.g. Thermometer measures every minute:

“19,05°C” - 30-05-2016 11:00“19,06°C” - 30-05-2016 11:01“19,11°C” - 30-05-2016 11:02“19,08°C” - 30-05-2016 11:03…

Typically exposed as an RDF stream = stream of <RDF triple, timestamp>

Querying continous dataClients send queries to server: e.g. What is the current temperature?

Server continuously evaluates the queries

→ Server does all of the work

Cause of low public endpoint availability!½ have availability of < 95% (Buil-Aranda 2013)

→ Clients just wait for results

What if we moved continuous query evaluation to the client?→ to lower server load

OverviewResearch questions

Research approach

Evaluation plan

Preliminary results

Research questionsHow to publish of dynamic data, to make it queryable together with static data at a low server cost?

How can we efficiently store dynamic data and allow efficient transfer to clients?

What kind of server interface do we need to enable client-side query evaluation over both static and dynamic data?

Hypotheses1. Our storage solution can store new data in linear time with respect to the

amount of new data.

2. Our storage solution can retrieve data by time or triple values in linear time with respect to the amount of retrieved data.

3. The server cost for our solution is lower than the alternatives.

4. Data transfer is the main factor influencing query execution time.


Research approach

Evaluation plan

Preliminary results

Moving continuous query evaluation to the client

Triple Pattern Fragments does this for static data!

Triple pattern fragments (TPF) (Verborgh 2016):

Servers can only respond to triple pattern queriesClients need to evaluate queries locally→ Lowers server complexity

How I will do this for dynamic data

Storage Transmission Query evaluation

StorageHow do we efficiently store / retrieve dynamic data? (Indexing)

It depends on the use cases:

Querying on a certain time (Indexing by time)

What was the temperature in Ghent yesterday?

Querying for a certain time (Indexing by property)

When was it 20°C in Ghent?

Can we / Do we have to combine these indexing techniques?

TransmissionDisadvantage:Moving query evaluation to the client requires more data to be transfered→ Increases bandwidth usage

→ Slows down query evaluation→ Limits query frequency

Possible solutions:Compression within and between versionsCachingHigher data selectivity

Query EvaluationScope: Data with a predictable valid time

Some thermometers measure /min → data will not change during that minute.Otherwise we need to poll or have a persistent server connection

Annotate data with their valid time:

Thermometer_1 : 10°C (10:00 - 10:01)Thermometer_1 : 20°C (10:01 - 10:02)Thermometer_1 : 20°C (10:02 - 10:03)

→ Clients can fetch this data as if it was static data


Research approach

Evaluation plan

Preliminary results

Evaluation of the three partsStorage

Transmission

Query evaluation

Insertion, lookup, size

Latency, bandwidth, cacheability

Result latency

Combined evaluationRealistic datasets/datastreams and queries

Compare with:Server-side:

C-SPARQL (Barbieri 2012)CQELS (Le-Phuoc 2011)

Client-side:Ztreamy (Fisteus 2014)

Compare by:latencycompletenessserver loadclient loadscalability

→ LSBench (Le-Phuoc 2012), SRBench (Zhang 2012), CityBench (Ali 2015), ...


Research approach

Evaluation plan

Preliminary results

Preliminary scalability testQuery Streamer prototype (Taelman 2016), based on TPF

Test server load for increasing #clients

Compared with C-SPARQL, CQELS

Query Streamer moves load from server to client

Server scalability Client load


Research approach

Evaluation plan

Preliminary results

continuous self-updating query results over dynamic linked data

Engineering