Data Tiering Options in SAP HANA Webcast Recap
This was another great SAP User Group webcast this week.
Data tiering introduced to help manage data growth in SAP HANA
Data is rising, increasing costs, additional hardware, additional license volume
Data tiering manages data in cost efficient way
Native storage extension, a new feature
Mission critical data is in Hot (main memory tier)
Data not as critical; certain aging aspect, older data becomes less important; not accessed as often, performance not as critical as hot data
Cold data – old, voluminous (data lakes)
DRAM – main memory for hot data, need performance there for most important data
Persistent memory – like DRAM, available in larger sizes
Warm tier – 3 technologies – dynamic tiering, extension node has been around for a while
Native storage extension is a new feature introduced in April
Cold store – nearline storage for SAP BW been around for a while, before HANA
Hot Store, Persistent Memory
Developed with Intel
Persistent memory – replaces some DRAM – compared to DRAM it does not lose its data; if shut down database, and restart, persistent memory doesn’t take as long to reload data compared to DRM
Reduce total startup – from 50 minutes to 4 minutes
Increased memory capacity
DRAM – 128GB sizes, some 256 – prices increase; most common is 64GB
Persistent memory is available in larger sizes – 128GB, 256 GB, 512GB; cheaper than DRAM (per TB)
Also known as non-volatile memory
Two operating modes – memory mode, application does not need to be changed; still need DRAM on server, DRAM acts as cache, address data volume of persistent memory
SAP HANA – app direct mode, take advantage of technology, application will need to be changed
Application will have DRAM available
Direct access enabled file system
Column store main in persistent memory
Column store delta stored in DRAM
Size your application to handle workload
This is an example
Different ratios possible
Impacts on data tiering
Separates storage tier
Can keep more data in HOT with persistent memory
Not a data tiering solution but impacts it
Warm Storage, Native Storage Extension
Simpler landscape, integrated into server of SAP HANA
SAP HANA Cloud Services – NSE is a strategic role
Plan to make available for any SAP HANA application
Complement to other data tiering solution
Strategic solution is NSE
Column loadable is default
Declare partitions to page loadable
Access data on NSE will load little as possible
Buffer cache – configurable size, to buffer to pages in main memory
Define a whole table as page loadable
Can do on partition level (with data aging)
Sizing and limitations
Soft limits, hope to lift limits soon, hope to before SPS05
Size of buffer cache recommendation is shown above, according to SAP’s experience
Tools for NSE include HANA Cockpit
Recommendation engine – can activate in HANA database to monitor query patterns executed to help you decide what is warm and partition; first step to automate data tiering in SAP HANA to make things easier
DLM is planned later this year
Warm Store new feature
Getting started with warm store
NSE is limited to 10TB; plan to extend, plan to come close to what dynamic tiering
Which options to use
Data Lifecycle Management
Q: Will data aging in Suite on HANA automatically move warm partitions to NSE?
A: Default SPS04
Q: Persistent Memory concept is available in SPS03 or not
Q: Is it Appliance dependent?
A: Yes, some hardware dependencies
The link to the recording is here.
As is understood Native Storage Extention as an option for Warm Tier base on Page-loadable columns which we define for columns, partitions or tables.
can we consider such enabled page-loadable columns or tables in the warm tier as an extended table or multi-store tables? I mean after deployment multi-temperature option for a specific table and deploy NSE for warm tier, can we consider our page-loadable columns or tables as an extended or multi-store table like the type of tables in warm partitions in dynamic tiering?
Also in NSE, can we say buffer cache in memory is part of warm tier?
Hi Arash -
Thank you for your comment.
We just implemented SoH, so I am not an expert in this area. Would you please ask this as a question at answers.sap.com? Thank you
The term "multi-store table" is exclusively used in the documentation to refer to a partitioned table splitting data between in-memory HANA storage and disk based storage using HANA dynamic tiering. In that context the term "multi-store table" only applies to DT.
From a conceptual standpoint, data can be assigned to be PAGE LOADABLE at a table, column, or partition level and a single table can have data that is in-memory COLUMN LOADABLE and disk-based PAGE LOADABLE which is the same modeling concept as for a multi-store table with DT.