the impact of data caching of on query execution for linked data

The Impact ofData Caching on

Query Execution for Linked Data

Olaf Hartighttp://olafhartig.de/foaf.rdf#olaf

@olafhartig

Database and Information Systems Research GroupHumboldt-Universität zu Berlin

Olaf Hartig - The Impact of Data Caching on Query Execution for Linked Data 2

SELECT DISTINCT ?i ?labelWHERE {

?prof rdf:type <http://res ... data/dbprofs#DBProfessor> ; foaf:topic_interest ?i .

OPTIONAL { ?i rdfs:label ?label FILTER( LANG(?label)="en" || LANG(?label)="") }}ORDER BY ?label

?

Can we query the Web of Dataas of it were a single,giant database?

Our approach: Link Traversal Based Query Execution [ISWC'09]


Main Idea

query-localdataset

● Intertwine query evaluation with traversal of data links

● We alternate between:● Evaluate parts of the query (triple patterns)

on a continuously augmented set of data● Look up URIs in intermediate

solutions and add retrieved datato the query-local dataset


Main Idea

query-localdataset





n

ame

project ?prj

Query

know

s

?acq

?prjName

http://bob.name


query-localdataset

Main Idea

http://bob.name

?





n

ame

project ?prj

Query

know

s

?acq

?prjName

http://bob.name


query-localdataset

Main Idea

http://bob.name

?





n

ame

project ?prj

Query

know

s

?acq

?prjName

http://bob.name

“Descriptor object”


query-localdataset





Main Idea

n

ame

project ?prj

Query

?prjName

know

s

http://bob.name

?acq


query-localdataset





Main Idea

knows

http://bob.name

http://alice.name

n

ame

project ?prj

Query

?prjName

know

s

http://bob.name

?acq n

ame

project ?prj

Query

?prjName

know

s

http://bob.name

?acq


query-localdataset





Main Idea

http://alice.name

?acq

n

ame

project ?prj

Query

?prjName

know

s

http://bob.name

?acq

knows

http://bob.name

http://alice.name


query-localdataset





Main Idea

http

://al

ice.

nam

e

?

http://alice.name

?acq

n

ame

project ?prj

Query

know

s

?acq

?prjName

http://bob.name


query-localdataset





Main Idea

n

ame

project ?prj

Query

know

s

?acq

?prjName

http://bob.name

http://alice.name

?acq


query-localdataset





Main Idea

http://alice.name

?acq

n

ame

?prjName

know

s

http://bob.nameQuery

project ?prj?acq


query-localdataset





Main Idea

project http://.../AlicesPrj

http://alice.name

http://alice.name

?acq

n

ame

?prjName

know

s


project ?prj?acq


query-localdataset





Main Idea

http://alice.name http://.../AlicesPrj

?prj?acq

http://alice.name

?acq

n

ame

?prjName

know

s


project ?prj?acq

project http://.../AlicesPrj

http://alice.name


query-localdataset





Main Idea

http://alice.name

?acq

n

ame

?prjName

know

s


project ?prj?acq


?prj?acq


query-localdataset





Main Idea

http://alice.name

?acq

n

ame

know

s


project?acq

?prjName

?prj


?prj?acq

http://.../AlicesPrj “ … “

?prjName?prj


query-localdataset

Main Idea

http://alice.name

?acq

n

ame

know

s


project?acq

?prjName

?prj


?prj?acq

http://.../AlicesPrj “ … “

?prjName?prj

http://alice.name

?acqhttp://.../AlicesPrj “ … “

?prjName?prj






Characteristics

● Link traversal based query execution:● Evaluation on a continuously augmented dataset● Discovery of potentially relevant data during execution● Discovery driven by intermediate solutions

● Main advantage:● No need to know all data sources in advance

● Limitations:● Query has to contain a URI as a starting point● Ignores data that is not reachable* by the query execution

* formal definition in [LDOW'11a]


query-localdataset

The Issue

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name


query-localdataset

The Issue

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

http://bob.name?


query-localdataset

The Issue

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

knows

http://bob.name

http://alice.name


query-localdataset

The Issue

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

knows

http://bob.name

http://alice.name

?acq ?iLabel?i


query-localdataset

query-localdataset

The Issue

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

nam

e

know

s


project?acq

?prjName

?prj


query-localdataset

query-localdataset

Reusing the Query-Local Dataset

lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

nam

e

know

s


project?acq

?prjName

?prj


query-localdataset


lab

el

interest?i

Querykn

ows

?acq

?iLabel

http://bob.name

nam

e

know

s


project?acq

?prjName

?prj

knows

http://alice.name

http://bob.name


query-localdataset


lab

el

interest?i

Querykn

ows

?iLabel

?acq

http://bob.name

nam

e

know

s


project?acq

?prjName

?prj

http://alice.name

?acq

knows

http://bob.name

http://alice.name


Re-using the query-local dataset (a.k.a. data caching)may benefit

query performance + result completeness

Hypothesis


Contributions

● Systematic analysis of the impact of data caching● Theoretical foundation* ● Conceptual analysis* ● Empirical evaluation of the potential impact

● Out of scope: Caching strategies (replacement, invalidation)

*see [LDOW'11a]


Experiment – Scenario

● Information about thedistributed social network of FOAF profiles

● 5 types of queries

● Experiment Setup:● 20 persons● Sequential use➔ 100 queries


ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60

no reuse reuse per query

query execution time (in seconds)

0,01 0,1 1 10 100

0,01 0,1 1 10 100

Experiment – Single Query

(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)

number of query results

● no reuse experiment:● No data caching

● reuse per query experiment● Reuse of query-local dataset

for 3 executions of each query● Third execution measured


query execution time (in seconds)

0,01 0,1 1 10 100

0,01 0,1 1 10 100


(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)


● no reuse experiment:● No data caching

● reuse per query experiment● Reuse of query-local dataset

for 3 executions of each query● Third execution measured

ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60



0,01 0,1 1 10 100

0,01 0,1 1 10 100


(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)

query execution time (in seconds)number of query results

ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60



0,01 0,1 1 10 100

0,01 0,1 1 10 100


(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)


ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60



Experiment – Complete Sequence


(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)

ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60


reuse all queries

query execution time(in seconds)

0,01 0,1 1 10 100

0,01 0,1 1 10 100

● reuse all queries experiment:● Reuse of the query-local

dataset for the complete sequence of all 100 queries




(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)

ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60


reuse all queries


0,01 0,1 1 10 100

0,01 0,1 1 10 100





(Query No. 61)

(Query No. 62)

(Query No. 63)

(Query No. 64)

(Query No. 65)

ContactInfoDanBri

UnsetPropsDanBri

2ndDegree1DanBri

2ndDegree2DanBri

IncomingDanBri

0 10 20 30 40 50 60

0 10 20 30 40 50 60


reuse all queries

0,01 0,1 1 10 100

0,01 0,1 1 10 100


Outlook

● Requirements of a data cache:● Replacement mechanism● Coherency mechanism


Cache Replacement

● Cache full → remove descriptor objects

● Replacement strategy● Primary goal: maximize hit rate● Recency-based● Frequency-based● Function-based● Randomized

● Replacement process● Watermarks: high and low


Studying Cache Replacement?



“Web cache replacement in its general form seems to be a solved topic.”

S. Podlipnig and L. Böszörmenyi: Survey of Web Cache Replacement Strategies, 2003



● 6 quad indexes* in main memory● Size grows linear in the number of quads

● Example (after reuse all queries experiment, 100 queries):● 905 descriptor objects, overall number of 745,756 triples● ca. 103 MB

➔ Available main memory is almost no limit

“Web cache replacement in its general form seems to be a solved topic.”

S. Podlipnig and L. Böszörmenyi: Survey of Web Cache Replacement Strategies, 2003

* as introduced in [LDOW'11b]


Cache Coherency

● Data items in the cache may become inconsistent

● Strong cache consistency● Server validation● Client validation

● Weak cache consistency● Time to live (TTL)● Adaptive TTL


Client Validation

● Polling every time

● Enables strong cache consistency

● Conditional GET● Request with If-Modified-Since header● Possible response: 304 Not Modified


Client Validation

● Polling every time

● Enables strong cache consistency

● Conditional GET● Request with If-Modified-Since header● Possible response: 304 Not Modified

● Not supported by most Linked Data servers● Experiment based on the CKAN catalog of linked datasets

● 41 out of 154 example resources (26.6%) from 110 datasets


Time to Live (TTL)

● TTL field: life time estimation for each object

● Supported by HTTP response headers:● Expires● Cache-Control: max-age

● When TTL elapses, object is invalid

● Accessing an invalid object → re-retrieve object again● Conditional GET


Time to Live (TTL)

● TTL field: life time estimation for each object

● Supported by HTTP response headers:● Expires● Cache-Control: max-age

● When TTL elapses, object is invalid

● Accessing an invalid object → re-retrieve object again● Conditional GET

● Alternative (due to lack of support in Linked Data servers):● Assume a default TTL for each object● Ordinary GET

37.7%

37.0%

26.6%


Adaptive TTL

● Assumption:● The older an object, the less likely it is to be modified

● TTL is a percentage of the age:● Threshold = 10% ; age = 30 days → TTL = 3 days● Last verification: yesterday → invalidation in 2 days

● HTTP-based implementation:● Calculation of age: use Last-Modified response header● Verification with conditional GET


Adaptive TTL

● Assumption:● The older an object, the less likely it is to be modified

● TTL is a percentage of the age:● Threshold = 10% ; age = 30 days → TTL = 3 days● Last verification: yesterday → invalidation in 2 days

● HTTP-based implementation:● Calculation of age: use Last-Modified response header● Verification with conditional GET

● Alternative (due to lack of support in Linked Data servers):● Assume Last-Modified is time of first retrieval● Verification by comparing a response to the current version

35.1%


Summary

● Systematic analysis of the impact of data cache ● Theoretical foundation● Conceptual analysis● Empirical evaluation

● Main findings:● Additional results possible (for semantically similar queries)● Impact on performance may be positive but also negative

● Future work:● Analysis of caching strategies in our context● Main issue: invalidation


Backup Slides


Contributions

● Theoretical foundation (extension of the original definition)

● Reachability by a Dseed

-initialized execution of a BGP query b

● Dseed

-dependent solution for a BGP query b

● Reachability R(B) for a serial execution of B = b1 , … , b

n

➔ Each solution for bcur

is also R(B)-dependent solution for bcur

● Conceptual analysis of the impact of data caching

● Performance factor: p( bcur

, B ) = c( bcur

, [ ] ) – c( bcur

, B )

● Serendipity factor: s( bcur

, B ) = b( bcur

, B ) – b( bcur

, [ ] )

● Empirical verification of the potential impact

● Out of scope: Caching strategies (replacement, invalidation)


Query Template Contact

SELECT * WHERE { <PERSON> foaf:knows ?p .

OPTIONAL { ?p foaf:name ?name } OPTIONAL { ?p foaf:firstName ?firstName } OPTIONAL { ?p foaf:givenName ?givenName } OPTIONAL { ?p foaf:givenname ?givenname } OPTIONAL { ?p foaf:familyName ?familyName } OPTIONAL { ?p foaf:family_name ?family_name } OPTIONAL { ?p foaf:lastName ?lastName } OPTIONAL { ?p foaf:surname ?surname }

OPTIONAL { ?p foaf:birthday ?birthday }

OPTIONAL { ?p foaf:img ?img }

OPTIONAL { ?p foaf:phone ?phone } OPTIONAL { ?p foaf:aimChatID ?aimChatID } OPTIONAL { ?p foaf:icqChatID ?icqChatID } OPTIONAL { ?p foaf:jabberID ?jabberID } OPTIONAL { ?p foaf:msnChatID ?msnChatID } OPTIONAL { ?p foaf:skypeID ?skypeID } OPTIONAL { ?p foaf:yahooChatID ?yahooChatID }

}


Query Template UnsetProps

SELECT DISTINCT ?result ?resultLabel WHERE{

?result rdfs:isDefinedBy <http://xmlns.com/foaf/0.1/> .?result rdfs:domain foaf:Person .

OPTIONAL { <PERSON> ?result ?var0 } FILTER ( !bound(?var0) )

<PERSON> foaf:knows ?var2 .?var2 ?result ?var3 .?result rdfs:label ?resultLabel .?result vs:term_status ?var1 .

}ORDER BY ?var1


Query Template Incoming

SELECT DISTINCT ?result WHERE{

?result foaf:knows <PERSON> .

OPTIONAL{

?result foaf:knows ?var1 .FILTER ( <PERSON> = ?var1 )<PERSON> foaf:knows ?result .

}FILTER ( !bound(?var1) )

}


Query Template 2ndDegree1


<PERSON> foaf:knows ?p1 .<PERSON> foaf:knows ?p2 .FILTER ( ?p1 != ?p2 )

?p1 foaf:knows ?result .FILTER ( <PERSON> != ?result )?p2 foaf:knows ?result .

OPTIONAL {<PERSON> ?knows ?result .FILTER ( ?knows = foaf:knows )

}FILTER ( !bound(?knows) )

}


Query Template 2ndDegree2


<PERSON> foaf:knows ?p1 .<PERSON> foaf:knows ?p2 .FILTER ( ?p1 != ?p2 )

?result foaf:knows ?p1 .FILTER ( <PERSON> != ?result )?result foaf:knows ?p2 .

OPTIONAL {<PERSON> ?knows ?result .FILTER ( ?knows = foaf:knows )

}FILTER ( !bound(?knows) )

}



● In the ideal case for Bupper

= [ bcur

, bcur

] :

● pupper

( bcur

, Bupper

) = c( bcur

, [ ] ) – c( bcur

, Bupper

) = c( bcur

, [ ] )

● supper

( bcur

, Bupper

) = b( bcur

, Bupper

) – b( bcur

, [ ] ) = 0

1 Averaged over all 100 queries

Experiment Avg.1 number of Query Results

(std.dev.)

Average1

Hit Rate

(std.dev.)

Avg.1 query Execution Time

(std.dev.)

no reuse27.37

(140.49)

0.849(0.205)

64.95 s(124.50)

reuse per query26.71

(148.77)

1(0)

0.02 s(0.07)



● Summary (measurement errors aside):● Same number of query results● Significant improvements in query performance



(std.dev.)

Average1

Hit Rate

(std.dev.)


(std.dev.)

no reuse27.37

(140.49)

0.849(0.205)

64.95 s(124.50)


(148.77)

1(0)

0.02 s(0.07)



● Summary:● Data cache may provide for additional query results● Impact on performance may be positive but also negative



(std.dev.)

Average1

Hit Rate

(std.dev.)


(std.dev.)

no reuse27.37

(140.49)

0.849(0.205)

64.95 s(124.50)


(148.77)

1(0)

0.02 s(0.07)

reuse all queries44.87

(178.36)

0.991(0.053)

37.91 s(112.94)



● Executing the query sequence in a random order results in measurements similar to the given order.


(std.dev.)

Average1

Hit Rate

(std.dev.)


(std.dev.)

no reuse27.37

(140.49)

0.849(0.205)

64.95 s(124.50)


(148.77)

1(0)

0.02 s(0.07)

reuse all queries44.87

(178.36)

0.991(0.053)

37.91 s(112.94)

reuse all queries(random orders)

118.18(867.07)

0.992(0.016)

20.61 s(216.61)


These slides have been created byOlaf Hartig

http://olafhartig.de

This work is licensed under aCreative Commons Attribution-Share Alike 3.0 License

(http://creativecommons.org/licenses/by-sa/3.0/)

the impact of data caching of on query execution for linked data

Technology

continuously

life time

prj datasetolaf

prj datasetolaf

prj datasetolaf

prj datasetolaf

add retrieved

local datasetolaf