The primary design objective for eXtremeDB is to provide extremely high performance, low latency, and the efficient use of storage space for the kinds of applications to which it is targeted. These applications are different from ordinary database business applications such as payroll or inventory programs.
First of all, eXtremeDB-based applications and embedded systems may run on inexpensive processing equipment with small amounts of memory and often without any permanent storage device. Secondly, in-memory data access must be fast (i.e. low latency) and predictable; simple queries and transactions should take at most a few microseconds, even when using slow processors; the amount of data that needs to be stored is relatively small compared to enterprise databases, and transactions are usually short. On the other hand, the data that needs to be stored can be complex.
With respect to high performance and low latency, eXtremeDB is a relatively compact set of libraries (relative to other DBMS). There are two implications of this:
1) A short code path means that the entire execution path can be loaded in L1 cache so that the instructions execute at CPU clock speed, versus multiple fetches from RAM across the much slower front-side bus.
2) As a set of libraries, eXtremeDB is an embedded database; the database functionality exists in the same address space as your applications, thereby eliminating inter-process communication with a separate database server from the execution path.
With respect to efficient use of storage space, eXtremeDB was designed from the start to be an in-memory database system, which has design goals that are diametrically opposed to disk-based database systems. Whereas an on-disk database will consume extra storage space (which is assumed to be cheap and abundant) to avoid file I/O (which is an expensive operation), an in-memory database is designed to use storage space as efficiently as possible because RAM is the storage space and is not cheap, or abundant. The result is that eXtremeDB can store more data in a given amount of memory than its competition.
Representative application domains are military / aerospace systems, process control, network / telephony infrastructure equipment, and consumer electronics. So the eXtremeDB design goals were derived from the requirements of these target applications, which are typically high transaction rate programs with,
a) soft or hard real-time requirements,
b) dynamic data streams, and
c) cost-effective (limited) hardware resources.
An important constraint is to fully support the conventional DBMS ACID transaction properties to assure database integrity and durability in the case of application and system failures.
To these goals was added the need to provide an easy-to-use approach to database application development and to give the developer the maximum possible configurability and control over the performance and impact of the database runtime within their applications. So, with these overriding requirements, the guiding principles in the design of the eXtremeDB include:
- Minimize resource requirements — essentially memory. Object sizes are kept small—the overhead that eXtremeDB introduces is low and, to a degree, controllable from the application
- Keep code size low
- Eliminate extra layers of code by closely integrating database storage and the host application language. Target applications often have many very small database transactions rather than large ones. That means that the operation to obtain data from an object, given a pointer or reference to the object, has to be very fast, otherwise the overhead cost (such as the cost of sending a “message”) could become prohibitive. The eXtremeDB data access methods make it possible to reference database objects at nearly the same speed as that of program variables
- Provide native support for dynamic data structures such as time series, variable-length strings, lists and trees. eXtremeDB “extends” the C/C++ language by supporting dynamic data in a very efficient (fast), safe (transactional), and compact (memory) way. Likewise, the Python extension module provides convenient Python database navigation classes, the Java API provides native Java language “data-enabling” and the eXtremeDB C# API integrates with the C# language and enhances LINQ query performance.
Send feedback on this topic to McObject.