What is an Embedded Database?
There are two main definitions of an embedded database:
- Database for embedded systems-such as mobile devices or consumer electronics. The embedded database needs to have a small footprint and provide adequate performance in an environment with limited memory and CPU capabilities.
- Databases embedded in applications-this means the application does not communicate with a database server, and has a built-in database component. This type of database is commonly used in edge computing applications.
In both definitions, an embedded database system is a set of libraries associated with application or firmware code, which provides built-in database functionality to the application or device. This is different from a client/server database system, in which another process (database server) provides database services for one or more client applications.
- Embedded Systems Characteristics
- Requirements for Embedded Databases
- Types of Embedded Databases
- Embedded Databases: SQL vs. APIs
- Change Data Capture (CDC) and Embedded Databases
- Raima Embedded Database
Embedded Systems Characteristics
An embedded system is a combination of computer hardware and software designed to perform specific functions. Examples include smartphones, digital cameras, and connected cars. Embedded systems have the following characteristics:
- Comprise hardware, firmware, and software
- Designed for specific system tasks, so it is typically integrated into a larger system
- Compute power is provided by integrated circuits-a microprocessor or microcontroller
- Usually required to perform its tasks under a time constraint to support other components of the larger system
Requirements for Embedded Databases
To see if a database is suitable for use as an embedded database, consider the following requirements:
- Does it support CRUD (create, read, update, delete)?
- Does it support ACID (atomicity, consistency, isolation, durability)?
- Can I work with different programming languages and operating platform?
- Is it possible to move data easily to a central database?
- Is it maintenance-free with no need for database administrators?
In almost all embedded database situations, embedded applications need to store multiple complex data streams for analysis and action. They must be able to receive data from multiple sources, and perform reads and writes simultaneously. The database not only needs to store data, but also must maintain integrity and be able to recover in the event of a system failure.
You can use basic CRUD functionality to modify data, but it does not guarantee data integrity. ACID provides a much better level of integrity and can support transactional scenarios. In embedded scenarios, data records are written to the database in several statements. Here is how ACID can help support this requirements:
- Atomicity requires the database to allow or deny all the statements that comprise the record.
- Consistency helps prevent partial changes that may corrupt the data
- Isolation allows you to write multiple data records at the same time without affecting each other
- Durability means that if a record is committed, it stays committed even if the system fails
Failure to comply with ACID requirements increases the risk of database corruption. In environments with hundreds or thousands of devices, errors are more likely to occur, and ACID-compliance becomes more important.
Types of Embedded Databases
There are three main types of databases used in embedded scenarios.
Traditional SQL databases can be used in embedded systems, but must often sacrifice storage space or functionality. Some implement only part of the SQL syntax, or provide weakly typed SQL syntax, which does not guarantee integrity.
Time series databases measure, track, investigate and automate time-sensitive data streams. Time series databases sacrifice some ACID functions for speed. For example, if your system is trying to optimize the number of writes, records may be locked for a shorter period of time, which may reduce consistency.
Data historian systems collect and store large volumes of time-stamped data. A data historian is typically built into a device, and is mainly used to collect and transmit information, with limited analysis capabilities. It can provide a SQL query interface, it does not necessarily follow standard SQL syntax.
Embedded Databases: SQL vs. APIs
In many embedded systems, there is a choice between enabling SQL access to the database (typically using JDBC/ODBC) vs. proprietary API access. Let’s see some of the pros and cons of each approach.
Using SQL to Access Embedded Databases
- SQL is well known and can be immediately useful for developers and administrators, as are the JDBC and ODBC APIs.
- Provides flexible querying capabilities.
- Ability to apply an UPDATE or DELETE statement to multiple rows at the same time, while non-SQL APIs treat each row separately.
- The overhead required to parse, optimize, and execute queries is high. These steps use CPU cycles, memory and other scarce resources.
- SQL is often not exactly compatible with other systems, for example with object oriented programming. This is known as “impedance mismatch”. To resolve this, object-relational mapping (ORM) was introduced, but it added even more overhead.
Using Proprietary APIs to Access Embedded Databases
- Avoids impedance mismatch, because the same company designs the embedded database and its API.
- Eliminates the overhead of processing SQL queries, granting direct access to data.
- Using a proprietary API is a specialized skill which team members will have to learn.
- Locks you into a specific database system, making it difficult to migrate if it doesn’t meet requirements.
Change Data Capture (CDC) and Embedded Databases
CDC is used in many embedded systems to identify which data has changed, and saving the data change for future purposes. This can allow database recovery, replication and handling of streaming events.
There are three primary functions change data capture provides in embedded databases:
- Transaction logging-used to retrieve database transactions after a crash, using UNDO and REDO actions
- Triggers-actions called when the database detects an INSERT, UPDATE or DELETE operation
- Replication-CDC can support several modes of replication:
- Copying committed transactions (mirroring or transactional replication)
- Copying both committed and uncommitted transactions (log shipping)
Raima Embedded Database
Whether you need an embeddable database or a database for embedded systems, RaimaDB is the go-to solution. Our relational embedded database is optimized for high-performance throughput and low memory usage.
RaimaDB can be used through a call from its extensive suite of API’s including C/C++’s cursor interface, Java’s JDBC interface, and C#’s ADO.NET interface. It also supports the use of standard third-party tools through the ODBC driver manager.
Today, businesses face the challenge of an accelerating pace of business on the edge, where real-time decisions on input from multiple devices are critical. Today´s organizations demand to have everything immediately. RaimaDB has been created for applications that need real-time and reliable data.
With the increased deployment of flash and SSD storage in the embedded market space, minimized writes to the media are important to deliver high performance and, at the same time, make sure that the medium lifetime is extended. Raima is one of the few embedded database vendors that has this functionality built in.
Raima´s modular architecture is designed to meet the complex architecture of future embedded applications.
