Using a High-Performance Embedded Database
By Steve Graves, McObject

Today’s telecommunications systems often must store, sort, and retrieve large amounts of complex data. Many developers meet this need by integrating a commercial, off-the-shelf (COTS) embedded database. They gain the reliability of integrating proven software, and the development efficiency of using a COTS component.

But database management systems (DBMSs) vary widely. There are many embedded databases, most designed for desktop or business software rather than embedded systems. The following key concepts will help you understand the jargon, allowing you to select the product that meets your needs.

Database API
A database system’s application programming interface (API) greatly affects development and run-time performance. The SQL API is a standard for enterprise applications because of its long history and widespread use. However, few embedded developers know SQL. Furthermore, its high abstraction level allows little control over application performance and memory consumption, and its on-the-fly parsing, optimization, and execution cause unpredictable response times.

In contrast, native APIs are more deterministic. They typically integrate with common programming languages such as C or C++ and step through the database one record at a time. Execution paths are pre-determined, so execution times are predictable and faster than SQL.

In-Memory vs. Disk-Based Systems
Most standard database systems cache frequently requested data in memory for faster access, but write changes to disk. A recent approach is the in-memory database system (IMDS), which eliminates disk access and manages data entirely in main memory. The main advantage of in-memory systems is fast performance, through elimination of disk accesses. With in-memory systems, the database system itself (though not necessarily the database’s contents) is generally smaller and simpler—as small as 100K code size in the case of eXtremeDB (see below).

On-disk databases avoid the issue of volatile memory, although in-memory databases can add persistence through support for non-volatile RAM (NVRAM), high availability/replication, and transaction logging.

Database Architectures
Some embedded databases utilize the client/server design typical of enterprise DBMSs, with client applications requesting information from a server via an inter-process communication “layer”. Other embedded databases consist instead of code libraries that are actually compiled into an application. This architecture is simpler, faster, and more efficient, but does not scale to support many concurrent connections (users) as readily.

McObject’s eXtremeDB
McObject’s eXtremeDB is the first embedded DBMS built from scratch to cope with the stringent performance demands and often limited hardware resources of embedded systems. Since its introduction, McObject has extended eXtremeDB’s core in-memory engine and native API, adding options such as support for SQL (eXtremeSQL), hybrid in-memory/on-disk data storage (eXtremeDB Fusion), and a proven high availability edition (eXtremeDB-HA).

Conclusion
As telecommunications systems increasingly need to retrieve, store, and sort large amounts of data quickly, developers are moving toward incorporating COTS embedded databases. Like off-the-shelf operating systems, such software provides proven functionality and allows developers to focus their efforts on product-differentiating features. The use of commercial databases speeds time-to-market, simplifies testing, and reduces resource consumption. Recent advances have led to databases better suited to the requirements of embedded systems and the backgrounds of their developers.