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