Pangea: An Eager Database Replication Middleware guaranteeing Snapshot Isolation without Modification of Database Server

1. Pangea: An Eager Database Replication Middleware guaranteeing Snapshot Isolationwithout Modification of Database Servers 2009.8.27 The University of Tokyo Takeshi MISHIMA and Hiroshi NAKAMURA

2. Introduction • Several database replication approaches have been proposed • Is database replication a solved problem? • No! Few approaches are cost-effective • Most database replication approaches need to modify database servers • The code is large and complex: too expensive replication functionalities database servers (replicas)

3. Introduction • Several database replication approaches have been proposed • Is database replication a solved problem? • No! Few approaches are cost-effective • Most database replication approaches need to modify database servers • The code is large and complex: too expensive replication functionalities low cost middleware flexibility maintenancability database servers (replicas)

4. Serial execution decreases the performance bottleneck Disadvantages of existing lazy replication middlewares Ri Wj Wj Wj Wi Wi Wi Rj middleware master slave slave

5. Disadvantages of existing eager replication middlewares Non-conflicting write operation cannot be executed concurrently Table-level lock Wk Wi Wi Wi middleware Table-level locking decreases the performance

6. Our proposal • Pangea: a new eager replication middleware • Guarantees snapshot isolation (SI) • Provides tuple-level concurrency control Assumption Wi and Wj conflict Wk does not conflict Wj Wj Wj Wi Wi Wi Wk Wk Wk Wi Wi Wi Wj Wj Wj sequentially sequentially sequentially Creates the same snapshot Wi, Wk Wi, Wk Wi, Wk Pangea concurrently concurrently concurrently Challenge 1 Challenge 2

7. Challenge 1: creation of the same snapshot • Database servers do not have the functionalityto create the same snapshot in a synchronized fashion. Challenge 1: How can Pangea create the same snapshot? Different snapshot Consistency is destroyed Pangea

8. Recap: snapshot creation • When is a snapshot created? • When is a database changed? Ti: Ri Wi Ci Ti’s snapshot

9. Recap: snapshot creation • When is a snapshot created? • When the first operation is executed • When is a database changed? • When the transaction commits Ti: Ri Wi Ci Ti’s snapshot

10. Recap: a version of a snapshot Ci F F F F F F Ci → F F → Ci same same If the relative order of the first and commit operations is the same, we get the same snapshot. time D1 D2 database snapshot

11. Algorithm 1: the same snapshot creation Pangea regulates the relative order of the first and commit operations Cm Cm Cm Cm Fk Fk Fk Cj Cj Cj Ci Ci Ci Pangea ack ack ack ack ack ack ack ack ack

12. Challenge 2: execution of non-conflicting and conflicting writes • To provide high performance with keeping consistency • Conflicting write operation • Executed in the same order serially (to keep consistency) • Non-conflicting write operation • Executed concurrently (to provide higher performance) • ex. • UPDATE table SET a = 1 WHERE b=1 • UPDATE table SET a = 2 WHERE c=2 Challenge 2: How can Pangea distinguish non-conflicting writes from conflicting ones? ※All existing eager replication middlewares can not distinguish them, and all writes must be executed serially. Conflict or non-conflict?

13. Blocked Recap: the first updater wins rule The first updater can progress, but the others have to wait for completion of the first updater’s transaction Wj Wi Assumption Wi and Wj conflict ack Execution order Wj Wi

14. Algorithm 2: execution of non-conflicting and conflicting writes Wj Wj Wj Wi Wi Wi Pangea Wk Wk Wk Assumption Wi and Wj conflict Wk does not conflict Wi Wi Wi Wj Wj Wj sequentially sequentially sequentially ack ack follower leader follower Wi, Wk Wi, Wk Wi, Wk concurrently concurrently concurrently

15. simple Higher performance Avoids a bottleneck Guarantees SI Summary: Pangea protocol • The first operation, commit operation (Algorithm 1) • Mutual exclusion (This guarantees all replicas create the same snapshot) • Write operation (Algorithm 2) • Sends it only to the leader • sends it to all followers after receiving an ack (This provides tuple-level concurrency control) • Read operation • Sends it to any slave replica unlike lazy replication (This reduces the load of the leader) ※See the proof in our paper

16. Evaluation • TPC-W benchmark • Scaling parameters: 1 million items and 2.88 million customers • Comparing • Pangea • LRM (Lazy Replication Middleware) Implemented the algorithm of Ganymed [17] • Prototype • Less than 2000 lines in C language • PostgreSQL servers: version 8.3.7 • Tomcat: version 6.0.18

17. Performance (browsing mix) 110%

18. Performance (shopping mix) 210%

19. Performance (ordering mix) 165%

20. Conclusions • Pangea, a new eager database replication middleware • Guarantees SI • Provides tuple-level concurrency control • Need not modify existing database servers • Prototype: The code size is very small • Experimental results • Provides higher performance • Practical, effective middleware

21. Thank you