maintaining logical and temporal consistency in rt embedded database systems
DESCRIPTION
Maintaining Logical and Temporal Consistency in RT Embedded Database Systems. Krithi Ramamritham. Overview. Motivation Problems in real-time database systems (RTDBs) Contributions Proposed solutions for Real-Time Databases : Maintaining temporal consistency - PowerPoint PPT PresentationTRANSCRIPT
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