Transaction management for a main memory database
Download as PPTX, PDF0 likes623 views
This document describes an experiment testing the performance of a main-memory database using physical memory as primary storage and disk as backup. Various tests were run involving 1,000 transactions across 80 database extents, with the transactions consisting of either 1 operation or 1-5 operations. The tests varied the percentage of updates versus queries from 0% to 98% updates. Metrics like transaction throughput, wait times, and deadlocks were measured. The results showed transaction waits and deadlocks increased with higher percentages of updates, while throughput was promising at over 200 transactions per second for single-operation transactions.
Transaction management for a main memory database
- 1. P. Burte, B. Aleman-Meza, D. Brent Weatherly, Rong Wu University of Georgia May 06, 2006 Repsented by :Mohamed Zeinelabdeen
- 2. • In traditional database systems rely on the disk subsystem to retrieve and update data and use an offline storage device such as magnetic tape for backup. • In this experiment, a main-memory database will use physical memory as primary storage and a disk subsystem for backup. • A Java object, class Transaction, encapsulates all operations that are accessible by a database transaction.
- 3. • The data set used for testing had 80 different extents. A total of 1,000 Transactions were run via 1,000 threads (one transaction per thread). • Each Transaction executed a fixed number of operations on each set of tests , each operation involves a single extent, which is chosen randomly from the 80 possibilities. • Each set of tests was run with different percentages of updates/queries.
- 4. The different percentages tested were: ◦ 0% updates, 100% queries . ◦ 20% updates, 80% queries. ◦ 40% updates, 60% queries. ◦ 60% updates, 40% queries. ◦ 80% updates, 20% queries. ◦ 98% updates, 2% queries . For each of these tests, the following information was recorded: ◦ time taken for completion of all the transactions. ◦ average number of times a transaction needed to wait for an extent used by other transaction. ◦ number of transactions aborted because of a detected Deadlock . Each of the tests was run several times to in order to obtain an average for each value.
- 5. Transaction performance is measured in two areas: the throughput for transaction completion. the average number of times a transaction goes to 'wait' state because it is unable to obtain a lock on a resource.
- 6. Transaction throughput is measured by taking the total number of transactions attempted, subtracting the number of transactions that were aborted because of deadlock, and dividing by the time required to complete the test.
- 8. • For the set of tests executing only one operation per transaction, the number of wait-states increased slowly for percentages of updates under 60%. • For percentages of updates over 60%, the number of wait-states increased rapidly. • For the set of tests executing 1 to 5 operations per transaction, the number of wait-states increased with the percentage of updates increasing.
- 10. for deadlock detection, the test results were as expected. The number of aborted transactions because of a detected deadlock increases as the percentage of updates increases. no deadlock occurs if all transactions contain a single operation on a single extent.
- 12. From this experiment, Inferred performance tests show our implementation is promising an average throughput of two hundred and thirty transactions per second for a thousand single-operation transactions is a good start.