从内存到数据湖，读懂 SAP HANA Cloud 的多层存储体系与 NSE 容量设计

一套只有 60 GB 内存的 SAP HANA Cloud 实例，为什么可以管理 72 GB 的压缩数据库数据，而且这 72 GB 还没有把数据库正常运行所需要的全部工作内存计算进去。SAP 官方在 Storage Options 文档里给出的 NSE sizing example 很适合拿来理解这个问题。实例总内存是 60 GB，NSE buffer cache 按默认比例得到 6 GB，真正长期驻留在 SAP HANA 内存中的压缩业务数据按示例计算为 30 GB 减去 6 GB，也就是 24 GB，而放在 NSE 数据卷中的温数据可以达到 48 GB。这样一来，数据库管理的数据规模就成为 24 GB 加 48 GB，也就是 72 GB。这个例子揭示了 SAP HANA Cloud 存储设计里一个很重要的变化。我们不再需要把所有能够被 SQL 查询的数据都理解成必须完整装入 DRAM 的数据。SAP HANA 依然保持以内存计算为核心，但在内存数据库外面增加了不同成本、不同访问特征的存储层，让数据的位置和数据的业务价值、访问频率以及性能要求匹配起来。传统 SAP HANA 项目里经常会遇到一个很现实的问题。数据库上线初期也许只有几百 GB，几年之后订单历史、物料凭证、财务凭证、日志、分析快照以及各种归档前数据不断积累，数据库容量越来越大。如果所有历史数据都按照热点业务数据的标准配置内存，扩容成本会越来越明显。很多数据虽然必须保留，也必须能够参与查询，却可能一个月只访问几次，甚至一年只在审计、财务追溯或者历史分析时访问几次。SAP HANA Cloud 的 Storage Options 就是在解决这种成本和性能之间的矛盾。当前 SAP 官方的产品设计里，SAP HANA Native Storage Exten