1 / 21

Database replication policies for dynamic content applications

Database replication policies for dynamic content applications. Gokul Soundararajan, Cristiana Amza, Ashvin Goel University of Toronto Presented by Ahmed Ataullah Wednesday, November 22 nd 2006. The plan. Motivation and Introduction Background Suggested Technique

theo
Télécharger la présentation

Database replication policies for dynamic content applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Database replication policies for dynamic content applications Gokul Soundararajan, Cristiana Amza, Ashvin Goel University of Toronto Presented by Ahmed Ataullah Wednesday, November 22nd 2006

  2. The plan • Motivation and Introduction • Background • Suggested Technique • Optimization/Feeback ‘loop’ • Summary of Results • Discussion

  3. The Problem • 3-Tier Framework • Recall: The benefits of partial/full database replication in dynamic content (web) applications • We need to address some issues in the framework as presented in ‘Ganymed’ • Problem: • How many replicas do we allocate? • How do we take care of overload situations while maximizing utilization and minimizing the number of replicas? • Solution: • Dynamically (de)allocate replicas as needed

  4. Assumptions • Query Load: • Write queries are short, sweet and simple • Read queries are complex, costly and more frequent • Infrastructure: • Replica addition is time consuming and ‘expensive’ • Machines are flexible in nature • Replica Allocation vs. Replica Mapping • Assume an intelligent middleware is present

  5. Replica Allocation • Full overlapping allocation • All databases replicated across all machines in the cluster • Disjoint allocation (no overlapping) B A (A two database Scenario: Global replica pool not shown) RS = Read Sets, WS=Write Sets : Ratio of WS to RS may be misleading in the above diagram

  6. Partial Overlapping Allocation • Only share write sets. Read sets do not overlap B A (A two database scenario) RS = Read Sets, WS=Write Sets

  7. Dynamic Replication (Eurosys 2006 Slides) • Assume a cluster hosts 2 applications • App1 (Red) using 2 machines • App2 (Blue) using 2 machines • Assume App1 has a load spike

  8. Dynamic Replication • Choose # of replicas to allocate to App1 • Say, we adapt by allocating one more replica • Then, two options • App2 still uses two replicas (overlap replica sets) • App2 loses one replica (disjoint replica sets)

  9. Dynamic Replication • Choose # of replicas to allocate to App1 • Say, we adapt by allocating one more replica • Then, two options • App2 still uses two replicas (overlap replica sets) • App2 loses one replica (disjoint replica sets)

  10. Dynamic Replication • Choose # of replicas to allocate to App1 • Say, we adapt by allocating one more replica • Then, two options • App2 still uses two replicas (overlap replica sets) • App2 loses one replica (disjoint replica sets)

  11. Challenges • Adding a replica can take time • Bring replica up-to-date • Warm-up memory • Can avoid adaptation with fully-overlapped replica sets

  12. Challenges • However, overlapping applications compete for memory causing interference • Can avoid interference with disjoint replica sets

  13. Challenges • However, overlapping applications compete for memory causing interference • Can avoid interference with disjoint replica sets Tradeoff between adaptation delay and interference

  14. Our Solution – Partial Overlap • Reads of applications sent to disjoint replica sets • Avoids interference • Read-Set • Set of replicas where reads are sent

  15. Our Solution – Partial Overlap • Writes of apps also sent to overlapping replica sets • Reduces replica addition time • Write-Set • Set of replicas where writes are sent

  16. Optimization • For a given application, • Replicas in Write-Set – Fully Up-to-Date • Other Replicas – Periodic Batch Updates

  17. Secondary Implementation Details • Scheduler(s): • Separate read-only from read/write queries • One copy serializability is guaranteed • Optimization: • Scheduler also stores some cached information (queries, write sets etc,) to reduce warm-up/ready time. • Conflict awareness at the scheduler layer

  18. Replica Allocation Logic ? Stability Delay Measure Average Query Latency by solving: WL= (alpha)L + (1 – alpha) WL L is the current query latency and alpha a constant. Note: Responsiveness/stability both depend on alpha

  19. Results It works…

  20. One last interesting issue • WL= (alpha)L + (1 – alpha) WL • L is the current query latency and alpha a constant

  21. Discussion • Questionable Assumptions • Are write requests really (always) simple? • Scalability beyond 60 replicas (is it an issue?) • How closely does this represent a real data center situation? • Load contention issues • Overlap assignment • Determination of alpha(s) • Actual cost savings vs. Implied cost savings • Depends on SLA etc. • Depends on hardware leasing agreements • The issue of readiness in secondary replicas • What level of ‘warmth’ is good enough for each application. Can some machines be turned off? • What about contention in many databases trying to stay warm. • Management concerns • Can we truly provide strong guarantees for keeping our end of the SLA promised?

More Related