Raima Database Manager

Non-SQL (core) DDL Features:

• C struct-like record type (table) declarations.
• Network model set declarations for defining 1-many inter-record relationships.
• Support for direct, B-tree, and hashed record access.
• In-memory database or file declarations. A database can be designed to be either on-disk or in-memory, or a hybrid where some parts reside in-memory while others are stored on disk.
• Circular record types (tables). Circular tables store a user-specified maximum number of records (rows). When that maximum has been reached, newly inserted records are stored in the location occupied by the oldest one. Circular tables are important for storing status data on resource-restricted devices.
• Supported datatypes: 8, 16, 32, and 64 bit signed or unsigned integers, float, double, decimal (BCD), fixed or variable-length character or wide character, binary or character large objects (blobs), date, time, timestamp, guid/uuid, and db_addr (database address—aka, rowid).
• Support for struct and array data fields.
• Optional user control over database file organization and page sizes.

SQL DDL Features:

• Declared referential integrity support automatically implemented using RDM's network model sets.
• Support for direct, B-tree, and hashed row access.
• In-memory database or table declarations.
• Circular tables.
• Virtual tables declarations that provide SQL access to external data sources (e.g., real-time sensor data).
• Supported data types: boolean, tinyint, smallint, integer, bigint, decimal, real, float/double, binary/varbinary, long varbinary, char/varchar, wchar/wvarchar, long varchar, long wvarchar, date, time, timestamp, guid/uuid, rowid (foreign and primary keys).
• Domain declarations.

The RDM Transactional File Server (TFS) specializes in the serving and managing of database files on a given medium. The TFS is a set of functions called by the RDM runtime to manage the sharing of database files among one or more runtime library instances. In a normal multi-user configuration, the TFS functions are wrapped into a server process called TFServer. Standard TCP/IP can be used to make the connection, whether the runtime library and TFServer are on the same computer or different computers. However, when on the same computer, a faster, shared-memory protocol is available by default.

The figure shows that one RDM client runtime may have connections to multiple TFServers, and one TFServer may be used by multiple client runtimes. To the applications using the RDM runtime and the TFServers, the locations of the other processes are invisible, so all processes may be on one computer, or all may be on different computers. This provides opportunities for true distributed processing.

Raima Database Manager Transactional File Server Operation

A TFServer should be considered a “database controller” in much the same way as a disk controller manages a storage device. A TFS is initialized with a root directory in which are stored all files managed by the TFS. If one computer has multiple disk controllers, it is recommended that one TFServer be assigned to each controller. This facilitates parallelism on one computer, especially when multiple CPU cores are also present.

A complete application system may have multiple TFServers running on one computer, and multiple computers networked together. Each TFServer will be able to run in parallel with the others, allowing the performance to scale accordingly.

The TFS functions are used by the RDM runtime, so the programmer has no visibility of the calls made to them. These functions are made available to the runtime library in three forms. For descriptive reasons, we call them TFSr, TFSt and TFSs:

• TFSt: The actual, full-featured TFS functions, called directly by the runtime library. Supports multiple threads in a single application.
• TFSr: The RPC (Remote Procedure Call) library. When called by the runtime library, these functions connect to one or more TFServer processes and call the TFS functions within them. A client/server configuration.
• TFSs: “Standalone” TFS functions called directly by the runtime library, but intended only for single-process use (if multiple threads are used, each must be accessing a different database only). To be used for high-throughput batch operations while the database(s) are otherwise offline. Unsafe (but fast) updates are allowed.

RDM's database union feature provides a unified view of multiple identically structured databases. Since RDM allows highly distributed data storage and processing, this feature provides a mechanism for unifying the distributed data, giving it the appearance of a single, large database.

As a simple illustration, consider a widely distributed database for an organization that has its headquarters in Seattle, and branch offices in Boston, London and Mumbai. Each office owns and maintains employee records locally, but the headquarters also performs reporting on the entire organization. The database at each location has a structure identical to the others, and although it is a fully contained database at each location, it is also considered a partition of the larger global database. In this case, the partitioning is based on geographical location. The mechanism for querying a distributed database is simple for the programmer. When the database is opened, all partitions are referenced together, with OR symbols (“|”) between the individual partition names.

Partitioning and unified queries are also used for scaling the performance. Consider a database where each operation begins with a lookup of a record’s primary key. If the“database” is composed of four partitions, each stored on the same multi-core computer, but on different disks controlled by different disk controllers, then the only requirement is a scheme that divides the primary key among the four partitions. If that scheme is a modulo of the primary key, then the application quickly determines which partition to store a record into or read the record from. Since there are multiple CPU cores to run the multiple processes (both the applications and the TFSs), and the four partitions are accessible in parallel (the four controllers permit this), the processing capacity is four times larger than with a single-core, single-disk, and single-partition configuration.

RDM allows all database content to be encrypted before it is transported across a network and written to the database files. RDM's encryption supports the Rijndael/AES encryption algorithm with 128-, 192- or 256-bit keys based on an application-specified encryption key.

Database mirroring in RDM reproduces an exact, byte-for-byte copy of a master database onto the mirrored (or slave) database. Database mirroring is an important database feature for applications that require high availability (HA) where should a TFServer fail for some reason, then the application's HA monitor can automatically switch over to the mirrored TFServer.

RDM provides synchronous mirroring where each transaction that is committed on the master TFServer is also securely committed to the mirror TFServer. RDM also provides a set HA support API functions that can be called from the application's HA monitor to monitor the operational status of the TFServers.

