Transaction management for a main memory database

615 views
493 views

Published on

Published in: Technology, Real Estate
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
615
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transaction management for a main memory database

  1. 1. P. Burte, B. Aleman-Meza, D. Brent Weatherly, Rong Wu University of Georgia May 06, 2006Repsented by :Mohamed Zeinelabdeen
  2. 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. 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. 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. 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. 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.
  7. 7. • 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.
  8. 8.  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.
  9. 9.  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.

×