Gaining a Performance Advantage with the eXtremeDB IMDS and Transaction Logging
eXtremeDB transaction logging adds recoverability to an in-memory database by writing database changes into a transaction log on persistent media. Logging may be set to different levels of transaction durability, allowing system designers to make intelligent trade-offs between performance and risk of unrecoverable transactions.
With the eXtremeDB embedded database version 2.3 and all subsequent versions, McObject increases the options for persistence with the introduction of transaction logging – a process that journals changes made to a database (by transactions), as they are made. With transaction logging enabled, the eXtremeDB runtime captures database changes and writes them to a file known as a transaction log. In the event of a hardware or software failure, the eXtremeDB runtime can recover the database using the log. Logging is performed through periodic checkpoints, where the image of the in-memory database (IMDS) is saved to persistent storage, and all intermediate changes to the database are written to the log files. In this way, the RAM database is made persistent.
Transaction logging does not alter the all-in-memory architecture of eXtremeDB, which retains a performance advantage over disk-based databases. Read performance is unaffected by transaction logging and write performance will far exceed write performance of traditional disk-based databases.
The reason is simple: eXtremeDB transaction logging requires exactly one write to the file system for one database transaction. A disk-based database, however, will perform many writes per transaction (data pages, index pages, transaction log, etc.,) and the larger the transaction and the more indexes that are modified, the more writes that are necessary.
To minimize the performance impact, eXtremeDB equips developers with all the controls they need to tune their applications with persistence and performance in mind. Many eXtremeDB transaction logging features are parameterized so that programmers can invoke the features most appropriate for their application scenario. For example, transaction logging may be turned on or off at runtime and, when turned on, logging may be set to different levels of transaction durability, allowing system designers to make intelligent trade offs between performance and risk for unrecoverable transactions.
Transaction logging also includes McObject’s eXtremeDB data relay technology which facilitates seamless, fine-grained data replication from embedded systems based on eXtremeDB to external systems such as enterprise DBMS, and eXtremeDB’s Persistent Queue of Events. (Use eXtremeDB’s Active Replication Fabric, High Availability or Cluster to replicate between eXtremeDB instances.)
Tests prove a performance advantage of eXtremeDB IMDS and with transaction logging. Review our white papers for complete details.
Hybrid In-memory and/or Persistent
Combine both database paradigms – in-memory and on-disk – in a single database instance. Specifying one set of data as transient (managed in memory), while choosing persistent storage for other record types, requires a simple database schema declaration.