Answering Queries Using Cooperative Semantic Caching

Size: px

Start display at page:

Download "Answering Queries Using Cooperative Semantic Caching"

Grant Alexander
6 years ago
Views:

Answering Queries Using Cooperative Caching

1 Answering Queries Using Cooperative Caching Andrei Vancea 1, Prof. Dr. Burkhard Stiller 1,2 1 Department of Informatics IFI, Communication Systems Group CSG, University of Zürich 2 associated with the D-ITET, ETH Zürich Background Approach Evaluation Conclusion

2 Background Databases Client / server architecture Client : asks a query (SQL) Server : returns the result (tuples) Data shipping architectures Most of the query processing is performed on the client side Data is sent from the server to the client at processing time Client-side caching Response time Server load

3 Client-side caching Page caching Tuple caching caching Background caching Clients store the results of old queries, together with their descriptions Old query results are used when answering new queries

4 Example Background - Caching Q1 : select * from persons where age > 10 Database

5 Example Background - Caching result store Q1 : age > 10 Database

6 Example Background - Caching Q2 : select * from persons where age > 7 Q1 : age > 10 Database

7 Example Background - Caching select * from persons where age > 7 and age <= 10 select * from Q1 Q1 : age > 10 Database

8 Example Background - Caching result result Q1 : age > 10 Database

9 Background - Caching Query Cache entry Query description Result set Query rewriting Probe Remainder Queries descriptions Probe QUERY REWRITING Remainder Server

10 Cooperative Caching Share the local semantic s between clients in a cooperative matter Before sending a query to the server, it is checked if there are other clients that have useful semantic entries Why? Reduce the load of the database server Decrease query response time Database

11 Query Rewriting Query rewriting Probe Remote probes Remainder QUERY All queries descriptions Query REWRITING Network information... Probe Remote probe Remote probe Remainder Local Remote Remote Server

12 Architecture Issues Who rewrites the queries? (clients, server) How/where are the queries descriptions stored? Updates Time-outs Two possible architectures Centralized Distributed

13 Cooperative Caching Centralized Approach Centralized manager Stores the descriptions of all queries d by different clients Rewrite queries Advantages Easy to implement Query rewriting simplified Disadvantages Scalability problems (the manager is contacted before every query execution) Bottleneck

14 Cooperative Caching Distributed Approach Queries descriptions stored in a DHT Query rewriting executed locally by each client using the data stored in the DHT Advantages Scalable Disadvantages Query rewriting much more difficult

15 Query Rewriting Theoretical problem : answering queries using view Not possible for all SQL queries Query containment is undecidable for general relational queries Range queries Multi-dimensional range queries

16 Evaluation Test-bed consisting of a database server and number of clients (in a LAN) Dataset from Wisconsin benchmark The clients execute, in parallel, queries under three different scenarios Without using the Using only the local semantic Using the cooperative semantic Average query response time computed in each scenario

17 Conclusions P2P approach used for reducing the load of the database server Two possible architectures proposed Evaluation

18 Questions?

SCRIPT: An Architecture for IPFIX Data Distribution

SCRIPT Public Workshop January 20, 2010, Zurich, Switzerland SCRIPT: An Architecture for IPFIX Data Distribution Peter Racz Communication Systems Group CSG Department of Informatics IFI University of Zürich