What is RDM – what does it consist of ?
The core of the product is a database engine. It provides functionality for storing and retrieving data quickly and reliably. It can be completely built into the application (linked into the application executable), or it can consist of a client-side component built into the application and a server-side component that runs as an independent process.
There are also further components that may be used with the core engine: a SQL engine, replication and mirroring, as well as multiple APIs/interfaces and numerous developer tools.
How does the database address data integrity?
RDM’s lock management system gives control over access by concurrent users, ensuring that only a single user can write to a particular record at a time. The system writes a group of related database updates as a unit, first to the transaction log, and then to the database, allowing data to be regenerated automatically in case of system error.
How does RDM’s choice of database models help developers model data?
The database allows developers to combine the strengths of two proven database models: relational and pointer-based. The pointer-based network model allows you to easily move from a record to its “child” records (a set of related records). If the child records are generally read together in the same order then the network model allows much better performance than the relational model, by greatly reducing the number of database reads required. Developers can utilize the familiar relational database model, or the network database model with the advantages of greater data integrity, higher performance, and reduced storage requirements. RDM Embedded also allows developers to combine both models in a single application, so the benefits of both can be utilized to optimize applications.
Why doesn’t Raima’s RDM Embeddded support all of the SQL API?
Embedded SQL was originally designed from the ground up to run in restricted environments. In these environments, excess code in a database engine takes away from valuable space needed by applications. Our selection of ODBC API functions and SQL language was based on what was essential for programming embedded applications. Even in larger environments, a complete SQL is not desirable. Embedded databases are typically controlled by a single application where the concept of users with various levels of access rights on views of the database is irrelevant. By omitting views and access rights functionality, Embedded SQL is optimized for the embedded deployment.
Can I use existing application with RDM Embedded without changing the dt_API?
Yes, the RDM Embedded API is slightly different than the two API’s provided by RDM Embedded 5.0. The native RDM Embedded API always includes a task parameter, and always uses the “d_” prefix. This release provides optional translations from the previous “dt_” API to the new form of the RDM Embedded API. Programmers may choose to leave existing applications unchanged by using one of the provided translations, or they may change their source to the new API. To utilize the translation, preprocessor constants must be defined, either on the command line or in application source code prior to the RDM Embedded headers.
If I put my database on a flash drive will RDM minimize the amount of disk writes, to preserve the flash lifetime?
RDM will always minimize disk writes, but if the database is disk-based, and transactions are frequently written to the database, disk writes are inevitable. The database page size is configurable, which can help by controlling the granularity of writes.
To maximize the flash lifetime the best option is to define the database as “in-memory persistent”, so that it only gets written to flash when it is closed, or when it is explicitly flushed to disk. RDM is optimized to write only the changed pages to disk when it flushes an in-memory persistent database.
I need to store my embedded database in memory, for performance reasons, but I cannot afford to lose the whole database if there’s a power failure. Losing the most recent data is acceptable, but not everything. Is there some compromise I can make?
Yes, you can store the database in memory and periodically flush it to disk. In RDM the flush operation is done safely, such that there is no risk of database corruption if the system fails while you are in the middle of flushing to disk. RDM offers three options for in-memory databases: “volatile”, “read” and “persistent”. A “volatile” in-memory database has no disk backup at all. A “read” in-memory database is read from disk the first time a task/thread opens it, but never written back to disk. A “persistent” in-memory database is read from disk the first time a task/thread opens it, and written back to disk when the last task/thread closes it. This type of database can be explicitly flushed at any time by the application.
I have a very large database with a lot of client applications reading and updating it. I would like to just get a powerful server with lots of cores and plenty of memory, and run a database server on it. The database server should be scalable, and exploit the hardware to guarantee good performance. That would be nice, but this solution may not prove optimal, with any database server. In practice there are always limits to how much parallel processing can be done within a single database server. This is partly because the server cannot know how best to allocate the resources it has. Multiple threads in the server can only update the database truly in parallel if they are writing to independent drives through independent disk controllers. And how can the database server know how to allocate disk space on different drives to ensure that this generally happens?
To ensure that resources are efficiently distributed across threads or processors it is usually necessary for the application and database to be designed around the intended pattern of data access. Sometimes the application writer must explicitly specify how the data will be distributed between drives, because only the application writer knows how the data will be accessed.
RDM supports distributed databases and parallel processing by allowing multiple lightweight servers to run on multiple cores or processors, and by providing the application with the ability to read data from all of these as if it was reading from one database.
Our embedded system receives data continuously at a high rate from sensors and other connected hardware. This data must be stored without data loss, and must also be available for reading by a monitoring process. How can I prevent the monitoring process from slowing down the storage rate, or blocking the incoming data?
The answer depends on how much memory there is on the embedded device, and how powerful the processor is. If there is a lot of memory, and the processor is powerful, you may be able to use Multi Versioning Concurrency Control (MVCC) to allow the monitoring process to read data during updates. If there is not so much memory or processor-power, it may be necessary to replicate the data from the embedded device to another system, and run the monitoring process there. RDM’s asynchronous replication puts very little processing overhead on the system.