Scaling Dynamic Content Applications through Data Replication - Opportunities for Compiler Optimizations Cristiana Amza UofT

2 Dynamic Content is Ubiquitous 1 2 3

3 We focus on scaling the database Dynamic Content Web Sites 3-tier: Web Server, Application Server, Database Query Response HTTP Request HTML Page Web Server Database Server App Server

4 Common Scaling Solution Query Response HTTP Request HTML Page Web ServerApp Server SMP Database Server

5 Alternative: Database Cluster Read-one, write all replication Cluster of Database Servers Query Response HTTP Request HTML Page Web ServerApp Server

6 Where to Implement? Web Server Scheduler App Server Query Response Query Response Cluster of Database Servers

7 Problem: Conflict Ordering Bestseller book Consistent order for conflicting transactions (Same client buys the book on all replicas) Buy Query Response Cluster of Database Servers

8 Synchronous (Eager) Replication Web Server Scheduler App Server Query Response Cluster of Database Servers Write Does not perform well

9 Our Asynchronous Solution Web Server Scheduler App Server Query Response Cluster of Database Servers Write

10 Our Asynchronous Solution Web Server Scheduler App Server Query Response Cluster of Database Servers How about conflict ordering ?

11 Idea: Application Code Known begin-transaction write a write b write c commit-transaction

12 Make Conflicts Explicit begin-transaction use a, b, c write a last-use a write b last-use b write c commit-transaction (Could be automated by compiler)

13 Order Conflicts  Scheduler assigns versions at “use” table declaration  Atomic (per transaction)  Per table  If conflict, assign a higher version number

14 Execution Rules  Enforced by database proxy at each query  Wait for appropriate version of tables to be produced  Versions are produced At commit/abort At last-use

15 How It Works begin use a, b, c  get versions e.g., (0, 0, 0) write a write b write c commit T0: a0, b0, c0 T1: a1, b1, c1

16 Order-placement begin orders, order_line, item, customer, credit_card insert new order in orders for all items in shopping_cart { insert order in order_line adjust item.stock field in item } find customer insert info in credit_card commit

17 Annotated Order-placement begin orders, order_line, item, customer, credit_card insert new order in orders table release orders for all items in shopping_cart insert order in order_line release order_line for all items in shopping_cart adjust item.stock field in item release item find customer release customer insert info in credit_card commit

18 Refine “Object” Granularity begin orders.*, order_line.*, item.stock, customer.* … insert new order in orders table release orders.* for all items in shopping_cart insert order in order_line release order_line.* for all items in shopping_cart adjust item.stock field in item release item.stock find customer release customer.* insert info in credit_card commit

19 Value Flow Analysis Known argument values for program BestSellers.php ? Category=“KIDS” Infer values of query fields Bestseller transaction on category = “KIDS” is disjoint from book order in category = “SPORTS”

20 Dependences $var = SELECT … SELECT …. WHERE … = $var

21 Other Applications for Optimizations Transparent Caching Determine if an update transaction should invalidate a cached query response Scheduler Database server App Server Query Response Query Response

22 Comparison to Eager

23 TPC-W Benchmark  Models an on-line book store  Three standard workloads (differ in % of writes) browsing (5%), shopping (20%) ordering (50%)  Application size: 4 GB

24 Comparison to Eager

25 Comparison to Eager

26 Comparison to Loose Consistency Methods

27 Conclusions  1-copy SR can be implemented with good performance  Key ingredients: asynchrony and conflict reduction  Looser consistency models needed only for (very) write- heavy workloads

28 Consistency & Lazy Replication L4 Switch Schedulers LOCK WR RD LOCK Seq SN SN LOCK Async writes  scaling Conflict ordering  consistency Conflict ? Order SN Web/App serversDatabase engines

29 Experimental Environment  Software Apache + PHP, MySQL  Hardware Athlon 800 Mhz, 256 MB RAM, Fast Ethernet  Implementation: on 8 replicas  Simulation: for up to 60 databases Calibrated against prototype