在一套已经运行多年的 SAP S/4HANA 或 SAP BW/4HANA 系统里，很容易出现一种颇为现实的矛盾。业务部门希望历史数据继续在线，财务需要追溯几年前的凭证，销售需要查询旧订单，审计团队可能突然调阅过去若干会计期间的数据，数据团队也可能用多年历史记录做趋势分析。但从数据库访问频率来看，大量历史数据一个月甚至几个月都未必被真正读取一次。如果这些数据全部按照传统 SAP HANA 的思路长期驻留内存，技术上当然很快，经济上却未必合理。SAP HANA 的核心竞争力来自内存计算，但内存并不是免费的资源。数据库规模越来越大以后，一个现实问题会越来越突出，我们究竟是否需要为了那些很少访问的数据，持续准备同等规模的 DRAM。SAP 给出的答案之一，就是 SAP HANA Native Storage Extension，也就是 NSE。SAP 官方目前对 NSE 的定位非常直接，它是一套内置于 SAP HANA 的通用温数据存储机制，用于管理访问频率较低的数据，而不要求把这些数据完整加载进内存。换一个更贴近系统架构的理解方式，NSE 并没有在 SAP HANA 外面再摆上一套数据库，也不是把查询切换到另一套归档系统，而是在 SAP HANA 自己的存储引擎内部改变数据被装载和访问的方式。这一点非常重要。当一张普通 SAP HANA Column Store 表采用传统的COLUMN LOADABLE方式时，SAP HANA 倾向于把需要使用的列完整装载到内存。采用 NSE 之后，我们可以把表、分区甚至单独某一列定义成PAGE LOADABLE。数据库处理查询时，不再要求整个对象全部进入内存，而是只把查询