Select Page

Real-time vs. Non-real-time Database Systems

Like conventional database systems, real-time database systems are data repositories and provide services for storage, retrieval and manipulation of data. The differences between conventional and 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., 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.

The eXtremeDB/rt transaction manager

The database transaction manager has a number of verification checkpoints in the code at which the transaction elapsed time is tested against the deadline. The frequency of the verifications eliminates the possibility of executing the database code long enough to miss the set deadline. If the control point is reached (the transaction ran out of the allotted time slice), the transaction is assigned a special “transaction interrupted” status and the control is returned back to the application. The application is then expected to rollback (abort) the transaction. The transaction manager ensures that all database runtime internals are in a “recoverable” condition. The subsequent transaction rollback will restore the database to the consistent state that existed prior to the start of the transaction. Crucially, the transaction manager guarantees that the rollback will be completed within the deadline, provided that the application initiates the rollback when signaled to do so by the database runtime. Thus, the transaction would miss the deadline, but not be “late” and the internal consistency of the database is preserved.

Chart of the eXtremeDB/rt database transaction scheduler

Related Resources

Documentation & Collateral

i

Review the eXtremeDB/rt data sheet

U

Learn more about eXtremeDB/rt in our on-line documentation

t

eXtremeDB/rt Q & A: what distinguishes a true real-time database?

In the News

"On eXtremeDB/rt. Q&A with Steven Graves" ODBMS.org guest blog by McObject CEO Steve Graves, October 7, 2021

eXtremeDB/rt offers deterministic ACID-compliant transactions

Tailored to your needs.

 

The nature of eXtremeDB/rt’s tight integration with the RTOS and target hardware requires that each evaluation package be assembled uniquely for your needs.

Please contact us so that we can gather information on your RTOS vendor, version, target hardware, tool chain, and so on.

Send us an email

Give us a call

+1-425-888-8505

Tailored to your needs.

 

The nature of eXtremeDB/rt’s tight integration with the RTOS and target hardware requires that each evaluation package be assembled uniquely for your needs.

Please contact us so that we can gather information on your RTOS vendor, version, target hardware, tool chain, and so on.

Send us an email

Give us a call

+1-425-888-8505