In-memory and Persistent Database Management System

eXtremeDB: an in-memory and persistent database management system.

The eXtremeDB database management system was originally designed and optimized to be an in-memory database system (IMDS) with direct data manipulation. Storing and manipulating data in exactly the form used by the application removes overheads associated with caching and translation. On embedded platforms (e.g. ARM, PowerPC), typical write accesses are at the level of a few microseconds, or less, and read-only access is sub-microsecond.  (Review our independently audited STAC benchmark test results.)  When used as an embedded database system, the engine is reentrant, allowing for multiple execution threads, with transactions supporting the ACID properties, assuring data integrity.

In addition, eXtremeDB combines the strengths of on-disk and in-memory database systems. Databases can be all-in-memory, all-persistent, or have a mix of in-memory tables and persistent tables. This unparalleled flexibility enables developers to tailor data management in order to optimize applications for speed and persistence, and make intelligent tradeoffs between cost-efficiency, power consumption, and physical space-conserving data storage hardware.

Data management where you need it

eXtremeDB can be utilized as an embedded database management system (typical in embedded platforms for Industrial Control, Aerospace/Defense, Consumer Electronics, and Network/Telecom gear), or as a highly scalable client/server architecture able to be distributed through sharding to gain maximum advantage of multiple cores, CPUs and/or servers (typical for High Performance Computing and Financial systems in private or public clouds).

Use the following menu to learn more about . . .

Embedded Platforms:

eXtremeDB was designed and implemented to be highly portable. Currently, eXtremeDB runs on Win32 and Win64 platforms, Linux, many Unix platforms, and various embedded operating systems including VxWorks, INTEGRITY, ThreadX, eCos, FreeRTOS and QNX, and target CPUs including x86, PowerPC, ARM, MIPS, and others. The list of supported platforms is constantly expanding.

• Find a current list on the eXtremeDB technical specifications page.
• Review a list of several platforms on our free trial page.  If you don’t see the one you’re looking for, please contact us so that we may prepare a special package for you.
• Read a summary of the White Paper, Portability Techniques for Embedded Systems Data Management by Andrei Gorine, McObject CTO & Co-founder

Back to Top

The eXtremeDB runtime environment provides:

• Accelerated transactions. The eXtremeDB in-memory database system stores data entirely in main memory, eliminating the need for disk access, caching and other processes that add overhead to disk-based databases. The eXtremeDB transaction manager is optimized for high transaction rates. When persistence is required, eXtremeDB gives you choices.
• Ultra-small footprint. eXtremeDB was originally designed to be an in-memory embedded database system. In this configuration, it eliminates many artifacts of persistent database systems and enables an unbelievably small code size of approximately 200K. As a persistent database system, the code size of eXtremeDB can still be under 200K. And, as a full-on SQL relational database system, the code size is still on the order of just 500K. This makes eXtremeDB a powerful enhancement to many intelligent devices with resource limits that, until now, ruled out the use of an embedded database system.
• Direct data access. Earlier data management technology required copying records from database storage to cache, and then to a new location for manipulation by the application. By operating as an in-memory database system that works with data directly in main memory, eXtremeDB eliminates the overhead of duplicate data sets and of copying data between locations.
• No Translation. eXtremeDB stores data in the exact form in which it is used by the application – no mapping a C data element to a relational representation, for example, or requiring additional code to pick fields from tables and copy them to C structures. By eliminating this overhead, eXtremeDB reduces memory and CPU demands.
• High reliability. For data integrity, eXtremeDB transactions support the ACID properties, ensuring that operations grouped into transactions will complete together or the database will be rolled back to the pre-transaction state.
• Native language APIs, as well as SQL. The native language API for C/C++ derives from the given application’s database schema and thus reflects the purpose for which it is being used. For the runtime environment, this means more reliable code – the C/C++ compiler will catch data typing and assignment errors when the application is built. This makes eXtremeDB-based applications more reliable, since it is much harder for coding errors to make it into the final build. For Java, the language itself can be the schema language by incorporating decorations into the class definitions, which are used at runtime to build the database dictionary. Multiple languages can use the same database by using one language to generate the database schema for the other language(s).  C# can be used with the ODBC .NET Managed Provider.

Download a free evaluation of the eXtremeDB in-memory and persistent database.

eXtremeDB is designed for High-Performance: optimized memory managers, hash and tree-based indices, multiple data layouts, transactions with priority scheduling and an application-specific API.

Try a free evaluation of the eXtremeDB in-memory and persistent database system.

Back to Top

