基于PMEM的PG数据库Memhive白皮书
概要
PG是一个广泛应用的开源数据库，从财务管理、地理信息、水务系统到气象服务等等。可部署在本地，也可以部署在云上。PG不仅在事务处理中有强大能力，也支持分析型的复杂查询语句。随着用户群的快速增长，PG受到的压力超出了最初的设计目标，导致需要大规模扩展PG。本文讨论了Memhive如何结合PM对扩展PG。
挑战
如何水平扩展、垂直扩展，或者两者皆支持是一个挑战性问题。
水平扩展包括在数据库集群中对表进行分区、讲每个分区驻留在单独的PG实例中。每个实例有自己专用的CPU、DRAM、存储资源。分片是一项横向扩展技术，用于切分表，让每个表分区独立运行在单独的PG实例上。这个方法有以下缺点：
Ø 由于集群需要额外资源，增加了总成本。
Ø 正确分片是一项复杂的任务。
Ø 管理也很复杂，例如为避免热点，数据重均衡等
Ø 多个分片上进行join非常重要
Ø PG不支持原生分片
垂直扩展需要给PG实例增加更多计算资源或DRAM容量。内存大的实例每个socket需要更大的DRAM，价格昂贵又受socket限制。
下面讨论结合PMEM如何进行垂直扩展。PMEM可提供多种模式：memory, fsdax, sector, devdax，用在PG的WAL，shared buffer，relation files等。以最佳的方式使用是个挑战。冗余部署是另一个挑战。
Intel的傲腾持久内存是什么？
持久内存具有非易失性、可字节寻址、低延迟，延迟介于DRAM和SSD直接。其比DRAM高的密度甚至使其成为DRAM替代品。他能给提供大容量，给耗内存的应用进行扩展提供便利。随着Intel Xeon第二代可扩展CPU的交付，傲腾持久内存可支持128、256、512GB。可使每个CPU socket达到3TB，从而可提供比DRAM大很多的替代品。DRAM容量限制为128GB。
傲腾持久内存通过内存总线直接和CPU进行交互。可以使程序直接访问，消除了系统调用的开销，设备驱动开销，中断和内存上下文的开销。甚至，应用可字节访问PM上数据。详细信息查询：intel.com/OptaneMemory。
Memhive扩展PG
Memhive是集成PM到PG的先驱，以APP Direct模式使用PM。包括以下几处：
Ø 提供大容量的持久cache
Ø 更快的WAL机制
Ø PMEM-only模式
同时提供Memhive manager，用于安装并管理PM。下图提供了其架构图。
Persistent cache
PG将热数据缓存到shared buffer cache中。这个cache由DRAM分配，同时也由限制，因为其他部件也要用到DRAM。Memhive通过fsdax模式将PM挂载，将cache部署在整个app direct PM namespace上。Cache容量大、持久性、可字节寻址。Cache的元数据也在PM上，因此断电不丢失。Memhive的持久cache确保CPU的cache line中数据及元数据以ACID特性刷写。
使用持久shared buffer cache具有以下优势：
Ø Server重启后者系统reboot后数据及元数据仍在持久cache，而表数据文件保留在现有存储上（DAS/SAN）。这样数据库可以继续从现有存储服务中获益，比如灾备和灾难恢复。
Ø 面向磁盘的数据库可以通过持久cache高效地转换成内存数据库。
Ø Cache数据和元数据都在PM，不再需要昂贵的DRAM。
Ø 重启后可以快速预热。
Ø 现存PG不需要迁移现有数据即可完成升级。
Fast WAL
WAL可以APP direct fsdax或者sector模式部署在PM上。fsdax模式：低延迟或者高事务性能。sector模式：数据可用性保证业务连续性。将PM应用WAL可以提高写性能，因为消除了日志更新的IO等待，非常适合事务型工作负载。
PMEM-only模式
该模式下，PG的所有数据，包括表索引文件都放到PM上。可以在整个数据都可容纳到PM时使用。APPDirect sector用于承载数据库文件，组合了PMEM和DRAM的优势。组合fast WAL，可以获得更好性能。
PMEM Manager
功能包括：
Ø 安装配置Memhive软件
Ø 交互式初始化配置，包括NUMA节点和持久cache和fast WAL配置。
Ø 启动、停止、重新设置配置
Ø 丰富的统计，包括大量counters和数据库、PMEM模块的统计信息
Ø 探测硬件故障并恢复
Ø 展示PG配置、硬件配置，包括CPU、内存和NUMA节点信息
测试
测试包括OLTP和OLAP。OLAP使用Database Test Suite。OLTP使用pgbench。配置如下：
Ø Intel Xeon Cascade Lake processor(24 cores, 2 threads per core) x 2
Ø 16 GB DRAM x 6 per processor
Ø 128GB Optane x 6 per processor
Ø 800 GB SATA SSD x 1
Ø 480 GB SATA SSD x 2
通过numactl(8)制定服务端和客户端的CPU。基于PG12进行修改，运行在Fedora Linux31 5.5.8-200。
结论
1、不太了解shared buffer是否在PM上后，必定现在PM比DRAM延迟大，不会拖累性能？
2、是否通过利用PMDK库进行改造？
3、数据文件的扩展如何实现？
4、www.memhive.io
总之，后续继续关注Memhive，看其是否将代码开源，以及是否提供更多相关材料。
