Real-time Database Systems
& eXtremeDB Solutions

eXtremeDB was originally conceived, designed and implemented as an in-memory database system

In contrast to in-memory capability that has been added on to what was originally a persistent, disk-based, DBMS, an IMDS avoids caches (no database cache and, more importantly, no file system cache). Any cache introduces indeterminate behavior (e.g. the uncertainty of a cache-hit or a cache-miss). The problem is exacerbated with hard disk drives; in the event of a cache-miss, the rotational latency of the drive is unpredictable. Rotational latency is the time waiting for the platter to spin and the disk head to re-position in order to read or write the desired track and sector of a platter).  Read a white paper about this topic, or visit our in-memory database Q&A page.

eXtremeDB never allocates system memory (e.g. malloc)

Implementations of malloc are “list allocators”. They keep a singly-linked list of free memory blocks. When a request is made for dynamic memory, the allocator walks the list until a free memory block that is large enough to satisfy the request is located. The problem here is, it is impossible to know for any given allocation request, how far the allocator will have to walk the list to find a suitable free memory block. Further, the linked list is a shared resource and must be protected from concurrent access, so a task requesting memory can be put into a wait queue for an indeterminate length of time. So, there are two sources of non-deterministic behavior: time spent walking the linked list, and time spent in the wait queue.  Read this article to learn more.

eXtremeDB provides hash indexes (in addition to b-tree, r-tree, patricia trie and trigram indexes)

Unlike tree indexes, hash indexes can be deterministic. Tree indexes are inherently non-deterministic: the search for a given value in a tree index always begins at the root node and progresses down the tree until the node on which the value resides is located. This could be at the root node itself, or deep within the tree. Once the particular node is located, a binary search is conducted within the node’s slots. The binary search can find the value immediately, or exhaustively search the slots (the binary search could require nslots / 2 probes). So, both the time to find the tree node of interest, and the time to find the value within the node are not deterministic. In contrast, a hash algorithm is constant, resulting in exactly the bucket of the hash table containing the search value. If the hash table is large enough, collisions are avoided (collisions would introduce a new, different, type of indeterminate behavior).  Learn more.

eXtremeDB is an embedded database system

That means that the database object code is linked with the application code in a single executable program image. This is in contrast to a client/server database system, which requires inter-process communication (IPC) or remote procedure calls (RPC) between the database client and the database server. IPC and RPC require interrupts, context switches, and, in the case of RPC, network latency. All of these introduce non-deterministic behavior and are unsuitable for real-time systems.

eXtremeDB offers a native C language API, when many DBMS only offer an SQL API

SQL is a wonderful language for OLTP systems, but entirely inappropriate for real-time systems. SQL requires parsing of the SQL statement and formulation of an execution plan. Formulating the execution plan requires analysis by an optimizer. The time needed by the optimizer is inherently unpredictable, which renders all of SQL non-deterministic. In contrast, a native C API is just function calls. A programmer can count the number of machine language instructions that the C compiler generates, and using the information about the CPU, calculate the time required, whether the function can complete within one cycle, etc. In other words, it is deterministic as long as the function call avoids non-deterministic artifacts like memory allocation, trees, caches, etc. Read our white paper about this topic.

eXtremeDB provides transaction priority

When an eXtremeDB transaction is started, it can be assigned one of 5 priority levels and will be queued accordingly by the eXtremeDB transaction manager. It should be used in concert with real-time operating system task priorities (and care should be taken not to create a priority inversion).  Learn more in our online documentation.