The key features and functionality of the solidDB database product include the hybrid, relational database server with disk-based and in-memory tables, direct linking of applications to bypass performance-limiting network protocols, and various replication capabilities including high availability.
Disk-based and in-memory tables
solidDB provides the ability to have both in-memory tables and on-disk tables within a single solidDB instance.
Disk-based tables (D-tables) are traditional relational database tables, equivalent to those found in other disk-based database products. The data is stored primarily on disk, and usually the server copies only small pieces of data at a time into memory.
In-memory tables (M-tables) store the entire contents of the table in memory so that the data can be accessed as quickly as possible. M-tables have low query latency and high throughput. Depending on the application needs, the in-memory data tables can be configured to be persistent or transient. In addition, flexible logging capabilities let you define the level of transactional durability that is required for persistent tables, including full durability.
With solidDB you can create a database engine that runs without any disk storage space to provide the best performance for disk-constrained environments. For more information, see Diskless servers.
Direct linking with SMA and LLA
Shared Memory Access (SMA) and Linked Library Access (LLA) allow applications to link to solidDB server directly, without the need to communicate through network protocols such as TCP/IP. With SMA, you can link multiple applications while with LLA, you can link one application. By replacing the network connection with local function calls, performance is improved significantly.
In solidDB, data replication can be implemented with different technologies, namely, C Replicator, Advanced Replication, solidDB High Availability (HotStandby), and solidDB grid.
Replication can be synchronous or asynchronous. In synchronous replication, the data is durably delivered to the receiving end within the transaction that is executed at the originating end. In asynchronous replication, the data is delivered to the receiving end after the original transaction is committed.
Replication can be based on a push or pull operational model. In the push model, it is the originating end that activates the replication. In the pull model, the receiving end takes the initiative.
C Replicator
C Replicator (CREP) is a replication technology that was introduced in solidDB 101. It complements solidDB HotStandby technology (see High availability technologies) and partly replaces the Advanced Replication technology.
CREP provides an asynchronous mechanism to replicate write operations across any number of solidDB instances. The mechanism is based on reading entries from transaction log and re-running the operations in one or more target databases as configured.
The mechanism is bidirectional allowing all participating database instances to accept write operations. CREP contains a mechanism for detecting and resolving conflicts caused by same row being updated simultaneously in multiple database instances.
The replication is configured by defining partitions containing tables to be replicated. Hence, it is possible for database instances to have local tables that are not part of replication. Also, replicated tables can have columns that are outside replication.
Designing a multi-database system built using CREP involves engineering work in both system topology and data model design.
Important solidDB Advanced Replication will be deprecated in future releases of solidDB.
Advanced Replication technology represents an asynchronous pull-based approach. It allows users to distribute and synchronize data across multiple database servers. Advanced Replication uses a master-replica model in which a single server holds the master copy of the data. One or more replica servers can also have a copy of part or all of the master data. Furthermore, each replica can also have data that is specific to that replica only.
Replication is bidirectional; replica nodes can upload data to the master as well as download from it. If replicas submit conflicting data, the master can reject the data or alter the data before it makes the data available to all replicas. The management of replicated data is based on a flexible publish-subscribe model. The management interface is in the form of proprietary extensions to the SQL language.
The asynchronous approach in Advanced Replication setups means that the system is inherently flexible. If some nodes are down for any reason, those nodes can resynchronize when they come back up or reconnect to the system. This allows mobile devices, such as PDAs or notebooks, to request updated data, disconnect from the network, and then reconnect later. Users can choose how frequently they want to synchronize data.
solidDB High Availability, or simply HotStandby (HSB), increases the availability of data. Servers are paired up in such a way that, if one fails, the other can take over. Data from the primary server is replicated to the secondary server, which is used as a ‘hot standby’ unit. If the primary server is unavailable, for example, because of hardware failure or scheduled maintenance, applications can connect to the secondary server and continue immediately without any loss of committed transactions.
Transparent Connectivity, a special connectivity mode of solidDB ODBC and JDBC drivers, offers the applications failover transparency and transparent load balancing between the primary and secondary.
Unlike Advanced Replication, with solidDB HSB, all the data in the database is always replicated. There are a few dynamic controls available, in the form of specialized SQL commands.
A solidDB grid is an availability and scalability solution that was introduced in solidDB version 200. You can configure a set of solidDB servers, that run in multiple connected nodes, to appear as a single logical database. For more information, see solidDB Grid overview.
Licensing and Deployment
To start solidDB, a license file must be present in the working directory of the server. The product package contains a time-constrained license file for evaluation use, see License certificate.
To use solidDB in a production environment, you must obtain a customer-specific or project-specific license file from UNICOM Systems, Inc. The license file is generated separately for each customer and might contain some technical limitations for product use. For example, the number of database connections might be restricted or some features might be disabled.
The terms and conditions for deploying the license file are always specified by the contract. With Enterprise contracts, the use is typically unlimited within a single company. In an OEM contract, the use of solidDB is typically limited to use with only a specified mass deployment application. The end users then receive a license file that limits their permitted use of solidDB to only that specific application.
Both Enterprise and OEM contracts contain other limitations such as export restrictions (as defined by U.S. and European Union regulations). Exporting solidDB to embargoed countries and using the product in specified application areas might be restricted. If you have already purchased the product, please check the contract for any applicable restrictions. If you are an evaluation user and want to check the export regulations for solidDB, please contact your UNICOM Systems, Inc. sales representative.