1. Towards a Non-2PC Transaction Management in Distributed Database Systems Qian Lin, Pengfei Chang, Gang Chen, Beng Chin Ooi, Kian-Lee Tan, Zhengkui Wang

2. Scaling Up vs. Scaling Out Scale In-memory OLTP Systems 1

3. Processing Distributed Transactions Distributed transaction –Accessing data spread over multiple nodes –Opp. to local transaction Traditionally, a distributed transaction is decomposed into multiple sub-transactions w.r.t. data partitioning –Each sub-transaction is sent to the corresponding data- residing node for local execution –For distributed consensus, the two-phase commit (2PC) protocol is used to conduct commit/abort of a distributed transaction w.r.t. its sub-transactions 2

4. 2PC-Based Distributed Txn Processing However, the use of the 2PC protocol greatly degrades the performance of distributed transaction processing –Complicating the commit procedure –Constraining data locality to be agnostic CoordinatorParticipant Prepare 2) Query to commit Prepare / Abort 3) Vote Yes/No Commit / Abort 4) Send commit/abort Commit / Abort 5) Acknowledgment End Task Distribution Atomic Commit 3

5. Processing Distributed Txns: The LEAP Way The LEAP protocol –Localizing Executions via Aggressive Placement of data –Idea: convert a distributed transaction into a local transaction by aggressively placing all cross-node data needed for the transaction on a single node that executes the transaction CoordinatorParticipant 4

6. Motivation of the LEAP Design Anticipation and key observations –Wide availability of modern fast networks –OLTP queries typically involve only a small number of data records –Depending on applications, the data record size may be comparable with the size of a sub-transaction –Data access in real-world distributed transactions typically exhibits some form of locality 5

7. Managing Ownership and Data Placement Owner Table Data Table Owner Table Data Table 6

8. Ownership Transfer Requester: requesting a data record Partitioner: holding the ownership information of the data record Owner: storing the actual data record Requester & Partitioner Owner transfer request response Requester Partitioner & Owner owner request response inform Requester Partitioner owner request response Owner transfer request inform (a) RP-O. (b) R-PO.(c) R-P-O. 7

9. LEAP-Based OLTP Engine Concurrency control –Directory-based cache coherency –Wait-Die policy for deadlock prevention Application Layer Txn Engine Storage Engine Node Mgnt Application Layer Txn Engine Storage Engine Node Mgnt... Distributed In-Memory Storage Multi-threading 8

10. Performance Evaluation L-Store: a LEAP-Based OLTP engine H-Store: a distributed in-memory OLTP system –Relying on 2PC for processing distributed transactions –Single-threaded transaction processing for each partition* H L -Store: a variant of H-Store –Replacing the 2PC-based distributed transaction processing with the LEAP-based one –Retaining the single-threaded processing model Workload –TPC-C (New-Order + Payment) 9 * With the single-threaded model, a node containing multiple partitions runs mul- tiple threads, whose number is equal to the number of partitions in the node.

11. Impact of Distributed Transactions 10 Along the increment of remote data accesses, the through- put of LEAP-based transaction processing decreases at a much slower rate than that of the 2PC-based one. Ownership Transfer System Throughput Distributed Transactions R-P-O of ownership transfer is most expensive comparing with RP-O and R-PO.

12. Impact of Locality of Remote Data Access With higher level of locality of remote data access, a data record migrated to a new node is more likely to be reaccessed by the transactions in that node. 11 ThroughputOwnership Transfer In LEAP, high locality of remote data access benefits high possibility of trivially turning a remote data access into a local data access without issuing any remote request. The rise of locality decreases the amount of ownership transfer, especially those of R-P-O.

13. Scalability LEAP-based transaction processing is highly scalable when the cluster memory is sufficient. 12 Over NodesOver database sizes

14. Summary Why not 2PC? –Overhead of preserving distributed consensus is expensive The LEAP protocol –Converting a distributed transaction into a local transaction through data migration LEAP-based transaction processing –Efficient and scalable (in anticipation of modern fast networks) 13