持久化内存编程及其思考

Posted 2021-01-19 cccchhhh

由于个人工作关系，接触到了持久化内存的概念，觉得这个概念特别有意思，对于未来的编程模型会有很大的影响，甚至，很多的软件（系统软件）优化和架构会有很大的不同，甚至重写。

• 背景知识

长久以来，我们一直接受的观念是，数据从磁盘读取到内存中，然后CPU从内存对数据进行操作，最后再从内存回写到磁盘保存，完成整个数据的读取，处理和保存。这个观念中，内存容量很小，很贵，磁盘容量很大但是很便宜。从4k访问延时或者吞吐量上来看，内存是要比磁盘快上1000倍或者以上的，然而，随着Intel的黑科技技术傲腾（Optane）诞生，貌似这一假设有可能会被终结。

这玩意可以长得和我们普通内存一样，可以插到内存插槽上，但是容量可以做到单根甚至是512GB，至于价格就不好说了，毕竟官方还没有公布，肯定是会比内存便宜很多。但这玩意也叫PM（Persistent Memory，持久化内存），肯定访问方式和内存还是会有点不太一样，既然是持久化，那么它和磁盘有什么区别么？

通常我们访问磁盘，都需要走文件系统，内核，驱动程序，最后是磁盘本身的操作，当然，磁盘自身的操作时间（延时）会比较长，前面一些操作的时间基本可以被忽略。随着磁盘越来越快，从传统HDD到SSD到PCI-E SSD再到现在的傲腾技术，我们发现“磁”盘自身操作的延时越来越短，那么相比之下，操作系统内核，驱动，文件系统所带来的开销就不能被忽略了，甚至会成为瓶颈，于是就有了新的持久化内存编程模型出来了。

应用程序会有3种模式可以访问傲腾磁盘（插在内存插槽上的傲腾介质）：

• • 仍然是传统的文件系统方式访问文件，把傲腾当成普通的SSD用；
    • 这个访问延迟可能会和访问PCI-E SSD不会有太大差别，毕竟延时都浪费再文件系统，内核，驱动上了，更不用谈现在的Java或者C++的文件API，通常都有“缓存”访问，天知道需要在内存里倒腾来倒腾去多少次最后才会写到真正的设备里；
    • 虽然看上去现有代码不需要怎么改动，但是性能优势和PCI-E SSD比，如果没有太大区别，除非其价格和PCI-E SSD可以拼一把，否则这种应用场景通常不会被考虑。
  • 用PM-Aware文件系统（可以持久化）
    • 会跳过文件系统本身的负载（比如文件缓存等），至于PM-Aware文件系统本身的负载有多大，就不得而知了，不知道Intel会不会公布他们的官方性能数据；相信应该是一个不错的数字；
    • 标准文件API这一块或许不是我们通常理解的标准C/C++/Java API，至少这些API底层需要重写或者有PM-Aware文件系统提供新型API；
  • 应用程序直接访问NVDIMM，操作系统内核把它当作内存用，并提供MMU的地址映射关系（可以不持久化）
    • 这块是我觉得让人很振奋的地方，理论上应该是应用程序可以获得一个更大的内存，和普通的内存使用没有什么太大区别，访问数据时，没有了系统调用，文件系统等多个拖累。

相信官方应该是推荐后面两种方案；（https://pmem.io）

• 个人的一些想法(随想)
  • 单机版应用（包括系统程序）可能需要有对应的修改
    • 比如传统的数据库系统（mysql/Oracle），大部分的优化是基于数据先写内存，积累到一定量一次性刷到底层存储系统，并保证一致性，但是现在有了PM-aware文件系统，数据存储足够快，数据是可以直接往底层设备上写，并保证其一致性的，内存“缓存”的概念可能会慢慢弱化；
    • 高级语言对应的API和数据结构优化，比如常见的文件操作（java中的StringBuffer，BufferedReader等等) ,或许对于性能而言，反而会导致性能下降，需要开发新的API以支持PM-aware文件系统或者是直接内存访问模式；
  • 分布式应用
    • 传统数据传输走的是以太网（TCP/IP），后面是不是可以用RDMA直接对接PM？也会减少很多内核和驱动的负载。
    • 比如Apache Spark，Kylin这类所谓的In-memory分布式计算引擎，如果有相应改动，会极大提升计算效率，当然会涉及到一些列的数据结构上的优化和修改，让它更适合访问“PM”类型的内存特性；
    • 分布式缓存框架，比如Alluxio，Apache Ignite等也有很多机会获得最好的性能或者延迟。
• 参考文档
  • Alluxio
  • 持久化内存编程模型