What you’ll learn:
- The actual definition of real-time database versus the abused interpretation used by marketers of real fast database systems.
- The interplay of transient and persistent memory, and hard and soft real-time capabilities.
Database systems are utilized in many embedded systems, and real-time databases are required for many, more demanding applications—especially those dealing with in-memory and real-time issues. A lot of myths revolve around real-time databases, which we rebut here.
1. Databases (and real-time databases) aren’t necessary for embedded devices because the data can be sent to a server.
Real-time systems running in embedded devices are becoming increasingly complex and require decision-making on the device. Consider sensor-data-fusion challenges that virtually all autonomous vehicles must address. Different types of data from different types of sensor and other inputs need to be “fused” to form a cohesive view of the operating environment (LiDAR, radar, optical cameras, GPS, maps, etc.). The timely reaction of the autonomous system to real-time events can’t tolerate the latency of communicating with the cloud.
2. Real-time database means fast reaction to live data.
The term “real-time database” is dominated by this use case, which unfortunately muddies the term real-time. In embedded systems, real-time has long been understood to mean operating within real-time constraints, i.e., that processing needs to be completed within a deadline.
However, the predominant term real-time database means a database system’s ability to respond quickly to changing data. Use cases commonly cited include recommendation engines, and certain banking operations such as fraud detection. Here, real-time is confused with real-fast.
3. Adding predictability significantly affects “traditional” performance.
Databases have traditionally measured performance as throughput: the number of transactions-per-second or kilobytes-per-second ingest speed. The performance metric for hard real-time databases, though, is the ratio of transactions that complete (commit) within their deadline versus transactions that must be aborted to meet their deadline.
In hard real-time database systems, transactions can “meet” or “miss” their deadline but can never be “late” (overrun their deadline). This myth implies that deadline management in hard real-time database systems is a drag on performance but ignores that the metric of success is fundamentally different.
4. Real-time databases are always in-memory databases.
While volatile storage memory architectures can be non-deterministic, persistent-media access is orders of magnitude less deterministic in nature than any RAM-based architecture. Persistent-media I/O is algorithmically complex and often highly uncontrollable. Two types of persistent-media devices are predominant—spinning media (hard disks) and devices based on flash technology (flash and SSD).
HDD is inherently unpredictable. The average access time might be, e.g., 9 ms, but in practice that means it might be 2 ms or 16 ms. Like Forrest Gump’s box of chocolates, you don’t know what you’re going to get.
HDDs have so-called seek time, the time needed to slew the disk head to the correct track, and rotational latency, meaning that once the head is positioned above the right track, it must wait for the disk platter to rotate to the sector that needs to be read. Like seek time, the average rotational latency for a 5,400 RPM disk is 5.5 ms (half a platter spin × 5,400 RPM) but could be 0 or a full rotation. These combined latencies make for HDD’s unpredictable access time. Unpredictability is a bane for any real-time task, including real-time database management.
Flash-based storage devices are pretty much a mandatory choice for persistent media in embedded devices due to their high-speed data transfer, reliability, and low power consumption. Yet from the standpoint of guaranteeing stable latencies, flash-based devices aren’t ideal. Low-level flash management is complex: All flash managers must deal with inherently unpredictable activities such as background garbage collection, wear leveling, bad block management, etc. Normally these issues are handled by flash translation layers (FTLs).
By definition, real-time applications must complete their real-time tasks within a particular time frame. In practice, however, real-time applications allow for different degrees of leniency to break these timing constraints—anywhere from never ("hard real-time") to tolerable to a degree (“firm” or “soft real-time”). Think of a radiotherapy machine versus humidity monitoring applications in a climate-control system.
Given the above constraints, data management in hard real-time systems is never based on persistent media. With soft real-time requirements, a database system can be implemented for persistent media. Real-time database kernels implement predictable scheduling algorithms and transaction deadline management that facilitate predictability to a high degree.
While it’s not practical for a database kernel to completely bypass flash-management software, minimizing layers between the database kernel and the underlying media access can greatly improve predictability. For example, removing a file system and taking over some FTL functions is instrumental in achieving high predictability levels.
5. Real-time database systems are only applicable for embedded applications.
Generally, this is true. Non-embedded real-time systems are rare. Real-time guarantees must be met on all levels, from applications to database kernels to OS kernels to low-level hardware. General-purpose computing platforms are hard to build this way.
6. Real-time databases keep data for a limited time.
In many cases, this is true, especially when an in-memory database is the basis of the real-time database. But it doesn’t have to be. A real-time database can be saved prior to shutdown and reloaded upon the next startup. Of course, this doesn’t change the inherent limit on the size of the database (constrained by available memory) but it does address the “limited time” aspect. And, as discussed above, a real-time database can be implemented over persistent memory (flash).
7. Real-time databases require special equipment.
As mentioned above, real-time guarantees must be met on all levels, so general-purpose (commodity) platforms are out. But how is “special equipment”defined? COTS hardware built around an Arm architecture is far from “special” and yet is suitable for real-time systems.
8. If a database system is integrated with a real-time OS, it becomes real-time itself.
Nothing could be further from the truth. If a database system doesn’t implement deadline management through internal instrumentation and development of time-cognizant transaction schedulers, it doesn’t matter if it’s running on an RTOS or not—it’s not a real-time database system.
9. DBMS can’t be made to be real-time because database operations are too complex and unpredictable. Index lookup, for instance, can take arbitrary time.
Though it’s true that not all database operations/algorithms can be made predictable, it’s possible to use search algorithms and other deterministic designs and avoid those that aren’t predictable. Another aspect is that these algorithms must be interruptible while preserving data integrity and the database kernel’s internal integrity.
10. Real-time database systems don’t guarantee data security/protection.
Not true. Both data at rest and data in transit can be protected via predictable encryption algorithms and TLS protocols.
11. There’s no need for a real-time database because all database operations can be done in the background.
Whether database access is in the background or foreground, if predictability requirements do exist, a real-time database kernel is necessary.