Storage Developer Conference 2020总结

Storage Developer Conference 2020有两篇关于PM适配PG的议题。一篇是之前总结过的memhive，一篇为NVM WAL BUFFER。

Memhive架构

Memhive的架构如下所示，大致分为四部分：基于PM的持久cache、wal文件置于PM、数据文件置于PM、Manager。有两种使用模式：Persistent Cache和表文件、WAL文件都在PM模式。

Persistent Cache下，buffer描述符和buffer block在PM上通过pmdk函数pmem_map_file方式映射到内存，并具有持久性。Cache Manager在关键时间点执行pmem_memcpy_nodrain()和pmem_flush()从CPU CACHE将buffer描述符和buffer block数据刷写到PM。但是数据还是需要刷写到硬盘的。这里有个问题，持久内存上的数据什么时候刷写到磁盘，仍然是按照PG原有机制异步刷新？

带来的好处：

1、PG重启时，减小free list的更新。我的理解是，buffer blocks位于PM本身具有持久性，重启后不需要再从磁盘加载到buffer blocks，从而避免了加载数据后需要更新free list的动作。这样启动后就天然具有数据预热功能，即启动后热数据就可以直接访问。

2、双重模式：

Always persistent：对于buffer内容和选择的描述符都执行CPU CACHE flush/drain。计划内和非计划内的服务重启都是持久性的。（正常关闭和异常宕机重启？）

Selective persistence：buffer/meta更新后不执行flush/drain。只有计划内的重启才具持久性。

3、仅对持久化有意义的buffer进行优化：生存周期很短的cache buffer不执行flush/drain（例如vacuum和COPY IN等）

WAL和表数据在PM情况下：

1、wal位于PM有两种模式，性能模式：以fsdax模式的namespace，XLOG刷写路径由pmem_memcpy_xxx()替代原来的write调用；Local（DIMM）冗余模式：sector 类型的namespace，在sector上LVM mirror。

2、表数据文件（索引和表）在PM上，PM为sector类型，当DB大小<=PM大小是，这些数据cache在DRAM。

3、PG在sector和fsdax类型下都可复制。

总结下，两种模式下的配置。

Persistent cache+WAL 在PM：

1）local redundancy：LVM mirror on sector（WAL）+fsdax(cache) namespace，non-interleaved DIMMS

2）Performance：fsdax（WAL+CACHE），interleaved DIMMS（这种情况应该是pmdk持久化cache+pmdk wal）

3）表数据文件在现有的DAS/SAN存储上

表数据文件+WAL on PM:

1) local redundancy: LVM mirror on sector namespace（WAL+表数据）

2) 性能：LVM on sector（表数据）+fsdax（WAL，应该是pmdk替换）

3) Cache on DRAM

文件布局：

总体上对于数据上的优化：buffer描述符和buffer block，WAL的优化。但是他这几种模式下哪种最优呢？持久化buffer描述符、buffer block前后性能有多大提升呢？期待Memhive提供更多资料，能够开源最好了~~

Takashi Menjo的NVM WAL BUFFER架构

单层的WAL架构，创建并映射buffer文件作为非易失性WAL buffer，将WAL日志直接写入buffer，避免两次拷贝。提交时，刷写CPU cache，保证WAL持久化到PM。XLOG FLUSH时，即提交时执行CPU CACHE FLUSH而不是每次xlog insert时。