Hard Real-time vs. Soft or Non-real-time Database Systems

Like conventional database systems, hard real-time database systems are data repositories and provide services for storage, retrieval and manipulation of data. The differences between conventional and hard real-time database systems lie in the temporal requirements of the managed data, timing constraints on transactions, and performance goals. The following aspects are often considered:

a) internal versus external consistency constraints and,
b) transaction schedules and performance metrics.

The design principles of conventional (i.e., soft or non-real-time) database systems always guarantee strong internal data consistency — a consistent view from all components of the database, avoiding contradictory data in the same database. To guarantee internal consistency, database systems ensure transactions’ ACIDAtomicity, Consistency, Isolation and Durability properties.  Real-time database system designers sometimes argue that, for real-time databases, external consistency (the requirement for a transaction to reflect the current physical environment), is preferable. Indeed, external consistency may be more important than internal consistency for certain applications. However, as a practical matter, most applications require preserving their databases’ internal consistency.

Performance metrics

The common performance metric for all database systems is response time. For conventional database systems, the metric comes down to a number of transactions per time unit; this measurement – the average number of transactions per second (TPS) –  is used heavily in optimizing the responsiveness of traditional database applications. In contrast, real-time database systems often use firm deadline semantics for transactions — transactions can “meet” (successfully commit) or “miss” (successfully abort) their deadlines, but cannot be “late” (go over their allotted time slot) to commit or abort their execution. A late commit of a real-time transaction can lead to a system’s state being incoherent. Thus, a typical performance metric for real-time databases is the number of transactions that miss their deadline.

eXtremeDB/rt implementation of deterministic ACID real-time transactions

eXtremeDB/rt provides semantics for passing a transaction’s deadline and priority to the database scheduler. Transactions are then scheduled either through the Earliest Deadline First (EDF) or Priority Inheritance (PI) algorithms (the schedule is serializable — “read-write” transactions are executed sequentially, “read-only” in parallel). Once scheduled, the eXtremeDB/rt transaction manager implementation enforces firm deadlines through utilizing a deterministic rollback policy. Data modifications or retrieval are allowed only if they are able to finish the within the transaction’s set deadline. “Late” transactions are identified, interrupted and forced to initiate rollback in time to satisfy set deadlines. The key is to ensure that all database runtime internals are in a “recoverable” condition. The database kernel reserves enough time out of the given transaction deadline to rollback modifications made to the point of interruption. We can prove that, at the control point, a transaction’s rollback time is less than the time the transaction has spent modifying the database, or searching through the database.

Learn more about eXtremeDB/rt