Hathi : Durable Transactions for Memory using Flash

Transactions serve two purposes that make it easier to build robust applications. First, transactions enable fine-grained concurrency control, allowing developers to scale applications more easily across multiple processors [1, 6]. Second, transactions provide a simple interface for managing the durability and consistency of application state in the face of failures [4]. However, the commonly used transactional stores – DBMSs or distributed transaction systems – are a poor fit for many modern workloads, mainly due to the cost and complexity of managing such systems even for lightweight operations. As a result, many applications, particularly web services, sacrifice strong consistency for simpler storage models, such as key-value stores [3]. Hathi is a lightweight, high-performance and ACIDcompliant transactional store based on durable memory transactions : a program updates an in-memory data structure that is persistent and consistent across failures. We leverage three recent architectural trends in the design. First, DRAM prices have dropped to a point that even mid-tier servers support up to 4 TB of memory. At these sizes, many workloads can execute in core rather than from disk — an observation also made by others [5, 8]. Second, power considerations have driven processor manufacturers away from uni-processors towards multi-core chips, so concurrency between threads becomes a key concern. Third, flash-based solid-state drives (SSDs) provide scalable bandwidth and 1-2 orders of magnitude lower latency than the fastest disks. Hathi presents an in-memory transactional heap interface that is automatically made persistent on fast SSDs. Thus, programs can create and manipulate in-memory data structures, but ensure that the data is durable with little extra effort. To do so, Hathi combines the simple and highly concurrent interface (“ACI”) of transactional memory [6] with an SSD-optimized write-ahead logging and checkpointing scheme for durability (“D”). Thus, a programmer can wrap a section of program in a transaction to make updates durable and consistent. As flash storage is fast but still much slower than memory, Hathi implements two approaches to reduce and eliminate the overhead of persistence. First, Hathi provides options at transaction commit to control whether the program blocks, similar to asynchronous file I/O. This control has not previously been available for memory transactions, and allows developers to leverage application knowledge for increased performance. Specifically, Hathi exposes split-phasecommit, which decouples the installation of in-memory updates from the flush of transaction log records. Using this interface, applications can continue with other tasks and later check for completion of the commit, thereby overlapping computation and commit I/O. Second, Hathi uses partitioned logging, in which each thread maintains a separate log. Partitioned logging leverages the SSD’s internal parallelism and avoids contention on in-memory log buffers that hold the tail of the transaction log. For full consistency, Hathi ensures that all preceding transactions from all threads are durable before marking a transaction as durable. However, Hathi also providespartitioned commit , which allows application threads to commit transactions that operate on independent data structures without coordinating with the logs from other threads. Finally, Hathi provides incremental checkpointing in small chunks of the memory heap and ensures consistency with concurrent transactions, without the need to pause execution because both chunks and log records share the same log sequence number space. After a crash, Hathi performs recovery by first loading the checkpoint in memory and then replaying the logs. It merges the log records from the different log partitions and then replays