The Future of Database Real-Time Performance“Real-time” is a term frequently mentioned by database system vendors, but real-time has a specific meaning in embedded systems. According to geeksforgeeks.org[1]: “A real-time system is one where the system is affected by real-time constraints, meaning it must respond within specified timing constraints or meet defined deadlines. For example, flight control systems, real-time monitors, etc. In other words, real-time does not necessarily mean truly fast. In real-time systems, speed is not the measure of success; determinism is the primary criterion for success.Real-time systems are evolving at an astonishing pace. In the past, real-time systems were relatively simple, such as anti-lock braking systems in airplanes and later in cars. Today, real-time systems have become much more complex. Advanced Driver Assistance Systems (ADAS) are a typical example. They are a great illustration of the complexity of modern real-time systems. ADAS must gather data from multiple different sources (such as LiDAR, sonar, radar, optical cameras, GPS, and maps) which leads to significant sensor data fusion challenges. It is essential to centralize all this data (in a database) so that it can be correlated, analyzed, and acted upon (start, stop, turn, etc.) within hard real-time deadlines.But the problem is: until recently, there were no Commercial Off-The-Shelf (COTS) embedded databases available for real-time systems because no product could meet the deadlines. To illustrate this, consider a real-time system that must respond within 50 milliseconds. As shown in Figure 1, the real-time task completes the first few steps at the 5-millisecond and 10-millisecond marks respectively. Then, the task calls the database runtime. However, the database runtime is unaware of the deadline and will not return control to the task before the deadline expires. This system fails.Figure 1. Here, the real-time task completes the first few steps at the 5-millisecond and 10-millisecond marks respectively. Then, the task calls the database runtime. The database runtime is unaware of the deadline and will not return control to the task before the deadline expires. This system fails.Three GoalsTo be suitable for use in real-time systems, embedded database runtime systems must achieve three goals. First, it must be aware of the deadlines and track the elapsed time against a given deadline. Second, it cannot have any external dependencies that lack time awareness. For example, the database runtime should not call malloc() (the C runtime function for dynamic memory allocation). The third goal is that it must be able to schedule database transactions in a way that is suitable for real-time systems.Deadlines – If the embedded database system must manage deadlines, then the embedded database runtime must have a method to understand deadlines. As long as the work units in the database are transactions, the database API that begins the transaction is the logical place to pass the deadline to the database runtime. As the transaction progresses, the database runtime needs to frequently check the progress against the deadline and abort the transaction if necessary to meet the deadline. In real-time database systems, transactions can either meet (successfully commit) or miss (successfully abort) their deadlines, but they will never be late (exceed their deadline). Achieving this is not as simple as you might think unless you are targeting a single Real-Time Operating System (RTOS), as different RTOSs manage clocks and timers differently. Figure 2 illustrates the timeline of transactions. Of interest are the deadline validation control points and the deadline control points.Figure 2. This illustrates the timeline of transactions. Note the deadline validation control points and deadline control points. (Click the image to enlarge)External Dependencies – Most embedded and real-time systems are written in C/C++. Programmers tend to freely use functions from the C Runtime (CRT) library. In many cases, this is harmless, but calls to CRT functions like malloc or performing input/output should be avoided. They carry the same risks as shown in Figure 1: calling tasks and (in this case, the database runtime) may disappear into time-unaware CRT functions and not return before violating the deadline, leading to the risk of system failure.Scheduling – Databases are typically accessed by multiple tasks/threads/processes. The database runtime must coordinate access to the database by tasks to avoid conflicts. In industry terminology, this is called concurrency control, which is divided into two major categories: optimistic and pessimistic concurrency control. When using pessimistic concurrency control, tasks request access to resources, which can be the entire database, a database table or set of tables, database pages, or rows of a table. Regardless of the granularity of such requests, a component of the database runtime (usually called a lock arbiter or lock manager) needs to coordinate these requests.This is typically done in a first-come, first-served manner. But this is not sufficient for real-time database systems. Real-time database systems must first schedule transactions based on priorities specified by the developer, and then within the same priority, first by the earliest deadline. Alternatively, the real-time database runtime must utilize priority inheritance so that transactions of low-priority tasks that are running can be elevated to the same priority as newly scheduled transactions with higher priority.Reimagining DatabasesToday’s real-time systems are growing, just like embedded systems in the late 1990s and early 2000s when embedded databases became a necessity because embedded systems had to do more. Business lines/departments need to reimagine embedded databases to operate within the resource constraints of embedded systems. Now, as the demand for data management in hard real-time systems continues to grow, we need to rethink and redesign COTS deterministic database management systems that operate under task and safety-critical real-time system constraints.References:https://www.geeksforgeeks.org/real-time-systems
