Transcript Document

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?