Developers strive to produce readable, maintainable, efficient code in the shortest possible time. The eXtremeDB in-memory database system (IMDS) includes several features that boost the developer’s capabilities when integrating the database in demanding IoT/real-time applications. Incorporating third party software often means learning and adopting an API that does not completely fit an application. eXtremeDB’s project-specific API ensures that each database operation in the API reflects the type of the data being manipulated. To help in application debugging, McObject’s embedded database includes numerous traps in the runtime code; these can be selectively disabled as development and testing progresses, to optimize the application for speed. McObject offers full source code, to give an in-depth understanding of eXtremeDB within an application. In addition, eXtremeDB supports virtually all data types as well as extremely efficient indexing for queries. For querying, McObject provides hash indexes for exact match searches; tree indexes for pattern match, range retrieval and sorting; and object-identifier references, for direct access. Specialized indexes support domains such as IP/telephony (Patricia trie), geospatial (R-Tree), query-by-example (KD-Tree) and fuzzy search (Trigram). Indexes are constructed and optimized according to the storage media. For an in-memory database, rather than storing duplicate data, indexes contain only a reference to data, keeping memory requirements for an in-memory database to an absolute minimum. For a persistent database, index structures include the indexed data to minimize I/O operations and optimize performance. With the eXtremeDB embedded database and native language C/C++ API, the developer focuses on the data definition first, then eXtremeDB generates the API from this definition via the schema compiler.

searThe result is:

• An easy-to-learn API that is optimized for the application.
• Code that is more legible as well as easier to write and maintain.
• Compile-time type checking that helps eliminate coding errors.

Example: The following is a (simple) class and an example of the API to put a new value into a record in the database:

Watch the Webinar:   Using Data Indexes to Boost Performance and Minimize Footprint in Embedded Software

Progressive error detection and consistency checking features If an application mistakenly passes a corrupted transaction or object handle into a runtime method, eXtremeDB (by default) raises a fatal exception and stops the execution of the program. In most cases, the application developer can then examine the call stack to find the source of corruption. The eXtremeDB runtime implements many verification traps and consistency checks like this. Obviously, that does not come free; the runtime requires extra CPU cycles and space for that. However, when the application is debugged and consistently passes verification tests, developers can link the optimized version of the eXtremeDB runtime, removing the traps and internal checks to restore valuable clock cycles.

Complex data types and efficient queries

• Supports virtually all data types, including strings, boolean, binary, structures, arrays, vectors and BLOBs
• Querying methods include hash indexes for exact match searches
• Tree indexes support queries for pattern match, range retrieval and sorting
• “Voluntary” indexes for program control over index population
• Object-identifier references provide direct data access
• Autoid for system-defined object identifiers
• Rather than storing duplicate data, indexes contain only a reference to data, minimizing memory requirements
• Synchronous/asynchronous event notifications

Download eXtremeDB for a free a 60 day evaluation, review our Technical FAQ page, or online documentation.

Back to Top

The eXtremeDB database system can operate in conventional memory, or shared memory for multi-processing environments such as Windows, Linux, Solaris, QNX, etc. When in shared memory, an eXtremeDB database or cache for a persistent database is created in shared memory and mapped to the local address space of each process, thereby allowing multiple processes and multiple threads within each process to share eXtremeDB in-memory databases and/or the cache of a persistent database. The shared memory eXtremeDB runtime is built as a different binary (library or archive) than the conventional memory version. Depending on the target platform, eXtremeDB supports one of the following three synchronization methods when managing shared memory databases:

• A System V semaphore mechanism is implemented for operating environments such as Sun Solaris and Linux platforms (System V semaphore methods are associated with system-wide integers, called keys, which are associated with files).
• A POSIX shared memory implementation that is suitable for QNX, AIX, HPUX, Linux, Lynx, SunOS and NetOS.
• A Win32 shared memory implementation is deployed for the Microsoft Windows Embedded and Microsoft Windows classic platforms.
• An INTEGRITY native synchronization implementation.
• An eCos native synchronization implementation.
• A ThreadX native synchronization implementation.
• A uCos native synchronization implementation.
• A VxWorks native synchronization implementation.
• A WinRT native synchronization implementation.

Click here to try a free evaluation of the eXtremeDB on-disk and in-memory database.   Or review our Technical FAQ page, or online documentation.

Back to Top

eXtremeDB provides Web Services using the popular REST (Representational State Transfer) protocol. The REST server can be accessed using any language that supports HTTP and JSON, which includes but is not limited to C/C++, Python, Java and C#. Note that the REST server is simply an HTTP server that serves JSON content, and thus conforms to the HTTP and JSON standards.

Learn more about the eXtremeDB embedded database in our extensive documentation.

Back to Top