Real-Time Versus Real Fast
December 18, 2024
Blog
So-called ‘real-time’ databases are popular these days. Here’s some quotes from the internet:
Firebase: “The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.”
Hazelcast: “A real-time database is defined as a data store that collects, processes, and/or enriches incoming data in real time, immediately after the data is created.”
InfluxDB: “Today, a real-time database can mean different things. This glossary page considers two categories of real-time databases.
The first kind of real-time database is any database (DB) system capable of processing a stream of data in real-time. This means the real-time database system can store data as soon as it is created. Several database management solutions meet this specification. For example, a time series database is capable of processing real-time data from APIs or sensors.
The second category of a real-time database is a system that makes it easy to store and sync data in real-time. Usually, this type of database solution provides SDKs and APIs that notify clients of changes to the database values in real time. Some examples of databases in this category include FireStore and RethinkDB.”
RethinkDB: “RethinkDB pushes JSON to your apps in realtime. When your app polls for data, it becomes slow, unscalable, and cumbersome to maintain.”
But, ‘real-time’ has a long and storied history in computing that bears no resemblance to the use of ‘real-time’ cited above. Actual real-time systems are subject to timing constraints and must guarantee response within specified time constraints (commonly referred to as deadlines), or the system is deemed to have failed. Fly-by-wire, drive-by-wire, and anti-lock brakes are real-time systems that everyone can understand, as well as understand why they’re real-time and what the consequences of failing to meet timing constraints are in the real world. Conversely, getting a notification of a change in a so-called real-time database in 500 milliseconds versus 100 milliseconds isn’t going to cause anyone to die.
So, all these so-called real-time databases are just real fast. They are “active” or “live” in that they proactively push relative database content to other connected systems. And that is how they should be described, active database or live database. The term real-time should be reserved for systems that are actually real-time, otherwise we risk the term ceasing to have any real meaning.
The characteristics of a database system that is real-time are:
- Database transactions are subject to timing constraints
- Transactions can be assigned different priorities
- Transactions are scheduled for execution according to their priority and, within the same priority, by the earliest deadline first
In contrast, non real-time database systems have:
- No concept of deadlines
- No concept of transaction priorities
- Simple first-in-first-out transaction scheduling policies
In non-real-time database systems, transactions can have two outcomes, committed or aborted. In real-time database systems, there are three possible outcomes, deadline met, deadline missed, and deadline exceeded. Transactions that meet their deadline are successfully committed to the database. Transactions that miss their deadline are deemed (by the database runtime) to not be able to be committed without exceeding the deadline and are forced to abort so that the transaction is complete before the deadline. Transactions that the database runtime determines cannot commit before its deadline are forced to abort to ensure completion before the deadline. Transactions should never exceed the deadline. If that happens, the integrity of the entire real-time system is questionable.
This leads to another difference between actual real-time database systems and non-real-time database systems. the criteria for goodness (a hip new technical term). Traditional database systems are commonly measured by throughput, which in turn is usually represented as some number of transactions per second (TPS). The measure of a real-time database, however, is the ratio of the number of transactions that met their deadline to the number of transactions that missed their deadline. Fast is a laudable goal, but operating within time constraints is the requirement.
