> I'm not sure that using mmap(2) is enough. You're still writing pages, so you're writing more than you have to, so writes will not go as fast on NVM as they could.
If you're using the new fangled memory there's a few components in play.
First in Linux there's DAX. DAX lets you mmap in the devices pages directly without going through the page cache. And the processor can handle this like a memory mmaped device (without interactions from the OS) including subpage read/writes.
Second, Intel chose to reuse previously existing operations that you would normally use for flushing cache lines (to main memory). Previously there were going to use additional pcommit operation. https://software.intel.com/en-us/blogs/2016/09/12/deprecate-...
Re:How to Build a Non-Volatile Memory DBMS
by cryptonector on Monday May 22, 2017 @04:29PM
(#14396671)
I got that. My point is that merely using this is insufficient to make your DB go fast on NVM. As the presentation says, you need to consider changing the on-disk^W^W^Wpersistent storage format to be one that writes less (not so much because of write cycle limits, but because writes are slower, and to reduce the number of additional writes needed in, say, a COW format.
LMDB does logging since it does copy-on-write -- it just reuses free pages as soon as possible, which means that over time the log disappears. (LMDB is not an append-only DB.)
I agree as to GCs. Having to GC is not just wasted work, it's a performance disaster, and any study that hand-waves about GC without actually measuring its impact on performance is fatally flawed. Assume petabytes of data, and assume performance between SSDs and DRAM: GC will still take enormous amounts of time and I/O that could have been used for something else. Write-behind logging is terrible if it means you need a GC. Why even bother with write-behind logging if a failure means that you must GC anyways.
Only write-ahead logging helps you avoid a GC. A write-ahead log could be optimized to log only (address, length) tuples for each transaction so as to minimize WAL writes.
However, the insights about smaller-than-page I/Os, particularly as to writes, seem likely to be correct. Though having anything like a b-tree on NVM with smaller-than-page writes seems to me to imply in-place writes, but I'm not ready to give up on COW.