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

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

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

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

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

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

Test Results (continued)

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

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?

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

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)

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

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?