Multi-Clock Snapshot Isolation (MCSI) is a concurrency control mechanism that implements snapshot isolation on a single-layer Non-Volatile Memory (NVM) database. It stores a single copy of data by using multi-version storage to ensure durability and runtime access. With multi-clock transaction timestamp assignment, MCSI can efficiently generate snapshots with vector clocks and use per-thread transaction status arrays to identify uncommitted versions in NVM. For evaluation, we compared MCSI with the PostgreSQL-style concurrency control used in the single-layer NVM database N2DB. The maximum transaction throughput of MCSI is 101%–195% higher than that of N2DB for the YCSB workloads, and 25%–49% higher for the TPC-C workloads. Moreover, the transaction latency of MCSI remains relatively stable as the thread count increases. With 18 worker threads, the average transaction latency of MCSI is 65%–84% lower than that of N2DB for the YCSB workloads and 16%–43% lower for the TPC-C workloads.

Non-Volatile Memory (NVM) offers byte-addressability and persistency. Because NVM can be plugged into memory and provide low latency, it offers a new opportunity to build new database systems with a single-layer storage design. A single-layer NVM-Native DataBase (N2DB) provides zero copy and log freedom. Hence, all data are stored in NVM and there is no extra data duplication and logging during execution. N2DB avoids complex data synchronization and logging overhead in the two-layer storage design of disk-oriented databases and in-memory databases. Garbage Collection (GC) is critical in such an NVM-based database because memory leaks on NVM are durable. Moreover, data recovery is equally essential to guarantee atomicity, consistency, isolation, and durability properties. Without logging, it is a great challenge for N2DB to restore data to a consistent state after crashes and recoveries. This paper presents the GC and data recovery mechanisms for N2DB. Evaluations show that the overall performance of N2DB is up to $\mathrm{3.6}\mathrm{\times }$ higher than that of InnoDB. Enabling GC reduces performance by up to $\mathrm{10}\mathrm{\%}$, but saves storage space by up to $\mathrm{67}\mathrm{\%}$. Moreover, our data recovery requires only $\mathrm{0.2}\mathrm{\%}$ of the time and half of the storage space of InnoDB.