1 / 38

Improving the Performance of Read-only Transactions Through Asynchronous Speculation

Improving the Performance of Read-only Transactions Through Asynchronous Speculation. T. Ragunathan and P. Krishna Reddy. International Institute of Information Technology (IIIT-H), Hyderabad, India E-mail: pkreddy@iiit.ac.in. Outline. Introduction and issues 2PL and SI-based Protocols

aulani
Download Presentation

Improving the Performance of Read-only Transactions Through Asynchronous Speculation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Improving the Performance of Read-only Transactions Through Asynchronous Speculation T. Ragunathan and P. Krishna Reddy • International Institute of Information Technology (IIIT-H), Hyderabad, India • E-mail: pkreddy@iiit.ac.in

  2. Outline • Introduction and issues • 2PL and SI-based Protocols • Overview of Speculative Locking • Speculative Locking for Read-only Transactions • Simulation results • Related Work • Conclusions and Future Work

  3. Introduction.. • Modern web-based information systems should meet intensive information requirements from large number of users. • Must exploit cost-effective processing power • Possibilities of parallel processing should be identified. • In this paper we investigate the issue of improving the performance of read-only transactions by increasing parallelism and exploiting cost-effective processing power.

  4. Introduction.. • Information systems frequently execute read-only transactions or queries. • Two-phase locking • lacks the power of meeting growing throughput demand. • performance degrades with data contention. • Snapshot-isolation-based protocol improves performance over 2PL. • Suffers from data currency issues • Correctness is compromised.

  5. Introduction • In the literature, speculative locking is proposed to improve the parallelism by exploiting the low cost processing power. • A transaction carries out multiple executions under speculation • It has been shown that speculation improves performance over two-phase locking for OLTP workloads. • In this paper we have extended speculative locking protocol for ROTs (SLR) by carrying out executions in asynchronous mode • It improves the performance over ROTs. • Trades performance with extra processing resources • Does not violate serializability criteria • No data currency related issues

  6. Issues for Processing ROTs • Performance • High throughput performance • Correctness • Serializability criteria: The execution of transactions should be equivalent to a serial execution. • Data currency • “The data currency of the data object provided to Ti is the value of “t” which is the time difference between the commit time of the transaction which created the latest version of the data object and the commit time of the transaction which created the version of that data object that was read by Ti. If “t” is less/more, it means that transactions are provided with high/low data currency.”. • Example: cricket score

  7. Outline • Introduction and issues • 2PL and SI-based Protocols • Overview of Speculative Locking • Speculative Locking for Read-only Transactions • Simulation results • Related Work • Conclusions and Future Work

  8. Two-Phase locking • Processes transactions at serializable-isolation level • No data currency related issues • Under 2PL, the performance of ROTs degrades with data contention. • ROTs wait for UTs.

  9. Snapshot-Isolation (SI) based protocol • SI-based protocol is a popular protocol • An ROT reads snapshot of the (committed) data. • Ignores the effect of concurrent UTs. • An ROT running at SI is never blocked. • High performance • Data currency is compromised • Violates serializability criteria

  10. Outline • Introduction and issues • 2PL and SI-based Protocols • Overview of Speculative Locking • Speculative Locking for Read-only Transactions • Simulation results • Related Work • Conclusions and Future Work

  11. Speculative Locking Protocol • Normally, a transaction starts producing after-images at the earlier stage of its execution. • Though these after-image values are not effected during remaining processing, the transaction releases locks only after commit processing. • In speculative approach, the transaction releases locks on a data object whenever it produces corresponding after-image value. • By accessing both before- and after-images, the waiting transaction carries out speculative executions. • A transaction commits only after receiving termination decisions of the preceding transactions.

  12. In case of 2PL, it can be observed that even though T1 updates X at earlier stage of execution, it releases the lock only after commit processing. In case of speculative approach, on completion of final update operation on X by T1, T2 reads both X and X´ and carries out speculative executions. T2 commits only after the termination of T1. If T1 commits , T22 is retained; otherwise T21 is retained. T1 releases lock on X T1 completes work on X T1: r1[X] w1[X'] r1[Y] w1[Y'] e1 c1 s1 T2: r2[X] w2[X'] r2[Z] w2[Z'] c2 s2 e2 time (i) 2PL T1: r1[X] w1[X'] r1[Y] w1[Y'] e1 c1 s1 T21 r2[X] w2[X"] r2[Z] w2[Z'] T2: s2 c2 e2 T22 r2[X'] w2[X"'] r2[Z] w2[Z"] time (ii) SL Speculative locking: Example

  13. SL family of protocols • In the literature, it has been shown that SL can improve the performance by trading extra resources in distributed environments. • A family of SL protocols, SL(n), SL(1), and SL(2) are proposed. • In SL(1) the number of speculative execution increases linearly with data contention. • SL protocol produces serializable executions. • The number of speculative executions explode with data contention.

  14. Outline • Introduction • 2PL and SI-based Protocols • Basic Speculative Locking Protocol • Asynchronous Speculative Locking protocol for Read-only Transactions • Performance Evaluation • Related Work • Conclusions and Future Work

  15. Speculative Locking for ROTs (SLR): Basic Idea • In the literature, speculative locking is proposed to process update transactions (UTs). • UTs contain both read and write operations. • In SL, whenever a UT carries out write operation, it produces new uncommitted versions which are added to the data object trees. • Observation: Write operations are the cause for the generation of new uncommitted versions which in turn increase speculative executions. • Regarding ROTs • ROTs only read data. • ROTs can commit at any time • So, if we process only ROTs with speculation, performance can be improved with less number of additional resources.

  16. Basic idea to improve performance of ROTswith speculation • Process update transactions with two-phase locking (2PL) • Update transactions release the locks whenever it completes execution. • ROTs are processed with speculation.

  17. Straightforward Extension of Speculation to ROT • Synchronous SL for ROT • Update Transactions are processed with 2PL. • Whenever UT produces after-images, ROT reads both before- and after-images and carries out speculative executions. • An ROT waits till the preceding transaction produces after-image to carry out speculative executions.

  18. Synchronous Speculation: Example(T1 and T3 are UTs and T2 is ROT)

  19. Proposed Method:Asynchronous Speculation to Process ROTs • The speculative executions of ROTs can be processed in an asynchronous fashion or independent manner. • An ROT does not wait for after-image. • The ROT is allowed to access the available data object versions and carry out speculative executions. • Whenever preceding transaction produces after-image, further speculative executions can be started in a dynamic manner. • In SLR, an ROT commits whenever it completes execution by retaining appropriate execution without waiting for the preceding transactions. • Parallelism improves as compared to synchronous SL and 2PL

  20. Asynchronous Speculation: Example time

  21. Asynchronous SpeculationLock compatibility matrix

  22. ASLR – correctness • Three types of conflicts can occur: - RW conflict - WW conflict - WR conflict. • Regarding RW conflict, a conflicting UT has to wait for the commitment of ROT to obtain the lock as per 2PL rule. So, all the RW conflicts are captured with ASLR. • WW conflicts happen among UTs only. UTs follow 2PL. • WR conflicts force ROT to do speculative executions. The ROT commits with the execution which has taken only committed values of UTs. So WR conflict is captured. • So, ASLR captures all the conflicts and ensures that serialization graph is acyclic. So, the history produced by ASLR is serializable.

  23. Outline • Introduction • 2PL and SI-based Protocols • Basic Speculative Locking Protocol • Speculative Locking protocol for Read-only Transactions • Performance Evaluation • Related Work • Conclusions and Future Work

  24. Simulation Model • Discrete event simulator based on a closed-queuing model is developed. • DB SIZE= 1000 • Transactions • ROTs (15-20) • UTs (5-15) • CPU time- 5 ms, IO Time – 10ms • We have compared 2PL, SL, ASLR, SI-2PL and FCWR protocols.

  25. Table 1. Simulation Parameters, Meaning and Values

  26. Performance Metrics • Throughput # of transactions completed per second • CPU Utilization Let ‘c’ and ‘t’ denote CPU idle time and total simulation time respectively. Then, CPU utilization = 100(1 – (c/t)).

  27. Performance results under unlimited resources

  28. MPL vs Throughput • Performance of ASLR is significantly higher than that of 2PL and FCWR, SI2PL. • FCWR and SI2PL suffers from correctness • ASLR performance is superior to SL.

  29. Details of Speculative Executions • The average number of speculative executions: SL= 4.2 and ASLR=1.5

  30. MPL versus CPU Utilization

  31. Performance results under limited resources

  32. Throughput Performance

  33. Implementation issues • Pre-compiling. - A software module is required to put lock conversion marker. - During execution, when the lock conversion marker is encountered, the EW-lock on the data object is converted into the SPW-lock. • Speculative executions. - We have assumed that speculative executions of a transaction are carried out in parallel by considering multi-processor (multi-core) environment.

  34. Comparison of ASLR,SL, 2PL and FCWR

  35. Outline • Introduction • 2PL and SI-based Protocols • Basic Speculative Locking Protocol • Asynchronous speculative locking protocol for read-only transactions. • Performance Evaluation • Related Work • Conclusions and Future Work

  36. Related Work • Four isolation levels are specified in ANSI/ISO SQL-92 standard • read uncommitted, read committed, repeatable read, and serializable. • Snapshot Isolation • Serializability Violation • Low Data Currency Problem • Recently Alan Fekete (ACM June 2005) has made an effort to make SI serilaizable by modifying the program logic. Also he works on automating the task of modifying the program (VLDB 2007). • Speculation has been extended to improve the performance of distributed database systems

  37. Outline • Introduction • 2PL and SI-based Protocols • Basic Speculative Locking Protocol • Synchronous speculative locking protocol for read-only transactions • Asynchronous speculative locking protocol for read-only transactions. • Performance Evaluation • Related Work • Conclusions and Future Work

  38. Conclusions and Future work • Proposed improved protocol for ROTs based on asynchronous speculation. • Improves the performance significantly over 2PL and SI-based protocols. • Improves data currency over SI-based protocols. • Requires manageable extra processing resources. • Future work • Investigation in distributed database environment • Investigating for real-time read-only transactions.

More Related