What is a hard real-time database system?

Hard real time doesn't mean real fast . these years , Database and software vendors have been “ real time ” The word is used as a synonym for instant or real-time , But for mission and safety critical systems , Its meaning is completely different .

It's amazing , It's not as simple as it sounds , But maybe we can start by defining some terms for our purposes . Hard real-time software refers to software that will fail if the time limit is not met . Mission critical software is one whose failure can lead to catastrophic consequences （ For example, someone died 、 property loss 、 Serious economic losses, etc ） Software for . Advanced driver assistance systems are mission critical and hard real-time ; Electronic trading system is a key task , But not hard real time ; Inkjet printers are hard real-time , But not a critical task .

let me put it another way , In hard real-time systems , There is a line that can have major consequences . In the context of a real-time database system , The sand line is the deadline for business . Crossing the line means that the transaction is delayed , Therefore, the real-time system cannot respond to events within the predefined time limit . In advanced driver assistance , A system failure may mean an accident .    

External consistency

therefore , A key principle of hard real-time database systems is term management or external consistency . External consistency means that the contents of the database reflect the real world within a certain time limit . So , The transaction must be completed within a predetermined time limit . In a hard real-time database system ,“ complete ” Means that the deadline is met by successfully submitting or successfully suspending before the deadline . Trading is never late ; They must meet the deadline to reflect the state of the real world , Or notify the interested system that the transaction has missed the deadline （ But was suspended within the deadline ）. For reliability , Hard real-time database management systems should （ But not necessarily ） Like any other ACID Enforce internal consistency just like a database .

Performance index of real-time database system

Hard real time doesn't mean real fast . these years , Databases and software vendors have been using the word real-time as a synonym for real-time . Mission critical hard real-time data management systems may require speed , But there must be certainty . let me put it another way , It has to work with RTOS（ Real-time operating system ） Work together to set and execute transaction deadlines . Performance is achieved by meeting its deadlines for successfully committed transactions and missing deadlines （ Successfully aborted before the deadline ） The ratio of the number of transactions . Speed is not an indicator for evaluating real-time database systems .

Transaction schedule

As you know , A database transaction is not necessarily a single operation , Although it may be . It could be a series of operations , For example, find a record 、 Delete five related records and update a field in the original record , These operations must both succeed or fail . Again , influence 1 or 100 A single update or delete command for records must all be successful or unsuccessful .

The transaction starts when the application code calls it . If the database system is busy with one or more other conflicting transactions , The newly created transaction will be put into the waiting queue , But the clock of its deadline has already started . In theory , Transactions may time out without being scheduled to execute , But in a well-designed real-time system, it doesn't . The following figure illustrates the timeline of real-time transactions .

Once arranged , The transaction starts executing the workload interval . The database runtime cannot be a black hole that cannot be identified . let me put it another way , When the system calls the database to run , The task cannot disappear for an indefinite period of time within the database runtime , The deadline before the database runtime returns control to the application may be exceeded . The database runtime needs to know the expiration date , And keep checking the clock , And be able to return control to the application before it's too late , This aborts the transaction and allows it to complete before the deadline . This is the deadline control point .

The ability to deterministically establish a deadline control point depends on knowing with certainty the time required to abort the transaction . By implementing a new real-time database transaction scheduler , We can assert that the time required to roll back changes in a transaction will not exceed the time required to apply these same changes . therefore , If the transaction deadline is T, Then the deadline control point is T / 2. actually , Aborting a transaction can take much faster than applying it to a point in time . therefore , Half of the actual deadline is the worst case , It can be adjusted according to the empirical data collected during the test and simulation . See chart 4.

Undo any changes made to the database by the transaction , Not more than the time required to apply these changes .

Real time transaction scheduling

The transaction scheduling policy has an impact on the ratio of completed transactions to aborted transactions . First , The transaction scheduler must enforce the transaction deadline , Then try to maximize the number of tasks that successfully commit their transactions relative to the number of tasks whose transactions are aborted .

One such strategy is High priority earliest due date first (EDF), The second is Priority inheritance (PI).

1、 Use EDF, Transactions are prioritized , And within the same priority before the earliest deadline . The priority of a transaction is another parameter passed to the transaction scheduler through the transaction start command , And the deadline .
2、 Priority inheritance (PI) Arrange transactions with the same priority in first in first out order , Regardless of their deadlines .
EDF and PI The main difference between them is ： stay EDF Manager , The database kernel organizes queues and determines the order in which transactions are executed . stay PI In the case , The order of execution is first in, first out (FIFO), Do not consider deadlines . however , When a higher priority task starts a database transaction ,PI Raise the priority of a lower priority task to a higher priority , This allows lower priority tasks to preempt higher priority tasks . In turn, , This allows lower priority transactions to complete quickly and avoid higher priority tasks . Different application patterns can take advantage of different transaction schedulers .

Conclusion

in summary , Real time database systems can be very fast , But it must be deterministic and ensure external consistency . When discussing data management , Speed is always a performance indicator , But in hard real-time databases , The most important performance metric is the number of successfully committed transactions , Instead of the number of transactions successfully rolled back on time , So that the system can always respond to mission critical events in real time . If a database system cannot guarantee external consistency , It is not hard real time , And may lead to the failure of mission critical systems .

Click here to read the original text

This article is from WeChat official account. - Open Source Software Alliance PostgreSQL Branch （kaiyuanlianmeng）.
If there is any infringement , Please contact the [email protected] Delete .
Participation of this paper “OSC Source creation plan ”, You are welcome to join us , share .