SAP HANA Native Storage Extension Breaks Down Cost/Performance Barriers
This post is part of Transformational Tuesdays: A Series on SAP HANA Business Value from the SAP HANA Solution Management team celebrating 10 years of SAP HANA in 2020.
Since its inception with the release of SAP HANA 2.0 SPS 04, Native Storage Extension (NSE) is helping customers manage large data capacity in a single node scale-up system at lower TCO. NSE capabilities are now further enhanced with scale-out support in the newly released SAP HANA 2.0 SPS 05 to help customers manage continuous data growth whilst overcoming the hardware limitations of a single host instance. Other enhancements include, flexible buffer caching sizing and monitoring views in NSE advisor.
A quick recap: NSE is an intelligent, built-in disk extension to the SAP HANA in-memory database, and its purpose is to add an integrated warm data tier to the SAP HANA database. NSE expands the SAP HANA database capacity at lower TCO. Available both in SAP HANA on-premises and in SAP HANA Cloud, NSE is the strategic direction for the warm data tier.
The scale-out support for NSE offers flexible choices to conveniently locate data across different nodes to deliver optimal processing to support desired SLAs. Depending on the frequency of data access and change needs, tables/partitions can be spread across multiple nodes. Scale-out systems with NSE support:
- Non-uniform configurations of HOT data in-memory and buffer cache size across nodes
- No NSE WARM data maximum limit per scale-out node
Tables/partitions/columns in scale-out database can be easily managed by existing SQL commands to enable NSE and distribute them across nodes.
- ALTER TABLE <table_name> PAGE LOADABLE
- ALTER TABLE <table_name> ALTER PARTITION <partition_name> PAGE LOADABLE
- ALTER TABLE <table_name> ALTER COLUMN <column_name> PAGE LOADABLE
- ALTER TABLE <table_name> MOVE TO ‘<HOST:PORT>’ [PHYSICAL]
- ALTER TABLE <table_name> MOVE PARTITION <partition_id> TO ‘<HOST:PORT>’ [PHYSICAL]
The rule of thumb for buffer cache size is 1/8th of the NSE WARM data size, but buffer cache size can differ according to data access needs of the workloads. SAP recommends performing a sizing analysis to estimate WARM data and NSE buffer cache sizes for the respective application. Moreover, the latest updates on functional limitations can be found on the SAP Help Portal.
The SAP HANA NSE Advisor in SAP HANA Cockpit helps determine suitable data temperature recommendations for table/partitions/columns in the database.
The SQL query performance of NSE WARM data is typically 2-3x slower than HOT in-memory data. However, performance could vary depending on buffer cache size and WARM data size. If the data set of SQL queries is already in the buffer cache, performance will be very similar to complete in-memory data.
The SAP HANA administration tasks such as back-up, recovery, and worker node fail-over are transparent to NSE configurations.
Fig 3: Data Pyramid
With the fully integrated support for NSE in SAP HANA, customers have the flexibility to configure it in the on-premises system and use it out of the box in SAP HANA Cloud. With a uniform architecture, it is also very convenient to manage hybrid landscapes to extend on-premises into the cloud. Complementing NSE with SAP IQ for on-premises or built-in Data Lake option in SAP HANA Cloud for cold data allows for a simpler and more efficient management of petabyte-scale workloads.
The primary use cases of SAP HANA with NSE are (1) Lower SAP HANA TCO for growing data volume needs, (2) HTAP (OLTP+OLAP) workloads in a single system with historical data retained in NSE, (3) Data mart and data warehousing applications, and (4) Central repository for all data with HANA+NSE complemented by SAP IQ for cold data.
SAP Application Support
Both, SAP S/4HANA and SAP BW/4HANA applications support NSE. However, its usage is entirely managed by the application layer and transparent to the end-users and database administrators. For additional information and current limitations please refer to SAP Note 2816823 (SAP S/4HANA) and SAP Note 2347382 (SAP BW/HANA).
Customers can now leverage NSE in all SAP HANA systems optimizing the in-memory usage by storing older data in warm storage offering the optimal cost/performance ratio. Keeping the data in a single database takes advantage of all the inherent capabilities of SAP HANA, including unparalleled performance, data compression, anonymization, and other multi-model processing engines my colleagues will cover. It allows the diminution of TCO by simplifying IT landscapes that offer great performance, reducing the need for data duplication and improving data governance and compliance management. Above all, NSE enables customers to access increasing volumes of data in a cost effective and highly performant manner anytime in SAP HANA.
Your Next Steps
For a technical deep-dive on the topic, please register to join the live session “What’s new in Native Storage Extension in SAP HANA 2.0 SPS 05” or access the session on-demand here. For additional information, refer to SAP Help.
is there any official statement if NSE is support also for BW on HANA?
NSE can only be used with DTO, which is a BW4 feature only.
did you hear something regarding NSE for SAP BW on HANA?
I hope that I will receive information on this: https://answers.sap.com/questions/13113772/bw-sap-hana-data-warehousing-1.html
NSE can only be used with DTO, which is a BW4 feature only.
Could you please advise on using Data Lifecycle Management on HANA Cloud?
We recently learned that Data Warehousing Foundation addon is not supported together with it's Data Lifecycle Management component.
We are looking for an alternative way to automate data cooling towards cold store on Azure.
DLM is not supported for HANA Cloud. Plan is to build similar functionality into HANA Cloud (built-in) in 2021. No committed timelines yet. It will be listed in HANA Cloud roadmap when committed.