A Scalability Service for Dynamic Web Applications

1. A Scalability Service for Dynamic Web Applications Olston, Ailamaki, Garrod, Maggs, Manjhi, Mowry, Carnegie Mellon University Conference on Innovative Data System Research, 2005 Raihan Al-Ekram University of Waterloo October 11, 2006

2. Outline • Scalability Problem • A Solution • Challenges • Proposed System • Architecture • Operation • Consistency Management • Channel-By-Query • Channel-By-Update • View Invalidation Strategies • Conclusion • Discussion

3. Scalability Problem • Sudden Popularity Spikes • Slashdot effect • Civic Emergency • 9/11, Hurricane Katrina

4. A Solution • Scalability as a Third Party Service • Content Distribution Network

5. Challenges • Strong Consistency • Inconsistency could cost lives • Precludes TTL based caching • Ownership of Data • Security concerns • Data corruption risks • Precludes distributed data replication • Invalidate cache instead of updating

6. Observations • Read domination • Modifications only in Home Servers • Predefined Query and Update Templates • Cache invalidation based on query/update independence analysis • Strong cache consistency

7. System Architecture

8. System Operation • Fixed set of query and update templates at the proxy servers • Statically analyze the templates for conflicting query templates for each update template • When an update template is instantiated, all proxies containing an instantiation of a conflicting query template is notified for invalidation • Query template instantiations are organized in multicast groups and notifications are sent to only to proper multicast groups

9. Consistency Management • Update Templates • insert into inv values (name=?, id=?, qty=?, date=now()) • update inv set qty=? Where id=? • Query Templates • select qty from inv where name=? • Select * from inv where date>? • select * from inv where qty<?

10. Channel-By-Query • Multicast Channels • One per query template, parameter independent • Q1-PI, Q2-PI, Q3-PI • One per parameter binding of an equality comparison • Q1-PS1, Q1-PS2, Q1-PS3 … • Query Template Instantiation • Subscribe own channels • Q1: Q1-PI , Q1-PSx • Q2: Q2-PI • Q3: Q3-PI • Update Template Instantiation • Notify conflicting query channels • U1: Q1-PSx, Q2-PI, Q3-PI • U2: Q1-PI, Q2-PI, Q3-PI • Receive Notification • Unsubscribe channels

11. Channel-By-Update • Multicast Channels • One per update template, parameter independent • U1-PI, U2-PI • One per parameter binding • U1-PS1, U1-PS2, …, U2-PS1, U2-PS2, … • Query Template Instantiation • Subscribe conflicting update channels • Q1: U1-PSx, U2-PI • Q2: U1-PI, U2-PI • Q3: U1-PI, U2-PI • Update Template Instantiation • Notify own channels • U1: U1-PSx, U1-PI • U2: U2-PI • Receive Notification • Unsubscribe to channels

12. Comparison • Channel-By-Query • Fewer channel subscriptions • More multicast messages • Channel-By-Update • More channel subscriptions • Fewer multicast messages

13. View Invalidation • Strategies • Black-box, only query and update available • View-Inspection, access to cache data is also available • Full-Access, access to base data is also available • Example • Books (Title, Author, Subject) • Authors (Author, Award, Country)

14. View Invalidation • View • create view MyView (Author, Award) asselect A.Author, B.Awardfrom Authors A, Books Bwhere A.Author=B.Author and A.Country=“USA” and B.Subject=“History” • Updates • update Authors set Country=“France”where Author=“Tocqueville” • update Booksset Subject=“Fiction”where Tilte=“Napoleon’s Television” • Can benefit from view-inspection if there is no Author=“Tocqueville” • Can benefit from full-access if before the update Subject “History”

15. Conclusion • Ongoing work • Scalable and consistent data caching • Co-operative caches • Minimal home server involvement

16. Discussion • How are the updates in the home servers propagated to the proxies? • How do the proxies determine if the client requested data is in the cache? • Can this scheme provide 1SR or SI guarantee?