Presentation is loading. Please wait.

Presentation is loading. Please wait.

@ Carnegie Mellon Databases 1 Invalidation Clues for Database Scalability Services Amit Manjhi* 1, Phillip B. Gibbons z, Anastassia Ailamaki *, Charles.

Similar presentations


Presentation on theme: "@ Carnegie Mellon Databases 1 Invalidation Clues for Database Scalability Services Amit Manjhi* 1, Phillip B. Gibbons z, Anastassia Ailamaki *, Charles."— Presentation transcript:

1 @ Carnegie Mellon Databases 1 Invalidation Clues for Database Scalability Services Amit Manjhi* 1, Phillip B. Gibbons z, Anastassia Ailamaki *, Charles Garrod*, Bruce M. Maggs * y, Todd C. Mowry * z, Christopher Olston © *, Anthony Tomasic *, Haifeng Yu x * Carnegie Mellon University 1 Buxfer, Inc. z Intel Research Pittsburgh y Akamai Technologies © Yahoo! Research x National University of Singapore

2 @ Carnegie Mellon Databases 2 Typical Architecture of Dynamic Web Applications Home server Web Server App Server DB Users Request Response Execute code Access DB Internet Dynamic Web applications need to provision for variable and unpredictable load

3 @ Carnegie Mellon Databases 3 Content Delivery Networks Users Scales central web server Works well for static content CDN nodes Internet

4 @ Carnegie Mellon Databases 4 CDN Application Services Users CDN nodes Database server is still a bottleneck Internet

5 @ Carnegie Mellon Databases 5 Database Scalability Service (DBSS) Architecture Users User queries answered from DB cache Internet How to guarantee privacy of data?

6 @ Carnegie Mellon Databases 6 Privacy concerns dictate that: Users Internet Home server maintains master copy and handles updates directly DBSS is provided encrypted data Cache base tables: does not work Cache query results – invalidate on updates

7 @ Carnegie Mellon Databases 7 A Simple Example Empty Home server database Q:SELECT id FROM comments WHERE story=“Wintel” AND rating>0 DBSS node Q Q:id=11,15 U Empty Q toy_id=15 Nothing is encrypted Results are encrypted No Invalidations Q: U Invalidate More encryption can lead to more invalidations comments (id, rating, story) Result U:UPDATE comments SET rating=2 WHERE id=15 Q: id=11,15 111Wintel 151Wintel 111Wintel 151Wintel 111Wintel 152Wintel 111Wintel 152Wintel

8 @ Carnegie Mellon Databases 8 Privacy-Scalability Space for Query Result Caching Scalability Privacy (Maximum privacy, read-only scalability) No encryption Encrypt everything Encrypt data not useful for invalidation (Our prior work, SIGMOD 2006) Want solutions in this space No Prior Full

9 @ Carnegie Mellon Databases 9 Our Approach: Invalidation Clues Home server DBSS Database QueryUpdate Empty query clue ResultQuery query clue ResultQueryResultQueryUpdate update clue Invalidations (query clue, update clue) Invalidation clues offer a more general, flexible framework Limit unnecessary invalidation Limit revealed information Limit home server overhead

10 @ Carnegie Mellon Databases 10 UPDATE comments SET rating=? WHERE id=? Example Bulletin-Board Application Invalidation clues enable more precise invalidations than the “No” encryption scenario 1. Extra invalidation in no encryption scenario: results with rating_param<2 and no id=5 in result : 2.Example clue: story of comment being updated (update clue) 2 5 SELECT id FROM comments WHERE story=? AND rating>?

11 @ Carnegie Mellon Databases 11 Privacy-Scalability Space for Query Result Caching Scalability Privacy (Maximum privacy, read-only scalability) No encryption Encrypt everything Encrypt data not useful for invalidation (Our prior work, SIGMOD 2006) Want solutions in this space No Prior Full Database (Code-analysis privacy, maximum scalability) clues offer fine-grained tradeoff

12 @ Carnegie Mellon Databases 12 Outline Introduction to invalidation clues framework Improving scalability in the clues framework Improving privacy in the clues framework Evaluation results Related work and summary

13 @ Carnegie Mellon Databases 13 Improving Scalability in the Clues Framework Fewer invalidations  More scalability What is the “most precise” invalidation that can be done? As a first cut, Database Inspection Strategy: Invalidate as if using the database Extra data (database clues) can either be attached to query results (query result clue) or updates (update clue)

14 @ Carnegie Mellon Databases 14 Database Clues and Beyond SELECT id FROM comments WHERE story=? AND rating>? UPDATE comments SET rating=? WHERE id=? Query Clue: Story of ALL comments Auxiliary view idstory Update Clue: Story of the comment being updated On-the-fly 1.Consistency 2.Privacy Still better: Opportunistic Strategy – use database clues only when benefit exceeds overhead

15 @ Carnegie Mellon Databases 15 Outline Introduction to invalidation clues framework Improving scalability in the clues framework Improving privacy in the clues framework Evaluation results Related work and summary

16 @ Carnegie Mellon Databases 16 Attack Model of the DBSS Users Internet 2.DBSS can pose as a user – chosen-plaintext attack 1. DBSS learns from query clues, update clues, and invalidations – ciphertext-only attack

17 @ Carnegie Mellon Databases 17 Results on Improving Privacy Invalidation decision involves equality on id and story ; order comparison on rating Needless invalidations can improve privacy SELECT id FROM comments WHERE story=? AND rating>? UPDATE comments SET rating=? WHERE id=? Key idea Paper has details on improving privacy for equality and order comparisons Extreme: If all query results are always invalidated, DBSS can’t distinguish between any two query results

18 @ Carnegie Mellon Databases 18 Outline Introduction to invalidation clues framework Improving scalability in the clues framework Improving privacy in the clues framework Evaluation results Related work and summary

19 @ Carnegie Mellon Databases 19 Benchmark Applications Auction (RUBiS, from Rice) Bulletin board (RUBBoS, from Rice) Bookstore (TPC-W, from UW-Madison)

20 @ Carnegie Mellon Databases 20 Evaluation Methodology Home server CDN and DBSSUsers 5 ms100 ms Scalability: max # concurrent users with acceptable response times

21 @ Carnegie Mellon Databases 21 Scalability (number of concurrent users supported) Benchmark Applications 0 1. Clues help 2. Opportunistic has the best scalability

22 @ Carnegie Mellon Databases 22 Related Work Outsource database: [Hacigumus+ 2002], [Hacigumus+ 2002], [Agrawal+ 2004] Outsource database scalability: DBCache [Luo+ 2002, Altinel+ 2003], DBProxy [Amiri+ 2003], NEC cache portal [Li+ 2003], MTCache [Larson+ 2004], [Manjhi+ 2006]

23 @ Carnegie Mellon Databases 23 Related Work View invalidation strategies: [Levy and Sagiv 1993], [Candan+ 2002], [Choi and Luo 2004] Privacy: [Agrawal+ 2004], [Hore+ 2004], [Manjhi+ 2006]

24 @ Carnegie Mellon Databases 24 Summary Invalidation clues: general framework for limiting  Unnecessary invalidation  Revealed information  Home server overhead Fine-grained tradeoff between privacy and scalability Database clues  Update clues better than query clues  Opportunistic use of database clues  best scalability Evaluation on three application benchmarks

25 @ Carnegie Mellon Databases 25 Back-up slides….


Download ppt "@ Carnegie Mellon Databases 1 Invalidation Clues for Database Scalability Services Amit Manjhi* 1, Phillip B. Gibbons z, Anastassia Ailamaki *, Charles."

Similar presentations


Ads by Google