Raima Database Manager
Raima Database Manager (or RDM) is an ACID-compliant embedded database management system designed for use in embedded systems applications. RDM has been designed to utilize multi-core computers, networking (local or wide area), and on-disk or in-memory storage management. RDM provides support for multiple application programming interfaces (APIs): low-level C API, C++, and SQL(native, ODBC, JDBC, ADO.NET, and REST). RDM is highly portable and is available on Windows, Linux, Unix and several real-time or embedded operating systems. A source-code license is also available. RDM has support for both non-SQL (record  and cursor level database access) and SQL database design and manipulation capabilities. The non-SQL features are important for the most resource-restricted embedded system environments, where high performance in a very small footprint is the priority. SQL is important in providing a widely known standard database access method in a small enough footprint for most embedded systems environments. History. Raima Inc. originally released RDM in 1984 and it was called db_VISTA. It was one of the first microcomputer network model database management systems designed exclusively for use with C language applications. A companion product called db_QUERY was introduced in  1986, which was the first SQL-like query and report writing utility for a network model database. A db_VISTA derivative DBMS designed to provide a high-performance, transaction-processing client-server SQL DBMS called Raima Database Server (RDS) was released in 1993. This was the first DBMS that provided an ODBC API as its native SQL interface. It was also the first SQL system that incorporated use of the network model in its DDL features. Soon thereafter, RDS was renamed Velocis and in 2001, RDM Server. Version 8.4 of RDM Server was released in 2012. Uninterrupted development of RDM (also  known as RDM Embedded) has continued, with the most recent feature additions including database mirroring use in support of highly available (HA) systems, database replication, multi-version concurrency with read-only transactions, multiple transactional file server access, encryption, and an SQL designed specifically for use in embedded systems applications. Version 12.0 of RDM was released in 2013. Also in 2013, RDM introduced the first on-platform SQL DBMS available for use with National Instruments' LabView graphical programming language; it was named the National Instruments' LabView Embedded Tools Network Product of the Year. Version 14.0 of RDM was released in Q3/16 . RDM v. 14.0 contains an all-new data storage engine optimized specifically for working with in-memory resident data sets. The new in-memory database (IMDB) allows for significant performance gains and a reduction in processing requirements when compared to older in-memory or on-disk implementations. Version 14.1 of RDM was released in Q1/18. The new release focuses on ease of use, portability, and speed. With Raima's new file format, you can develop once and deploy anywhere. Performance is increased by over 50-100% depending on the use case when compared to previous RDM releases. Raima has extended  and improved SQL support, snapshots, and geospatial functionality. Version 14.2 of RDM was released in 2020. The new release has continuous focus on ease of use, portability, and speed. Multi-user Focused Storage Format: the updated database file format increase database throughput through a focus on locking contention prevention. Extended and improved geospatial functionality and a newly supported REST-ful interface have been added to the database server functionality. Version 15.0 of RDM was released Q2 in 2021. The focus of that release was speed, ease of use and new functionality. Custom generated time series support has been added to  RDM. Also FFT support for data transformations. An administrative GUI is introduced. Product features. Both the source code lines and features in Raima Database Manager and RDM Server are consolidated into one source code. RDM includes these major features: updated in-memory support, time series and FFT support, snapshots, R-Tree support, compression, encryption, SQL, SQL PL, and platform independence—develop once, deploy anywhere. RMD includes portability options such as direct copy and paste that permit development and deployment on different target platforms, regardless of architecture or byte order. The release includes a streamlined interface that is cursor-based, extended  SQL support and stored procedures that support SQL PL; it also supports ODBC (C, C++), ADO.NET (C#), RESTful and JDBC (Java). Supported development environments include Microsoft Visual Studio, Apple XCode, Eclipse and Wind River Workbench. A redesigned and optimized database file format architecture maintains ACID compliance and data safeguards, with separate formats for in-memory, on-disk or hybrid storage. File formats hide hardware platform specifics (e.g., byte ordering). Download packages include examples of RDM speed and performance benchmarks. Transactional File Server (TFS) A software component within the RDM system that maintains safe multi-user transactional updates to a set  of files and responds to page requests. The TFServer utility links to the TFS to allow it to run as a separate utility, allowing users to run RDM in a distributed computing environment. The TFS may also be linked directly into an application to avoid the RPC overhead of calling a separate server. Modes of Operation Dynamic DDL Encryption Additional SQL Data Types Data Providers and Drivers: Interoperability Different “tree” support Snapshots Circular Tables support Database limitations Data Types Supported Database Design Language (DDL). Non-SQL (core) DDL Features: SQL DDL Features: Transactional File Server. 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. 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: Database unions. 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. Database encryption. 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 and HA Support. 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. Database replication. 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. SQL/PL. 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. RDM SQL has been designed specifically for use in embedded systems applications. Some of the more important features of RDM SQL include: Application programming interfaces. RDM provides application programming interfaces that allow application development in a variety of programming languages: Supported platforms. RDM has been ported to a wide variety of computers and operating systems. Packages are available for the following platforms: RDM packages. RDM consists of two packages: RDM Core and RDM Enterprise. Customers and applications. RDM  based applications are used today in all major industries including Aerospace & Defense, Automotive, Business Automation, Financial, Government, Industrial Automation, Medical, and Telecommunication. A sampling of RDM users includes the following: