SAP HANA 和非易失性存储
一种新硬件产品的推广，必然需要有配套的软件产品来助阵。SAP HANA 作为一款著名的企 业级内存数据库产品，正是持久化内存最合适的场景之一。所以，SAP 和 Intel 二者很早 就开始相关产品的研发合作，这是一件再自然不过的事情了。SAP HANA 是市场上第一个针 对 DCPMM 优化过的主流数据库产品，SAP HANA 2.0 SPS 03 就已经支持 DCPMM 了1。
SAP HANA 的架构
SAP HANA 本质上是一个内存数据库，它也是最早提出 HTAP 的企业级数据库产品。因此， SAP HANA 给人的第一印象就是需要很多的内存，例如好几个 TiB。因此，云厂商的超大内 存规格就是为了 SAP HANA 这样的产品准备的。这也是为什么 DCPMM 作为一种新介质，很 早就吸引了 SAP HANA 的研发投入。
内存数据库的操作是以内存为中心的，而不是像磁盘数据库那样将内存作为磁盘的缓存。为 了保证数据的持久化，它仍然要依赖 WAL 机制先写日志，也需要依赖检查点等机制将数据 持久化。磁盘数据库遇到重启的时候，需要执行崩溃恢复过程，才能提供服务；内存数据库 也不例外，不过它的操作以内存为中心，还需要将大量数据加载到内存才可以工作。加速重 启的恢复过程也是企业级数据库一个很重要的优化。从内存和外存的角度看，SAP HANA 的 宏观结构如下2：
为了在 OLAP 和 OLTP 类访问中获得平衡，SAP HANA 在列存和压缩的基础上，将每列数据 分为两个部分：Main 和 Delta。前者主要是只读的，为 OLAP 类访问优化；后者为写服务， 为 OLTP 类访问优化。为了支持并发访问，这两部分都实现了 MVCC 。大致的架构如下：
实际的系统结构远比这个结构图要复杂，毕竟 SAP HANA 是一个完备的产品，也实现了很多 内存数据库、列存引擎的经典特性。更多的资料请移步 SAP HANA 官网3。
SAP HANA 的优化思路
在其他的文章中我已经分析过 DCPMM 之类介质的特点，例如带宽要稍逊于 DRAM，读写速度 不对称等。SAP HANA 也对介质的特点做了仔细的考量，结合 Main 内存的访问特点（例如 容量大、读多写少等），很自然的，先把 DCPMM 当做字节寻址的持久化介质用于 Main 内 存的优化。为了做到务实的架构设计，SAP 不可能对 HANA 大动干戈，为了 DCPMM 做全面 的改造，毕竟系统的备份、恢复、复制等都存在依赖。这也是写 PAPER，做原型和在产品上 做改进的重要区别。
SAP HANA 的优化结果
原型系统中2中讨论较多场景下的性能改进，例如简单的 INSERT、SELECT、类 TPC-H 查询、系统恢复时间等。但是需要注意的是，数据都是用 DRAM 附加延迟等模拟出来的， 不能代表实际的系统数据。产品中1的性能给出的主要是系统恢复时间的减少， 以及 DCPMM 带来的相对 DRAM 的增加。
从图中可以看出，系统启动的时间从 50 分钟下降到了 4 分钟，可以大大减少系统的停机 时间。
SAP HANA 的启示
一种新硬件产品的推广从来都不是凌空出世的，它需要很多年研究和开发的积累。与此同时， 硬件还需要操作系统等基础软件环境的支撑，才可能被更上层的应用软件所用。此外，硬件 要被广泛采用，必须要获得 Killer Application 的支持。DCPMM 之类的新硬件，因为它独 特的特性，存在很多种用法。至于实际的系统中应该采用哪种用法，就是应用软件各显神通 之处了。
SAP HANA 产品中对新存储介质的引入必然是慎重的。首先是企业的预研部门对新介质的用 法做出评估，并在以原型等形式予以实现和验证，其次才是真正的在产品中引入。最后，改 进后的产品要真正发布给客户并在实际系统中应用。
Footnotes
1 https://blogs.saphana.com/2018/11/29/sap-hana-persistent-memory/
PMDK , SAP HANA