Transcript 下載/瀏覽
Transaction reordering
Speaker :Po-Hung Lai
Adviser : Chih-Hung Lin
Date :2011.1.4
1
Outline
Introduction
Transaction reordering framework
Method
Experiment
conclusion
2
Introduction
Traditional :allows a certain number of complex queries
a crash
focus on the current system status
Our :information about the interaction
wait run
current system status
3
Introduction
Why transaction reordering be effective
– system independent
eliminates some intrinsic lock conflicts
– system dependent
4
Introduction
Advantage/ flaw
inside
outside
Advantage :
current state of the system
Don’t change database engine
synchronized scans
more opportunities for
reordering
Flaw :
Need set system and reorder
model
System will be miss transaction
an additional parsing of each
transaction
5
Introduction
general transaction reordering framework
– current system status
– queued and running transactions
6
Introduction
reordering algorithms
– Run all the transactions
– Analyze and record transactions
7
Introduction
Our reordering algorithms
– Luck conflicts
– buffer pool
8
Transaction reordering framework
Two method to increase the transaction throughput:
– increasing concurrency
preventing conflicting transactions
– sharing resources
No deadlock
Purpose
– improve RDBMS performance
9
Our method
typical operational data warehouse [16]
– OLTP data warehouse
(Operational Load Transaction Process)
– Acknowledge client input something
– Ensuring data’s durability
Fig :operational data warehouse
10
Our method
loading data continuously into an RDBMS
Files 、 message 、 queues …
11
Our method
Continuous load utilities definition
– ([20]Oracle,[6]Teradata)
– like RDBMS series of transactions
– free to arbitrarily group
free to arbitrarily group Characteristic
– It’s not anomalies
12
Our method
applications tolerate such anomalies
Ex 刪除記錄後 紀錄表
尚未更新記錄前
交易隨即移動走
使其發生之異常
13
Our method
application ensures not allow such
anomalies
ex 在新增交易
資料完成之前
不允許做任何
動作
14
Our method
Increase concurrency
Files 、 message 、 queues …
15
Our method
Materialized view maintenance
– Important class of Materialized view call join
view
Deadluck occur
– because
allow data load into multiple relations
RDBMS’s data as up-tpdate
JV is defined on multiple base relations
16
Our method
Deadluck probability
– k > 1 concurrent
p(1
transactions
– n modification operations
– p = A’s probability
– P-1 = B’s probability
– S = totally
S >> kn
p)( k 1)n /( 2s)
2
17
Our method
Example
– p = 50%,k = 8,n = 32 and s = 10000
– Deadluck probability = 9%
– n = 64 , Deadluck probability = 36%
18
Our method
Solution follow as rule
– data can only be loaded into one base relation
of JV
– Modification operations
– uses a high concurrency locking protocol
19
Our method
we schedule transactions as follows
– Action 1
20
Our method
– Action 2
21
Our method
– Action 3
– schedule a transaction to the RDBMS
desirable transaction T or first transactions
starvation problem
– Use timestamp(TS) to solution
– give pointer r ; r = 0 ; (0<=r<=k)
22
Our method
Situation
– Qm (1<=m<=k) is empty ,r = 0
– Anytime r =0; transaction coming Qm r = m
– r = m ; first transaction leave ; r = r+1
if (m = k, r =1)
v = r last number ; TS is pre-defined
– If v > ts then Qv transaction become first
23
Our method
24
Our method
buffer pool analysis
– buffer management methods cannot utilize the
synchronized scan technique efficiently
– solution to this problem
synchronized scan technique
25
Our method
lower RDBMS’s capability problem
26
Our method
lower RDBMS’s capability problem
– involve full table scans
27
Our method
Solution : synchronized scan technique
28
Our method
Our method
– addition K1 buffer;
Hold recent resource
– DS ;
Record T1 need all resource
– fast scan; slow scan
29
Our method
T2 start can check DB
30
Our method
T2 start scan
31
Our method
Defect
– t1 doing transaction
– t2 transaction end
– New transaction can’t enter share resource
32
Our method
Improve
– Applying transaction reordering
Technique1 maintain hash table (HT) and find
desirable transaction
Technique2 new transaction , check DS
Propose
– improve the throughput
– economize I/O resource
33
experiment
IBM DB2
– Concurrency
deadlock probability and throughput testing results
– deadlock probability. Fig. 5 and 6
P =50% ; s=10000 ; n=1 to 128 ; K =2 or 4 or 6
or 8
34
experiment
Ex
P =50% ; s=10000 ; n=64 ; K =2
Deadluck probability = 5%
35
experiment
Predicted deadlock probability
of the naive method
Measured deadlock probability of the naive
method
36
experiment
Throughput of the naive method
Throughput of the reordering
method
37
experiment
throughput
Naive’
Naive’
probability throughput
Reorder
Reorder
probability throughput
deadluck bad
Bad
Good
good
No
Similer
deadluck Reorder
Similer
Reorder
Similer
Naive
Similer
Naive
38
experiment
Data ratio test results
– K=16; n=64; p=50%; s= 5000 to 20000
– Fig10
39
experiment
Data ratio test results
– throughput of Reprdering and naive
40
experiment
Transaction ratio test results
41
conclusion
Improve the performance of an RDBMS
Combine running transaction and wait
transaction
Predict the occurrence of deadlock
42