百度|优化Feed流遭遇拦路虎是谁帮百度打破了“内存墙”？( 二 ) cube|dram|数据库

百度就曾经考虑过以堆DRAM的方式为Feed-Cube构建更大的内存池，但这一方面会使其TCO大幅抬升，另一方面，这种方式也依然跟不上Feed-Cube数据承载能力的发展要求。
在验证依靠DRAM难以突破内存墙后，百度还尝试使用性能不断提升的、基于非易失性存储（non-volatile memory ， NVM）技术的存储设备，如 NVMe 固态盘来存储 Feed-Cube 中的数据文件和哈希表。但经测试发现，这一方案在QoS、IO 速度等方面都难以满足服务需求。
【百度|优化Feed流遭遇拦路虎是谁帮百度打破了“内存墙”？】傲腾? 持久内存成破“墙”利器，兼顾性能、容量和成本收益
求助DRAM和NVMe固态盘都不顺利，那么Feed-Cube突破内存墙的路径和方案到底在哪里呢？百度抱着寻求突破性方案的初衷，把眼光瞄向合作多年的伙伴英特尔，瞄向它意在颠覆传统内存-存储架构的傲腾? 持久内存。

图二、傲腾?持久内存在内存-存储层级中的位置及作用
傲腾? 持久内存进入百度视野的原因其实很简单，即它比较好的兼顾了现有DRAM内存和存储产品的优势，同时又不像它们那样有各自明显的不足之处——它凭借创新的介质，可提供接近DRAM的读写性能和访问时延、更接近固态盘的存储容量，并支持DRAM内存所不具备的数据持久性和更高价格容量比，以及NAND固态盘所无法比肩的耐用性。这使得它在多用户、高并发和大容量的场景下有着非常突出的优势，也特别适合用于扩展内存来承载更大体量、需要更高读写速度和时延来处理的数据。
有鉴于此，百度开始尝试使用傲腾? 持久内存来破解Feed-Cube面对的内存墙问题。其做法就是用持久内存来存储Feed-Cube中的数据文件部分，并仍用DRAM来存放哈希表。采用这一混合配置的目的，一方面是为了验证傲腾? 持久内存在 Feed-Cube 中的性能表现；另一方面， Feed- Cube 在查询 Value 值的过程中，读哈希表的次数要远大于读数据文件，因此先在数据文件部分进行替换，可以尽可能地减少对 Feed-Cube 性能的影响。
与此同步，百度还与英特尔合作，根据 Feed-Cube 应用场景的需求，在服务器 BIOS 中加入了对傲腾? 持久内存的支持驱动，还在百度自研Linux内核的基础上增添了相关的补丁，以求实现硬件、操作系统、内核等组件的全方位优化，进而充分释放整个系统的性能潜力。
经过这一系列操作后，百度就模拟了实际场景中可能出现的大并发访问压力，对纯 DRAM 内存模式与上述混合配置模式进行了对比测试。测试中，每秒查询次数（Query Per Second ， QPS）设为 20 万次，每次访问需要查询 100 组 Key-Value 组，总访问压力为 2 千万级。结果显示，在此如此大的访问压力下，平均访问耗时仅上升约 24%（30 微秒），处理器消耗整机占比仅上升7% ，性能波动也在百度可接受的范围内。而与此相对应的是，单服务器的 DRAM 内存使用量下降过半，这对于 Feed-Cube PB 级的存储容量而言，无疑可大大降低成本。
在这一成果的激励下，百度又进一步尝试将 Feed-Cube的哈希表及数据文件都存入傲腾? 持久内存中，以每秒 50 万次查询（QPS）的访问压力进行测试，结果证明这一模式与只配置DRAM 内存的方案相比，平均时延仅上升约 9.66% ，性能波动也在百度可接受的范围内。

图三、百度Feed-Cube内存硬件变化路径?
经过这些探索和实践，百度最终验证了其 Feed 流服务的核心模块 Feed-Cube 从仅配置 DRAM 内存的模式，迁移至同时使用 DRAM 内存与英特尔? 傲腾? 持久内存的混合配置模式，再到全面依托英特尔? 傲腾? 持久内存模式的可行性。这一系列创新举措在大并发访问压力下的优异的性能表现以及符合百度预期的资源消耗，充分展示了傲腾??持久内存在打破内存墙过程中发挥的关键作用。

百度|优化Feed流遭遇拦路虎 是谁帮百度打破了“内存墙”？( 二 )

百度|优化Feed流遭遇拦路虎是谁帮百度打破了“内存墙”？( 二 )