continuous self-updating query results over dynamic linked data
TRANSCRIPT
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
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.
OverviewResearch questions
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
OverviewResearch questions
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), ...
OverviewResearch questions
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
OverviewResearch questions
Research approach
Evaluation plan
Preliminary results