Our Framework 2.1. Enforcing Temporal Consistency by Post Processing
Maintaining Logical and Temporal Consistency in RT Embedded Database Systems
description
Transcript of Maintaining Logical and Temporal Consistency in RT Embedded Database Systems
1
Maintaining Logical and Temporal Consistency
in RT Embedded Database Systems
Krithi Ramamritham
2
Overview• Motivation
• Problems in real-time database systems (RTDBs)
• Contributions
• Proposed solutions for Real-Time Databases: – Maintaining temporal consistency – A novel principle to assign deadlines & periods for real-time update
transactions
• Conclusions
• Other contributions & future work
3
Motivation
• Embedded applications need access to time varying data– e.g., temperature, pressure, etc.
• Need sufficiently fresh data for informed decisions, especially for real-time applications.
• A RTDB provides necessary support– executes transactions within deadlines– maintains temporal consistency of data
data values valid only for limited time
• A RTDB is a core component of real-time applications– Air traffic control– Avionics – Process control – Intelligent networks
4
RTDB Model for Maintaining Temporal Validity of Real-Time Data
Real-TimeDatabases
Network
Sensor 1
Sensor 2
Sensor N
. . . .
• A real-time object in RTDBs models a real world entity, e.g., position of an aircraft• Values are sampled by sensors, and propagated to RTDBs (propagation delay >= 0)• Real-time data in RTDBs must remain fresh in order to react to abnormal situations timely
• Transactions may be triggered to deal with abnormal situations
5
What is Data Temporal Consistency in RTDBs?
Temporal Consistency: keep data valid relative to real world
Time
Value
X
• Real-time data values change continuously• Data values are sampled periodically• A validity interval is associated with a data value• Within validity interval, a data value is temporally valid
– deviation from real world is acceptable
0 1 2 3 4 5
6
Applications with Temporal Consistency
in RTDBs• Air traffic control:
– Real-time data: aircraft position, speed, direction, altitude, etc.
• 20,000 data entities
• validity intervals of 1 ~ 10 seconds
• Process control:– Real-time data: pressure, temperature, flow rate, etc.
• Intelligent network: network services databases– Real-time data: network traffic management data
e.g., bandwidth utilization, buffer usage
7
• Our focus:
real-time data
& their impact on transactions
• Traditional RTDB work focuses on transactions with deadlines
• Commercial RTDBs– EagleSpeed: meeting timing constraints
– ClustRa: providing real-time response for telecom applications
8
Commercial RTDB Examples
• EagleSpeed TM – meeting timing constraints (Lockheed Martin Corp. Ocean, Radar & Sensor Systems)
– Quick, efficient and deterministic processing – Predictable response time– Concurrency control and deadlock prevention– Priority inheritance for transactions– Fault tolerance
• Applications – Navy’s AN/BSY-2 combat system– The AN/SQQ-89 (V) 14 and (V) 15 surface ship systems – The C130 AEWC mission systems
• For more info: http://www.lmco.com/orss/eaglespeed
9
Commercial RTDB Examples, Continued
• ClustRa -- supporting commercial telecom applications• Real-time requirements:
– Real-time response: <100 ms– High throughput: > 1000 transactions/second– High availability: < 2 minutes unavailable per year– High scalability: worldwide telephony network
• Applications:– Next generation network service (Telcordia)– Global mobility management (Inmarsat)– Intelligent telecom network (Oddvar Hesjedal)– Real-time network management
• For more info: http://www.clustra.com
10
Maintaining Temporal consistency-- Strict Transaction Correctness in
RTDBs• Observation: Validity intervals of accessed data may
expire if a transaction does not complete in time
• Transaction correctness criterion:
A transaction can commit if and only if
– it is logically consistent,
– it meets its deadline, and– at the commit time, the objects it has read are still
temporally consistent.
11
Data-Deadline in RTDBs
ValidXValidY
DeadlineTTime
T : Transaction
X,Y : Data
t0
BeginT
t1
RT(Y)
t2 t5
• Our novel concept: Data-Deadline (DDL)– derived from data validity and transaction deadline
• DDL t (T) = min (deadline(T), min(End_Valid(X)))
– T: a transaction – t: time – X: real-time data read by T by time t– End_Valid(X): end of validity interval of X
DDLt2(T) = t5
DDLt3(T) = t4
RT(X)
t3 t4
AbortT
12
Novel Transaction Scheduling Algorithms:
Data-Deadline based Scheduling • Data-Deadline based scheduling
– Data-Deadline based Least Slack First (DDLSF) slack t (T) = DDL t (T) - t - Estimated Remaining Execution Time t (T)
– Earliest Data-Deadline First (EDDF)
DDL t (T)t
slack t (T)E Time
13
Novel Transaction Scheduling Algorithms:Forced Wait
• If T can commit before X becomes invalid, T reads X.
• Otherwise, T waits for the next version of X.
BeginTWait ?
ValidX
DeadlineT Time
T : Transaction
X : Data
t1 t2 t4t3
ValidX
RT(X)
t5
CommitT
14
Novel Transaction Scheduling Algorithms:Similarity
BeginT
ValidX
DeadlineTTime
T : Transaction
X : Data
t1 t2 t3
ValidX
RT(X)
t5
Commit ?
t4
• If a version read is similar to the current version, the transaction can commit
15
Novel Transaction Scheduling Algorithms:
Forced Wait + Similarity
ValidX
ValidY
DeadlineTTime
T : Transaction
X,Y : Data
t0
BeginT
t1
RT(Y)
t2 t4
RT(X)
t5t3
Wait? Commit?
t6
ValidX
ValidY
• Forced wait is employed when a data is read• Similarity is employed at commit time
16
Summary of Experimental Results: Temporal Consistency Maintenance
• Data-Deadline based policies alone do not improve performance significantly
• Forced Wait improves performance significantly
(reduces missed deadline percentage up to 50% )
• Similarity improves performance
(reduces missed deadline percentage up to 30%)
• When combined with Similarity, Forced Wait plays a dominant role in enhancing performance
17
Proposed Solutions & Results
• Maintaining Temporal Consistency
• Assign Deadlines & Periods to RT Update Transactions
18
Assign Periods & Deadlines-- Problem & Goals
• Problem domain:
– maintaining temporal validity of real-time data by periodic update transactions
• Goals: assigning periods and deadlines s.t.
– update transactions can be guaranteed to complete by their deadlines
– the imposed workload is minimized
• Problems with traditional approaches
• Proposed solution and performance results
• Summary
19
Problem : Maintaining Temporal Validity of Real-Time
DataV
t+Vt
V : Validity length
t’+Vt’
V
• Real-time data refreshed by periodic update sensor transactions– X has to be refreshed before its validity interval expires– validity duration updated upon refresh
• How to maintain the validity of data while minimizing the workloads due to update transactions ?
20
Traditional Approach: Half-Half -- Sample at twice the rate of change: P = D =
V/2
Definition:
• X : Real-Time Data
• V : Validity Interval Length
• T : Trans Updating X
• P : Period of T
• D : Deadline of T
• C : Computation Time of T V
Problem : Imposes unnecessarily high workload
t
P=D
t+V/2 t +Vt
Observation : Data validity can be guaranteed if Period + Deadline <= Validity LengthWorkload : C / P = 2C / V
P=D
D
t t+V/2 t +Vt
P
P more than V/2 & D less than V/2 !
21
Deriving Deadlines and Periods:Intuition of More-Less Principle
• Data validity can be guaranteed if Period + Relative Deadline <= Validity Length (1)
• To reduce the workload (C/P) imposed by T without
violating (1) :
Increase period to be more than half of validity length
Decrease relative deadline to be less than half of validity length
• If relative deadline <= period,
deadline monotonic scheduling is an optimal fixed
priority scheduling alg
22
For a set of transactions {Ti} 1 <= i <= m • Validity Constraint (to ensure data validity) : Period + Deadline <= Validity Length
More-Less Principle: Definition
• Deadline Constraint (to reduce workload) : Computation Time <= Deadline <= Period
• Schedulability Constraint (by deadline monotonic) :
Response time of the 1st instance <= Deadline
Note: 1st instance response time is the longest response time if all transactions start at same time
Question: Is More-Less always better than Half-Half ?
23
More-Less Principle: P & D
T1T2
C V1 32 20
Parameters
Half-Half
T1
T2
D P
1.5 1.5
10 10
Utilization : 1/1.5 + 2/10 = 0.867
More-Less (priority order: T1 > T2)
T1
T2
D P
1 2
4 16
Utilization : 1/2 + 2/16 = 0.625 <
Determining deadline and period of a transaction in More-Less:Deadline: D = Response time of the 1st instance;
Period : P = Validity Length - Deadline;
Does the priority order T2 > T1 produce same P and D?
Is more-less always better than half-half ?
24
More-Less Better than Half-Half
• Theorem: {Ti} can be scheduled by
(Half-Half , any fixed priority scheduling alg)
{Ti} can be scheduled by
(More-Less, Deadline Monotonic scheduling)
• The reverse is not true
• Question: How to determine transaction priority order s.t. load is minimized under More-Less ?
25
Shortest Validity First• Shortest Validity First (SVF)
– assign orders to transactions
• in the inverse order of validity interval length
• resolve ties in favor of a transaction with less slack (V - C)
– is optimal under certain restrictions
26
Shortest Validity First: Summary
• Restrictions:
1) Ci <= min (Vj /2)
2) C2 - C1 <= 2(V2 - V1) (i.e., the increase of computation time is less than twice the increase in validity interval length),
• If restrictions (1) & (2) hold, SVF is optimal
• If only restriction (1) holds, SVF is near optimal
• In general, SVF is a good heuristic (shown in experiments)
27
Applications & Experimental Results• Application of More-Less: Avionics Systems
• Experimental Parameters : Ci = [5,15] ms & Vi = [4000,8000] ms
• Experimental results show that More-Less provides lower CPU workload and better schedulability than Half-Half
0
0.2
0.4
0.6
0.8
1
1.2
1.4
100 150 200 250 300 350 375
Half-HalfMore-Less
No. of Sensor Transactions
CP
U
Wor
kloa
d
More-Less can deal with 30% more load !!!
28
Experiments: Coscheduling of Mixed Workloads
-- Performance of Sensor Transactions
0
0.05
0.1
0.15
0.2
100 150 200 250 300 350
Half-Half(Sensor)
More-Less(Sensor)
No. of Sensor Transactions
Mis
sed
Dea
dlin
e R
atio
Mixed Workloads: Sensor Transaction Class &Triggered Transaction ClassTransaction Scheduling:
High priority class: Sensor -- Deadline monotonic schedulingLow priority class:Triggered -- Earliest deadline first scheduling
29
Experiments: Coscheduling of Mixed Workloads
-- Performance of Triggered Transactions
0
0.2
0.4
0.6
0.8
1
100 150 200 250 300 350
Half-Half(Trigger)
More-Less(Trigger)
No. of Sensor Transactions (Triggered Trans Arrival Rate = 10 trans/s)
Mis
sed
Dea
dlin
e R
atio
More-Less improves perf. of triggered transactions by 80%!
30
Conclusions
• Development and evaluation of efficient and novel approaches to temporal consistency maintenance
– concept of data-deadline and related scheduling algorithms
– forced-wait
– similarity
• Development, analysis, and evaluation of More-Less, an efficient principle for maintaining real-time data validity