在过去的几个月里，英特尔发布了越来越多关于其新内存技术的信息，包括其官方名称：英特尔®；Optane™ DC持久内存。这一承诺无非是对数据中心内存存储层次结构的重新设想。

英特尔正在字节可寻址DRAM和基于块的SSD存储设备之间引入一种新的内存层。他们正从两个方向接近这一新的层次，更快的块设备和更具创新性的字节可寻址主存，具有持久的DIMM外形尺寸。""持久"意味着即使在重新启动服务器后也不会丢失存储的信息。

SAP非常自豪SAP HANA是第一个专门为Intel®Optane优化的主要数据库平台™ DC持久内存。SAP和英特尔多年来的强大合作使这成为可能。SAP HANA从HANA 2.0 SPS 03开始就进行了优化，以利用这项技术的独特特性—即使硬件尚未上市。

大多数应用程序仅依赖操作系统进行内存分配和管理。当然，saphana需要从操作系统分配内存，就像其他应用程序一样。一旦分配了内存，saphana倾向于对其内存管理施加更高程度的控制。原因很简单：它允许更高程度的优化。这对于SAP HANA这样的内存中数据库尤其重要。这个范例无缝地扩展到持久性内存。

换句话说：SAP HANA知道哪些数据结构最受益于持久性内存。SAP HANA自动检测持久性内存硬件，并通过自动将这些数据结构放置在持久性内存上进行自我调整，而其他所有数据结构都保留在DRAM中。

这可以通过持久性内存的应用程序直接模式实现—这是Intel几天前刚刚公开披露的两种持久性内存操作模式之一。应用程序直接模式允许应用程序在持久内存中持久存储数据。内存模式–HANA不使用！–不提供这种数据持久性，但提供更便宜和/或更大的主内存。

使用应用程序直接模式，持久性内存特别适合非易失性数据结构。"非易失性存储器"和"非易失性RAM"经常被用作持久性存储器的同义词，这并非巧合。

鉴于这些特性，列存储main是放置在持久性存储器中的一个很好的候选者。它在压缩方面进行了大量优化，形成了非常稳定的非易失性数据结构。在大多数saphana数据库中，主存储区通常包含超过90%的数据占用，这意味着它提供了很多潜力。此外，在三角洲合并期间很少重建。只有在达到数据库表更改的某个阈值后才触发的进程。对于大多数表，增量合并一天不会发生超过一次。

这种设计非常适合SAP HANA的体系结构。写优化的delta和读优化的主存的分离以及两者的特性与DRAM和持久性存储器各自的优点是完美匹配的，SAP HANA的其他关键功能依赖于传统持久性存储（如SSD）上的持久性层。这包括行存储和列存储增量，以及系统复制和数据库备份。使用SAP HANA的shared nothing体系结构，这也会对自动主机故障切换产生影响，因为不活动主机的持久内存不能重新分配给活动主机。还有成本方面。持久内存将比DRAM便宜，但仍然比传统的持久存储设备贵。saphana采用了一些技术来减少需要大量内存的数据类型的内存占用，例如BLOB（Binary Large Object）。将这些数据保存在内存中，即使是在持久性内存中，也会增加不必要的成本。

在这个阶段，我想说几句话，网站建站平台，说明作为一个运行SAP HANA的客户，持久性内存是如何让您受益的。

增加了主内存容量

不久前，英特尔透露，在发布时，每个模块的持久内存容量将高达512GB。与目前的DRAM（其最大容量可达128gb）相比，这一数字已经增加了四倍。考虑到目前大多数系统甚至不使用128 GB DRAM DIMM，由于供应有限和相应的价格标签，潜在收益更高。

不难得出结论，SAP HANA的整体容量将从这项技术中受益匪浅。当前的技术界限将被打破，即使您的SAP HANA实例不需要更高的容量，与DRAM相比，您仍将受益于持久内存的预期更便宜的价格标签。

尽管持久内存不是数据分层解决方案，但其更高的容量将通过提高阈值来影响这一点。在某种程度上，大数据查询平台，您可以简单地忽略它，并将所有数据保留在原处—在主内存中以最大的性能。

启动时加载数据

SAP HANA的独特之处在于其"内存优先"范例的后续实现。所有数据库操作都直接在内存中的数据结构上执行，而不是像市场上的许多遗留数据库一样，首先将所有内容应用于持久的基于块的存储（例如ssd），然后简单地将更改复制到内存缓存中。这意味着必须先将表加载到主内存，然后才能对此表执行任何操作（读或写）。对于绝大多数表（SAP HANAs列存储中的表），这是在数据库重新启动后异步发生的。在此期间，数据库完全可用，但对尚未完全加载的表的查询可能会降低性能。