1. Ganymed: Scalable Replication for Transactional Web Applications
Christian Plattner and Gustavo Alonso
Presented by Ahmed Ataullah

2. Background and Motivation
Is replication avoidable?
Is our choice limited only to eager or lazy solutions?
Or a mix of both..

3. What is Ganymed? One master copy, several slave copies
Middleware and scheduling algorithm
Key Idea: Separate the read-only and update requests
Assumption: Incoming requests are a “reasonable” mix of update and read-only transactions

4. Scheduling Algorithm (RSI-PC)
Read-only requests sent to any ‘available’ copy
Update requests sent directly to the master copy
Global database version number incremented after each update
Writesets sent to all slaves after completion

5. Ganymed Architecture
“…Ganymed resembles more a router than a scheduler.”

6. Test Results
Change from GNY-1 to GNY-2 configuration is perhaps interesting…

7. Test Results (continued)

8. Reliability Concerns What if a replica fails?
What if the master database fails?
What if the scheduler(s) fail?

9. Other concerns…
Is the assumption of balanced query load a fair one to make?
What if most queries are update queries?
At What point does the master copy become the bottleneck?
Can the scheduler become the bottleneck?

10. Other concerns (continued)
What about disconnected (or mobile) replicas?
Serializablilty, freshness etc…
Others Issues?

11. Improvement ideas… Have two master-copies working together
Dynamically Increase/decrease number of master copies with respect to update load
Khuzaima Daudjee and Kenneth Salem (Waterloo)

12. Improvement ideas (continued)
Have two scheduling points
What if the connection between the two points is unreliable?
Improving the RSI-PC algorithm without degrading the performance

13. Conclusion Gynamed presents a neat idea
Separate read-only and update transactions and exploit the properties of the expected query load
Subsequent work has improved the concept substantially.
Questions and Comments?