Mirroring can also be used to support maintaining multiple copies of a database in which updates are only made to the master but readers are directed to one of the mirrored slaves in order to distribute many possible database readers across multiple computers. In this situation, it is not necessary for the master to wait for each slave to confirm a successful commit of each transaction and the mirroring process can run asynchronously.

RDM database mirroring requires that the master and all mirrored databases be maintained on the same computer/operating system platforms.

This is due to be released in Q2/18. Replication is similar to mirroring but it not really intended for HA support but for transferring all or, more likely, portions of one database (master) to another database (slave). Replication is designed to work where the databases are not necessarily being maintained on the same platform. The slave databases can be other RDM-managed databases or they can be a 3rd-party DBMS.

RDM's replication includes support for multiple master to single slave selective replication of circular table data—important for embedded computers and devices at the edge of the data grid where status and condition monitoring occurs. The status data stored in each master's circular table is replicated to a central control system maintaining a permanent history of all device statuses, which can then be made available for a variety of time series and other analyses.

RDM also provides a database change notification API library that allows a slave to access the master replication logs without the data be stored and managed in a database. This allows, for example, a master to store device control information in a database that is replicated to the device through the notification API in order to efficiently control device operation.

The RDM SQL Programming Language (SQL PL) is based on the ansi/ISO SQL Persistent Stored Modules (PSM) specification (ISO/IEC 90756-4:2011 +2012). It provides a high-level language in which stored procedures and functions can be written, compiled and called within the RDM SQL system.

• SQL PL is a computationally complete programming language for use in RDM SQL stored routines (procedures or functions). The language is block structured with the ability to declare variables that conform to the usual scoping rules with an assignment statement so that value can be assigned to them. Control flow constructs provided include if-elseif-else and case statements along with several loop control constructs (including while, repeat-until, and for loop statement).
• Seamless access to SQL is provided via the ability to execute most SQL statements that can include references to locally declared variables. Also provided is the ability to declare cursors allowing rows from select statements to be fetched into locally declared variables, allowing the result column values to be checked and manipulated within the stored routine.
• Exception handling is also provided, allowing handlers to be coded for specific or classes of errors or statuses returned from the execution of an SQL statement. In addition, it is also possible to define a user condition and exception handler and for the program to signal its own, special-purpose exceptions.

RDM SQL has been designed specifically for use in embedded systems applications. Some of the more important features of RDM SQL include:

• Small footprint—no SQL views or security is provided as these are usually unnecessary in embedded systems apps and their absence helps to keep the SQL footprint small.[2]
• Standard SQL transaction and referential integrity support.
• The SQL system catalog and stored procedures can be stored in a file or as statically declared data structures in C modules.
• Cost-based query optimization with a rich set of built-in scalar and aggregate functions. A variety of table access methods are available for consideration by the optimizer: direct row access (through rowid primarykeys), optimal primary/foreign key join access through network model sets, B-tree and hash indexes.
• Ability to extend SQL capabilities through C-based user-defined scalar and aggregate functions.
• Ability to extend SQL capabilities through C-based user-defined virtual table interfaces that provide SQL access to external data sources such as real-time sensor data.
• Database table import/export to/from comma-delimited or XML files.
• Ability to have read-only access from SQL to a non-SQL (i.e.,core level) database. This means, for example, that a remote RDM SQL application can access a non-SQL RDM database running on a very resource-restricted device.

RDM provides application programming interfaces that allow application development in a variety of programming languages:

• C based Cursor API – Facilitates the traversal of database records for retrieval, insertion, update and removal of database records. With Record, Key and Set cursors, it fits seamlessly with RDM’s database concepts. It resembles modern programming concepts of iteration over a collection.
• Comprehensive SQL API – Accessed internally through a simplified ODBC-like API that uses a Raima design. It also supports stored procedures and most other standard SQL.
• SQL Programming Language (PL) API – Allows programming logic to be done through pure SQL. Developers can leverage their knowledge of SQL and still add programming conditionals and logic.
• Standards Based ODBC API – Following the ODBC standards, the ODBC API was developed so developers have a familiar way to use the RDM database engine.
• JDBC – Standard JAVA interface to the RDM database engine, with two modes of operation: the first through TCP/IP and the second a direct link through JNI.
• ADO.NET – Standard C# interface. Supported connection method is through TCP/IP.
• RESTful – The REST-ful API is a modern API designed for application developers who want to be able to view and modify database contents through HTTP GET, POST, PUT and DELETE methods with a return format of JSON. Additionally, an administrative set of APIs is exposed to allow for a quick overview of the whole RDM subsystem's status. Items such as memory usage, CPU usage, database size, and database configuration are all available through the HTTP interface. This API is perfect for the developer who is interested in web development or wants to create a quick interface to an RDM database that is accessible on any platform through a web browser.
• Object Oriented C++ Cursor API – The C++ API was designed to be easy to use while providing developers with full access and control to both RDM’s network and relational functionality.
• Legacy Navigational C API –RDM’s low-level C is still supported, with minor changes required for the developer.

RDM has been ported to a wide variety of computers and operating systems. Packages are available for the following platforms:

• MS Windows 32, 64 bit
• Linux 32, 64 bit
• Android
• QNX Neutrino ARM/x86/PPC 32-bit
• Wind River VxWorks
• Green Hills Integrity
• macOS 64-bit
• HPUX PA-Risc/Itanium 32, 64 bit
• Solaris SPARC/x86 32, 64 bit
• AIX PPC 32, 64 bit.
• iOS
• FreeRTOS