基于PMEM的PG数据库Memhive白皮书

基于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,看其是否将代码开源,以及是否提供更多相关材料。

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值