A host computing system typically executes an application (e.g., a database application) which requires application data to be stored locally on the host computing system and/or remotely on one or more data storage arrays. A host computing system typically includes volatile byte addressable random access memory (RAM) resources to support low-latency and high throughput data access operations, as well as non-volatile block addressable storage devices to support data persistence. A data storage array typically includes storage devices that provide both high speed non-volatile random access storage capacity (e.g., flash memory devices) and slower non-volatile large storage capacity (e.g., hard disk drives (HDDs)).
Currently, in-memory data management systems are being designed to rely on primary data residency in main memory (e.g., RAM) and, primary data persistence in either low-latency non-volatile, byte addressable memory or maintained using traditional storage-based persistence methods that include performing write I/O (input/output) to logs and data files residing on block devices. Any type of byte-addressable memory resource is either volatile (e.g. DRAM) or still considered to be very expensive (e.g., Storage Class Memory) and, consequently, not a candidate for long term storage of backup copies of primary data (e.g., in-memory data). In this regard, in-memory data management systems typically implement methods for backing up in-memory data by storing versions of in-memory data to other, more cost effective, types of storage.
For example, if an in-memory data management system already implements a traditional storage-based persistence method to guarantee data persistence, then the system will typically back up those persisted storage assets (logs and data files) to inexpensive backup media such as HDD or NAND Flash. If the in-memory data management system relies on byte-addressable non-volatile memory for persistence, then the system will typically have to copy that data into a file format on a block device in order to back it up to lower cost media, thus taking it out of the memory domain. While “restart” functions can be performed after system failure from the non-volatile byte-addressable memory, “recovery” functions most often will need to rely on a completely separate set of processes that read data from files on block devices. In both of the examples above, the application is not functioning in a memory mode or being programmed to an in-memory module during the recovery processes. These conventional techniques are inefficient since, for example, the reformatted data is not a directly consumable form of data for an in-memory type application.
USPTO Backgrounds
USPTO Backgrounds