Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Sang H. Son
Department of Computer Science
University of Virginia
Charlottesville, Virginia 22903
son@cs.virginia.edu
Outline
Introduction: real-time database systems and real-time data
services
Why real-time databases?
Misconceptions about real-time DBS
Paradigm comparison
Characteristics of data and transactions in real-time DBS
Origins of time constraints
Temporal consistency and data freshness
Time constraints of transactions
Real-time transaction processing
Priority assignment
Scheduling and concurrency control
Overload management and recovery
Outline (contd)
Advanced real-time applications
Active, object-oriented, main-memory databases
Flexible security paradigm for real-time databases
Embedded databases
Real-world applications and examples
Real-time database projects and research prototypes
BeeHive system
Research issues, trends, and challenges
Exercises
I. Introduction
Outline
Motivation: Why real-time databases and data services?
A brief review: real-time systems
Misconceptions about real-time DBS
Comparison of different paradigms:
Real-time systems vs real-time database system
Conventional DBS vs real-time DBS
Real-time FAST
Real-time nonosecs or secs
Real-time means explicit or implicit time constraints
A high-performance database which is simply fast without
the capability of specifying and enforcing time constraints
are not appropriate for real-time applications
Time Constraints
v(t)
v(t)
Soft deadline
v0
d1
d2
10
11
12
16
18
19
20
21
is sufficient.
although main-memory resident database eliminate disk
delays, conventional databases have many sources of
unpredictability, such as delays due to blocking on locks and
transaction scheduling
increases in performance cannot completely make up for the
lack of time-cognizant protocols in conventional database
systems
A temporal database is a RTDB.
while both of temporal DB and RTDB support time-specific
data operations, they support different aspects of time
in RTDB, timely execution is of primary concern, while in
temporal DB, fairness, resource utilization, and ACID
properties of transactions are more important
22
23
27
28
29
Outline
The origin of time constraints
Types of time constraints
Real-time data and temporal consistency
Real-time transactions
30
Issues to be discussed:
1. What are the origins of (the semantics of) time
constraints of the data, events, and actions?
2. Can we do better by knowing the origins of time
constraints?
3. What is the connection between time-constrained
events, data, and real-time transactions?
31
Example #1 (contd)
Features of an object must be collected while the
object is still in front of the camera.
Current object and features apply just to the object
in front of the camera
Lose validity once a different object enters the
system.
Objects features matched against models in
database.
Based on match, object directed to selected workcell.
Alternative: discard object and later bring it back
again in front of the camera.
33
34
35
Designer Artifacts
Subsequent decisions of the database system designer
introduce additional constraints:
The type of computing platform used (e.g. centralized vs.
distributed)
The type of software design methodology used (e.g., datacentric vs. action-centric)
The (pre-existing) subsystems used in composing the
system
The nature of the actions (e.g., monolithic action vs. graphstructured or triggered action)
Time constraints reflect the specific design strategy and the
subsystems chosen as much as the externally imposed
timing requirements
37
39
40
41
42
43
45
An Example
Data object is specified by
(value, absolute validity interval, time-stamp)
Interested in {temperature and pressure}
with relative validity interval of 5
Let current time = 100
temperature = (347, 10, 95) and pressure = (50, 20, 98)
-- temporally consistent
temperature = (347, 10, 98) and pressure = (50, 20, 91)
-- temporally inconsistent
46
47
48
49
50
Aperiodic
- If temperature > 1000
within 10 secs add coolant to reactor
Based on Value:
Hard: must execute before deadline
Firm: abort if not completed by deadline
Soft: diminished value if completed after deadline
51
52
53
54
55
Outline
Priority assignment
Scheduling paradigms
Priority inversion problem
Concurrency control protocols
Predictability issues
Overload management and recovery
56
Priority Assignment
Different approaches
EDF: earliest deadline first
highest value (benefit) first
highest (value/computation time) first
complex function of deadline, value, slack time
Priority assignment has significant impact on database
system performance
Assignment based on deadline and value has shown
good performance
57
59
(variable)
tI/O
= I/O processing
(variable)
tint
= transaction interference
(variable)
tappl
tcomm
= communication time
60
Scheduling Paradigms
Scheduling analysis or feasibility checking of real-time
computations can predict whether timing constraints will
be met
Several scheduling paradigms emerge, depending on
whether a system performs schedulability analysis
if it does, whether it is done statically or dynamically,
and
whether the result of the analysis itself produces a
schedule or plan according to which computations are
dispatched at run-time
61
Different Paradigms
1. Static Table-Driven approaches:
Perform static schedulability analysis
The resulting schedule is used at run-time to decide
when a computation must begin execution
2. Static Priority Driven Preemptive Approaches:
Perform static schedulability analysis but unlike in the
previous approach, no explicit schedule is constructed
At run-time, computations are executed (typically)
highest-priority- first
Example: rate-monotonic priority assignment - priority is
assigned proportional to frequency
62
63
64
65
Read X
Activate
TR T
Begin
TR T
Read Y
DD(Y)
DD(X)
Deadline
of TR T
66
Read X
Activate
TR T
Read Y
DD(Y)
Begin
TR T
DD = Data deadline
DD(X)
Deadline
of TR T
Commit
X and Y are valid
TR T makes deadline
67
Read X
Activate
TR T
Read Y
DD(Y)
Begin
TR T
DD(X)
Deadline
of TR T
ABORT
68
DD(Y)
Read X
DD(X)
Read Y
Activate
TR T
Begin
TR T
Force TR T to Wait for Update to Y
since it will occur soon!
Deadline
of TR T
69
Read X
Read Y
15.70
DD(X)
Activate
TR T
Begin
TR T
Deadline
of TR T
Commit
Deadline of TR T is met
Data X is OK
Data Y is similar (defined in DB)
70
71
Pessimistic
Optimistic (OCC)
Hybrid (e.g., integrated real-time locking)
Speculative
Semantic-based
Priority ceiling
72
73
T2:
write_lock (X);
read_object (X);
X = X + 1;
write_object (X);
unlock (X);
read_lock (X);
read_object (X);
write_lock (Y);
unlock (X);
read_object (Y);
Y = X + Y;
write_object (Y);
unlock (Y);
74
T2:
read_lock (X);
read_object (X);
write_lock (Y); [blocked]
:
read_lock (Y);
read_object (Y);
:
:
75
76
77
T2:
read_lock (X);
read_object (X);
write_lock (Y);
unlock (X);
time
read_object (Y);
Y = X + Y;
write_object (Y);
unlock (Y);
78
79
80
81
Performance Results
Priority inheritance does reduce blocking times. However, it
is inappropriate under strict 2PL due to life-time blocking of
the high priority transaction. It performs even worse than
simple waiting when data contention is high
Priority abort is sensitive to the level of data contention
Conditional priority inheritance is better than priority abort
when data contention becomes high
Blocking is a more serious problem than resource waste,
especially when deadlines are not tight
In general priority abort and conditional priority inheritance
are better than simple waiting and priority inheritance
Deadlock detection and restart policies appear to have little
impact
82
write phase:
if validation ok then local copies are written to the DB
otherwise discard updates and (re)start transaction
Non-blocking
Deadlock free
Several conflict resolution policies
83
84
OCC Example
T 1:
read_object (X);
X = X + 1;
write_object (X);
validation
<conflict resolution, .e.g, restart
transaction>
T2:
read_object (X);
read_object (Y);
T 3:
read_object (Y);
Y = Y + 1;
write_object (Y);
...
Y = X + Y;
write_object (Y);
validation
<conflict resolution, e.g.,
restart transaction>
85
86
OCC: Comparison
Broadcasting commit (no priority consideration)
not effective in real-time databases
Sacrifice policy: wasteful
theres no guarantee the a transaction in H will actually
commit; if all in H abort, T is aborted for nothing
Wait policy: address the above problem
if commit after waiting, it aborts lower priority
transactions after waiting, which may have not enough
time to restart and commit
the longer T stays, the higher the probability of conflicts
Wait-X policy: compromise between sacrifice and wait
X=O: sacrifice policy; X=100: wait policy
performance study shows X=50 gives the best results
87
Why?
to provide blocking at most once property
the system can compute (pre-analyze) the worst case
blocking time of a transaction, and thus schedulability
analysis for a set of transaction is feasible
A complete knowledge of data and real-rime transactions
necessary: for each data object, all the transactions that
might access it need to be known
true in certain applications (hard real-time applications)
not applicable to other general applications
88
90