Real Time Vs General Purpose Databases

The queries associated with a Real time databases are associated with a deadline, there may be some response after the queries passed the deadlines.

The data returned in response to a query must have absolute and relative consistency.

Absolute Vs Relative Consistency

Absolute consistency is accuracy. The data returned in response to a query must be close to the results expected. If temperature or pressure is interrogated in a chemical vessel, we want the data returned to be close to the current temperature or pressure.

Relative consistency means that for multiple data, the data must have been collected reasonably close to one another.

Need for Response Time predictability

There are many factors that affect the response time predictability

• The requirement to meet the ACID properties will entail a overhead.
• Transactions may be aborted one or more times to avoid deadlock and to maintain serialization consistency. So transaction abortion leads to a delay.
• Databases are often quite large to fit in the main memory and therefore rely mainly on the disk based systems. Page faults are the problem creators if the requested record is not in the main memory.
• Transaction access are data dependant. The transaction to deduct an amount from a database which has lower balance is faster whereas the higher balance leads to slowness.
• Transaction may suffer with a delay in accessing a data which is being locked by some other transactions.

Relaxing the ACID Properties

    General purpose databases always obey the ACID properties, but Real Time databases often relaxing the ACID properties or even sometime violates the ACID properties.

In Machine tool Control System, the current tool position is not regarded as durable data and is discarded after it become outdated. In such an application, data durability is not worth maintaining if new measurements are frequently collected.

Sometimes even serialization consistency is also violated. Maintain serialization consistency leads to avoid concurrent transactions.

For example,

A and B are two airports. Users can book the tickets online to travel to the destination. For example,

• if more than or equal to 100 passengers are allotted in a flight, then there should be 5 flight attendants else only 3 flight attendants
• if less than 85 passengers (after cancellation) there should be only 3 flight attendants.

In such a case, assume if there is already 99 tickets booked for particular flight, and there will be one reservation and one cancellation

• If reservation happens first, then 100 tickets sold and 5 flight attendants
• Then cancellation happens, 99 tickets with the same 5 flight attendants (only if less than 85, flight attendants will be 3)

In second case,

• If cancellation first, 98 tickets with 3 flight attendants
• Reservation next, 99 tickets with the same 3 flight attendants

If the above cases, since both the reservation and cancellation happens to be running serially (one after other) to maintain serialization consistency, it may be decided to interleave both the transactions and the second transaction can be aborted to maintain serialization consistency.