Survey of Real Time Databases

1
Survey of Real Time Databases

• Telvis Calhoun
• CSc 6710

2
Introduction

• Data repository for a real-time systems
• Real-Time systems include
• Automotive control systems
• Telecommunications
• Industrial Process Control
• Real-Time Systems impose temporal consistency
  constraints
• Database must closely represent the real-time
  system in real time.
• Value of data decreases with time.

3
RTDBS Characteristics

• Primary metric is number transactions that missed
  their deadlines.
• Provide predictable response time.
• Guarantee completion of time critical
  transactions
• Usually designed as in-memory databases.

4
Hard Real Time vs. Soft Real Time

• Critical real-time systems such as nuclear power
  plants or fly-by-wire airplanes are Hard Real
  Time
• Non-critical real time systems where missed
  transactions only degrade system quality are Soft
  Real Time
• RTDB design depends on real time system
  characteristics
• This presentation shows algorithms for soft-real
  time systems only.

5
Dynamic On-Demand Scheduling

• Goal Minimize computational workload by
  initiating transactions on-demand.
• Target System Embedded systems with limited
  resources

6
On-Demand Definitions

• Definitions
• Base Data - Data continuously added to the
  database by sensors
• Derived Data Data calculated using base data or
  other derived data items
• Read Set All data items needed to calculate a
  derived data item
• Similarity Updates are not required for minor
  changes in base items even if the data is old

7
On-Demand Relationship Between Data Items

• The relationship between base and derived items
  can be represented using a directed acyclic graph
• Read set retrieved using On-Demand Depth-First
  Traversal (ODDFT)

8
On-Demand Basic Algorithm

• When a base item (b) is updated, flag derived
  items that include the (b) in their read set.
• When a transaction occurs for (d), traverse graph
  backwards from (d) to locate stale items .
• Each stale item is prioritized and an update
  schedule is created and executed.
• Execute updates until the transaction deadline
  expires.

9
Quality of Service Scheduling

• Goal Maintain temporal consistency during
  transient overload periods.
• Target System Real time services systems with
  unpredictable workloads

10
QoS Metrics

• Two groups of transactions
• Mandatory transactions must be computed before
  the transaction deadline.
• Optional Transactions are executed if there is
  time available before the transaction deadline.
• Quality of Data (QoD)
• Maximum Data Error (MDE) - Defines the maximum
  deviation between a data item and its real world
  value
• Quality of Transactions (QoT)
• Mandatory miss percentage (MM) Percentage of
  Mandatory Transactions that missed their deadline
• Optional miss percentage (MO) Percentage of
  optional transactions that missed their deadline.

11
QoS Metrics cont.

• Quality of Service (QoS)
• Overshoot - Worst-case system performance in
  terms transaction miss percentages
• Settling Time Time to transition from overshoot
  to steady state.
• Utilization Computing resources used
• QoT vs. QoD Trade-off
• Increase the MDE (degrade data) to decrease
  optional transactions during transient overloads.

12
QoS Feedback Scheduler

• Feedback control scheduler adapts QoT vs. QoD
  Trade-off

13
QoS Basic Algorithm

• Define QoS and Transaction metrics U, MM, MO
• Monitor mandatory and optional miss percentages
• During transient overload periods decrease
  optional updates by increasing MDE.
• Feedback control scheduling is used to adapt the
  MDE in order to satisfy pre-determined QoS
  specifications.
• Decrease MDE as workload decreases (i.e. increase
  triggered optional transactions).

14
Deferrable Scheduling for Fixed Priority Systems

• Goal Actively schedule the maximum time between
  periodic sensor updates to minimize energy
  consumption.
• Target System Process control systems that
  require continuous sensor updates

15
DS Definitions

• Validity interval Time that a data item is
  considered fresh after an update transaction.
• Response Time Time required to retrieve data
  from a sensor.
• Transaction Deadline Time when a transaction
  must be complete

16
DS Basic Algorithm

1. Set the update transaction deadline (d) to be the
   end of the validity interval.
2. The transaction start time is derived backward
   from the deadline using the known response time
   (r).

17
DS Basic Algorithm cont.

• Adjust the schedule for high priority preemption.
• Construct a hyper-period that executes the
  schedule repeatedly to decrease scheduling
  overhead.