Raima Database Manager is an embedded relational database management system developed for time and mission-critical applications needing high performance, small footprint and compact storage.
Raima is perfectly designed to run on edge Industrial Internet of Things (IIoT) or Internet of Things (IoT) resource constrained devices where computing resources may be limited. Raima allows data to be summarized on the embedded device and pushed to the cloud or to another back-end database system.
Raima is designed for applications needing lightly embedded Lightly embedded databases have been used for many years; typically, they are based on hierarchical file structures. Lightly embedded databases like RDM differ from typical databases, such’s as IBM DB, Oracle and Microsoft SQL server, in that they are more integrated into the application in such way that the end- user has little if any, knowledge of its existence. Users and administrators are not burdened with time-consuming installations as the database is packaged with the application and should be self-maintaining. and deeply embedded Deeply embedded databases are recognized by being developed and deployed with the application/device itself and are not intended to be changed or manipulated with while it has been deployed. In these types of applications, the database is invisible to the end user. database requirements. The product provides the flexibility to run in-process with the application; allowing the application to become the database server; or, running as a more traditional client / server database. The result of this flexible architecture achieves fast, predictable performance with ACID An acronym that stands for: atomicity, consistency, isolation, and durability. It refers to important reliability properties of database transactions that a database management system must be able to guarantee. transactions on almost any hardware and software combination.
Flexible Application Modeling Design
Optimum performance is achieved when the database is closest to the data consumer or data producer. RDM provides flexibility with configuring the transaction engine (TFS) in-process with the application; remotely via a remote procedure call (RPC) across a network; or, a combination of both for a distributed database configuration. The remote transaction engine can be either a standalone process or even the in-process transaction engine in another application module.
The persistent database storage is optimized to increase write performance and transaction durability with the fewest number of actual disk-writes possible. The persisted database image is platform independent (portable to any hardware architecture).
For more information, see Persistent Database Storage.
RDM in-memory database (IMDB) implementation has been designed to either work as dynamically allocated memory (uses memory as needed) or work with a pre-defined, constrained memory block for heavily constrained resource application deployments. IMDB images can be preloaded from a persisted image on disk or saved to a persisted image by default or on-demand.
For more information, see In-Memory Database (IMDB).
Compact Data Storage
RDM implements simple compression techniques as well as optional LZMA compression to reduce the amount of data stored on the disk.
RDM allows the database to be encrypted using the Advanced Encryption Standard The Advanced Encryption Standard is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001. Based on the Rijndael cipher developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted a proposal which was evaluated by the NIST during the AES selection process. (AES). For encrypted databases, the communication with the remote transaction engines is also encrypted using the same encryption key. The supported block ciphers are AES-128, AES-192 and AES-256.
RDM supports multiple access methods to your database which can be use concurrently.
RDM SQL implements a full feature SQL interpreter which follows the ANSI 2012 standard for its implementation. The implementation features SQL Persistent Stored Module (SQL/PL) support and SQL Triggers.
For more information, see SQL Programming Language (PL) Guide and RDM SQL Triggers Guide.
RDM supports multiple different programming languages that interact with the SQL engine. For Java, Raima supports JDBC. For C/C++, Raima has full SQL CLI support direct to the runtime or through the Microsoft ODBC Driver Manager. RDM is designed so that whatever language the programmer is comfortable with, they can stay within that environment.
Native Cursor API
The RDM native cursor API is a low-level C/C++ access to the database when performance and memory footprint are key drivers in the decision making for selecting the interface language.
RDM allows for several methods of concurrency control to manage multi-user / multi-process or multi-task access to the database.
Exclusive access to the database (single task access) ensures no blocks on read or write transaction with an application process.
Pessimistic locking is the traditional lock-based concurrency control. The granularity of the locking mechanism for RDM is table-based. This method will serialize the access for writers and allows shared reading of the table by all readers. The locks are queued to be granted in chronological order.
Multi-Version Concurrency Control (MVCC)
RDM supports "snapshot isolation" within its MVCC implementation. Snapshot isolation guarantees a consistent view of the database at the time the snapshot was started while still allowing updates to the database to proceed uninhibited.
For more information, see Transactions and Locking Overview.
RDM supports multiple indexing methodologies to allow the requested information to be accessed quickly.
RDM implements the B+tree variant of the B-tree. This indexing method is a standard default for almost all disk-based DBMS vendors.
RDM implements its hash index using extendible hashing. The extendible hash provides quick access to the desired row through an index where next or previous key navigation is not needed.
RDM implements the AVL tree as another self-balancing binary search tree, like B-tree. The exception is that the AVL tree is much more suited to in-memory database configurations because of its reduced memory footprint. It provides all the same functionality as a B-tree index.
The RDM implementation supports multi-dimensional spatial data using a rectangular bounding box. Up to 4 dimensions can be supported.
The RowID access to the database is the fastest access method. Each row has a unique identifier than can be used to directly access the row data.