1. Predicting Replicated Database Scalability Sameh Elnikety, Microsoft Research Steven Dropsho, Google Inc. Emmanuel Cecchet, Univ. of Mass. Willy Zwaenepoel, EPFL

2. Environment –E-commerce website –DB throughput is 500 tps Is 5000 tps achievable? –Yes: use 10 replicas –Yes: use 16 replicas –No: faster machines needed How tx workload scales on replicated db? Motivation Single DBMS 2

3. Multi-Master Single-Master Replica 2 Replica 1 Replica 3 3 Slave 1 Master Slave 2

4. Background: Multi-Master Replica 2 Replica 1 Replica 3 Standalone DBMS Load Balancer 4

5. Read Tx Replica 2 Replica 1 Replica 3 Load Balancer T 5 Read tx does not change DB state

6. Update Tx Replica 2 Replica 1 Replica 3 Cert Load Balancer T wswswsws 6 Update tx changes DB state Update tx changes DB state

7. Additional Replica Replica 2 Replica 1 Replica 3 Load Balancer T ws Replica 3 7 Replica 4 Cert wsws

8. Standalone DBMS –Service demands Multi-master system –Service demands –Queuing model Experimental validation Coming Up … 8

9. Required –readonly tx: R –update tx: W Transaction load –readonly tx: R –update tx: W / (1 - A 1 ) Standalone DBMS Single DBMS Abort probability is A 1 Submit W / (1 - A 1 ) update tx Commited tx: W Aborted tx: W ∙ A 1 / (1- A 1 ) Abort probability is A 1 Submit W / (1 - A 1 ) update tx Commited tx: W Aborted tx: W ∙ A 1 / (1- A 1 ) 9

10. Standalone DBMS Single DBMS 10 Required –readonly tx: R –update tx: W Transaction load –readonly tx: R –update tx: W / (1 - A 1 )

11. Service Demand 11

12. Required (whole system of N replicas) –Readonly tx: N ∙ R –Update tx: N ∙ W Transaction load per replica –Readonly tx: R –Update tx: W / (1 - A N ) –Writeset: W ∙ (N - 1) Multi-Master with N Replicas 12

13. MM Service Demand 13 Explosive cost!

14. Compare: Standalone vs MM Explosive cost! 14 Standalone: Multi-Master:

15. Readonly Workload Explosive cost! 15 Standalone: Multi-Master:

16. Update Workload Explosive cost! 16 Standalone: Multi-Master:

17. Closed-Loop Queuing Model 17

18. Standard algorithm Iterates over the number of clients Inputs: –Number of clients –Service demand at service centers –Delay time at delay centers Outputs: –Response time –Throughput Mean Value Analysis (MVA) 18

19. Using the Model 19

20. Copy of database Log all txs, (Pr : Pw) Python script replays txs –Readonly (rc) –Updates (wc) Writesets –Instrument db with triggers –Play txs to log writesets –Play writesets (ws) Standalone Profiling (Offline) 20

21. MM Service Demand 21 Explosive cost!

22. Abort Probability Predicting abort probability is hard Single-master –No prediction needed –Measure offline on master Multi-master –Approximate using –Sensitivity analysis in the paper 22

23. Using the Model # clients, think time 1.5 ∙ fsync() 1 ms 23

24. Compare –Measured performance vs model predictions Environment –Linux cluster running PostgreSQL TPC-W workload –Browsing (5% update txs) –Shopping (20% update txs) –Ordering (50% update txs) RUBiS workload –Browsing (0% update txs) –Bidding (20% update txs) Experimental Validation 24

25. Multi-Master TPC-W Performance Throughput Response time 25

26. 26 Browsing, 5% u 15.7 X Ordering, 50% u 6.7 X 15%

27. Multi-Master RUBiS Performance Throughput Response time 27

28. 28 Browsing, 0% u 16 X bidding, 20% u 3.4 X

29. Database system –Snapshot isolation –No hotspots –Low abort rates Server system –Scalable server (no thrashing) Queuing model & MVA –Exponential distribution for service demands Model Assumptions 29

30. Models –Single-Master –Multi-Master Experimental results –TPC-W –RUBiS Sensitivity analysis –Abort rates –Certifier delay Checkout the Paper 30

31. Urgaonkar, Pacifici, Shenoy, Spreitzer, Tantawi. “An analytical model for multi-tier internet services and its applications.” Sigmetrics 2005. Related Work 31

32. Derived an analytical model –Predicts workload scalability Implemented replicated systems –Multi-master –Single-master Experimental validation –TPC-W –RUBiS –Throughput predictions match within 15% Conclusions 32

33. Questions? Danke Schön! 33 Predicting Replicated Database Scalability