FlashArray and SAP HANA with Native Storage Extension

With the release of SAP HANA SPS04 a new data tiering option, Native Storage Extension (NSE), has been released to assist in further lowering TCO for large data footprints. This feature greatly enhances scalability by setting moderately accessed read-only information to be provisioned in a “warm” location, separating the tiers into frequently accessed critical in-memory (hot) and infrequently accessed (cold) data with NSE between them.

Using this feature, FlashArray//X is capable of offering more to organizations as because it can provide near in-memory response times when using NSE as a warm store (observed average SELECT query performance difference is 0.00041 milliseconds for 50% or 0.00149 milliseconds for 100% of data in the tier compared to all data residing in-memory). The end result is that lower cost can be achieved with similar performance using a storage platform architected for this scenario.

SAP HANA typically requires high performing and low latency storage for the data and log persistence areas in order to maintain the exceptional response times for OLTP and OLAP workloads. FlashArray//X, Pure’s all-flash, enterprise end-to-end NVMe array already pairs well with this in-memory data platform due to the low latencies it can deliver while offering rich data services to help organizations focus on their core business objectives.

Taken from SAP’s public material NSE is shown to live alongside other existing solutions such as extension nodes and dynamic tiering offering organizations a more flexible landscape in which solutions can be deployed.

SAP Native Storage Extension Offers More Flexibility

Configuring Native Storage Extension

Any organization or existing SAP HANA landscape can easily configure and explore NSE by creating or reconfiguring database objects such as column tables (row tables cannot be configured to use this feature), partitions and indexes to be “PAGE LOADABLE” . When not specifying database objects to be page loadable the default configuration will be “COLUMN LOADABLE” which specifies the object to be located in-memory or the “hot” data tier.

Here is an example of a normal table declaration :

CREATE COLUMN TABLE SITES (SiteID INT);

Now to create the table and ensure it resides in the warm data tier :

CREATE COLUMN TABLE SITES (SiteID INT) PAGE LOADABLE;

Or altering an existing object :

ALTER TABLE SITES PAGE LOADABLE IMMEDIATE CASCADE;

Benefits of NSE and FlashArray//X

When data growth occurs over time with any system the result is typically an increase in hardware costs. This is especially true for SAP HANA as additional compute , memory and storage must be taken into consideration. With NSE and FlashArray//X a substantial increase in SAP HANA data capacity can be achieved with minimal impact on performance, lowering TCO and allowing for additional flexibility.

Performing an evaluation of NSE with FlashArray I attempted to showcase the differences when comparing SELECT query performance with different configurations. This was done by using two different scenarios :

All tables and partitions set to be “COLUMN LOADABLE” with no indexes
50% of tables and partitions set to be “PAGE LOADABLE” with the remaining being “COLUMN LOADABLE”

The schema was made up of 64 tables with 500GB of column table data on a single host with 768GB of memory. The FlashArray model used in this evaluation was a FlashArray X70 R2.

FlashArray//X R2 storage is certified by SAP to serve up to the following node counts per model:

14 nodes per //X10 R2
22 nodes per //X20 R2
30 nodes per //X50 R2
38 nodes per //X70 R2
44 nodes per //X90 R2

Inspecting the “M_CS_TABLES” view after table creation allowed the identification of tables set up to be “COLUMN LOADED” (in memory data) or “PAGE LOADED” when querying the LOAD_UNIT column :

Results

Queries were run over the schema using 64 parallel independent user threads and a complex set of joins and subqueries to unify the tables and retrieve data in both hot and warm data tiers.

The scenarios created for evaluating NSE were the following :

All tables in-memory (the default option of COLUMN LOADABLE)
50% of tables specified to use NSE (PAGE LOADABLE)
100% of tables specified to use NSE (PAGE LOADABLE)

With the above results we see that when comparing each scenario there is minimal degradation (7.97%) when applying the PAGE LOADABLE option to half of the tables and only slightly more (28%)when all tables are in the NSE tier compared to all the tables being in memory. The trend also identifies that once warm data has been retrieved it becomes more intelligent over time and query speed improves for future operations.

Also when monitoring disk activity through the iostat tool while the above evaluation areas are running, disk activity for the operating system is shown to scale with the amount of tables configured to use NSE :