1. Consistent Join Queries for Cloud Data Stores Zhou Wei 1,2 Guillaume Pierre 1, Chi-Hung Chi 2 1 VU University Amsterdam 2 Tsinghua University Beijing

2. Background Cloud Computing Platforms for Web Apps – Unlimited resources – Scalable NoSQL data stores – Pay-as-you-go

3. Problems of Cloud data stores Problem 1: No Join queries – Only support queries within a single table – No queries across tables Problem 2: Relaxed data consistency – Single-row transaction only – No consistency guarantee across multi-items Web apps need consistent join queries

4. Why Web App needs join? Data Normalization  Foreign-key Equi-joins PKTitleComment 1IPhoneCool 2IPhoneNice 3IPhoneExpensive Post PKTitle 1IPhone PKPost_idComment 11Cool 21Nice 31Expensive Post Comment

5. Why consistent? Application correctness is not an option Hard to maintain correctness with an inconsistent data store – Require skillful programmers – Error-Prone – Cost more time

6. Alternatives SQL databases – Centralized – Full Replication – NOT scalable to update workload – Complicated queries – ACID Transaction NoSQL data stores – Distributed – Partitioned – Scalable to update workload – No Join Queries – Single-row Transaction Google Bigtable Amazon SimpleDB Cassandra … Google Bigtable Amazon SimpleDB Cassandra … MySQL Oracle … MySQL Oracle …

7. Our Position Scalable NoSQL data stores supporting equi- joins queries for Web applications Join query as a ACID transaction Queries of Web applications access only a small portion of data – Also true for join queries – All of them are foreign-key equi-joins

8. How it works? 8 Web Application Cloud Data Store Load Data TM Checkpoint Transactions TM CloudTPS Join Queries

9. Outline Join Algorithm Transaction Protocol Performance Evaluation Conclusion

10. Join Algorithm Web applications are response-time sensitive – Table scan is not an option The basic idea – Linking records by FK relationships in advance – Each join query has well identified “root records” – Begin from accessing each “root record” – Recursively obtaining its related records

11. Link records for forward join PKFK 12 23 32 Comment PK 1 2 3 Post Given referring row  identify referenced row (FK)(PK)

12. Comment (1,3) 2 Link records for backward join PKFK 12 23 32 PK 1 2 3 Comment Post Give referenced row  identify referring rows (PK) (FK)

13. Joining two tables SELECT * FROM post, comment WHERE post.id = 1 and comment.post_id = post.id post comment id=1 post.id = comment.post_id

14. Multi-Joins The table of the “root record” is the root Recursively join child tables Length of critical execution path = 2 Post Comment Id=1 User Revision

15. Outline Join Algorithm Transaction Protocol Performance Evaluation Conclusion

16. Distributed Transaction TM RW-TC Data1 TM RW-TC Data2 TM RW-TC Data3 SubT(1) SubT(2) SubT(3) 2 Phase Commit (2PC)

17. Problem 2PC requires all records identified in advance Join queries/index management identify accessed records on the fly Solution: extend 2PC to allow adding records dynamically

18. The Original 2PC TC Data1 Data2 TC Data1 Data2 TC Data1 Data2 2. Vote3. Commit/Abort1. Submit

19. Extended 2PC Dynamically add data items to the transaction TC Data1 Data2 TC Data1 Data2 2. Vote 1. Submit CommitAdd Data3

20. Extended 2PC TC Data1 Data2 3. Derive Data3

21. Extended 2PC TC Data1 Data2 4. Vote Data3 Commit

22. Extended 2PC TC Data1 Data2 5. Commit Data3

23. Outline Join Algorithm Transaction Protocol Performance Evaluation Conclusion

24. Experiment Setup Implement a prototype of CloudTPS – Java Servlet – Deployed in Tomcat v6.0 Environments – 1. Das3+Hbase+Tomcat (99% reqs < 100ms) – 2. EC2+SimpleDB+Tomcat (90% reqs < 100ms) High-CPU medium instances

25. Micro-benchmarks Generate specific workload – Containing only Join queries/RW transactions – Changing the number of accessed data items – Changing the length of critical execution path – Switch between Update indexes/Not update All configured with 10 CloudTPS nodes Measuring maximum sustainable throughput – Under response time constraint

26. Two-table join evaluation Transaction Per SecondRecord Per Second Increasing number of accessed records in a transaction

27. Multi-Joins Evaluation Increasing the height of join-query tree All join queries access 12 records

28. RW transactions evaluation Transaction Per SecondRecord Per Second Increasing number of accessed records in a transaction

29. Scalability Evaluation Macro-Benchmark – Derived from TPC-W, simulating an online book store – Our workload includes only the join queries and RW transactions – No simple queries

30. Scalability Results Linearly Scalability: Any increase of workload can be addressed by adding more machines

31. CloudTPS vs. Postgresql Postgresql: binary-replication

32. Fault Tolerance Recovers from 3 network partitions and 2 machine failures

33. Conclusion We demonstrate supporting consistent join queries over partitioned and distributed data Join queries from Web applications only access a small portion of data It scales linearly even under an intensive workload of only join queries and read-write transactions

34. Questions? Thank you!

35. Details in Macro-benchmark workload Join queriesRW transactions

36. PKSK 1A 2B 3B Secondary-key Queries Select * from Table1 Where SK = ‘B’ Create a separate index table for the SK Translate into a join query Table 1 Index Table PK’(SK) T1 A1 B2,3

37. Index Management Indexes link the related records PKTitle 1Hello 2Good 3Well PKFK 11 21 32 post comment T1 1,2 3 -

38. Index Management (cont.) Case: a new comment inserted Updating indexes atomically PKTitle 1Hello 2Good 3Well PKFK 11 21 32 42 post comment T1 1,2 3, 4 -

39. Index Management (cont.) Consistency Violated Case 1 PKTitle 1Hello 2Good 3Well PKFK 11 21 32 42 post comment T1 1,2 3 - Index

40. Index Management (cont.) Consistency Violated Case 2 PKTitle 1Hello 2Good 3OK PKFK 11 21 32 post comment T1 1,2 3, 4 - Index

41. Fault tolerance Maintain ACID during server failure – Transactions that reach an agreement of “COMMIT” should Commit – Abort other transactions Replication to N transaction managers – Values of Data Items – States of Transactions (Vote result and “redo logs”) Failover of a failed server – Transfer ownership of data items – Transfer leadership of transactions being coordinated

42. Optimization for Join Queries Join Query is a Read-only transaction – Remove the final Commit phase – Sub-transactions removed immediately after local execution – RO transactions will not block other transactions

43. Concurrency Control 43 Data1 SubT(1) 5 5 Timestamp Ordering Data2 SubT(2) 5 5

44. Read-Only Transaction Data1 ROSubT(1) SubT(1) 5 5 Data2 SubT(2) 5 5 TM RW-TC Data3 RO-TC Join(Data1) TM SubT(1) 7 7

45. Read-Only Transaction (Cont.) Data1 ROSubT(1) Data2 TM RW-TC Data3 RO-TC Join(Data1) TM Data2 SubT(1) 7 7

46. Read-only Transaction (cont.) Data2 TM RW-TC Data3 RO-TC TM None ROSubT(2) Result Data1 SubT(1) 7 7